Copyright © 1998 by Hewlett-Packard Co. (9/98)
Consult (or create) a
.Fill in the project priority matrix (see
). Determine whichparameter among scope, schedule, or resources will be constrained (not flexible; changes will be very difficultor not possible). Then, select which of the remaining two project parameters will be optimized (somewhatflexible; small changes are difficult, but may be considered). The third parameter will be accepted (mostflexible; small changes to this project parameter are undesirable, but will be easiest to get accepted). Use thismatrix to plan, to optimize trade-offs in the project, to analyze proposed project changes, and to avoid overlyconstraining the project before doing proper analysis and planning.
List project requirements in a list headed
. Also, identify things that are not part of the project in a listheaded
. The project
will be part of the
list; transfer all project
to one list or the other inorder to minimize fuzzy specifications. Use these lists (particularly
) to bound the project and to reducemisunderstandings.
List all major deliverables for the project. Include all major components of the final project deliverable andany critical interim deliverables.
Document the specifications, assumptions, and other necessary detail information about the project. Usewhatever formats are customary for your type of project (for example: datasheet, statement of work, externalreference specification, product definition document, project charter, or systems requirements document).
3.Validate the project objective statement.
Validate the project objective at least twice:
, very earlyin the project to test your understanding of the project request;
, after detailed, bottom-up project planning to committo a realistic baseline project plan. Major project changesmay require additional project validation cycles. For eachvalidation cycle, seek consensus between the views of theproject team and the project sponsor. (See
Use the POS, priority matrix and other draft documentationbased on the initial top-down goal to validate the projectobjective with the project sponsor before planning andexecuting the project. Resolve misunderstandings to avoidomissions or errors in detail definition and planning. Useinitial validation discussions to clarify objectives and testinterpretations, not to make a firm project commitment.
Set the baseline project plan through a second validation of the project objective. Use this discussion to gain agreementon a firm deadline, budget, and frozen specifications basedon realistic and thorough
Additional validation of the project objective may be required, perhaps several times, later in the project.Possible causes are: your
process; requested changes that materiallyaffect project scope, schedule, or resources; or business reorganization.
4.Use the definition to plan and manage the project.
Use the results of project definition when developing the
. Make process decisionsregarding planning, tracking, practices, and relationships.
Distribute the validated POS, priority matrix, and other project information to the project team for use duringthe project. Uses include: determining additional staffing, specification change management, and additionalproject planning.The current
for this ActionSheet are on the web-based version. See index at
P r o j e c t D e f i n i t i o n
Figure 3. Validation cycles
Management, SponsorTopDown1. Project Objective2. Project Plan3(4,5...) ChangesBottomUpProject Team
V a l i d a t i o n G o a l s