There are many reasons why requirements are crucial to the success of projects.
Information captured during requirements acquisition feeds directly into the activities of bid writing, contracting, project planning and scheduling, risk management, trade-offs, decision-making, project monitoring, acceptance testing, performance management, quality management, change control and reporting. They also feed into the contract and procurement cycles and can be useful in expectation management, relationship management, managing partnerships and, most fundamentally, can underpin communication. Undoubtedly, requirements should underpin many management activities and concerns, while providing a sound basis for subsequent activities. The rest of this section will view requirements through a variety of perspectives, and roles that they enable.
Requirements as a map: A key purpose of the requirements is to provide a blueprint for the development of the project and the required artifacts. The process and resulting documentation are designed to give a better idea about what needs to be done, and how to get there, whilst providing detailed information about the technical aspects. The remainder of the process can be informed and guided by the documented requirements.
Requirements as a test: Continuing with the journey analogy it also provides a means of determining whether the journey has been completed successfully by establishing the specific criteria, or the yardstick, required to test the satisfaction of the stated needs and the achievement of the required functionalities and capabilities.
Requirements as a decision point: The requirements provide managers with a natural go/no go gateway at the beginning of the development and delivery process.
Requirements as insight: The processes of needs assessment and requirement management provide analysts, developers and managers with insights into the issues and concerns of various stakeholder communities. They also enable stakeholders working together with analysts to make better sense of their context and real requirements.
Requirements as communication: The process of identifying needs and eliciting requirements provides a mechanism for engaging with the various stakeholder communities. Intermediate products and statements offer a means and mechanism for facilitating discussion and fostering agreement.
Requirements as a contract: Requirements can be used as the contract that underpins further development. They are often used as a proof of concept and as evidence that developers understand what needs to be done.
Requirements as agreement: Requirements involve negotiation and trade-off between multiple communities, stakeholders, preferences, viewpoints and perspectives. The artifacts employed during the process provide the interface needed to view different positions and reach agreement, documenting the common understanding. The collaborative process of teasing out and ranking the requirements becomes an effective tool for stakeholder engagement and for managing the expectations of the diverse stakeholder communities.
Requirements as management: Managing the set of requirements enables projects to maintain focus on the key needs and agreed requirements. Mapping the requirements offers greater visibility into the activities and processes required in managing the project.
Requirements as quality: Requirements management ensures that the correct system is being built. One of the definitions of quality relates to conformance to requirements.
Specifying requirements with test criteria allows the establishment of measures that can be used in measuring the quality of projects and deliverables.
Requirements as history: Requirements provide a historical record of how an idea or concept came into being.
Requirements as interface: Requirements provide a link between business objectives, stakeholder needs, proposed improvements, and specific projects. They provide traceability from specific endeavors to organizational priorities and back to stakeholder concerns, and thus carry, facilitate, record and enable communication and sharing across different levels, communities and concerns.
anD The counTer-case: Why We cannoT Do WiThouT iT
The consequences of wrong, incomplete or messy requirements are rejection of the system by stakeholders whose needs have not been addressed, the need to retrofit and make corrections to released systems, loss of confidence and reputation, loss of money and the potential for ultimate project failure. Young (2006) points out that errors in requirements account for the largest class of errors typically found in a project, using examples of between 41–56% of errors discovered overall. Other evidence also identifies a range of 40–60%. The figures suggest that the greatest impact can be accomplished by correcting, or not making, errors during the requirements activities. Additional effort invested in improving the requirements process may prove a cost-effective investment.
Requirements determination is a particularly volatile phase, as requirements are unearthed during the initiation phases when the level of uncertainty about the project is at its greatest (Figure 9.3, mouth of the cone showing the greatest degree of variance).
Accurate estimates can be made when the requirements are understood and agreed, offering a greater degree of confidence in what needs to be addressed, and what the financial implications might be. The sooner a mutual understanding of the project is achieved, the greater the likelihood of deriving correct products, reflective plans and accurate estimates.
155 r e q u i r e m e n t s M a n a g e m e n t
It is now generally accepted in project management that the cost to affect changes and correct errors increases dramatically as the project progresses (Figure 9.4).
When errors are found later in the life-cycle they cost significantly more to trace, address, re-do and integrate. Discovery during acceptance testing will typically cost between 30 to 70 times the cost of correcting the same error during requirements analysis and specification, while correction when the system is operational would fit in the range of a factor of 40–1,000. The relative cost of correcting errors is a function dependent on the phase during which they are corrected. The cheapest and easiest time to make changes is early in the process, when their effects can still be modeled on paper. From a monetary perspective, the ability to cost-effectively control the outcome of the project decreases rapidly in accordance with the life-cycle phase. Consequently, reducing requirements errors and investing additional time and resources in finding and correcting errors and Figure 9.3 cone of uncertainly surrounding a project
Figure 9.4 the relative cost to fix a problem as a function of time Requirements
Analysis Design Cost of
finding a fault
Implementation Delivery In service
omissions early on constitute the single most effective course of action that developers and mangers can take to mitigate failures and improve project outcomes.
Requirements activities do not fall within the remit of project management.
Requirements elicitation, analysis, prioritization and specification require specialist skills which are normally provided by systems analysts, business analysts, requirements analysts, business process reengineering (BPR) specialists, enterprise architects or requirements engineers. However they clearly impact on project outcomes and therefore should constitute a key concern for project managers.
The Standish Group (2010) has been tracking the reason for project failures for two decades. They regularly publish the top 10 reasons for project failure. Figure 9.5 shows the factors from their 2010 report.
The second column shows which factors relate to requirements management with 2 representing a direct impact, and 1 an area that might be improved as a result of greater attention to requirements management. The table indicates that requirements management issues have a clear impact on the outcome and potential failure of projects as major impacts can be identified across at least four of the 10 items, with some impact indicated for at least two additional factors. Hull et al (2011) show a similar exercise Figure 9.5 top 10 reasons for projects to be challenged
157 r e q u i r e m e n t s M a n a g e m e n t
for earlier results of the survey: factors related to failures in requirements management account for 51.6% of project failures, while successful requirements management practices also appear to be associated with 42% of the factors identified as leading to success.
Requirements management clearly plays a key part in the success or failure of projects and therefore merits more attention from the project management community. Young (2006) contends that project managers can provide the focus for requirements activities by:
1. Setting a high standard for project requirements, demanding and facilitating good requirements analysis, and not accepting inferior requirements;
2. Receiving support from project managers for requirements work, including a greater proportion of project resources;
3. Using the requirements, assumptions and risks that emerge from the elicitation and analysis activities to shape and refine project plans;
4. Ensuring that the right requirements practices, methods and approaches are deployed according to the type of project;
5. ‘Working behind the scenes’ to ensure that all relevant stakeholders are identified and influencing them to support and participate in the requirements activities.
Given the importance of requirements activities we might add an additional requirement:
6. Employing experienced and well qualified analysts to support and underpin the discovery, communication and management of better requirements that underpin successful projects.
Identifying excellent analysts with communication and facilitation skills will be a good first step towards improving the track record of dealing with requirements.
DifficulTies associaTeD WiTh neeDs anD requireMenTs
Table 9.1 shows key difficulties and hurdles associated with instituting and executing requirements management activities on projects.
Not surprisingly, the majority of concerns appear to relate to softer factors associated with people, communication, understanding, politics, knowledge, needs, expectations, conflict, influence, agreement, disagreement and finding good people.
concluding remarks
Requirements involve people. Skilled specialists are used to work with different groups to identify their concerns and needs. The difficulties attached revolve around softer issues ranging from politics, to biases, and from expectations to acceptance and collaboration. Yet, requirements also embody strategic considerations. Needs analysis enables organizations to build a bridge between strategic goals and business case on the one hand, and design and deployment of solutions that underpin and support the organization on the other. The requirements management process translates ideas and needs into a formal document which defines and delineates the expectations related to a project, product or outcome. Traceability provides a much-needed link between the
levels and perspectives. Project management is unlikely to succeed without the support of requirements management. Requirements describe how a project will meet the business needs that the organization is endeavoring to address as well as guiding the execution of that action. Without requirements management it is difficult to know what has been achieved and who might be satisfied with the results.
table 9.1 Difficulties associated with implementing requirements management process
Issues with Nature of difficulties
stakeholders • need for stakeholder involvement (and their time availability
• ability to articulate needs
• multiplicity of viewpoints and perspectives
• conflicting needs
• need to reconcile needs of different stakeholder groups
• non-negotiable demands
• ranking all needs as high priority
• changing needs
• changing stakeholders environment • ill-defined system boundaries
• poor understanding of the problem domain
• conflicting priorities
• changing needs
• rapidly changing requirements (a.k.a. requirements volatility)
• fragmented information
• power and politics
requirements process • identifying and involving all stakeholder groups
• confusing wants and needs
• addressing the needs of the wrong stakeholder group
• focusing on the ‘what’ rather than the ‘how’
• translating needs into requirements
• stakeholders specifying unnecessary technical detail that confuses rather than clarifies the objectives
• specifying ambiguous requirements
• unrealistic trade-offs
• ranking all requirments as high priority
• determining completeness; establishing if there are any gaps or omissions
• measuring the ‘value’ of requirements
• inattention to business requirements human resources • problems with natural language as medium
• differing interpretations
• how do we know that the needs have been understood?
• complexity of mapping real needs
• poor understanding of the capabilities needed
• communication difficulties
159 r e q u i r e m e n t s M a n a g e m e n t
• omitting ‘obvious’ information
• identifying assumptions
analysts • expertise is not clearly defined and stated
• need to access tacit and unknown facts and intuitions
• analyst’s ability to translate between user needs and system requirements
• limited user domain knowledge
• complexity of integrating multiple perspectives and concerns
• premature identification of solution/s
• establishing priorities and trading-off needs and requirements
• lack of appreciation of politics and power in the organization
By way of a conclusion, the following list inspired by Meyer (1985) offers a re-organization of the seven deadly sins in the context of requirements specifications:
1. Noise: The presence of elements containing information that is not relevant to the problem, or unnecessary repetition of the same item.
2. Silence: Relevant and important aspects of the problem that were omitted from the formulation.
3. Over-specification: Focusing on the implementation of a solution instead of the needs, or the problem.
4. Contradictions: Describing the same aspects in two or more different and incompatible ways.
5. Ambiguity: Use of language that allows the interpretation of a requirement in two or more ways.
6. Forward reference: Features are used before they are defined.
7. Wishful thinking: Using fanciful and unrealistic descriptions that cannot be met by a realistic solution or cannot be realistically tested.
Above all the list seems to offer much needed precision and focus to guide the exploration of our needs, and direct the execution of our desires.
references and further reading
APM, 2012, APM Body of Knowledge, 6th edition, High Wycombe, UK: Association for Project Management.
Brennan, K., 2009, A Guide to the Business Analysis Body of Knowledge, London: International Institute of Business Analysis.
Davis, A.M., 2005, Just Enough Requirements Management, New York: Dorset House Publishing.
Doran, G.T., 1981, There’s a S.M.A.R.T. Way to Write Management Goals and Objectives, Management Review, 70(11), 35–6.
Frame, J.D., 2003, Managing Projects in Organizations: How to Make the Best Use of Time Techniques and People, 3rd edition, San Francisco, CA: Jossey-Bass.
Hood, C., Wiedemann, S., Fichtinger, S. and Pautz U., 2008, Requirements Management: The Interface between Requirements Development and Other Systems Engineering Processes, Heidelberg: Springer.
Hull, E,. Jackson, K. and Dick, J., 2011, Requirements Engineering, London: Springer.
Jonasson, A., 2012, Determining Project Requirements, Boca Raton, FL: Auerbach Publications.
Meyer, B., 1985, On Formalism in Specification, IEEE Software, Vol. 2, no. 1, 6–26.
Robertson, S. and Robertson, J., 2004, Requirements-led Project Management; Discovering David’s Slingshot, Boston: Addison-Wesley.
Robertson, S. and Robertson, J., 2012, Mastering the Requirements Process: Getting Requirements Right, Boston: Addison-Wesley.
Standish Group, 2010, The Chaos Report, Yarmouth, MA: The Standish Group.
Young, R.R., 2006, Project Requirements: A Guide to Best Practices, Vienna, VA: Management Concepts.
chapter
10 Managing Scope and Configuration
Hemanta Doloi
Projects are strategic tools of organizations which help them to achieve their business goals and objectives (Chapter 3). Projects provide different deliverables including products, services, knowledge and so on. Project deliverables create business changes and these business changes help organizations achieve their goals (Chapter, 2, Turner, 2009). In the context of developing a project scope management plan, project scope must include all the activities and only activities that should be performed to provide the deliverables. However, an important issue in scope delivery is how to align business goals and objectives with the project activities. Lack of effective scope management will lead to different issues such as unsatisfied customers and potentially contribute significantly to the failure of the project. Thus, project managers need a comprehensive approach in scope management.