Joe's Jottings
Jottings Number 37, by Joe Podolsky:
From: uunet!HP-PaloAlto-om4.om.hp.com!JOE_PODOLSKY
Date: Tue, 1 Aug 95 14:46:55 -0700
We all know how hard it is to estimate projects, especially anything that has software in it. The problem, as we all well know, is that we don't know what we're going to get into until we're already there. Beforehand, all we have to go on is the past, and one thing we do know is that the future will be different. Well, not always. Professors Rita McGrath and Ian MacMillan have written an article in the July-August 1995 Harvard Business Review called "Discovery-Driven Planning." McGrath and MacMillan point out that for tasks that are extensions of past activities, "managers can extrapolate future results from a well-understood and predictable platform of past experience." (A corollary to this truth (not in the article) is that, when it's REALLY important that the delivery date, the cost, and/or the functionality be predicted accurately, we MUST follow this little rhyme: When in doubt, build it stout, out of things you know about.) When, however, we venture into the unknown, which is the usual case for most information systems projects, the professors well advise us to use their discovery-based planning process to give at least as much control as possible. Their process "offers a systematic way to uncover the dangerous implicit assumptions that would otherwise slip unnoticed and thus unchallenged into the plan." Their process is built around four documents: a reverse income statement for financial control, pro forma operations specs that describe how the new venture will operate, a key assumptions checklist, and a milestone planning chart. The HBR article is written with a profit center in mind, but the concepts translate well into a typical information system cost center model. The key to the reverse income statement is to start at the bottom line (profits) and work up. In our case, we would build a budget by first stating the maximum expense totals by month (Monthly is about right. Quarterly would be too long to take appropriate action, and weekly probably has too many normal fluctuations in it). Then we build the rest of the target lines so that they add up to this bottom line. While doing this, it's crucial that we carefully record on the assumption checklist every assumption we make in order to make the budget fit. The assumption checklist should then be expanded also to include all other assumptions you can think of, especially technical issues, learning curve expectations, and interactions with project partners. For each item on the checklist, include a description of the assumption and whatever metrics describe the assumption. For example, if you expect to hire five software engineers, you might say that you will have them on board by August 31, for an average salary of $7000 per month, and an ability to immediately produce 500 lines of tested C++ code per month. Note that, in fact, each on of those metrics implies a separate assumption. (For convenience of future reference, the authors suggest that the assumptions be numbered.) The pro forma operations specification lays out the activity to be performed by the project. I won't talk about that here because most IS projects accomplish this from their requirements document, especially from the description of the process that the system will support. As we look at the specification, however, we again should be on the lookout for any implicit assumptions that might be lurking behind the process descriptions. And, when we see those assumptions, we should again attach metrics and add them to the assumptions checklist. The last tool, milestone planning, is also familiar to us. However, for discovery-based ventures, the authors recommend that we yet again explicitly describe what assumptions should be checked at each milestone. The examples in the article show only a dozen or so assumptions. I can imagine there being hundreds of assumptions in a fairly routine information systems project. And, frankly, I have a hard time imagining adequate control over hundreds of assumptions. I suppose we can prioritize them somehow, but Murphy's Law guarantees that it's a low priority one that will bite us hard. Note, however, that what McGrath and MacMillan are proposing isn't fancy. Their process asks that we plan our future operations, our development cost, and our development schedule much as we have normally done, but they ask, as we go through our estimates, that we carefully record the implicit assumptions. "All" this does is to force us to make visible and public the blatant and subtle issues that are always there. And that's the point. Whether we document the assumptions or not, they are lurking in our projects. It's essential that they be made visible so they can be managed, e.g., problems can be escalated, plans revised, and/or new assumptions made. Whether or not our projects have too many assumptions to manage, it's dumb to ignore them. If the revealed complexity scares us, we'd be better off chopping the project into manageable chunks rather than ignoring the elephant sitting in our tent. For information systems projects, I think the McGrath/MacMillan discovery-planning process reveals to our customers the risks we often know but don't articulate. Using the process might let us keep something very valuable that often slips away ... our credibility. Does this makes sense to you? I have the feeling that we often are afraid to disclose the scary assumptions in our projects for fear that our customers will think that we're wimps and can't deal with a few problems. I think that we're more willing to deal with the inevitable project failures than we are to face the tough issues up front. Maybe we'd rather look dumb and macho instead of smart but nerdy. It may have to do with some of the issues about lying mentioned in jottings #35. I'd really be interested in how you see these choices we make. Would you use this process to list all the assumptions in your projects ... and if not, why not? Regards, Joe