In a previous post, I used the Eisenhower quote “…plans are useless but planning is indispensable”. The Agile Manifesto expresses a preference for “Responding to change over following a plan”. A tweet I saw recently illustrates both of those points and touches on why so many seem to have problems with estimates:
Programming IRL:
“ETA for an apple pie?”
“2h”
8h later:
“Where is it?”
“You didn’t tell me the dishes were dirty and you lacked an oven.”
At first glance, it’s the age-old story of being given inadequate requirements and then being held to an estimate long after it’s proven unreasonable. However, it should also be clear that the estimate was given without adequate initial planning, no “plan B” and when the issues were discovered, there was no communication of the need to revise the estimate by an additional 300%.
Before the torches and pitchforks come out, I’m not assigning blame. There are no villains in the scenario, just two victims. While I’ve seen my share of dysfunctional situations where the mutual distrust between IT and the business was the result of bad actors, I’ve also seen plenty that were the result of good people trapped inside bad processes. If the situation can be salvaged, communication and collaboration are going to be critical to doing so.
People deal with uncertainty every day. Construction projects face delays due to weather. Watch any home improvement show and chances are you’ll see a renovation project that has to change scope or cost due to an unforeseen situation. Even surgeons find themselves changing course due to circumstances they weren’t aware of until the patient was on the table. What the parties need to be aware of is that the critical matter is not whether or not an issue appears, but how it’s handled.
The first aspect of handling issues is not to stick to a plan that is past its “sell by” date. A plan is only valid within its context and when the context changes, sticking to the plan is delusional. If your GPS tells you to go straight and your eyes tell you the bridge is out, which should you believe?
Sometimes the expiration of a plan is strategic; the goal is not feasible and continuing will only waste time, money, and effort. Other times, the goal remains, but the original tactical approach is no longer valid. There are multiple methods appropriate to tactical decision-making. Two prominent ones are Deming’s Plan-Do-Check-Act and Boyd’s Observe-Orient-Decide-Act. Each has its place, but have a looping nature in common. Static plans work for neither business leaders nor fighter pilots.
The second aspect of handling issues is communication. It can be easy for IT to lose sight of the fact that the plan they’re executing is a facet of the overarching plan that their customer is executing. Whether in-house IT or contractor, the relationship with the business is a symbiotic one. In my experience, success follows those who recognize that and breakdowns occur when it is ignored. Constant communication and involvement with that customer avoids the trust-killing green-green-green-RED!!! project management theater.
In his post “Setting Expectations”, George Dinwiddie nailed the whole issue with plans and estimates:
What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?
The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?
Form Follows Function 
Gene,
Well played. The problem with that many of us have with estimates is that regardless of the relationship at the project or program level that understands what is known and unknown the number has a different life. Estimates become budgets that finance departments include as part of financial plans which include none of the nuances. Those stark numbers become goals which managers are held accountable in make. All of that said it tends to be cycle we all have to find a way to surf.
LikeLike
Tom,
Agreed, no matter what, there’s potential for abuse (more or less depending on the corporate culture). In my experience, it’s more prevalent in companies where IT is a centrally owned resource “bestowed” on the other business units according to some arcane formula none is privy to. That model promotes distrust, gold-plating (you never know when you’re going to get another release so ask for it now), etc. A more federated model where those units “own” their resources and IT is just a provider (as appropriate, e.g. the enterprise as a whole will own its infrastructure via IT) tends to promote more collaboration, product teams rather than project teams, and ownership on the part of the business unit managers. That teamwork tends to lead to a healthier environment for both business and IT in my experience.
LikeLike
Pingback: Fixing IT – Taming the (Customer) Beast | Form Follows Function
Pingback: Estimates – Uses, Abuses, and that Credibility Thing Again | Form Follows Function
Pingback: ‘Customer collaboration over contract negotiation’ and #NoEstimates | Form Follows Function
Pingback: This is not a project | Form Follows Function