I had a requirements document sent to me this week to review. It was a piece of art! The document was about 100 pages long. It was prepared about 3 years ago and has sat on a shelf until now. Now it's time to start planning the project.
The first step was to ignore most of the document. My approach to move forward will be to look at the high-level business process and come up with a rough estimate on how big the project is. Then my team will engage the process owners to start drilling down into the requirements as we start building the process. We'll have regular reviews, and probably in 2-3 months, we'll have the process ready to deploy.
I think of how much waste went into this document. First, there was the time to try to document everything. In all likelyhood, a lot of what was documented doesn't really need to be in the final system. Then the document sat and gathered dust. Any Lean advocate will tell you to avoid work in progress. Regardless of how the requirements were being captured, it shouldn't have been done until everyone was ready to start on the project. Finally, there was my time trying to read/understand the requirements. As typical, it was written standard requirements-speak "the system shall provide the capability to..." and then followed by use cases that provided the same information in a more confusing manner. I could probably summarize the whole thing in a dozen user stories.
I'd like to start a reality show like "What not to Wear" expect about project management. Each week it would look at a different project and help get the project moving in the right direction. I'll have to think of a good name.
3 comments:
Great post. Got to it from a tweet from @projectshrink. At the present time, we have a backlog of ~100 projects with 'Functional User Specs'. These are planned to be implemented over the next few years. Most of them are obsolete. Many address functionality no longer required, or changed in such fundamental ways that they no longer describe either the problem nor the solution. Yes, we do revisit the both the problem & the solution when the project finally gets the go-ahead. I'm not upset at this, because it's unreasonable to expect someone to know everything that's needed in advance, especially in light of such a rapidly changing environment.
Ray - Thanks for the comment. I think the trick is to get enough info on a project to evaluate it against other projects so you can take on the most important one first. Then you start gathering more details on the project you're working on.
interestingly i read it,it is so useful in project managment
and we provide a project managment course,I wish u could have a look on it.....
http://afdy.com/pmi
thanks
Post a Comment