Decisions

If you could travel back in time and change one thing in a delivered project, what would it be?

I spent my last two years working on a major digital transformation project. The project was delivered using at its peak a project team of about sixty team-members, organised in nine teams across two geographical locations. We’ve used Kanban, ran a #NoEstimates approach and relied heavily on Lean product management concepts.

It was what I consider a fairly successful project. We delivered regularly working software (deploying to production multiple times per week), we engaged well with the client, we learnt and got things done.

As the project ramped down for me, it felt natural to look back and reflect. Were we as successful as we could have been? Could we have done more? What was the ‘one thing’ that done differently it would have made the biggest impact? That one thing.

Maybe the question is not the right one, maybe you should not look for only one thing to improve and maybe improving loads of small things creates that significant impact. If you would tell me that I wouldn’t disagree with you, however I was determined to find the most impactful ‘thing’.

I spent quite some time thinking about it. Could we have tweaked more our Kanban method? Could we have had more collocated Product Owners? Could we have identified our risks sooner? Yeah, maybe all of the above would have helped, but none of them would have been the ‘one thing’ I’m looking for, the one thing that would have made the biggest impact.

After a number of sleepless nights, it dawned to me — that one thing that would have made the biggest impact was a better decision making process. OK, just kidding on losing sleep over it …

Throughout a day hundreds of micro decisions were made. What should I build first, this story or that story? Should I start a new story, or should I do a bit of refactoring? When should we release, today or tomorrow? Is this story really needed for this release, or can it wait for another release? Can it wait another fortnight? Which feature should we build first? Do I need extra people for the user research, or what I have is enough?

For a project of over five hundred working days, with a team of around sixty members, that amounts to a lot of decisions.

With so many decisions, it was not surprising that some of them were not understood by the wider team, some were disputed, some disappointed. And, at times some wrong decisions were made.

Decisions are triggers of our actions. We act based on what we decided. Take a wrong decision and you create a lot of wasted effort. Make a decision that is not well understood and you have a lot of displeased team members whose morale will be negatively affected. And that had a significant negative impact.

So how can we make better decisions?

First of all, we need to understand when we are really in a position to make a decision. Ronald A. Howard, quoted by Sam Savage in his book “Flaw of Averages”, put it succinctly:

The three elements of any decision are alternatives, information and preferences.

Like a three legged stool, if any of these is missing we don’t really have a decision .— Ronald A. Howard

This is an important aspect to acknowledge. Paying attention that all elements are present in the decision making process is key. All too often decisions are made on preference alone.

Assuming that we are in position to make a decision, then how can we improve the decision making process?

Making all the decisions centrally by a person or a group of people it is just not feasible.

What about defining all the rules upfront and giving each team-member a rule book? This approach doesn’t seem too appealing either. The rules would impose too many constraints, likely they would not be exhaustive (could you define all possible instances of action?), hard to maintain and difficult to introduce at scale.

How about a heuristic based approach? Daniel Kahneman in his best-seller “Thinking, Fast and Slow” defined heuristics as “a simple procedure that helps find adequate, though often imperfect answers to difficult questions.”

Dave Snowden talks about the use of heuristics in a Cynefin context [2]. He cites the US Marines who rely on heuristics when the original battle plan breaks down — “capture the high ground, stay in touch and keep moving”.

A good heuristic should be easy to comprehend and easy to measure compliance with it. For instance, in the US Marines case it is easy to measure if the heuristic was followed or not — ‘have you captured the high ground?’ This is an easy assessment.

The goal of each project then would be to define a set of heuristics specific to its context. Once defined they would form part of the team’s doctrine (in the same way they are part of the US Marine doctrines) and teams would use it to derive decisions.

As an example, a set of heuristics could look something like this:

• work only on items which are part of your work-in-progress.
• work on the oldest work-in-progress items. Therefore, before we start working on a new item we check the age of all the items. We select the oldest one we can deal with.
• value buying information, but understand that cost of gathering the information should not exceed the value of the information itself. Therefore, in face of uncertainty we seek ways to reduce it by doing first the activities that will give us the information (as long as they are in WIP).
• value cost of delay over solution purity. Therefore, we will prioritise activities that will give us the fastest route to gain benefits.
• question why we are doing the work. Therefore before starting any activity we ask ‘why’ are we doing this?

We will be able to easily measure if we followed the heuristic or not, if we are compliant with it. For instance we can ask ourselves, “have we worked on the oldest work-in-progress item”? This should be a very easy question to answer.

As Daniel Kahneman stated, heuristics don’t offer guarantee of success in all situations. Equally, in the US Marines case by following the heuristics success won’t be always guaranteed. However, what heuristics offer is an ability to move forward in a coherent fashion — as long as all team-members use the same heuristics they should arrive to the same decision, understand how and why the decisions have been made. If the heuristics stop working, then they would focus on finding new heuristics.

And don’t forget about the three legged stool. Maybe you are not even faced to make a decision.

Yeah, if I could go back in time this is what I’d change. I’d look to improve the decision making process. I can’t go back in time but I will have a chance to do something about it in a new project.

These doodling mean nothing of course. I did them unconsciously while making some decisions.

[1] Sam, Savage (2009). The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty

[2] http://cognitive-edge.com/blog/cynefin-dynamics/