Capstone Project Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====Project Success Agreement=====
<-System Refinement Review and Final Design Report^.:home|Design Reviews^->
<html><div class="capnote">
NOTE: The Project Success Agreement is a required component of both the
Fall Semester Design Report and the Final Design Report.  It will take
time to obtain approval for the Project Success Agreement, so you
should start the process soon after you have successfully completed
the Concept Review.
</div></html>

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.

====Content====
The Project Success Agreement includes the following content:

===Title and Signature Pages===
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.

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

===Project Background===
 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.

===Project Scope===
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.

===Product Requirements===
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.




===Key Success Measures===
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
[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=239|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.

<html><div class="capnote">
NOTE: Once the Project Success Agreement has been approved, changes to the key success measures require approved changes to the Project Success Agreement as described in Change Management.
</div></html>

Sample Key Success Measures for a Capstone team working on an antenna positioner are shown here. \\
^ Measure ^ Stretch Goal ^ Excellent Performance (A) ^ Good Performance (B) ^ Fair Performance (C or lower) ^ Lower Acceptable Limit ^ Ideal ^ Upper Acceptable Limit ^
| Measured angular acceleration on each axis | 18.0 deg/sec<html><sup>2</sup></html> or more | 15.0 deg/sec<html><sup>2</sup></html> to 17.9 deg/sec<html><sup>2</sup></html> | 12.0 to 14.9 deg/sec<html><sup>2</sup></html> | Less than 12.0 deg/sec<html><sup>2</sup></html> | 12.0 deg/sec<html><sup>2</sup></html> | 15.0 deg/sec<html><sup>2</sup></html> | NA |
| Measured antenna spherical envelope | NA | 35 inches or more | 29 to 34.9 inches | 24 to 28.9 inches | 24 inches | 48 inches | NA |
| Predicted maximum allowable antenna weight | NA | 175 lbm or more | 130 to 174 lbm | 100 to 129 lbm | 100 lbm | 200 lbm | NA |
| Test interface ease of use | NA | Use is self-evident to the technician | Usable with minor training | Usable with notes, but awkward | Usable but somewhat difficult | Self-evident to the technician | NA |


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.

===Change Management===
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
[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=223|Engineering Change Orders]] for suggestions.  You may also wish to review the change management procedures in the [[https://byu.app.box.com/folder/139422795586|Examples folder on Box]] for procedures that are more specific to the PSA.

====Mechanics====

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.

{{ project-wiki:design_reviews:psa_figure.png }}\\
The process used to obtain approval of the Project Success Agreement.  Follow the same process to get approval for changes.

===Informal Approval===

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.

<html><div class="capnote">
NOTE: The informal approval process should be completed before the Architecture Review.
</div></html>

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

===Formal Approval===

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
[[mailto:capstonereports@byu.edu|capstonereports@byu.edu]]
with a subject line of
''Capstone Team ## Approved Project Success Agreement''
with ''##'' replaced by your team number.

<html><div class="capnote">
NOTE: Emails are sorted by mailbox rules.  If your subject line is incorrect, we will
not process your Project Success Agreement and signatures will not be obtained.  Please
make sure you use the required subject line.
</div></html>

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.
Capstone Project Wiki

User Tools

Site Tools

Page Tools
