Death by poor pre-analysis
August 1, 2010 | In: Project management
So, you thought you had it all worked out… It was back then in those beautiful days of early Inception. When sponsor gave you the project, you found yourself a brilliant business analyst and second to none software architect. You did the estimates and won the contract. And now, 6 months later, all hell broke loose.
Project closure is nowhere in sight. Nobody is sure what exactly the Scope is. You all thought you nailed the sucker by signing off those two or three Excel sheets called “specifications” but now it seems that you never really knew this Scope dude.
If this looks familiar to you, chances are you’re guilty of poor pre-analysis.
It’s sad but it’s true: real requirement analysis is done after the contract is signed. Rare are the situations in which customer is willing to pay for a more detailed upfront analysis, or for that matter participate in one for free if it requires “significant” effort from their side (whatever significant means to them). It’s far more common to conduct a couple of BA sessions with customer, just enough to define high-level goals (enough only for a level or two of any decent WBS) while leaving everything else in the dark until post-contract-signing period.
This translates directly to key stakeholders not engaged early enough and vague requirements, no matter how explicit and clear they might seem at the time. These fragments of requirements, full of uncertainties and assumptions are what you should be basing your estimates on. Starting to feel like running with open scissors in your hand yet?
On top of that, you also heard about something called “Rolling Wave Planning” and “Progressive Elaboration” so you’re not afraid to say „I’m not exactly sure what I’m supposed to do here but whatever it is, it can’t be more complex than xyz man-days….can it?… no way…“
So you estimate your efforts based on these next-to-random data and you make your offer. If you are a religious person, you probably say a prayer. Finally, you win a contract and start your project oblivious to the fact that the path you’re walking is in fact your personal Green Mile.
Here are couple of tips for you to experience the Green Mile only as a motion picture:
Always identify all key stakeholders as soon as possible, preferably during pre-analysis. If you don’t, they will emerge eventually and claim that what you see as a 50% scope increase is actually assumed from the beginning.
Don’t be shy while filling your “Not in scope” chapter in a proposal. Toss here everything you can think of. Never mind if it is implied or agreed upon earlier. Write it down.
Don’t underestimate nonfunctional requirements. These are usually not addressed explicitly which makes them a very common source of conflicts. There are thousands of ways one can develop GUI for certain functionality. If not explicitly stated, by definition you will aim for command prompt while your customer will expect Mac OS X.
Get a hold of Subject matter expert. If you’re entering a project and having hard time even speaking with the customer about the business side of the project, find yourself a good SME. Do not kid yourself that you’ll be able to grasp the full width of complex business rules. You will not have time for that. After all, that is not even your job. Good SME is priceless. I know projects, complex in business nature, where project teams comprised of one (rarely two) business analyst and six or seven developers. We used to kid that we would probably finish off earlier if we had the developer/analyst ratio inversed: six analysts and only one developer. And, to some point, we were probably right.
Beware of big chunks of work disguised as amorphous work packages not decomposed due to Rolling Wave Planning. They always contain more work than you think.
If you have more tips on this subject, please share them in comments….thanks!