So you want to improve your service? The chances are you make improvements by getting approval for projects to be spun up and deliver some change. Doing so though runs the risk of reinforcing bad behaviours, wasting money and creating a bloated product. Why should making improvements be that structurally different from running your business?
ITIL described operations as the ‘day to day management’ of the service. Historically, the closest operations that came to product changes was acting as a gatekeeper, exerting the only control they had, that being the go/no-go sign-off. They were stuck with the un-pleasurable task of weighing up the appropriate risk to the business against the desire to release value. This would mean often imposing their own batching on the release cycle in order to make their own processes more efficient, and that would come at the detriment of the overall lead time.
Projects by their very nature are temporary; as opposed to running your service, what they deliver, as the PMI says is, ‘unique in that it is not routine in operation’. Projects can be difficult to find funding for and get started on, it’s no wonder the scope ends up larger than needed. The results are a poor return on investment, as a bloated scope includes unvalidated and low-value items which were in truth not needed. The effort and associated delay to get projects off the ground is often referred to as the ‘fuzz front end’; if you measured your cycle time from idea to start of work what would it be? Weeks, months, or even years?
going live is the beginning, not the end
By moving to a service-aligned management approach, very much like the UK government is undertaking, going live is the beginning and not the end. Service managers are given a budget to do the initial build, and then run and develop the service. They take on the combined oversight of product management and operations while focusing on the customer need.
What should you do?
Align, budgets, people and resources around your services
It’s likely you fund your service today by having a budget line item for the operations and low-level continuous improvement. Then in addition to using projects for improvement activities, on top of this, you are creating new teams running under separate governance, potentially working at cross purposes. Consider how changing to closely aligned teams, that can flex in size, growing or contracting over a period of time based on the current demand could help build a cohesive service.
Move people, even if only in a matrixed way, to work on your service and not be split across many activities. This change results in less task switching, and therefore better productivity and more buy-in for the work. It is easy to pull together if you are all heading in the same direction.
Instead of large pots of money, look to use an incremental funding model. You can then initially limit the time and capital spent exploring and validating before going on to create what some might refer to as a Minimum Viable Product. Working this way also makes the decision to stop easier.
Have a common backlog
Your objective is to look holistically at what you are delivering. This means merging, at a relatively granular level, the improvement ideas that would have traditionally been in the different projects and continuous improvement backlogs. Firstly, it allows you to have a ‘stand-back’ view of what is needed and then blend the changes, like a good winemaker, to create a coherent solution. Secondly, it has the benefit that low-value or unvalidated ideas are pushed to the bottom of the pile.
Operating using the concept of pulling work from the top of your backlog, you can also aid alignment across disciplines; there is no value if IT delivers, but the people on the ground haven’t been trained.
Have appropriate metrics for improvements and running the business
Broadly speaking, there will be two sides to your business: the day-to-day operations and improving what you do.
Broadly speaking, there will be two sides to your business: the day-to-day operations and improving what you do. Look at what ‘outside looking in’ metrics are right to describe how well these functions operate. If you can describe numerically how your customers perceive your business, are you more likely to be able to please them? Broadly you will have measures like lead and cycle times, frequency and failure demand, in addition to items specific to your business.
By moving to a product and service-oriented structure in your organisation, you find the focus moves to making great products and services your users want, instead of running projects well.
Your service is not operating in a vacuum, so don’t make improvements in one either.