Whether you are an individual team member or a department manager, just about all of us–at one time or another–have been asked to produce an estimated work plan for some project or deliverable. And just about all of us-—at one time or another–have opened up Excel or Project, thrown in ten or a hundred tasks, slapped absolute-guess-estimates on each task, scrutinized the total until feeling comfortable with it, published the plan to get that manager or sponsor off our back, then moved on to actually doing the work, and never looked at that plan ever again.
This is not planning. This is storytelling. And it can kill your project. All of us have done it with small stuff. I’ve done it with small stuff. But some of us–I’d wager–have done it with 10 million dollar projects. And storytelling killed those projects, too.
But Why is Storytelling So Dangerous?
Two reasons. First, storytelling hides uncertainty and risk. When we “storytell” our way into a detailed plan, we suggest that we know much more than we really do about what we are building and how we are building it. We suggest that all the important business decisions, technical issues, requirements and design details are sorted out. We give reviewers the impression that our estimates really mean something and should not wander very much. Even when stakeholders cannot make head or tail of the plan, they see all the detail in the plan, they assume that we believe in that detail, and they commit themselves and us to meeting the delivery dates in the plan and the budget targets that the plan implies.
What does NOT show up in the storytelling plan is that the business users are still divided over the primary purpose of the project, the business analysts still do not understand the major workflows, and the tech lead has yet to select a programming language. But these are the exact things we need to have in mind when managers and stakeholders commit to delivery dates and budgets. By hiding these risks and unknowns under a mound of detail we encourage our managers, our stakeholders and our teams to make decisions based on fiction. Yes, its possible that things will go better than depicted in our storytale plan. But history argues quick convincingly that it rarely works out that way.
The second danger behind storytelling is that it commits us to a plan that no one on the team has any intention of following. So when our stakeholder or manager asks where we are on the plan, we have to either fess up that we aren’t following that plan (nor any other plan) or start storytelling our status as well (forty-two percent done). Either option, it doesn’t end well. It’s like telling your wife that you are stuck at work late for a meeting but then running off to happy hour. Yes, you can step outside of the place to call and explain why the “meeting” is running past eight. But at the end of the night you are going to have to go home and you are not going to smell like a conference room and take-out Chinese when you get there.
And not following your plan causes a lot more grief then just getting you in trouble with your boss or the stakeholder committee. Without a plan you cannot measure your velocity in completing work, nor you distance to the finish line. You are flying blind. You don’t know how far you’ve gone, how long till you get there, and you quite possibly don’t even know where “there” is. Once again, you might pull this flight off. But you wouldn’t want History as your co-pilot.
Always Guess at Effort Estimates, Never Guess At What Needs to be Done
How do you plan without storytelling? Tell the work that you are certain needs to be done, at whatever level that may be. If you know that you will need to build a simple invoicing engine as part of the project but no one really knows how simple (or not) it should be, then capture the invoicing engine in two lines on the plan:
- High-level requirements and design for Invoicing Engine: 9 Effort Days
- Build Invoicing Engine: 30 Effort Days
At present, this is all that you know for certain. These two lines in the plan effectively communicate that (1) an invoicing engine will need to be built, (2) the what and how still need to be decided, and (3) each estimate is merely a best guess.
Meanwhile, the team may know more about what needs to be done for the Work Queue, and that area of the plan may look something like this:
- Mock up and agree on screen design: 4 Effort Days
- Develop Main Work Queue Screen: 5 Effort Days
- Develop create and assign order functionality: 3 Effort Days
- Develop other order actions (cancel, escalate, etc.): 4 Effort Days
- Develop Order Detail Screen: 3 Effort Days
- Develop Order Fulfillment Screens: 5 Effort Days
- Define user rights and roles: 4 Effort Days
- Develop User Setup Screens: 5 Effort Days
Here, the team understands–and can detail–what needs to be done with a higher level of fidelity. This level of detail in plan suggests: (1) the business understands what it wants done, (2) the team knows at a high-level what needs to be built and how to build it, (3) the business and the team still need to sort out the details, and (4) each estimate should be based on some past experience.
You Can Help Fight Against Project Failure
To guard against failure on their own projects, teams need to produce plans that truthfully detail what the team knows and doesn’t know about the project. Better-understood parts of the system can be detailed in multiple deliverables with small- or medium-sized estimates. Less-well understood parts of the system, meanwhile, will have only one or two deliverables with large or very large estimates. If we draft and submit plans in this manner, the reviewer’s nose for detail should be an asset instead of a liability. The reviewer will interpret more detail and reasonably-sized estimates as less unknowns and less risks while interpreting little detail and high estimates as high risk. Any commitments made to the plan–or made to portions of the plan–will be colored by fuzzy reality instead of certain fiction.
Finally, this is a plan that the team can elaborate upon as it learns and report against as it works. At the beginning of a project, a simple plan can be the team’s best asset. And by growing and updating the plan the team can reliably see where it has been, gage how fast it is going, say where it is going, and estimate how long until it gets there.