Progress iteratively – why “baby steps” are better than all or nothing

Progressing iteratively means that changes (in effect, smaller changes) are easier for people to stomach and you’ll get a better level of engagement. Also, if you get something wrong in process change, the size of the error is less impactful. Taking baby steps gives you the opportunity to make small changes, see how they work and adjust accordingly.

Progress iteratively is one of ITIL^{® Practitioner's 9 Guiding Principles} – it’s also something I refer to as "baby steps". Clearly, this depends on the size of the “baby” and the business problem you’re trying to solve.

For example, baby steps for a small organization with few people and low complexity could be a “big bang”. Conversely, a large organization with many stakeholders and people resistant to change is a different proposition and requires a baby-steps approach.

Therefore, you need to keep revisiting the central business problem to identify areas where you can affect change by playing to people’s agendas and organizational politics – baby step by baby step. If you can understand the problems faced by influential people – and help them to achieve their outcomes with the right solution – you can sell any process change.

In an agile world, the rate of change means our business improvements must be fast-paced. However, any approach should be about taking deliberate steps to realize benefits and address business problems that are drivers for the processes in the first place.

An iterative approach is a safe bet and doesn’t have to run counter to an organizations’ sense of urgency for everything. While there are times when hard dates are required for change projects (to meet regulation, legislation or protect human life) everything else is perceived urgency.

In the example of working with one company to introduce best practice incident management, we introduced mechanisms to help prioritize incidents according to business impact and urgency. However, in the absence of a defined service portfolio, service level agreements and a lack of mature process in areas such as configuration management, combined with a changing team environment and a high rate of change within the organization it was hard to gain a true understanding of business impact.

So, in a second wave of development it’s been necessary to be very specific about the problems they want to solve and embed the right process activities to solve just those specific problems. In essence, taking baby steps.

This involves asking the question “what do you want to solve?” and creating a gateway to ensure that issues are solved before moving forward. For example, having introduced change management we are now looking to release management. But rather than introducing the entire process and a full suite of templates, we’ve had to recognize that different parts of the organization do things differently and have different requirements for release management. Some parts of the organization release regularly using an Agile approach, whereas others use a more traditional waterfall approach for bespoke single phase projects. In order to ensure that we address the business problem that we’re aiming to solve with release management, we’re introducing gateways rather than standardized process to ensure that the elements of the process have been met.

Taking ITIL Practitioner’s focus on Continual Service Improvement (CSI), it’s about continual service improvement of processes and practices as well as an approach to change overall and ensuring that processes are addressing real business problems.

To be effective, meet budgets and manage scarce resources progressing iteratively and focusing on business problems is the way to most safely add value either as external consultants or as an internal IT organization.

How to plan for major incidents in ITSM

How to prove effectiveness and value in ITIL^®

4 steps to getting the most from managed service providers

The modern service desk