Situational Awareness
In the end, it’s not about the number, but situational awareness. Discover what the possibilities are and where the dangers lie. Use your estimates to sense the world around you and make visible the intangible and ineffable. Mark the areas you want to avoid. But whatever you do, do not fool yourself into believing that estimates are truth. Especially do not believe a simple number.
When the Depth Sounder Broke
Our sailboat, when we bought her, had an electronic depth sounder that measured the water depth by bouncing sound waves off the bottom. In spite of this tool, we often ran aground. The tributaries of the Chesapeake Bay have a lot of shallow water, irregularly shaped and often unmarked. When the depth sounder showed that I was venturing into shallow water, I often didn’t know which side had the deeper water. I had been watching the number on the dial. I frequently turned the wrong way and went promptly aground.
One day while entering a notoriously difficult passage, both narrow and shallow, the depth sounder showed no less than 80 feet all the way in. That was particularly noteworthy given that the water was about six feet deep. It turned out that the wire to the transducer had chafed through, so no signal was returning.
A remarkable thing happened after that, though. I ran aground much less frequently. Instead of looking at a number, I was looking around me. I was noticing the shape of the land and inferring the shape of the bottom from that. I was picking up clues from the color and texture of the surface of the water, from the activity of birds and fish, and from the locations of crab pots and twigs. I was paying attention to the world instead of trusting a number. For those times when I really did need to measure, I bought a leadline. It’s a lot less convenient and has a less precise readout, but it’s generally enough.
Keep your eye on the prize. What made you, or the organization, want to undertake this in the first place? How can you reach that goal? How can you tell that you’re on track? The prudent mariner will not rely solely on any single aid to navigation. Take what you learn and try to confirm it in a completely independent way. Even if these assessments agree, trust them tentatively. It’s far too easy to have a single assumption affect them both without noticing.
Steering and Prioritizing
Once you’ve reached the point where you can confidently track progress within a project, then you can apply a lot of the trade-offs pertaining to choosing between projects to choosing between capabilities or implementations. You can select between options based on estimated benefit, cost, and time. Should you cancel or postpone the current effort to start on this new idea now, or would it be better to let it run to a logical conclusion point? You can select urgent things that can be done before items that have a hard deadline, without running undue risk. For example, can this bug that is annoying our biggest customer be fixed without endangering a critical integration date? You can determine if sufficient value can be reached by a deadline to make the effort worth attempting: for example, can this feature be added in time to show it at the big industry trade show? You can monitor the risk of not meeting a hard deadline, such as the Christmas market, or a regulatory deadline. Are you still on the “safe side” of this hazard? See Danger Bearings for more on this.
Confidently tracking and predicting progress allow you to make smart business decisions. You can compare the cash flow of projected expenses and income to determine your break-even point. Ultimate ROI may not be the best criteria for your current decision. What about cost of delay? A lower ROI project that can start generating revenue sooner may be a better choice. What is your need for cash flow? Do you have the reserves for expenses prior to break-even? Is this the best use of those reserves? Consider the time value of money. A dollar today is worth more than a dollar next year. Identify “low-hanging fruit” that can provide near-term benefit for little cost. Fix “broken windows” that consistently cost money without benefit. This includes both things that slow down the user and those that slow down the development team.
You may have several approaches you can take on a single project, and you want to choose the best one given your constraints. Which of these approaches is more likely to be shorter or cheaper? Do you have the information to estimate that? Can you develop a little each way to confirm or refute those estimates?
Picture the situation where a version upgrade of a third-party framework had an unexpected change of some minor functionality, and a feature depending on that functionality was broken. As of this writing, work was ongoing to resolve that problem. Consider the uncertainty of the situation and the questions you might have. Is there similar functionality in the new version of the framework that the feature can use? Does the feature need to be rewritten to work around the framework? Can we afford to try both approaches in parallel?
Managers requested an estimate of when that work might complete relative the scheduled production release. This estimate might be a date if the fix looks possible and progress is being made. It might be “unknown” if the possibility of success can’t be judged. Or it might yield “unlikely” as the possibilities of a simple resolution are dwindling. Based on this estimate, the managers might decide to authorize reworking the feature to avoid that functionality. They might also consider rescheduling the production release.
Are we on track, or should we reexamine our assumptions? When we estimate how much time, effort, and money it will take to do something, we’ve wrapped up a bunch of assumptions into those estimates—whether we chose those assumptions explicitly or not. If the actuals differ from the estimate, it calls those assumptions into question.
We’ll want to identify any problems well before our final deliverable date, when there’s still time to take action. This implies that we want to estimate intermediate or short-range milestones to give us early warning. Perhaps we discover that costs are going up or that we won’t make a necessary target date. The action might be corrective, such as cutting scope, or it might be to cancel the project because it’s unlikely to meet our goals. The urgent question is, how soon can we know things are not as we planned?
