By Gary Hinkle
Stretching a Stretch Goal
How far can you stretch a stretch goal before it snaps? Wouldn’t it be nice if there were a formula for that—if it were actually a predictable property with a scientific underpinning you could look up in your old physics textbook?
By stretch goal, I’m referring primarily to deadlines, when we estimate how long a project task will take and decide to be aggressive, when a get-it-done spirit comes over the team: It usually takes us a week to run this series of tests, but let’s make it happen in two days this time. Let’s stretch ourselves and bring this in earlier than usual! Next thing you know, the stretch goal is on the project schedule.
But when reality hits, the testing takes almost four days, better than the usual week but a “miss” on the task…and it then ripples to the “complete testing” milestone.
When an overly optimistic mindset drives an entire project schedule, the ripple effect leads to projects that are weeks, months, or sometimes even years late. Wouldn’t it be nice to know how far you can stretch a stretch goal before it snaps?
Damage from Overstretching
When a stretch goal snaps, there are damaging effects, some quantifiable, some not. Late projects hurt morale, causing distrust to surface within the team and the larger organization. Managers start to doubt the accuracy of future estimates, and then team members stop believing that management supports realistic plans.
Late projects cut into profits, too, and though the exact amount might be hard to nail, it’s usually more significant than the financial metrics suggest. To make matters worse, subsequent projects can’t get started, because project team members are still tied up with the previous late delivery and aren’t available.
Let’s say the first year revenue resulting from an engineering project is forecasted to be $5 million and ten engineers are working on the project. As the planned completion date approaches, the revenue opportunity from the completed project is $20,000 per day. The cost to employ the engineering team is in the neighborhood of $5,000 per day. So the cost of delay (lost revenue plus employee expense) is about $25,000 per day—not even taking into account the impact on other opportunities. Significant!
When engineering projects are late, the cost runs from thousands to tens of thousands per day, on top of the cost of the other damages mentioned earlier. All stakeholders must fully appreciate the implications of underestimating and overstretching so they can focus efforts in the right places.
Avoid the Damage: Improve the Estimates
There are several steps you can take immediately to improve the accuracy of estimates. Here are a few, three of the most important:
Break down project tasks into manageable pieces. You can’t prepare an estimate for a task that’s too big—like “write requirements” or “test the system.” The tasks need to be small enough to envision the start, finish and all interim activity.
Use all appropriate and relevant methods for estimating. There are many ways to estimate, everything from educated guessing to consulting experts to compartmentalizing tasks in groups. Whatever methods are relevant to the project you’re working on, use them.
Make sure the team has both the time and the education necessary to develop good estimates, including knowing what methods they should employ.
If your team is pressured to provide an estimate on a project when the scope of work is still unfinished or poorly understood, provide your best estimate based on conditions that the team defines—and be specific about your exclusions and assumptions. Make it clear to stakeholders that the estimate depends on those conditions. If those conditions aren’t acceptable, the scope needs more work before the team can develop a definitive estimate.
Most importantly, get the team’s buy-in. When every stakeholder agrees that a project estimate is achievable, then planning is good enough to start the project. Sure, planning details continue and stuff happens that causes plans to change—but these typical, day-to-day challenges won’t throw you for a loop if your project isn’t stretched to the snapping point by damaging, under-defined and over-ambitious estimates.