There are many people in this world that I am indebted to, but Donald Rumsfeld, US Secretary of Defence, was never one that I expected! But alas, it’s true.
I have been working with a client on explaining the concept and management of Uncertainty. I write Uncertainty here with a capital as I would like to differentiate it from the generic use of the word in the same way Agile is often stated. There are many definitions of what Agile thinking is all about, but here at IndigoBlue we consider the three pillars of Agile as collaboration, incremental delivery and Uncertainty management. So, understanding Uncertainty management is pretty fundamental.
And yet it’s pretty hard to get your head around. I say that because a few years ago, I was in a room full of colleagues trying to define what we meant by Uncertainty. Coming up with something we all agreed on was a real challenge and after a number of hours of heated debate we came up with ‘an unanswered question’. I am not sure any of us were terribly happy with that, but considering the amount of blood on the floor at that time we considered it a compromise we could all live with for now. This is where Donald Rumsfeld can help, and you will soon see why.
Not only that, there is significant ‘confusion’ with project risk, the uncertainty (notice the lower case in this instance) of the generic project unknowns and the change that we constantly face. All of this adds together to make Agile projects look quite daunting for those that lack courage. So, I decided that there needs to be an understanding that extends past just the definition of Uncertainty.
Let’s start with the collective concept of Project Variance. I am defining this as everything that can change within a project. It’s a good start but pretty vague without further definitions. So, I have said that Project Variance comprises three distinct factors. These are Risk, Change and Uncertainty.
Probably the easiest to define is Risk. There are many definitions but the one I use is something that has the possibility of happening what will have a detrimental effect on the project. I think the key factor here is ‘possibility’. It may or may not happen. For now, let’s just think of this as the standard risk challenge every project faces and we can deal with this using tried and trusted risk management approaches. I believe there is a better way to look at this, but that’s for another blog.
Moving onto Change. These are what Donald would have called ‘unknown unknowns’. And this is where I owe him a debt, because it’s a definition that people understand. It’s stuff we forgot we needed to do, it's assumptions that prove to be wrong, it's estimates that don’t play out, it’s changing our mind about things. It’s all the things we know from experience will come in one form or another but we have no idea what they will be.
Finally, we have Uncertainty. It’s the ‘known unknowns’. Here, I refer to Donald’s most famous phrase. Uncertainty is something you don’t know today, but will need to know before you finish the project. On most IT projects, this is mainly, but not restricted to, outstanding design. In a traditional project, we have virtually no Uncertainty left when we start developing because we have baked our Uncertainty resolutions into a design. Don’t get me wrong, that’s not a good idea because we will generate loads of additional Change and Risk, as I have defined it, when our assumptions are proved invalid or we just change our minds.
So, we need to manage this Uncertainty as we would any other project deliverable. Do it too early and we have the risk of change due to inappropriate assumptions, and we may never even need to have resolved the Uncertainties if the project vision changes. Do it too late and we may end up with a rushed solution or even worse a stalled team.
It’s a balancing act which brings in the concept of the ‘last responsible moment’. I have found that the easiest way of managing this is to list the Uncertainty and come up with a plan of action for each. In this case I am talking about items of significance and not lower level detail that we will absorb as we go.
A project may have a dozen or so Uncertainties I would track. For each Uncertainty I decide an approach. ‘Do now’ represents something that to move forward with will add additional risk and should be resolved immediately. ‘Resolve with a story’ represents tying it to an item on the backlog and resolving in time to play the story it's assigned to. ‘Resolve with overarching plan’ represents the Uncertainty is calendar- more than priority-based and can be tied to a date timeline which IndigoBlue addresses using a time-based plan we call the Overarching plan. Finally, there is change the ‘way you work’. Some Uncertainties are pervasive and should be made part of the way work is undertaken so they are addressed on an ongoing basis.
However you identify and categorise them, Uncertainties are a factor in Agile projects that require management. Indeed, much of the benefit to be derived from Agile is obtained by doing this well.
So, thanks Donald for your ‘known unknowns’ and ‘unknown unknowns’ model. It’s been very useful to me. What I hope is these definitions will help others understand in seconds what my colleagues and I struggled with for hours. That doesn’t make up for everything else you did, but for this gem you have my gratitude.
If your organisation is looking for support with Uncertainty management, please get in touch.