In the last lesson, we discussed the scope management work process. Then we started to look at the work process to develop a project scope statement, including developing the scope management plan. In this lesson, we'll learn how to develop the project requirements, an essential element of a project scope statement. We will also look at the scope validation process and discuss its importance. So, we have a new project. Where do we find the requirements? In some cases, the project charter or the contract for the project defines all of the requirements. This is typically the case where the project has been studied extensively and is a well known activity. The requirements may be referenced in a set of specifications in a detailed scope statement attached to a reference in these documents. This is an ideal situation. However, even when it appears that the requirements are well documented, many times there are hidden requirements that are not fully explained. So, what do we do if the project charter or the contract does not contain all of the requirements? If the requirements are not well-defined, or if we want to test to see if there are hidden requirements, then we will want to look for other sources. A good place to start is to use some of the processes listed here. The first approach is to read and incorporate available data in the requirements traceability matrix. To do this, we should review the project charter, contract, bid documents, or specifications, to the extent they exist. These sources will contain the written and documented requirements for the project and give us a starting baseline. The next step is to survey the stakeholders. This can be done in several different ways. Face-to-face interviews, facilitated workshops, formal surveys or questionnaires. If there's a product, or process prototype, that has been produced for our project or a similar project, we can use this to help us define the requirements. Finally, we look to similar products and projects to incorporate similar requirements that have been used in the past. It is important that we keep track of the source of each one of these requirements that we collect. It's not unusual that we go through this process of collecting requirements. We collect conflicting requirements from different sources. Different stakeholders will hold different views on what the project is trying to accomplish. Other sources may conflict with the stakeholder and each other. The key in this first step is to document all the sources and all potential requirements. Do not restrict your requirement collection to strictly technical requirements. The requirements that you may be asked to assess will probably span a broad range. Some of the areas included are listed here. To be considered a successful project we will need to satisfy, not only the technical requirements, but also the organization's strategic goals and the overall quality requirements for the product or service. A great project satisfies all of these areas, or at a minimum, has agreement on the priority and the scope for this project. The next step in the process is to review the requirements. In order to have a good requirements matrix in your project scope statement, each requirement must be well understood by all stakeholders, and there is no ambiguity in what the requirements might be. The first step in this process is to reconcile conflicting requirements. Requirements that are not fully aligned with each other should be identified and then presented to the project sponsor and the customer. The project manager must facilitate a process to resolve these conflicting requirements and then agree on the controlling interpretation. The next step is to make sure each requirement has a single meaning and that any ambiguity is removed. A good work process to achieve this goal is described in the chapter 4 of our textbook, Project Management Toolbox: Tools and Techniques for Practicing Project Management. This chapter contains a section entitled Requirements Ambiguity Checklist that provides guidance on how we can make sure our project requirements are well-defined. I suggest you review this process and incorporate it in your next project. It includes all of the elements you see here and more. Earlier we talked about keeping track of where the requirements you have collected originated. One good way to do this is a requirements traceability matrix. Each requirement identified in the collection process is added to the matrix along with an identification code, its source, what business objective it satisfied, and how it will be addressed in the project. The matrix can also be used to capture any modifications to the requirement that are made to resolve conflicts and its overall priority on the project. It should also include a description of how we will satisfy the requirement, including the acceptance criteria. A good requirements traceability metrics will look something like this, the one we see here on the screen. As we review all the project's requirements with the project sponsors, and prepare time and cost estimates, some of the requirements may be modified or even dropped. The traceability matrix is a great place to capture the disposition of any requirement that is modified or dropped, including the source of the authority to make these changes. The beauty of this approach, is that when a stakeholder approaches you at the end of the project, and asks us why you didn't include a feature or service in the project, you can go back to the requirements traceability matrix to find the answer. As part of the project scope development process, we incorporate these requirements into the scope statement and add any services that are required to implement the requirements. Then as a last statement, we present the completed project scope statement to the project sponsor, any other approving authority, for final review, comment, and approval. The approved project scope statement becomes our agreement on the products and services we will deliver as part of the project. It also includes the agreed acceptance criteria that outline how we will know that we've met the requirements. This becomes a key document to define our project. At this point, we have an approved requirement matrix that has been incorporated into the approved project scope statement. Let's assume that we're executing our project and producing deliverables. The process to confirm that we're meeting the requirements of the project is called scope validation. Scope validation is a confirmation by the customer, and other identified stakeholders, that the deliverables from the project meet their needs. If we have done the scope development process well, then these needs are well-defined in the project scope statement as project requirements. So, how is the scope validation different than inspection checking and quality control teams that we will study in course three, Risk and Quality Management? Scope validation comes after these internal checks have been complete. This process addresses acceptance by the ultimate customer, either the project sponsor or the client. The inputs to the process are checked deliverables, the requirements captured in the project scope statement, and the requirements traceability matrix. The process itself involves review and testing of the deliverables by the customer to determine whether they meet their needs. In reality, there are three outcomes from this process. First, the customer finds a defect with a deliverable that does not meet the requirements as stated in the project scope statement. In this case, the project must correct the defect and resubmit. Second, the customer accepts the deliverables meeting their requirements. A third, the customer does not accept the deliverable but acknowledges it met the original scope. In this case, they should formally issue a change request to modify their requirements and request a deliverable be modified. This scope validation process emphasizes the importance of a complete and unambiguous scope statement. This project scope statement is the yardstick by which we will be measuring. It should be as specific as possible, in order to leave little room for interpretation during the validation process. The entire scope development process is a key to successful project execution. It aligns the stakeholders, including the project team, on a common set of requirements. It sets expectations on how you will deliver the products. It sets the standards for acceptance on the work products. And finally, it makes up one leg of our iron triangle for project delivery. So in the next lesson, we're going to review the scope control process.
