Being a former McKinsey consultant, I have spent too much time immersed in frameworks, maturity models and methodologies. As I age, and my pragmatism grows, I find that many maturity models are too high level and vague and do not reflect the actual progression companies go through as they mature a given business function.
What I do find extremely useful are empirical maturity models since they categorize what companies are ACTUALLY doing TODAY in response to given challenges and pressures. Unfortunately, most models, rather than providing empirical data, are often just theory. The reason for this is because frequently, the author does not have access to large numbers of relevant companies willing to share their experience.
At Jama Software, we are quite fortunate to be working with hundreds of organizations immersed in maturing their requirements management approach within a broader product development process. Some are motivated to mature their requirements management process to reach compliance with relevant standards, others have experienced significant delays, cost overruns, or defects and are looking to improve process performance while the most advanced are able to measure end-end process performance and benchmark themselves against others.
The table below shows the key dimensions of requirements management and the five maturity levels we observe within our customer base.
Requirements Management Maturity Model
Let me start by describing the key dimensions:
- Change Control – The process by which requirements are documented, versioned, reviewed, approved, tracked, centralized, access controlled, updated, and referenced post–decomposition into development.
- Compliance Reporting – The generation of the necessary proof of process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments and test results.
- Living Requirements™ – Visibility and traceability of the state of each requirement and its downstream decomposition, development, and testing at any time from requirement draft through to product release. Requirements that are not living are static and trapped in documents with no system linkage to the entire product development process. I discuss this topic in more detail in this earlier blog: Requirements Management: Living vs. Static. Living Requirements reduce common product development risks of delays, missed requirements, rework, compliance gaps, limited reuse, defects, and recalls.
- Process Improvement – Manage the product development process through data with the end-to-end visibility provided with Living Requirements. Cycle time targets at various stages, rework percentages, process exception reporting, etc.
- Benchmark – Once the end-to-end product development process can be measured, it can then be compared to peer organizations to determine areas to focus on for further process performance gains.
Organizations are at different levels of requirements management maturity across these dimensions. Here are descriptions of each level:
(0) No Formal Requirements – No documentation exists for user or system requirements. Instead, development operates off user stories with no clear distinction between the functionality of the system being built and the expected user experience.
(1) Document-Based Requirements – Static requirements documents are created and most often maintained by each author on his/her desktop with various emails, Slack comments, etc. containing more information.
(2) Siloed Requirements Tool – A standalone tool is in place to draft, review, track comments, version, and store static requirements documents.
(3) System-Based Compliance – Compliance is the forcing function to shift from static to Living Requirements to meet standards for requirement validation, verification, and traceability in a single end-to-end system.
(4) Product Risk Reduction – A process-centric focus to reduce the likelihood of all forms of product risk via system–enabled Living Requirements. This requires detection and alerts for specification and functional changes, process exceptions, and test failures with the resulting impact analyses. The risks mitigated include:
- (a) Failure to meet the needs of customers
- (b) Failure to perform specified functions
- (c) Delays
- (d) Cost overruns
- (e) Defects
- (f) Compliance and regulatory gaps, delays, fines
- (g) Recalls
(5) Development Process Improvement – Moving past compliance and risk and into the spirit of the standards based on quality management and process control. A focus on measuring, managing, and improving the product development process.
Current Level of Maturity
Now that the model has been described, the first question is: Which maturity level best describes your organization today? Before working with us, most companies we speak with are either using Microsoft Word/Excel and at level 1 or frustrated with their current tool and struggling to move much past level 2. Our top customers are at level 4 and moving to level 5.
Desired Level of Maturity
Once you have made an honest assessment of what level your organization is currently at, the next step is to determine your desired maturity level and gain organizational support for the change. We generally do not recommend jumping more than 2 levels for the first stage of a process change.
Next Step
Once you have completed your self-assessment of current and desired maturity levels, we would encourage you to reach out to us to speak with one of our consultants. We will listen to understand your organization’s unique needs and provide some guidance on best practices based on years of clients’ success.
To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.