Responding to Change

“Plan the work and work the plan.” Who hasn’t heard that phrase at least once in their life? The idea is that you come up with a plan, then execute the plan and see amazing results. “No plan survives first contact with the enemy.” Not as many people know this quote, and even fewer see how it may apply to project management.

This comes back to change management in project management. Once the plan is in place and working the classic approach is to limit change to the plan. There are many reasons for this. For instance, the plan in place was approved by everyone involved. There may be budgetary constraints preventing anything additional. There could be regulatory concerns with doing things in a different manner than was approved. In some cases, momentum is the problem. The organization may just be unwilling to put in the work needed for a shift in direction as opposed to allowing everything to continue in the direction it’s already moving.

This brings us to the second phrase, the one about plans not surviving contact with the enemy. In this context the enemy is often the customer. Sometimes it’s the team itself, and in many cases the work being done becomes the enemy. The enemy in these cases works via the “known unknowns” and the “unknown unknowns.” As we get further along in the project we’ll be able to fill in blanks that we couldn’t when the project was just starting out. We answer questions we didn’t know the answer to at the outset, and that may cause us to change our approach a little. Because we know this would happen, there may be room for this type of change in the plan. If it requires too big of a shift, then there won’t be though. The real problem is the other one, the items we discover partway through a project that nobody saw coming, like an asteroid emerging from behind the moon. When something like this comes along the approved plan often shows its limits.

The great balancing act is knowing how tightly to stick to the plan. There needs to be something everyone is working towards. That goal, and the progress towards it, must be flexible enough to handle both known unknowns and unknown unknowns. This is where the value of responding to change over following a plan comes in.

Instead of putting a strict change management process in place, Agile methods acknowledge that change will happen and put processes in place to increase flexibility and reduce long-term lock-in. The most common form this takes is a backlog of items instead of a Gantt chart of tasks.

The classic Gantt chart maps out every task a project needs to be completed. The tasks are derived from spending a long time breaking down the desired product to smaller and smaller pieces in meetings. The problem here is when the project is underway and more tasks are found or some tasks become irrelevant. The new knowledge means the plan has to change.

With the backlog of item approach the product is not broken down into all of its tasks immediately. Instead, it is broken into major functionality and ordered by importance. The most important items, traditionally at the top, are broken down to tasks and immediately worked on. While they are worked on the next most important item is broken down so it is ready to be worked on. If some functionality is deemed irrelevant it is simply removed from the list, the tasks never created. If some new knowledge comes up requiring a set of tasks immediately, they are added at the top of the list.

I know what you’re thinking, how can we plan in this environment? It requires shifting the thoughts on the iron triangle. Instead of trying to fix scope, budget, and time – which never actually works – you fix budget and time and let the most important scope continually bubble to the top. As a project progresses the speed at which features are delivered will form a pattern and planning will become easier and easier. In fact, instead of guessing how long everything will take from day one the team generally will guess at only the features at the top of the list, and their guesses halfway through the project will be more accurate than their guesses at the beginning.

Bringing the values found in the Agile Manifesto for Software Development to your project often means embracing the complexity of the modern world and finding a way to work with it instead of against it. There are many ways to implement these values, found in many of the various methodologies around agile work in the market today. The most successful agile implementations often start with a methodology or framework, learn how it works, get ok at using it, then start to customize it to their environment. If the customization is done to more closely align with the core values of the agile manifesto then often the implementation gets better. If customization is done to more closely align with how things “have always been done” then the implementation is ripe for failure.

If you’d like help integrating the values in your organization, contact me here and we’ll have a chat about what that might look like.

While this wraps my latest look at the value statements on the manifesto, I do still plan to go over the principles before the 20th anniversary of the manifesto. Stick around and lets continue the journey together!