Requirements Management is one of the most mistreated and misunderstood knowledge areas in Project Management. In my professional practice, I experience the full spectrum of functional requirements management styles and opinions. In most cases, client’s will make their best attempt to extract some form of written requirements at the onset of a project to put some shape on the estimates for the job (for lack of a deeper purpose). These written requirements are more often than not just published on a project wiki page, and are often open ended statements that are indistinguishable from a stakeholder expectations log. This “publication” is often a onetime posting that is not maintained throughout the project cycle. This practice is very prevalent among the clients that declare they are operationally “Agile”. At the other end of the spectrum, clients who operate in industry sectors demanding regulated product assurance standards elaborate and formally release requirements documents, but fall short when it comes to adequately managing these requirements. This practice is very prevalent among the clients that declare they are operationally “Certified” in accordance to their respective regulatory standards.
For many of the self-proclaimed Agile clients, they are really using the word (agile) to distinguish themselves from the other end of the spectrum. They tend to refer to written requirements as the nemesis of dynamic creativity; hence to formally commit to such a written list would completely limit the final product. This is a completely distorted view of agility and is completely misaligned to the practice of Agile Project Management. The ability to be truly agile is to be open to change and to manage change in a structured fashion. Requirements form the frame upon which the final deliverable(s) is structured. Having these requirements documented in a way that facilitates a visual mapping breeds creativity. This mapping, when correctly structured, forms the basis of the epics and stories which are the foundation of the agile framework.
As for the other end of the spectrum, documented and formally released requirements are more often than mismanaged because of the following reasons:
- Incorrectly or completely uncategorized listing of singular statements
- Buried or nonexistent traceability to lower tier requirements and specifications
- Loose or nonexistent relationship to ancillary applicable documents
- Loose or nonexistent relationship to derived requirements (orphans)
- Loose or nonexistent relationship to formalized change orders
- Loose or nonexistent relationship to deviations and waivers
- Loose or nonexistent management of TBD’s and TBC’s
- Loose or nonexistent relationship to stakeholder expectations
- Uncontrolled dissemination of requirements change to the wide team
- Incorrect connections to the Risk Register
Believe it or not, I see all of these key violations in the high reliability sector. I have listed the association to the Risk Register last because it is both a reason and a resulting case of collateral damage. As I have mentioned in previous blog posts, risk adverse clients transfer these issues into risk, and proceed to claim hold harmless status thereafter. This happens because the Requirements Management Plan does not address how to handle these issues. The management of requirements is simply transferred to the Systems Management Plan, and the Project Manager completely lets go of this critical part of overall project leadership. This is real mistake on many levels. At the top of the list is the impact on Change Management. I have yet to experience (going on 30 years in this business) a top level requirements document being “static” and not subject to change. The requirements always change.
Agile Project Managers must take charge of Requirements Management. There is a distinct segment of the defined responsibilities in the execution of requirements management that falls into the Systems Team’s scope of control. Certainly capturing, clarification, and interpretation of customer requirements clearly falls into the Systems domain. This must include clearly derived TBD’s in lieu of customer’s future clarifications. In cases where the stated requirements are on the light side, (the “Agile” case I mentioned earlier) the Project Manager must endeavor to back fill these requirements with stakeholder expectations and derived requirements in order to set a clear and complete visualization for the team. This must be defined and well-rounded prior to kicking off the project. All work effort and non-labor spend during execution must clearly tie back to the requirements. This definitely must be a section in the execution playbook because the requirements visualization is the hitchhiker’s guide to the galaxy®. All successful teams rely on a strong playbook!