Capstone Project Wiki

The Project Success Agreement (PSA) is a three- to six-page artifact that documents the expectations of the team, the sponsor, and the Capstone administration about what constitutes success on the project. The Agreement includes information on the project scope, the product requirements, and the key success measures for the product. The objective of the PSA is to ensure that all stakeholders are clear on what is (and what is not) to be done during the course of the project. The PSA refers to primary artifacts that provide more in-depth information.

The Project Success Agreement includes the following content:

Because the PSA must be agreed upon by the team, sponsor, and instructor, a signature page is included. This signature page indicates that all stakeholders approve of the PSA. Signatures are necessary only for the final submission.

A tabular summary of the revision history of the PSA the reader to see how the document has evolved over its lifetime.

A brief description of the project, the sponsor, and any other information necessary as background to help understand the rest of the PSA. Please note that the PSA may be shared with people who are unfamiliar with the project, so some background is needed to help such readers get up to speed.

The project scope is a brief but complete description of the product design to be delivered at the end of the project. It includes a definition of the prototypes to be delivered at the end of the project, including their fidelity to the sponsor's final need. It should explain whether the goal is to produce a preliminary design for further refinement by the sponsor, or to produce a design that is ready for producibility refinement followed by release to the market.

The Project Objective Statement can be included as part of the project scope, but in most cases there should be more detail on the scope than is contained in the Project Objective Statement alone.

In this section of the PSA, it is also often helpful to briefly discuss an overall schedule and the expected resources for the project.

This section of the PSA should highlight the system-level requirements, probably in the form of a system Requirements Matrix or a Software Requirement Specification. It should also refer to other, revision-controlled requirements artifacts. The PSA does not replace the requirements artifacts. Rather, the requirements are summarized here to provide context for the key success measures.

Subsystem requirements are generally internal to the team, and are not included in the Project Success Agreement.

The Project Success Agreement does not need to be changed if the product requirements are changed in a way that does not affect the key success measures.

If it is used, the Requirements Matrix identifies a large number of performance measures by which the success of the product will be judged. Typically, many of these are constraints, meaning that they must be met if the product is to be a viable product, but they are not deciding factors between excellent and good products. Constraints generally have no target value; any value within the acceptable limits is satisfactory. Constraints can often be recognized because they are binary (yes/no).

Most of the performance measures are likely to be basic measures, which have non-binary target values but are not important enough to the customer to spend a lot of time optimizing them. In contrast, a relatively small number of measures will be Key Success Measures, which dominate the desirability of the product. If all the Key Success Measures are achieved, the product will be excellent. In addition, one or two Key Success Measures may have stretch goals for their target values, which are used to identify exceptional products.

The Key Success Measures comprise a list of approximately four to eight critical performance measures that distinguish between good products and great products. The values chosen for the final Key Success Measures reflect the desired performance of the product at the end of the development project.

At any stage of development, the desirability of the design can be determined by evaluating the likelihood of achieving the Key Success Measures.

Stretch goals are difficult, but potentially achievable, performance values for Key Success Measures. Achieving stretch goals constitutes exceptional performance; failure to achieve stretch goals does not constitute poor performance.

See the Development Reference entry on Goal Pyramid for more information on constraints, basic measures, and Key Success Measures.

The anticipated values for the key success measures will form part of your grade at the end of Fall semester; the achieved values will form part of your grade at the end of Winter semester.

The key success measures are vital to ensuring that your team, your sponsor, and the Capstone administration are on the same page concerning your work on the project. Changing key success measures requires a change to the project success agreement.

Sample Key Success Measures for a Capstone team working on an antenna positioner are shown here.

Note that the key success measures above show a continuous range of possible values for each of the performance measures. They leave no uncertainty as to what performance level a particular measurement corresponds to. Thus, if the achieved allowable antenna mass is 135 lbm, it is clear it constitutes the lower end of good performance.

As the project proceeds, there may be reasons to change the Project Success Agreement. The sponsor, the team, or the Capstone administration can recommend changes to the PSA. Changes to the PSA can be required by the sponsor in consultation with the Capstone administration. If the team wishes to change the PSA, they should informally request a change in discussions with the sponsor and the pod instructor. Once all parties have agreed on the change, the team will email the approved revision to the external relations manager, who will obtain final approval signatures from the sponsor and the pod instructor.

The process used to propose, approve, and implement changes to the PSA should be described here. The Change Management Procedure will generally use some form of Engineering Change Order procedure. See the Development Reference entry on Engineering Change Orders for suggestions. You may also wish to review the change management procedures in the Examples folder on Box for procedures that are more specific to the PSA.

There is a two-step process for obtaining approval of the Project Success Agreement. The first step is obtaining informal approval; the second is obtaining formal approval. A graphical representation of the approval process is shown below.

The process used to obtain approval of the Project Success Agreement. Follow the same process to get approval for changes.

During the informal approval process, the team prepares a draft of the Project Success Agreement and shares it simultaneously with the sponsor and the pod instructor. This sharing is most commonly done by email. During this process, we expect that changes will be requested by both the sponsor and the instructor, and changes can be made without following the change management procedure listed in the PSA. However revisions should still be tracked and the revision history updated.

Once the sponsor, instructors, and team have agreed on the contents of the PSA, the formal approval process is begun.

The formal approval process is initiated by the team preparing a PDF copy of the agreed-upon Project Success Agreement with approval signatures of the team and coach. These signatures may be either physical or digital. We have had good success with using Adobe Fill and Sign as a way to obtain digital signatures in a PDF document.

Once the team has prepared the signed PDF copy, it is sent as an email attachment to capstonereports@byu.edu with a subject line of Capstone Team ## Approved Project Success Agreement with ## replaced by your team number.

The external relations director for your project will then obtain digital signatures from the pod instructor and the sponsor. When the signatures have been obtained, the approved copy will be sent to your team for inclusion in the fall semester design report.

After final approval has been given, any changes to the Key Success Measures will require formal approval of the change consistent with the change management procedures you have adopted.