Business users’ demands on IT are fairly constant – as is the tension between the two. The business wants to do things quickly and cost effectively so that they have a competitive advantage. IT, meanwhile, wants to maintain control and proceed carefully to ensure security, performance, and service quality – which are table stakes for running IT.
The goal of IT as a cloud provider is much the same: to meet the business requirements in as efficient a manner as possible while still maintaining the control it needs. This way, the business user (now known as the cloud customer) gains the trust of the cloud provider and has no motivation to bypass IT and take on 3rd party “shadow IT” cloud implementations (i.e. removing its “IT overhead”, but leaving no control or policies in place).
So far, so good. But how do you get there? This post details a process for service initiation that, based on our experience with a variety of customers, allows IT to offer the business the services it needs without it having to resort to playing in the shadows.
Think of the process as a (hopefully, not too dramatic!) story in four acts.
Act 1- Outlining the Service
First, of course, you need to define the services you will deliver.
Just to be clear, by ‘service’ we’re referring to the creation of something that will ultimately be offered from within a portal and that end users will then be able to deploy. So when a business user has a requirement for a new service, it’s the responsibility of the customer relationship manager to have the conversation with them to understand exactly why (from a business point of view) the service is required, and what the service will look like when it’s been implemented.
The customer relationship manager (as we’re defining the role) will document this information in a service proposal, detailing things such as business benefits, financial benefits & costs, risks, organizational considerations, service overview, high level service requirements and high level functional & non-functional requirements.
Act 2 – Enter the Service Portfolio Manager
On completion, this proposal & business justification is handed off to the service portfolio manager for review. This is essential, because the service portfolio manager is in the unique position of having a full overview of the current portfolio of cloud services – including services that are in the pipeline (i.e. either being built, or planned to be built), services that are currently live and are being offered from the cloud service catalog for customers to deploy, and services that are no longer required and that have been retired.
Additionally, if the organization is of a reasonable size, it is very possible that a number of customer relationship mangers, each with their own set of cloud customers, are documenting and passing on their own ideas for new services to the same service portfolio manager . The service portfolio manager, then, is uniquely positioned to view all the new services that are being requested from all the cloud customers, and thus notice those with similar requirements that could be combined into a single service offering.
So now the service portfolio manager has:
- The service proposal & business justification,
- Knowledge of the current portfolio of cloud services
- Knowledge of other requested cloud services
That means he or she is now in an excellent position to make a decision on the service proposal.
It’s quite likely that service portfolio managers won’t make that decision in isolation (although they may). They may seek advice from different individuals depending on the service proposal, its requirements and any potential impact on the cloud implementation (it may have huge capacity requirements for example). There could also be executive sponsors to consult, business unit managers, the tenant operations leader, a project stakeholder board, etc.
Act 3 – The Assessment and its Aftermath
Now, though, comes the assessment. For that, we’ve established that the service portfolio manager needs to look at 3 considerations:
- Does the business justification stack up, and does the service portfolio manager think the benefits detailed will be realised?
- Does the service portfolio manager think the service requirements can be fulfilled by the cloud implementation they are managing the portfolio for?
- What is the demand for the service, both today and in the future, and does this demand warrant providing the service?
When the decision is made, if the service proposal is rejected, then the customer relationship manager will need to inform the customer and work with them to decide whether to move on, or review and update the proposal.
What they decide will likely depend on the feedback provided by the service portfolio manager as to why the proposal was rejected. For example, if the business case doesn’t stack up, then the service may be dropped. But if there are specific requirements that couldn’t be fulfilled, then a decision may be made to adjust the requirements so they can be satisfied.
If the service portfolio manager approves the service, the next decision to make is whether the service is required now, or whether this is a service for the future. Future services, like those that depend on future cloud capabilities, are placed into the service portfolio pipeline until the service needs to be created. This service portfolio pipeline now becomes your road map of cloud services and will develop in maturity, providing you with a good view of how the cloud services will change over time.
Act 4 – Assigning the Service Owner
The final act in the cloud service initiation process is to assign a service owner for services that are approved and that are required now. The tenant operations leader assigns the service owner to the service, and from that point forward the service owner is responsible for the overall life cycle of the service from definition to creation, to release to maintenance, to retirement and all points in between.
To recap, here are the four steps to service initiation:
- Outline the service
- Hand off to the Service Portfolio Manager
- Do the assessment
- (If it’s a go), assign the service owner
Stay tuned for the sequel, where Khalid Hakim will start discussing how best to approach defining your cloud services.
For more information, see the related webcast by David Crane and Kurt Milne, Service Initiation: Understanding the People and Process Behind the Portal.
Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
Note: This blog uses the roles that are part of the Tenant Operations organization as described in the VMware white paper, Organizing for the Cloud.