Without a Trace?
When gathering requirements for a deliverable, there is tremendous focus of energy in doing all the research you can with business people, marketing people, customers, product users and others to determine how to best define what a project team should be building.
After a strong initial effort to come up with a design, there is then an equally important component in keeping the team directed on the project while cautiously incorporating changes into the mix. There may be things that were missed or developments that occurred that necessitated project adaptations. Sometimes though, there are just times when someone wants a feature included--more based on a whim than a need.
While a project scope needs to keep a laser-like lock on the end of the project lifecycle, it nonetheless may evolve as needs and out-of-project-control factors change. Making sure those changes can rationally be fit into the scope is an effort of negotiation and rationalization, but it also needs to have accountability.
Incorporating robust requirements traceability guidelines into a project keeps a strong check-and-balance approach in place by making sure that each business need is truly identified as a genuine requirement, and that those requirements are then directly connected to deliverables. In the course of a project, there is an intense need to keep customer requirements and their
Please log in or sign up below to read the rest of the article.
|
"You can't build a reputation on what you are going to do." - Henry Ford |




