Critical success factors for professional requirements management
Requirements management as part of a project management methodology is a basic skill for project managers. And it is even more: It is a key success factor to increase the likelihood for project success.
This paper illustrates basics of traditional requirements management aligned to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition (PMI, 2008) introduces some agile requirements techniques and takes the reader onto a journey to manage requirements professionally throughout the entire project.
After briefly discussing the necessity and importance of traditional requirements management a more complex but comprehensive approach to professional requirements management will be introduced: Aligning different phases of requirements management to phases of a project, each phase accounting for individual critical success factors.
Despite that this paper focuses on traditional project management, agile techniques are explained whenever they seem to be helpful.
What is Requirements Management About?
Because project management got the level of attention it deserves a variety of approaches to manage requirements developed. What they all have in common are two fundamental questions:
- Why is requirements management important and what is it all about?
- Who is responsible to manage the process of collecting, documenting, and managing requirements throughout the project life cycle?
Requirements management is typically seen from two different points of view: First, requirements management as an own profession; second, requirements management as part of a project management methodology. This paper focuses on the second one.
Every now and then daily business shows projects in which requirements management is not more than only collecting requirements or, even worse, it is not seen as necessary at all but called “academic exercise.”
The PMBOK® Guide gives a nice explanation what requirements and its management is about: Requirements management includes quantified and documented needs and expectations of sponsors, stakeholders and customers. Requirements must be elicited and analyzed in enough detail that they can be measured once execution of a project begins (PMI, 2008, p. 105).
Following this explanation, requirements management asks for even more than just collecting requirements: capture, document and manage requirements by defining stakeholders’/customers’ needs and expectations to meet the agreed project objectives.
Requirements management is part of stakeholder/customer management and hence one important approach to project communication. If done professionally the likelihood for project success increases significantly.
In a traditional project business analysts are typically in charge of managing requirements, sometimes the system architect or the customer itself takes responsibility to manage requirements.
Whoever is officially in charge, it is the project manager's responsibility to ensure all requirements are captured, documented, agreed, and delivered.
What Input Is Needed to Start Managing Requirements Professionally?
There are two critical inputs for professional requirements management to start: the project charter and the stakeholder register (PMI, 2008, p. 106).
While the project charter is used to provide high-level project requirements and high-level product/service description in a way that a product/service can be developed, the stakeholder register is critical to identify key stakeholders. Stakeholders can provide important information on detailed requirements. Moreover, early interaction with stakeholders turns out to be a critical success factor for professional requirements management.
How to Align Requirements Management to Project Phases?
Traditional projects are divided into well-known phases: Initiation – Planning – Execution – Monitoring and Controlling – Closing. Traditionally, requirements management concentrates on the planning phase. But is requirements management less important in the remaining phases?
When a project is initiated it is an important step to identify key stakeholders. Always ask them for their opinion on requirements and find out their true needs and prime expectations as well as the expected business value generated from the project. Get them “on board” as early as possible and involve them in decision-making, which does not start with status meetings or change requests: it already starts when collecting requirements.
Stakeholders can help promote a project and hence promote requirements. Stakeholders are an important source of information, especially on detailed requirements as they may know the customer and its expectations very well.
The goal of the planning phase is to agree upon a mutually acceptable number of requirements between the project and stakeholder/customer. This is mostly about finding consensus. Typically, it is unrealistic that a project can deliver all requirements the customer asks for. Hence, it is important to negotiate requirements and early agree upon the most important ones the project is able to deliver.
In order to achieve an agreed set of requirements various techniques can be applied.
You may start out using the parameters “High, Medium, Low” to group requirements regarding to their Client/Business Value identified in the Initiation phase (Juli, 2010, Appendix B). Be sure to “define the meanings of the various parameters with your project team to secure consistency and coherence of the requirements evaluation.” In order to further classify requirements you can use the same parameters for a second dimension, e.g., technical complexity.
Alternatively, you can utilize the MoSCoW rule proposed by the Dynamic Systems Development Method (VersionOne, 2010) and regularly used in agile projects. The M stands for “Must have requirements,” the S for “Should have if at all possible,” the C for “Could have but not critical,” and the W for “Won't have this time but Would like in the future.”
One-on-one interviews, either formal or informal, are an approach to discover information by talking to people personally. You may like to use the Root Cause Analysis (iSixSigma, 2010) exploring the interviewee's needs and expectations. Following this analysis you may ask “Why?” several times (usually up to five times) to find the root of the needs.
Interviews need not be conducted one-on-one generally. Sometimes talking to more than one interviewee at the same time is the only way to get key stakeholders together. In this case you must ask yourself if more than one interviewer is needed.
Always adapt interviews to your current needs! Keep in mind that interviewing is close to systemic coaching: Help the interviewee explore and find its true needs and hence requirements itself.
The goal of a requirements workshop is to bring key stakeholders together in order to define requirements and reconcile stakeholders’/customers’ differences. Workshops are an interactive approach where issues are discovered and mostly resolved more quickly than in individual sessions. Furthermore, they can leverage trust building, foster relationships and improve communication among the participants. Ideally, this leads to an increased likelihood of consensus.
Have decision-makers attend the workshop! Keep in mind that a consensus on requirements between the project and stakeholders/customers is critical at this stage of the project.
Most times it is applicable not only to focus on one approach but also to combine them, for example one-on-one interviews first and a workshop afterward. In either case you can leverage the agile techniques mentioned. This way a shared vision of project deliverables for every individual as well as all participants together is more likely to be reached.
What makes good requirements?
Several criteria have developed to characterize good requirements with the following approaches among them.
Requirements must be unambiguous, resulting in the following questions to be answered:
Are the requirements…
- Measurable? Delivered requirements can be measured against a baseline of what was expected.
- Testable? Each requirement must be tested before delivery.
- Traceable? Requirements are tracked throughout the project life cycle, e.g., by their status of progress.
- Complete? No other requirements are to be met except for documented ones.
- Consistent? There must not be contradictions among all requirements.
- Acceptable? Requirements must meet stakeholders’/customers’ expectations within a particular project.
The INVEST acronym is typically used to specify user stories in agile project management (for a nice introduction to agile approaches, see Larman, 2004; for an introduction to user stories, see Cohn, 2004). Even though it can be used in traditional project management to specify the quality of requirements, following the INVEST acronym, a good requirement must be Independent, Negotiable, Valuable, Estimatable, Small and Testable (Juli, 2010, Appendix B).
Another criterion for good requirements—originally evolved from agile project management—is the 3 Cs approach (Gadodia, 2010): The 3 Cs stand for:
- Card: A requirement must be as small as to fit on one index card.
- Conversation: Requirements must be as specific as to allow communication on details of the expectations. Basic requirements should already be understood and made clear.
- Confirmation: Each requirement needs acceptance criteria.
Having captured and documented requirements successfully it is now the project manager's responsibility to ensure products and/or services are develop as expected. An adoption of an agile approach to regularly ensure expectations are met can be applied: early implementation of potentially shippable product increments.
Therefore, requirements need to be optimized for productivity via short cycles enabling shipping of frequent Customer Technology Previews for valuable, early customer feedback throughout the project lifecycle (Barry, 2010).
Because product increments are tangible and allow to experiment rather than discussing abstract representations of requirements, early and iterative feedback cycles are helpful to obtain stakeholders’/customers’ feedback on current development.
Make stakeholders/customers touch, feel, and see something real instead of following theoretical presentations.
As time goes by and more of these inspect and adapt cycles are performed, stakeholders/customers develop a more detailed idea of how their expectation is realized and the project manager receives early and regular feedback on the product/service.
Monitoring and Controlling
Requirements evolve as the project evolves. And usually only few requirements are static, which means they are not supposed to change throughout the project life cycle. Hence, changes in requirements happen—and, of course, can be expected. But if changes apply they must be assessed and managed thoroughly.
Surprisingly, this is common sense but not always common practice as it is to combine requirements management and change management.
Professional requirements management interacts closely with change management. It is the project manager's responsibility to ensure adequate collaboration between the requirements manager and the change manager.
The more detailed requirements have been assessed in the planning phase the more professionally can change requests be assessed.
How do you know your project is finished, delivered all requirements and met stakeholders’/customers’ expectations? “The project is finished when all deliverables are handed over to the customer” is a very common approach.
Lessons learned workshops are an established way to close a project and are a great chance for the entire project team to discuss various aspects of the project, both high level and in detail. Ideally, the team does not only learn what could be improved but also what went well in the past project.
Typically, these workshops are only conducted at the end of a project—one lessons learned session per project. It may be of great help to conduct lessons learned workshops after each phase or iteration of the project instead of only one workshop at the end of the project. In addition focused lessons learned workshops concentrate only on one aspect of the project, e.g., requirements management. Hence, they provide the chance to deeply dive into one topic.
In agile practices, the Retrospective Meeting is an event that happens at the end of iterations with the team discussing three things: what went well, what didn't and what could be improved. This way the team gets the insight into the project from the perspective of each member (Kwiecien, 2010).
Following the PMBOK® Guide there are three important outputs from requirements management: requirements documentation, requirements management plan, and requirements traceability matrix (PMI, 2008, p. 109ff).
This artifact shows how each requirement meets the business needs and hence increases the value for the project. Documents simply listing requirements categorized by specific criteria (e.g., complexity, business value, priority) can as well be used as more elaborate forms containing executive summaries, detailed descriptions, and attachments.
Requirements Management Plan
A requirements management plan documents how requirements will be analyzed, documented, and managed throughout the project life cycle.
Requirements Traceability Matrix
A requirements traceability matrix, also known as scope matrix, is a “table that lists all requirements the project team has to deliver as part of the project. It helps categorize and prioritize the requirements in a systematic manner” (Juli, 2010, Appendix B). You can break down and describe all project requirements to an appropriate level of detail. They may start out at high level and become progressively more detailed as more is known.
The content of a requirements traceability matrix may include, but is not limited to linking requirements to business and client value, project objectives, complexity, estimated effort, test scenarios, owner of the requirement, their source, bounding assumptions, and their current status of progress.
Note that the Scope Document includes both functional and non-functional requirements. While often times “technical in nature it is crucial to capture non-functional requirements early in the process […] as they constrain functional ones and hence must not be neglected” (Juli, 2010, Appendix B).
Professional requirements management is an effective and efficient way to improve project success. Nevertheless, one must keep in mind that requirements management is more than only capturing customers’ and stakeholders’ expectations in the beginning of a project. Moreover a project manager must realize it is about managing expectations, true needs and requirements throughout the entire project life cycle, containing all five project phases. Hence, each phase of a project accounts for its own critical success factors to manage requirements professionally.
Barry, Graham. (2007). Microsoft Visual Studio 2005 Team Foundation Server. Retrieved on July 17, 2010 from http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home
Cohn, Mike. (2004). User stories applied – For Agile software development. Boston: Pearson Education, Inc.
Gadodia, Vaibhav. (2010). Six features of a good user story — INVEST Model. Retrieved on July 17, 2010 from http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest.
iSixSigma. (2010). Determine the root cause: 5 whys. Retrieved on July 17, 2010 from http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1308:&Itemid=49#startOfPageId1308
Juli, Thomas. (2010). Leadership principles for project success. New York: CRC Press.
Kwiecien, Marek. (2010). What is a retrospective? Retrieved on July 17, 2010 from http://agile.dzone.com/articles/whatretrospective?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fagile+(Agile+Zone)
Larman, Craig. (2004). Agile & iterative development – A manager's guide. Boston: Pearson Education, Inc.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK®guide) – fourth edition. Newtown Square, PA: Project Management Institute.
VersionOne. (2010). Dynamic systems development method (DSDM). Retrieved on July 17, 2010 from http://www.versionone.com/Resources/AgileMethodologies.asp#DSDM
© 2010, Robert Misch
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington DC