Projects support strategy execution and the advancement of business objectives. Project delivery focuses on meeting requirements, scope, and quality expectations to produce the expected deliverables that will drive the intended outcomes.
The following definitions are relevant to the Delivery Performance Domain:
Requirement. A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.
Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
Definition of Done (DoD). A checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use.
Quality. The degree to which a set of inherent characteristics fulfills requirements.
Cost of Quality (COQ). All costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraisal of the product or service for conformance to requirements, and failure to meet requirements.
Projects provide business value by developing new products or services, solving problems, or fixing features that were defective or suboptimal. Projects often deliver multiple outcomes that stakeholders may value differently. For example, one group may value ease of use or the time-saving aspects of a deliverable while another group values its economic return or market differentiation.
2.6.1 DELIVERY OF VALUE
Projects that use a development approach that supports releasing deliverables throughout the project life cycle can start delivering value to the business, customer, or other stakeholders during the project. Projects that deliver the bulk of their deliverable at the end of the project life cycle generate value after the initial deployment.
Business value often continues to be captured long after the initial project has ended. Frequently, longer product and program life cycles are used to measure the benefits and value contributed by earlier projects.
A business case document often provides the business justification and a projection of anticipated business value from a project. The format of this business case varies based on the development approach and life cycle selected. Examples include business case documents with detailed estimates of return on investment or a lean, start-up canvas that describes high-level elements such as the problem, solution, revenue streams, and cost structures. These business documents demonstrate how the project outcomes align with the organization’s business objectives.
Project-authorizing documents attempt to quantify the project’s desired outcomes to allow for periodic measurement. These documents may range from detailed, baselined plans or high-level roadmaps that provide an overview of the project life cycle, major releases, key deliverables, reviews, and other top-level information.
2.6.2 DELIVERABLES
In this context, deliverable refers to the interim or final product, service, or results from a project. The deliverables enable the outcomes that the project was undertaken to create. Deliverables reflect the stakeholder requirements, scope, and quality, along with the long-term impacts to profit, people, and the planet.
2.6.2.1 Requirements
A requirement is a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need. Requirements can be very high level, such as those found in a business case, or they can be very detailed, such as those found in acceptance criteria for a component of a system.
Projects that have a well-defined scope, which is relatively stable, generally work with project stakeholders to elicit and document the requirements during up-front planning. Projects that have a high-level understanding of the requirements at the start of a project may evolve those requirements over time. Some projects discover requirements during project work.
▶ Requirements elicitation. To elicit means to draw out, bring forth, or evoke. There is more to collecting requirements than interviewing or conducting focus groups. Sometimes requirements are drawn out by analyzing data, observing processes, reviewing defect logs, or other methods.
Part of eliciting requirements is documenting them and gaining stakeholder agreement. Well-documented requirements meet the following criteria:
▹Clear. There is only one way to interpret the requirement.
▹Concise. The requirement is stated in as few words as possible. ▹ Verifiable. There is a way to verify that the requirement has been met.
▹Consistent. There are no contradictory requirements.
▹Complete. The set of requirements represents the entirety of the current project or product needs.
▹Traceable. Each requirement can be recognized by a unique identifier.
▶ Evolving and discovering requirements. On projects that do not have clearly defined requirements up front, prototypes, demonstrations, storyboards, and mock-ups can be used to evolve the requirements. In these situations, stakeholders are more likely to take an “I’ll know it when I see it” approach to developing requirements. Evolving requirements are common in projects using iterative, incremental, or adaptive development approaches. In some cases, new opportunities arise that change requirements.
▶ Managing requirements. Regardless of whether requirements are documented up front, evolved along the way, or discovered, there is a need to manage them. Ineffective requirements management can lead to rework, scope creep, customer dissatisfaction, budget overruns, schedule delay, and overall project failure. Therefore, many projects have one accountable person for requirements management. This person may serve as business analyst, product owner, value engineer, or other title. Those individuals managing requirements may use specialized software, backlogs, index cards, traceability matrices, or some other method to ensure there is an appropriate level of requirement flexibility versus stability, and that new and changing requirements are agreed to by all relevant stakeholders.
2.6.2.2 Scope Definition
As requirements are identified, the scope that will meet them is defined. Scope is the sum of the products, services, and results to be provided as a project. As scope is defined, it creates the need for more requirements identification. Therefore, like requirements, scope can be well defined up front, it can evolve over time, or it can be discovered.
▶Scope decomposition. Scope can be elaborated using a scope statement to identify the major deliverables associated with the project and the acceptance criteria for each deliverable. Scope can also be elaborated by decomposing it into lower levels of detail using a work breakdown structure (WBS). A WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each level down in the hierarchy represents a greater level of detail of the deliverable and work required to produce it.
Another way to elaborate scope is by identifying the themes of the project in an agile charter, roadmap, or as part of the product hierarchy. Themes represent large groups of customer value reflected as user stories associated by a common factor, such as functionality, data source, or security level. To accomplish themes, the project team develops epics, which are logical containers for a large user story that is too big to complete within an iteration. Epics may be decomposed into features, a set of related requirements typically described as a short phrase or function, which represent specific behaviors of a product. Each feature will have multiple user stories. A user story is a brief description of an outcome for a specific user, which is a promise for a conversation to clarify details. The project team defines story details at the last responsible moment to avoid wasteful planning should the scope change. The story is a clear and concise representation of a requirement written from the end user’s perspective.
▶Completion of deliverables. Depending on the approach used, there are different ways to describe component or project completion:
▹Acceptance or completion criteria. The criteria required to be met before the customer accepts the deliverable or before the project is considered complete are often documented in a scope statement.
▹Technical performance measures. The technical specifications for a product may be documented in a separate specifications document, or they may be documented as an extension to the WBS. This extension, known as a WBS dictionary, elaborates the information for each deliverable (work package) in the WBS.
▹Definition of done. The definition of done is used with adaptive approaches, particularly in software development projects. It is a checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use.
2.6.2.3 Moving Targets of Completion
Projects that operate in uncertain and rapidly changing environments face the situation that a “good enough for release” or “done” goal may be subject to change. In markets where competitors are releasing new products frequently, the features planned for a new release may be updated. Likewise, new technology trends, such as mobile devices or wearable devices, might trigger a change in direction or introduce new requirements.
In these environments, the definition of the project goal being delivered or “done” is constantly moving. Project teams track the planned rate of project goal achievement relative to the rate of progress toward completion. The longer the project takes to complete, the further the project goal of “done” is likely to move. This is sometimes referred to as “done drift.”
Figure 2-21 shows a scenario for developing a new smart watch. The initial schedule shows 12 months to develop the watch with the initial set of capabilities and features. As competitors launch similar products, the initial set of capabilities and features increases to stay relevant with the market. This pushes the launch date to Month 14. At 13 months, another competitor launches a product with even more capabilities. Adding these capabilities would delay the launch to Month 16. At some point, a decision will be made whether to release the product as is, even though it doesn’t have the latest features, or continue to update the features prior to launch.
Projects that operate in a more stable environment often face “scope creep.” This is when additional scope or requirements are accepted without adjusting the corresponding schedule, budget, or resource needs. To combat scope creep, project teams use a change control system where all changes are evaluated for the potential value they bring to the project and the potential resources, time, and budget needed to realize the potential value. The project team then presents the changes to the project governance body, product owner, or executive sponsor for formal approval.
Tiếng Việt