The Influence

“Make a plan, stick to the plan, always deliver!”

From the movie Storks. Originally by Hunter, then Junior.

“No Plan Survives First Contact With Customers”

Steve Blank, borrowing from Helmuth von Moltke the Elder

The Dilemma

• Was writing the training course procrastination for completing the book?
• Or was it a perfectly appropriate response to changing customer needs (and potentially aiming for a different market)?

We’ve all had similar issues. Do we continue with on the current direction or do we turn and pivot to a new direction? We’re left with a feeling of Fear of Missing Out whichever we go with, not knowing which would have been the better option.

The issue is that there’s very little to help us decide which. We can run many analyses, we can apply rules that we’ve read from industry-leaders (and for every rule, I can probably find someone of interest saying the opposite) or we can go with gut feel. Daniel Kahneman’s output would probably indicate that it’s as much about gut feel first, then the logical brain kicks in to rationalise the decision.

However, note that there’s one angle that didn’t fully enter in my calculation; the amount of time and effort that I had already committed to the book. Basing decisions on sunk cost is flawed decision-making. 

What matters is how much effort is required to complete.

What also matters is getting something complete.

I can imagine a world where everybody ignores sunk cost (as they should), but then nothing ever gets completed. That’s an extreme situation, and fortunately not likely to occur. Even when not taking into account sunk cost, there are many occasions where the current course still delivers quicker and with less effort than changing.

The Reality

So why do so many stakeholders induce change in their projects?

Do they think that their sponsored changes, in terms of setting a new direction, will deliver better results than supporting the project to deliver on its current course?

Often, I say yes, that is their opinion. And it’s not necessarily wrong.

What’s missing though is the misunderstanding of how long it takes an organisation, its suppliers, its partners and its customers to adapt to the new direction. Imagine having a cup final of whatever sport you like, with two world-class teams, their entourages (cooks, cleaners, physiotherapists, etc), a stadium with assigned personnel and services (many 3rd party), supporters with travel arrangements (again many 3rd party arrangements including coaches, hotels, restaurants, etc). Now imagine changing something about that event. Even a minor change will involve a significant number of messages, assuming that it can be unilaterally decided. More likely, decisions would be multilateral and hence would include discussion and negotiation.

The Expectations

Many enterprise changes affect a similar number of people, especially when we consider customers and the whole supply chain. Despite promises of agile methods for delivery, talking to 20,000 people about a proposed change is cumbersome. It can be designed to be less problematic and require less effort of those affected, but that can only be done when there is time to plan in those changes. That planning and alignment may have to happen in parallel to the development of the product/change. Hence why continually changing development aims can cause confusion for end-users and other stakeholders who may have to plan their business around the changes being provided to them. That last part is the real symptom of this. At the root is a lack of empathy for the customers. After all, if it’s not to make the lives of its customers better, why does any organisation exist? Making their experience worse by changing dates, functionality, expectations is not in their interest and definitely not in ours.

Even though many turn against Gantt charts, they were one type of diagram that allowed us to understand dependencies. There are other diagrams and methods. As long as one of them is being used, I’m happier. Where no dependency mapping is adhered to (and this includes rawer agile implementations), I’m less comfortable, since I see the risk to end-users increasing. That half-day change, maybe even a few days of development change, can result in additional weeks of implementation change, maybe months if the implications of the change are ignored.