Posted at 20:47h in Project Management Training by admin 0 Comments
Look out! Im going Biblical! If youre undertaking a project without doing requirements, you are
like a foolish man who built his house on the sand. The rain fell, and the floods came, and the winds blew and slammed against that house; and it felland great was its fall.*
Requirements are the bedrock on which your projector rather, the end result your project is to produceis built. If theyre not done, and done well, your life is going to be a swirling storm of bad-surprise phone calls, labyrinthine email threads, last-minute meetings and hacked-off sponsors.
The title I picked for this entry (before I started writing itoops) isnt really correct. Sure, you can un-gild the lilythats a decrease in scope. You can gild it, toothats a scope increase. If youve got good requirements, you can look at what is changing and what the impacts will be with relative ease, since youve got them right there in front of you, more or less. You can also set the changes in an orderly way so the folks who are building your wondrous widget will be able to make the proper adjustments. (It goes without saying youll have a cool change control process in place, right?)
Even with this lovely requirements arrangement, scope changes are a somewhat of pain in the neck and shoulders. Without it
yikes! You end up in a situation like I did with the first software effort I ever managed, in which the requirements came in each day over the phone, directly from the client, to the programmers. The programmers were always frustrated and the client was always dissatisfied. (Dont worry, I fixed it and they all lived happily ever after.)
I could go on with a lot of obvious stuff about how great requirements are, but you probably know most of that already, so let me throw out a few pithy propositions.
Business Analyst. Use a Business Analyst to create the requirements and dont treat them like a note-taker or layout specialist. The BA is the person at the nexus of the requirements whirlwind, but doesnt have an axe to grind for any particular faction of the team. A good one will be alert for anything that lacks sufficient detail, will raise a flag when anything seems to be left out and will actively solicit input from the silent introverts in the room to be sure their ideas arent missed. An even better BA will act as an Architect Lite and keep the discussion on the right technical track. Business Analysts are often gifted facilitators, too, and can drive requirements meetings to productive results.
Straw Man. Start with a straw man. If you, or whoever is responsible for the requirements, can kick things off with a diagram or a model of how the project should flow and/or how the end product should look, youll see much more activity from the requirements team. It doesnt matter if your mock-up is entirely wrong; in fact, that might be the best of all possible worlds. Peoples creativity is often awakened when they have something to cast stones at. As the team tears the straw man up and puts it back together again to show how things should really be done, the genuine requirements emerge. Few things are scarier than a blank slate youve got to fill with good ideas, so avoid putting the team through that by having something written down to start with.
Traceability. One should be able to trace the most granular technical requirement back to the higher-level tech requirements, to the architecture documents, to the business functionality requirements, to the marketing description (if there is one). This is important for two reasons. One, when the actual builder of a feature is down in the weeds, they can often benefit from a view of the larger context in which requirement #5.4.8.01-c1 was written. Given the larger view, they can build the granular component more closely to spec. Two, in almost every project, someone eventually asks, why in the heck did we do it that way? Usually this person is someone is a senior position and its most pleasant to be able to show them, in an orderly way, why the fruit baskets were woven of bamboo fibers instead of sweetgrass. Many organizations use database systems to organize requirements for traceabilitynot a bad idea.
* Matthew 7:26-27, from the New American Standard Bible