Quit Sweeping Known Uncertainity Under The Rug

This is a continuation of the post – Mr. Yuk Says Project Roadmaps Are Poisonous

As the saying goes, the first step in fighting addiction is admitting you have a problem. Unfortunately, it is human nature for us to rationalize away our problems. Problems which then create ticking time bombs in fragile card houses.

One of the biggest plagues in the management of software is never admitting that there is uncertainty in projects. Instead we quantify these unknowns in buffered estimations and optimistic risk analysis spreadsheets. This is the equivalent of sweeping known uncertainty under the rug.

What is known uncertainty? Like I have said before – we don’t know what we don’t know; however, I would debate that we do know roughly how uncertain we feel about a particular thing. For example, how many times have you said something like:

I am 100% confident that is correct, but I am only 80% sure that other one is right.

I am not going to go into depth today about how horribly wrong the above statement is, but it does prove my point that we have uncertainties that we should leverage as variables in management. But how do we do this?

Explore The Domain Early

The first step has historically always been the hardest for me to convince management of, and that is being allowed to have early in-depth conversations with the client about the domain problem.

The de facto retort of management when asked to understand more about the problem upfront is something like this:

We don’t want to waste time or money on a client or project we don’t know if we have yet. Let’s just figure out how much it is going to cost so we can give them a bid and we will figure out the rest later.

Do I even have to go into depth why this is stupid and counter intuitive? How can we even be remotely close in our estimations if we have no context of what we are building. We obviously are slow learners because numbers still fly out of our mouths when given an elevator pitch’s worth of information.

Estimate Early And With Uncertainity

Along with exploring and prototyping the domain early, we also need to estimate very early on. More important than just estimating, we need to estimate with uncertainty by doing the following:

• Always estimate in ranges – never give a single point estimation
• Use the Cone of Uncertainty to widen or narrow your ranges
• Bait and switch management so you don’t become responsible of horrible estimations based on no information.

I explain most of this information in an old post – Never Be Responsible For Your Estimations Again. But in short, here is the tactic:

1. Estimate in ranges or using something like the Fibonacci sequence method found in Planning Poker
2. Place a % of certainty that you can accomplish these goals given the time and budget, then divide that % by 2 (because you are being optimistic)
3. Pitch it to management – “I am 35% confident we can meet those timelines, so either that is a risk you know upfront or we have to realign expectations.”

Use Agile / Scrum For In-Transit Management

Not to kick the dead horse, but if you aren’t using Scrum or some other Agile development process you aren’t working as people are meant to work. You are working like robots, or factories, or some theoretical imaginary land that some professor made up, but you aren’t working in an environment where real life is a vacuum. Features change, people get sick, and money runs tight, manage all these with Agile approaches.

I am not going to preach to the choir, and those in the pews that still don’t practice these techniques are dirty dirty sinners. Same on you. 😉

Flaunt Your Weaknesses, Then Crush Them

Because people don’t psychologically like being uncertain it will be hard to receive initial buy in – this really is an act of humbleness and humility.

Ask these people if they are personalities who would rather be comfortable but feed lies, or know the uncomfortable truth. Only people in the latter group should be in business…well, at least a successful business.

In summary, if you can get your team to a state of practicing flaunting their uncertainty, you will eventually grow an environment where people will speed to extinguish uncertainty. Therefore, you will grow an environment that continually overcomes their greatest weakness next in the queue.

Give it a whirl, be humble. Give your poor rug a break and show your team how damn uncertain you are about things. I do and that is why I am the putz with the successful projects.