What is it that IT does? What if I said that IT Operations does only 4 things, well more accurately, 4 types of work? And by understanding the types, their relative importance and how work flows through the organisation you will be better equipped to improve the delivery of projects, manage outages and compliance, and limit work-in-progress. I recently encountered this idea while reading the book “The Phoenix Project” and I must admit the concept has really sparked my interest.
So what are they? No, one of them is not email.
Well it should come as no great surprise that the first one is Business Projects. You know, those projects that the business is screaming for, those projects that have a direct link to business processes and tie to the outcomes of the business groups. In essence this is all the business is really asking IT for.
The second is Internal Projects. Installing a fleet of new network devices, decommissioning a data centre, and any number of other internally focused system based activities. The problem with many of these projects is that all too often internal teams are left to manage them independently. They progress with little oversight or visibility and consume untold amounts of resource, which will often adversely affect progress on Business Projects. We have the PMO managing Business Projects, but who manages internal Projects?
So projects are generally classed as larger pieces of work, but we all know IT does a lot of little jobs to keep systems functioning. Patching, security upgrades, vendor software updates, problem resolutions etc. All of these, and many more, make up a third category of work, Operational Change. Every day IT operations will be registering, planning, assessing, building, testing and deploying changes, which may also include managing the process to deploy a change that relates to ether of the project types above.
And lastly the killer, the work that keeps Operations Managers, Service Owners and other IT folk awake at night. This type of work has the ability to put everything else on the backburner, which can then affect the delivery of projects, the deployment of changes, and any other work that IT may be attempting to deliver. Unplanned Work. Unplanned work is recovery work, which almost always takes you away from meeting your goals.
Why is this important?
Well unless you have a strong understanding of each of the work types being undertaken in your organisation, you can never hope to truly manage it. Many of the organisations I have worked with in the past would generally assign one prioritisation to business projects, and a second prioritisation to internal projects and so on. But often the organisation is doing all that independently of each work type, simply because they don’t see them all, and don’t understand the relationship of each of the work types. These organisations didn’t have a great understanding for the overall work that was being committed to by the organisation. If you can’t see it, you can’t manage it – let alone organise it, sequence it and be sure that your resources can complete it.
If you have identified that each type of work shares common resources at the very least, you will then see how important it is to plan work across the work types and to identify sources of unplanned work, implementing action plans to eradicate them.
Understanding the way in which work flows through the organisation is a valuable start to coordination and will also help uncover constraints along the way. IT should be operating at a speed that meets the needs of the business. The Service Portfolio should offer some guidance as to the required cadence of each service offered. This may be fast when being early to market is key, or developing in high cadence environments. Or it may be slower where high risk exists and the need for bombproof stability is a requirement. Either way we need to ensure the way workflows from development to operations is managed to ultimately deliver value to the business.
This knowledge of work types also has the potential to help with developing an understanding of demand and addressing resource demand issues, identifying constraints and developing strategies to mitigate the affect of one or more constraints and in identifying the value a given work type or task has to the business.
Demand Management and Workload Management.
Once the way in which work is generated and flows through the organisation is understood, we then need to develop mechanisms to control that flow. We need to understand the impact of work-in-progress and be in a position to prioritise work across each type.
The Theory of Constraints, Lean production and Total Quality Management all talk about work-in-progress as the silent killer. The quantity of work-in-progress will directly affect cycle-time, the more work you are currently undertaking the greater the required cycle-time to complete each task. In the manufacturing industry this is known as Little’s Law. Therefore one of the most important mechanisms to get right is how you release new tasks, where they go and at what frequency, and take into account the entire value chain and it’s ability to deliver, not just the next step in the process.
Our Demand model above identifies the triggers for work across the different work types, and models the flow of activity through to the allocation of tasks. Once work has been approved to proceed, either via Demand Management or through an operational process, it is then added to the backlog to be scheduled in a prioritised order – this would be a good opportunity to add the work to a Kanban backlog. Priorities are derived from from Service Levels, Project Plans, Change Schedules and other sources, but regardless the impact of work-in-progress for all tasks currently in progress should considered prior to the release of any new tasks.
It is also equally important to limit the size and scope of each task. Agile development practices identify that it is far more productive, and more conducive to better quality outcomes, to release smaller more frequent packages than it is to release a single large package. I think this topic is deserving of its own blog in the near future.
Using techniques like Kanban is a good start to delivering a visual representation of all work across the value chain. Kanban offers a view across the entire value chain so you can see all work-in-progress, and use that to control the release of new work, taking into account the backlog currently being addressed by each resource.
So where to from here? Think about how your organisation is currently dealing with work-in-progress, how does it affect the overall delivery of your services? Investigate Kanban further; Kanban by David J Anderson is a great place to start. It is also worth delving deeper into both DevOps and Agile, as they both contain a lot of the foundation for this thinking. There are a number of free DevOps books on Amazon for download.
This is still only touching the surface, I have already started writing a second part to this blog that talks more about Theory of Constraints, Social Capital and other ideas. Please join the conversation by leaving your comments below, or feel free to contact me directly.