In my last blog posting I talked about how to prioritize automation improvements for SaaS and Cloud services.  But how do you decide what automation or other service delivery improvement features should be  completed relative to other new functionality features?

For on premise software this is the process of managing what is in the next release including bug fixes but with services it is much more fluid and some service improvements may not be directly part of the core software.  Typically what features go into a service is totally controlled by the product manager.  This may not give the best overall results and the organization needs a broad and multi-department view to make the best decisions.  The product manager definitely needs to be accountable for the overall service but may not understand or know about some of the service delivery aspects of the service.  A product manager can’t be expected to be an expert in everything.

The way that I’ve seen this successfully addressed is to make sure that there is a commonly known and maintained list of desired improvements and changes to the service.  Any part of the company should be able to contribute to the list.  The potential set of improvements should be well understand by key group of leaders from across the organization and it usually makes sense to have this be at least a semi-formal group that meets regularly.  This group is charged with selecting the service changes which will have the most value to the company and customers.  They will need to understand the list of desired changes, the rough cost and ROI of each, have the ability to assign resources and have the business perspective to make the priority judgements.  Leadership of the group should ideally done by the product management group or product manager and some process for  making decisions needs to be in place particularly in the case of controversial issues.

This approach avoids the problem of certain groups not being included in the recommendation and selection of service improvements and provides a way to make a true business decision about the important changes.  Without an approach like this often the operations, implementation group, and customer support team input can get ignored.  Likewise the key new features needed to be competitive in the long run can end up being set aside for what is needed to compete for the current new deal.

Some of the dangers that need to be avoided in this approach are to make sure that the customer’s input is well represented and that the decisions made are truly followed.

This type of approach works well within an overall process for deciding on major new services and initiatives and within whatever development methodology that is in place.  Without a team based approach like this the service delivery staff can feel that their input is being ignored, good ideas don’t get the attention that they deserve, and customers don’t benefit from the collective wisdom of the whole organization.

Paul