Download PDF Excerpt
Rights Information
Project Requirements: A Guide to Best Practices
Ralph R. Young (Author)
Publication date: 03/01/2006
Clarify real requirements before you initiate project work
Improve management of project requirements
Save time and effort
Manage to your schedule
Improve the quality of deliverables
Increase customer satisfaction and drive repeat business
Project Requirements: A Guide to Best Practices provides project managers with a direct, practical strategy to overcome requirements challenges and manage requirements successfully.
Find out more about our Bulk Buyer Program
- 10-49: 20% discount
- 50-99: 35% discount
- 100-999: 38% discount
- 1000-1999: 40% discount
- 2000+ Contact ( [email protected] )
Clarify real requirements before you initiate project work
Improve management of project requirements
Save time and effort
Manage to your schedule
Improve the quality of deliverables
Increase customer satisfaction and drive repeat business
Project Requirements: A Guide to Best Practices provides project managers with a direct, practical strategy to overcome requirements challenges and manage requirements successfully.
Ralph R. Young, DBA, has led projects in local government, management information systems, systems and software engineering, process improvement, and systems integration. He is the author of four books that address aspects of requirements engineering. Dr. Young is a graduate of the University of New Hampshire and holds an MA in economics and a DBA from The George Washington University.
CHAPTER
1
Introduction
When all is said and done, project success comes down to project performance: cost, schedule, and quality. Adopting requirements-shaping practices can greatly improve your project’s probability of success. Additional investment in understanding user requirements early in the project, before you initiate other technical work, will reduce the amount of rework that must be performed. In fact, the reduced rework will pay for any additional costs associated with improving the requirements process!
Granted, this investment needs to be made early, and recouping it will take time. But proceeding without knowing what users really require is asking for problems and, rest assured, will incur added costs for rework. The project manager (PM) needs to address uncertainties using appropriate methods, techniques, and tools, including requirements-shaping PM practices, stakeholder modeling, prototyping, risk analysis, and careful analysis of assumptions.
The Impact of Requirements on Project Success—A Project Management Professional’s Perspective
Numerous surveys conducted during the past decade, including the most widely quoted information technology (IT) industry CHAOS research, have identified requirements issues as a major reason for project failure. PMs have repeatedly experienced this, as we encounter poor requirements processes (or the lack thereof) as a key project issue in our high-priority projects.
For example, based on years of experience in the project management profession, we PMs find requirements gathering to be a very time-consuming activity. In some projects, requirements gathering can take up 25 percent of the project’s life cycle. Yet this activity can be futile, if it doesn’t result in delivering a complete and accurate set of customer requirements. Many organizations continue to treat requirements gathering as an activity, not as a standardized organizational process. To be effective, requirements gathering has to be structured and conducted in collaboration with customers and in association with other requirements activities involving customers, such as requirements elicitation and requirements validation.
PMs can also point to numerous unsuccessful projects, challenged mainly by the project team’s inability to control scope creep. Although this is a very common problem in project development, many project-oriented organizations are unable to manage and control scope creep effectively. Scope changes, depending on when they are introduced to the project, can increase development work (and rework) tremendously. Although project changes, including scope changes, are inevitable, requirements processes in managing and controlling scope changes can help improve the likelihood of project success. Scope changes, along with already accepted requirements, should be reprioritized to contain the entire project scope and to deliver the project according to the predetermined project time line, as originally planned.
Another approach to effectively handling requirements changes is by introducing and institutionalizing a requirements change management process. This can be as simple as requiring change request forms (or change orders) for scope changes and setting up a change control board that is responsible for assessing the project impact of change requests: reviewing, approving, and rejecting change requests. Although it seems simple to implement, many organizations do not take this approach, because customers do not conform to completing change orders and consider the approach too bureaucratic.
PMs have found a number of requirements tools and techniques that are used in requirements processes in the IT industry to be very helpful in improving project success rates. These include requirements traceability matrixes, prototypes, and use cases.
With many PMs familiar with the practice of conducting lessons-learned sessions and applying lessons learned from previous projects to subsequent projects, we use lessons-learned practices in preventing the recurrence of requirements problems and issues. We track requirements issues in current projects and ensure that we address them (and prevent their recurrence) in subsequent projects by introducing and implementing appropriate requirements processes in project development. Guidelines on project management methodology, and project management tools and techniques from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute 2004) are very helpful in establishing and institutionalizing appropriate requirements processes.
In the current state of requirements management in the project management profession, PMs raise and highlight requirements issues as they arise. They attempt to use requirements processes to address the issues. If all PMs apply lessons learned to prevent the recurrence of requirements problems, many requirements issues can be identified and resolved during the early stages of project development or can even be eliminated during project development.
This is not all that simple, however, because many requirements processes require the customers’ involvement and participation, as well as their cooperation and collaboration. Some requirements processes present implementation challenges.
As project management communities in IT organizations focus on tackling the major causes of project failure and take steps to address these requirements issues, PMs are finding that the implementation of organizational requirements processes can and do contribute to project success.
Victoria Kumar, PMP
HOW THE PM WILL BENEFIT BY PAYING ATTENTION TO REQUIREMENTS
The Data and Analysis Center for Software (DACS), a U.S. Department of Defense Information Analysis Center, reports that more than 75 percent of large software projects suffer significant cost and schedule overruns or fail outright. Deficits in project requirements cause more than half of these failures and overruns. This is in part the result of the high complexity of the requirements task (by no means limited to technical complexity!). Finding ways to manage and reduce the complexity is an important step in reducing the risks of software development.
By paying attention to requirements, the PM will improve the likelihood that his or her project will be successful.
WHAT ARE REQUIREMENTS AND WHY ARE THEY IMPORTANT?
A requirement is a statement of a customer need—a statement that identifies a condition, capability, characteristic, or quality factor of a system that is necessary for the system to have value and utility to a user. User requirements specify the verified needs of the intended users of the system (regardless of whether the user chooses to exercise them in the provided system) and system requirements identify a condition, capability, characteristic, or quality factor of the planned system. The Capability Maturity Model Integration (CMMI®), which is the current industry framework for process improvement, uses the term product requirements as a refinement of the user requirements into the developer’s language; the developer uses the product requirements to guide the design and building of the product (the system).
Requirements are important because they reflect the needs of the customer and users, and because they provide the basis for all the other technical work that is done on a project. Requirements are so important because they:
• Document a common understanding between customers/users and the contractor and provide a basis for work
• Define “what,” not “how”
• Ensure that an engineering project is completed within cost and schedule constraints to the customer’s satisfaction (managing the customers’ and users’ expectations is an important factor).
Figure 1-1 describes what drives requirements.
Understanding requirements is the cornerstone of effective project cost and schedule estimation. A clear understanding of and agreement on the requirements must be reached and committed to by the project and all stakeholders. A defined process for requirements development and requirements management should be established, documented, followed, and continuously improved. Nevertheless, requirements changes are inevitable and must be planned for, managed, and controlled.
Figure 1-1 What Drives Requirements?
Source: Adapted from an original work by Ivy Hooks. Used with permission.
By understanding “requirements basics,” you gain an increased understanding of the importance of requirements to project success.
WHY PAY ATTENTION TO REQUIREMENTS?
Requirements are the basis of all the technical work performed on projects. Major contributing factors to requirements problems include incorrect facts, omitted requirements, lack of user input, incomplete requirements, and changing requirements.
If we don’t handle requirements properly, we incur significant risk. In fact, investing more in your project’s documented requirements process can save at least half the cost of your project.
Other reasons to pay attention to requirements include:
• Requirements errors are the largest class of errors typically found in a project (41–56 percent of errors discovered [Hooks and Farry 2001]).
• Reducing requirements errors is the single most effective action developers can take to improve project outcomes.
• Identifying omitted requirements and finding errors during the requirements stage (as opposed to later stages of the life cycle) provide great leverage (and cost savings).
• The cost of rework is typically 45 percent of projects (Dion 1993, McConnell 1996).
• Requirements-related activities can reduce rework substantially.
Paying attention to requirements will have a major positive impact on controlling project costs.
In this book I distinguish between stated requirements and real requirements. The “stated” requirements are the requirements that are provided to a project by a customer at the beginning of a system or software development effort. Experience has shown that the stated requirements are hardly ever the real requirements. Customers and users need help to evolve the stated requirements into the “real” requirements—requirements that reflect the verified needs for a system.
Understanding the difference between “stated” requirements and “real” requirements is fundamental to improving project results.
WHY THIS BOOK?
I have written two other books concerning requirements. Effective Requirements Practices provides a set of recommended practices and describes what to do. The Requirements Engineering Handbook describes how to perform requirements work. Both books are targeted at the practitioner: the requirements manager, requirements analyst (RA), requirements engineer, systems analyst, or business analyst charged to lead and perform requirements elicitation, analysis, development, and management duties.
However, it is the PM who leads the overall project and is in a position to allocate project resources. I have written this book to explain how you can improve project success by paying more attention to requirements. I believe that for the project management profession to be more successful, PMs need to direct additional focus on requirements.
Some of the key ways that PMs can provide this focus are the following:
1. PMs must demand and facilitate good requirements analysis, not just tolerate what they get (or worse).
2. Those who are actually performing “requirements work” need the support of their PM so that a greater proportion of the project’s resources can be allocated to the requirements process.
3. Crucially, PMs must take on the requirements that are discovered during the project, as well as assumptions and risks that are identified during the requirements process, and use them to shape and refine the project’s plans.
4. The PM can help ensure that the right requirements practices, methods, techniques, tools, and templates are deployed for the type of project.
5. The PM can work “behind the scenes” to ensure that all stakeholders are identified and to impress on them how important they are in helping guide the project in the right direction by providing, prioritizing, and checking their own requirements. (Note that there are always many stakeholders who are not users; they too will place essential requirements on a development project.)
Identifying Project Stakeholders
Your project’s stakeholders include all the people who contribute in some way to the project’s success or failure. The first step to effective collaboration is to find the necessary people and to establish who needs to be involved in what.
Traditionally we did this by identifying the users—people who will have a “hands on” connection to the end product—and the developers—people who will build the product. However, this approach misses many important stakeholders and consequently many requirements. For example, if you are building a banking system and your only source of requirements is the tellers, then you will get requirements specific to doing the job of a teller. You will miss the requirements of the branch supervisor, the bank customers, the people who open the mail, the security guards . . . and any other stakeholder whose knowledge or needs affect the product you are building. On the other hand, you don’t want to go in the opposite direction and involve too many people.
The purpose of doing a project stakeholder analysis is to identify the stakeholders who are relevant to your project. This includes people who have an active role in building or using it or whose knowledge is necessary to make it fit into the world.
To identify these people and provide the basis for discovering requirements, start your project by doing a Stakeholder, Goals, Scope (SGS) cycle analysis. This approach uses each of these components as the driver for asking questions, defining details, and determining connections. For example, if you have a stakeholder on your list, then there must be some specific knowledge within the scope that comes from that stakeholder and that knowledge must be relevant to the project’s goals.
When using the SGS approach people often ask, “Should we find the stakeholders first, analyze the goals, or try to define the work and product scope?” We actually do all these things in parallel. Discoveries about one lead to questions and answers about another. We are looking for a balance between the sources of the subject matter (stakeholders), the business reasons for doing the project (goals), and the subject matter we need to investigate (scope).
There are many ways of representing the results of an SGS analysis; some suggestions are:
• The stakeholders define the human society that has some effect on the success or otherwise of the project. A project stakeholder is someone who gains or loses something (could be functionality, revenue, status, compliance with rule) as a result of that project. Represent as a stakeholder map or a stakeholder spreadsheet.
• The goals define the success criteria for the project. They answer the question: How will we know if this project is or is not a success? The goals are used to guide the project and to help the project team make choices about where to concentrate their efforts. Represent as measurable statements covering purpose, advantage, and measurement.
• The scope defines the boundaries of the investigation and the boundaries of the product to be built by the project. We have learned that it minimizes confusion if we build two scope models—one for the requirements investigation and one for the product. Represent as a work context diagram and a product context diagram.
During your SGS session you discover and define the sociology of your project. This provides a foundation for discovering relevant requirements and formally tracing them throughout the project’s life. To learn more about this approach, see the articles and templates at www.volere.co.uk.
Suzanne Robertson
The Atlantic Systems Guild Ltd
Many of the key issues and problems of PMs can be addressed by improving the project’s requirements process.
REQUIREMENTS ACTIVITIES IN THE PROJECT LIFE CYCLE
Many believe that requirements activities are performed only during the early stages of a project. In fact, the requirements process involves a set of activities that is performed throughout the full life cycle of the project.
Requirements-related tasks span the entire project life cycle.
The typical project life cycle encompasses a feasibility analysis phase, a requirements analysis phase, a design phase, a development phase, a testing phase, and finally a deployment phase. A project life cycle can of course be characterized by additional phases and stages; for instance, feasibility and requirements analysis can be broken down into more detailed and specific activities such as:
• Identifying the stakeholders
• Gaining an understanding of the customers’ and users’ needs and expectations (known to requirements specialists as “requirements elicitation”)
• Identifying the stated requirements
• Clarifying the requirements
• Evolving the real requirements
• Specifying and prioritizing the requirements
• Identifying the derived requirements
• Identifying the interface requirements
• Performing requirements traceability (see Appendix A for a discussion of the value and importance of this critical activity)
• Identifying the verification approach
• Iterating the requirements and the system or software architecture.
Requirements-related activities that occur during the design and development phases include developing the architecture, partitioning requirements, allocating requirements, and performing requirements verification.
The next phase of the project life cycle is testing. Because the objective of the test phase is to confirm that all requirements are met in the system or software, considerable requirements-related effort is undertaken during this phase. Some projects spend as much as 40 percent of total project cost on testing—and doing a better job during requirements analysis can reduce this proportion significantly. For example, industry data concerning requirements errors indicate that half the errors are the result of incorrect facts and another 29 percent are the result of omitted requirements (Hooks and Farry 2001). Taking steps to address these two areas during requirements analysis can reduce both rework and the testing effort considerably.
The final phase of the project life cycle is deployment. Validation is a process for confirming that the real requirements are implemented in the delivered system.
Thus, the requirements process involves a whole set of activities performed throughout the full life cycle of the project. Table 1-1 describes the requirements work products that result from these activities.
REQUIREMENTS-SHAPING PM PRACTICES
The PM’s role is crucial to understanding and effecting needed improvement. So what can a project manager do to implement requirements-shaping practices on a project? For starters:
1. Jointly with the customer and users, evolve and understand the real requirements before initiating other project work. Identify the minimum requirements that will meet real needs for the agreed-on vision and scope of the initial delivery of the software or system to be developed. If you have concerns about the concept of “minimum requirements,” see Appendix B for a short, convincing article. (See Chapter 2.)
2. With your customers and users, use mechanisms to manage changes to requirements and new requirements jointly. Limit requirements volatility to 0.5 percent per month (6 percent per year), realizing that higher levels will result in loss of control of the project and the inability to deliver it. (See Chapter 2.)
3. Invest 8 to 14 percent of total project costs in a documented and continuously improved project requirements process. Engage all stakeholders in requirements activities throughout the development of the software or system. Use trained and experienced RAs. Perform requirements planning. (See Chapter 2.)
4. Use the partnering process from the initial startup of the project to gain and maintain the commitment of all stake-holders to project success. (See Chapter 3.)
5. Recognize and appreciate your staff. (See Chapter 3.)
6. Reduce wasted time and effort in project startup. (See Chapter 4.)
7. Foster effective teamwork among the project staff. (See Chapter 5)
Table 1-1 Requirements Work Products
8. Be an effective coach. (See Chapter 6.)
9. Strengthen communications. (See Chapter 7.)
10. Provide the “right amount” of discipline and process. (See Chapter 8.)
11. Establish an attitude of continuous improvement on the project and ensure that all project staff practice it as second nature in everything they do. (See Chapter 9.)
12. Identify, prioritize, mitigate, and manage project risks. (See Chapter 10.)
13. Incorporate a proactive quality assurance (QA) role on the project. (See Chapter 11.)
14. Ensure that executive sponsorship and senior management support are provided and communicated to the project staff. (See Chapter 12.)
By using a set of proven requirements best practices, the PM will improve the probability of the project being successful.
Although some of the recommended practices may be familiar from your previous experiences, we generally don’t actually incorporate these best practices in our daily work. We recognize the need for the practices, but we don’t incorporate the discipline to deploy, implement, and institutionalize the best practices. In other words, we know what to do, but we often don’t do it because it requires more discipline, practice, and perseverance than we are used to providing.
I believe that we can do much better than the current state of project management practice. We can improve project success rates, we can achieve greater customer satisfaction, we can save time and money, and we can increase job satisfaction and fulfillment from our own work and that of everyone else involved.
Achieving these goals requires leadership and coaching by dedicated PMs. And the PMs are in the best position to lead project efforts. This leadership includes guiding people outside the project and not putting inappropriate pressure on project staff, for example, to reduce budget or time allocated to requirements-related activities, to start coding prematurely, to using testing to provide quality rather than building quality into the process and products, and so forth. One aim of this book is to contribute to your own quest for more project and personal success, as well as added job fulfillment.
SETTING EXPECTATIONS CONCERNING THE REQUIREMENTS
Among the many areas in which the PM must set expectations, five are at the top of my list:
1. Identify the real needs that are to be met by the development effort. Here, the PM can rely on his or her requirements manager and RAs to identify the real requirements (assuming they use effective requirements practices to do this). Failure to identify the real requirements before initiating other technical work was previously identified as the number one problem in requirements engineering.
2. Control new requirements and changes to requirements. Here again, the PM can rely on his or her requirements manager and RAs to help, providing the PM is leading the project team and setting the expectations of the customer and users. Failure to control new requirements and changes to requirements during the system or software development effort was previously identified as the number two problem in requirements engineering.
3. Invest in the requirements process. Failure to invest sufficiently in the requirements process was previously identified as a major industry weakness. The added investment in the process will easily repay the added cost in savings that accrue to the project as a result of the use of effective requirements practices.
4. Establish an environment of teamwork and support of each other among all project stakeholders and particularly on the project team.
5. Establish an attitude of continuous improvement among all project staff.
GOALS OF THIS BOOK
The goals of this book are to:
• Provide ideas and suggestions that will enable you to be even more successful as a PM
• Suggest approaches that will benefit your project and improve its chances of being “successful”
• Provide an informed basis for you to have an even more positive impact on your project staff
• Enable improvement in the success rates of systems and software projects within the project management profession
• Provide added job fulfillment for you and for the people on your staff
• Motivate you to select a few ideas, strategies, methods, and tools that will make a bigger difference in your workplace
• Convince you that it’s worth your valuable time to address requirements issues.
Chapter 2 of this book provides and explains a set of key success factors. Experience has shown that incorporating these key success factors into your project approach will greatly enhance the probability of a successful outcome. The most important key success factor is to evolve and understand the real requirements before initiating other technical work and to identify the minimal number of requirements that will meet real needs.
Chapter 3 recommends an approach called partnering. This approach extends significantly beyond the normal use of the term, particularly with respect to commitment to project success. Partnering is a proven, powerful process that you can use to garner the commitment of all stakeholders for project success.
Chapter 4 presents a set of requirements-related project startup issues and suggests remedies for them. A requirements-related startup checklist is also provided.
Chapter 5 addresses fostering effective teamwork. An effective, empowered team can accomplish almost anything it sets out to do. This chapter describes how to create a team environment and how to provide mechanisms that work to everyone’s advantage.
Chapter 6 addresses the PM as “coach.” Your job is to mentor and support each and every member of your team so that the team has the best possible probability of being successful. Specific suggestions relating to how you can coach your requirements manager, analyst, or engineer are provided.
Chapter 7 presents the cornerstone concept of the whole book, and indeed, of all that has ever been written and said about project management: communication! Communication is almost always severely challenged on technical efforts. This chapter offers some ideas and suggestions that will help foster superior project and interpersonal communications.
Chapter 8 addresses the “right” amount of discipline and process. It seems that we have basically two camps in U.S. industry (perhaps even in world): process geeks who obstinately and intolerantly advocate the use of process as the solution to all problems, and those who have no use for process. What is the right amount of discipline and process to foster project success? This chapter addresses why a degree of discipline and process support project success.
Chapter 9 moves beyond discipline and process to the concept of continuous improvement. Establishing an attitude of continuous improvement on a project harnesses the energy and resourcefulness, the ideas and the imagination, and the work ethic and knowledge of every member of the team to work toward improving project effectiveness, efficiency, and success.
Chapter 10 recommends that you start or improve a risk management program on your project. There is a lot of talk about risk management in the project management world, but there is not enough action. This chapter will arm you with strategies for confronting risks as well as for making aggressive risk-taking possible.
Chapter 11 suggests that you use or strengthen what I call an “integrated quality approach” on your project. I advocate proactive QA and having trained, competent QA professionals who can make an enormous contribution to your project.
The final chapter in this book, Chapter 12, provides a summary of all these topics as well as suggested implementation steps. Appendices A through C offer further insights into some key areas discussed in the chapters.
Standardized Terminology and Processes
A standardized approach allows project managers to learn from each other’s diverse and rich experiences. Otherwise, there is bound to be miscommunication and misunderstanding that will inhibit the learning process. PMI® has spent several decades collecting terms from many industries and standardizing them. Project management processes across industries also are quite similar. As part of the quest for standardization, PMI® has published A Guide to the Project Management Body of Knowledge (PMBOK® Guide), which is updated every few years.
Any time an individual uses the word “project,” “process,” or “requirement,” a very specific image, meaning, and set of feelings come to mind, depending on the individual’s personal and professional background. The following are key requirements-related terms from the PMBOK® Guide (PMI® 2004). Incorporating these terms into your project’s glossary will facilitate a common understanding and save time and effort.
acceptance criteria—those criteria, including performance requirements and essential conditions, that must be met before project deliverables are accepted
baseline—the approved, time-phased plan (for a project, a work breakdown structure component, a work package, or a schedule activity), plus or minus approved project scope, cost, schedule, and technical changes; generally refers to the current baseline, but may refer to the original or some other baseline; usually used with a modifier (e.g., cost baseline, schedule baseline, performance measurement baseline, technical baseline)
change control—identifying, documenting, approving or rejecting, and controlling changes to the project baselines
change control board (CCB)—a formally constituted group of stakeholders responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, with all decisions and recommendations being recorded
change request—requests to expand or reduce the project scope; modify policies, processes, plans, or procedures; modify costs or budgets; or revise schedules; requests for a change can be direct or indirect, externally or internally initiated, and legally or contractually mandated, or optional; only formally documented requested changes are processed and only approved change requests are implemented
contract statement of work—a narrative description of products, services, or results to be supplied under contract
deliverable—any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project; often used more narrowly in reference to an external deliverable, which is a work product subject to approval by the project sponsor or customer
design review—a management technique used for evaluating a proposed design to ensure that the design of the system or product meets the customer requirements, or to ensure that the design will perform successfully, can be produced, and can be maintained
earned value management (EVM)—a management methodology for integrating scope, schedule, and resources, and for objectively measuring project performance and progress; performance is measured by determining the budgeted cost of work performed (i.e., earned value) and comparing it with the actual cost of work performed (i.e., actual cost); progress is measured by comparing the earned value with the planned value.
product scope—the features and functions that characterize a product, service, or result
project charter—a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities
project scope—the work that must be performed to deliver a product, service, or result with the specified features and functions
project scope management plan—the document that describes how the project scope will be defined, developed, and verified; that describes how the work breakdown structure will be created and defined; and that provides guidance on how the project scope will be managed and controlled by the project management team; contained in or is a subsidiary plan of the project management plan; informal and broadly framed, or formal and highly detailed, based on the needs of the project
project scope statement—the narrative description of the project scope, including major deliverables, project objectives, project assumptions, project constraints, and a statement of work, that provides a documented basis for making future project decisions and for confirming or developing a common understanding of project scope among the stakeholders; the definition of the project scope—what needs to be accomplished
project summary work breakdown structure (PSWBS)—a work breakdown structure for the project that is only developed down to the subproject level of detail within some legs of the work breakdown structure, and in which the details of those subprojects are provided by the use of contract work breakdown structures
requirement—a condition or capability that must be met or provided by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document; includes the quantified and documented needs, wants, and expectations of the sponsor, customer, and other stakeholders
scope—the sum of the products, services, and results to be provided as a project
scope change—any change to the project scope; almost always requires an adjustment to the project cost or schedule
scope creep—adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval
scope definition—the process of developing a detailed project scope statement as the basis for future project decisions
scope planning—the process of creating a project scope management plan
scope verification—the process of formalizing acceptance of the completed project deliverables
service—useful work performed that does not produce a tangible product or result, such as performing any of the business functions supporting production or distribution; contrast with product and result
specification—a document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system, component, product, result, or service and, often, the procedures for determining whether these provisions have been satisfied; examples include requirement specification, design specification, product specification, and test specification
statement of work (SOW)—a narrative description of products, services, or results to be supplied
voice of the customer—a planning technique used to provide products, services, and results that truly reflect customer requirements by translating those customer requirements into the appropriate technical requirements for each phase of project product development
work breakdown structure (WBS)—a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and to create the required deliverables; organizes and defines the total scope of the project; each descending level represents an increasingly detailed definition of the project work; the WBS is decomposed into work packages; the deliverable orientation of the hierarchy includes both internal and external deliverables.
work breakdown structure dictionary—a document that describes each component in the WBS; for each WBS component, the WBS dictionary includes a brief definition of the scope or SOW, defined deliverables, a list of associated activities, and a list of milestones; other information may include responsible organization, start and end dates, resources required, an estimate of cost, charge number, contract information, quality requirements, and technical references to facilitate performance of work.
work package—a deliverable or project work component at the lowest level of each branch of the WBS; includes the schedule activities and schedule milestones required to complete the work package deliverable or project work component.
Source: Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK ® Guide)—Third Edition, Project Management Institute, Inc., 2004. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI®.
It is my fervent hope that:
• You will be more successful by considering, adopting, and enacting suggestions and recommendations provided in this book—particularly, the recommended requirements best practices for the PM
• You and your project staff enjoy added fulfillment from your work-related activities
• Industry practices and performance will be helped.
You and your fellow program and project managers are the key to achieving these goals.
