Every project requires investments in terms of time, money, and other resources. This chapter will help you analyze the requirements of your project at hand, and decide how to proceed in light of the investments required to make it work.
Project Management: What is the Value of Requirements?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
You absolutely must have a requirements spec for any project – IT or not. With no requirements, you would never get budget signoff, there would be no specific deliverable, and the project would never gain official “complete” status. Time and money invested in getting the right requirements set out correctly and explicitly can save so much later down the line.
I would phrase it differently – requirements are essential, but every requirement should also have a basis (i.e., justification for why it is needed), a statement of consequences if it is not met (e.g., fallback position), a description of the tests to be done to show that it is met, the person who is responsible for signing off that a requirement has been met, etc. The process of developing requirements is not easy and can be time consuming, but in the end it provides all parties (sponsors, managers, and developers) with a clear description of what a project is intended to accomplish and also provides a foundation for push-back when feature-creep inevitably sets in.
A great explanation of the requirements process. I like and am going to plagarise your ideas.
🙂 thanks
You absolutely must have a requirements spec for any project – IT or not. With no requirements, you would never get budget signoff, there would be no specific deliverable, and the project would never gain official “complete” status. Time and money invested in getting the right requirements set out correctly and explicitly can save so much later down the line.
Yep…and later, the requirements get ignored or even lost.
I’m working on a project now where that happened to the latest requirements, and we are piecing them back together. Along with that, project has an documented database format that makes absolutely no sense…and I’m re-writing that including substantial changes.
The requirements include pointers to contract penalties…and both the customer and the contractor are oblivious that they are both in violation of the contract and the requirements.
Neither the customer or the contractor can get information out of each other…though the managers on both side are keen on identifying these problems and sorting them out. Or are they? Lots of lip service.
The good news is that neither side is ready to draw blood. Good personal relations, if not a good degree of professionalism.
Really wish I could tell you the details. Wish I could tell you why I can’t tell you. …oh well.
One thing that has worked well for us is to the a wiki for documentation.
The key reason documents probably get ignored or lost is that it’s too bulky to maintain or it’s too hard to keep track of the current version or see how a document evolves and how changed what. Wikis solve this problem, and if you have the right wiki format, it’s possible to generate your own reports (I like Dokuwiki because it doesn’t use a database. You can just copy it to CD and take it anywhere.)
Another value of wikis is that it’s easy to use hypertext to provide more technical information as needed. This allows for a high level view to be created for managers, and a more detailed view to be created for implementors.
This being said, I agree with the rest of your response that project management is really people management. The success of a project depends as much as how you manage your project sponsor(s) and process owners as the work that actually gets done.
One thing that has worked well for us is to the a wiki for documentation.
Wikis are naturals. I’m proposing one for simple docs plus another based on Plone for more advanced uses — though Plone is typically overkill.
So far: none have been deployed where I am, and I’ve had to deal with being grilled over how this will mesh with the required MS Word Doc-based requirements database. (Yes, I attempted to avoid Word as it is paper-centric and not easily searchable and was shot down.)
The key reason documents probably get ignored or lost is that it’s too bulky to maintain or it’s too hard to keep track of the current version or see how a document evolves and how changed what. Wikis solve this problem, and if you have the right wiki format, it’s possible to generate your own reports (I like Dokuwiki because it doesn’t use a database. You can just copy it to CD and take it anywhere.)
Thanks for the tip about Dokuwiki. The rest I agree with 100%.
Another value of wikis is that it’s easy to use hypertext to provide more technical information as needed. This allows for a high level view to be created for managers, and a more detailed view to be created for implementors.
I agree…though one of my more stressful conversations was with someone who kept asking “how are we going to integrate PPT and Project?”. His solution was to use something with attachments. Wikis allow that and some provide translation to a web-viewable format. His comment: How will it handle attachments? Grrrrr…
This being said, I agree with the rest of your response that project management is really people management. The success of a project depends as much as how you manage your project sponsor(s) and process owners as the work that actually gets done.
I also agree.
A dirty phrase — “customer management” — is really the key if you are on the contractor’s side. It doesn’t mean treating them like sheep to be hearded, but instead manage expectations and to focus on the unambigious parts (such as well written requirements). That way trust can be built…slowly…and you have less of a chance of having them think you are trying to screw them over. (That, and you really can’t be a scum bag…people will only put up with lies and deception for so long. Well, they shouldn’t put up with it as much as they do, though there’s no reason to be that way.)
I worked for about 4 years as a consultant and always followed (if even loosly and informal) a project management/development lifecycle which always began w/ the gathering and analysis of project requirements.
Five months ago I took employment w/ a local company and in my new IT department…I was shocked to find that none of them followed any type of process…forget documentation or project requirements. It also wasn’t hard to notice how hard it was to pick up someone else’s work and get down to business.
We have a great CIO who…in a brilliant flash of wisdom…is getting us all ITIL trained and certified.
Think of it as ISO for IT professionals…everytyhing is done by the book…every time. Period.
I wouldn’t want it any other way, myself…this is how things get done and done right…or atleast provides a valid explanation as to why something went wrong…should that happen.
You would be surprised how many projects are done without requirements or just BAD requiremnts. AND IT SHOWS! How can people be expected to create testcaes later on without well-defined requirements? Also a MS Word Doc does not count as requirements! You cannot go through a Word doc and say implement this paragraph but not this sentence!
You would be surprised how many projects are done without requirements or just BAD requiremnts.
Been there. Done that. Had the drag-out-smack-down ‘fights’. Been kicked off of projects because people don’t like following a process of some sort — and I was glad to be booted off.
At the end of the day, most hostile contracts or projects are hostile because;
* Nobody wrote down the requirements or they did not take them seriously.
* Roles and responsibilites were not defined at the customer/contractor or team level.
* Bad will built up and now neither ‘side’ can agree on anything…let alone what a requirements document covers.
How can people be expected to create testcaes later on without well-defined requirements?
Test? What’s that? :/
Also a MS Word Doc does not count as requirements! You cannot go through a Word doc and say implement this paragraph but not this sentence!
I’ve attempted to get the current project I’m on off of this model. No go. Instead, we now have an expensive requirements management system that is … MS Word Doc based.
The only saving grace: The system can (???) create a requirements document in multiple formats (including MS Word Doc) from the requirements database. Well, that’s what the salepeople said. We have to use a specific tool, though, per edict of the customer…even though they will never be dealing with anything but MS Word Doc files. (Hey, Doc is superior to faxes…and yes, I know how pitiful that is.)
Well, in my experience, the Requirements Document is one of the most cursed and praised pieces of paper I’ve seen. I’ve been on some projects without one that went horribly awry and some that were very successful. I’ve been on other projects with a RD and the RD got out of date quicker than a pack of expired yogurt. Other times the requirements doc was a valuable tool that helped keep the whole group in sync.
To me the Requirements Doc is an ideal goal. It’s worth trying to do it, it’s probably the best way, but in some groups it’s just useless. Depends on the particular business climate your project is in.
You might want to try http://www.basecamphq.com/ (ruby and rails as well).