Share via

Dealing with uncertainty

  • Article

Once a project goes far enough off the rails to need recovery it is a good bet that the people involved are making decisions based on fear, uncertainty, and doubt (affectionately referred to as F.U.D) instead of reason, experience, and logic (R.E.a.L.).  Fear and Doubt are emotional responses and while careful handling and good soft skills go a long way to helping, addressing uncertainty first establishes credibility and generally encourages the team to be open to the possibility of success.

Uncertainty isn't a new concept.  The top graph below is the "cone of uncertainty".  Basically, predictions made about the future are exponentially less likely to be correct than predictions about something that will occur now.  The impact on software development is striking.   When you step back and consider the cone of uncertainly and the software development lifecycle, the bottom graph below, together.

uncertainty

Building software requires us to estimate current activities when we can only really know the results out in the future.  Clearly these two truisms are at odds.  So what can we do?  One option common in failing projects it to delude ourselves into believing we can somehow beat the cone of uncertainty.  Failing projects choose to be certain.  Their predictive activities, which frequently go 12 to 18 months out into the future, are not only correct when the predictions are made but any variance during execution is clearly wrong and fire drills ensue to "correct" things.  Another option is to create seemingly detailed analysis that supports a pre-determined supposition.  These are generally easy to spot.  Major dates that are exactly 60 days apart of things end on fiscal quarter boundaries very quarter are immediately suspect.  IT is ok to back into important business dates, but do so openly without the pretense of calculated precision.

A more productive way to beat the cone of uncertainty is to break the work into smaller iterations.  This allows you to do detailed planning for the next, nearest, thing and delay detailed planning on the parts further away for a time when they are.. well... not far away.  This does not relieve the burden of identifying the chunks of work to be done, their dependencies, and the order they will be executed.  Good architecture, high level design, and project planning go a very long way, also done incrementally can identify the business needs and their interactions.  Working closely with the users prioritization completes the iteration definition work.

Comments