Assess results
The project manager needs to regularly assess the results as planned. For example, in iterative development, this will
be done at the end of each iteration. Even if he or she is not using iterative development, the manager
should define quantifiable goals for a given period to facilitate regular assessment of the project's progress.
Below are questions that project managers can ask themselves and the rest of the team to help know the project
status:
-
Were the defined goals and objectives met?
-
-
Were risks reduced or eliminated?
-
Did the release meet its functionality and quality goals? Did the release meet performance and capacity
goals?
-
Are changes to the project plan required?
-
What portion of the current release will be baselined? What portion will need to be reworked?
-
Have new risks been identified?
-
Have there been external changes such as changes in the marketplace, in the user community, or in the
requirements?
One very important aspect of project assessment is to base the assessments on objective measures, as much as it is
possible to do so. For example, to assess that a given requirement is developed, the project manager must check that
the corresponding test cases were successfully run against it, rather than considering it done when the implementation
is done.
|
Gather stakeholder feedback
Assessing the results is also a good opportunity to get feedback from the stakeholders.
This feedback can be gathered through ways such as giving stakeholders informal demonstrations of what's developed as
the project progress and sending partial deliveries to stakeholders. However the feedback is gathered, it is good to
record changes that could have an impact on the project's scope or duration.
|
Refine project scope and duration
Depending on the result assessment and the stakeholders' feedback, the project manager could need to revise the project
plan to adapt to those changes. If a change affects defined project milestones, the project manager should consult with
the stakeholders before committing to the changes.
Necessary changes can also encompass the need to acquire new resources, to absorb an unplanned effort increase, or be
something specialized able to implement a specific change request.
|
Close-out phase
This step is optional and must be performed only when the assessment period coincide with the end of a phase.
The end of a phase represents a point of synchronization of technical and management expectations and closure for
a project. In iterative development, it coincides with the end of an iteration. However, phase ends mark a point
when it is possible to consider re-scoping and even re-contracting a project. For example, the inception phase is
exploratory and may be appropriately performed under a time-and-materials contract or a cost-plus type of contract. The
elaboration phase could be done as a fixed-price contract or a cost-plus contract, depending on the extent to which the
development is unusual. By the construction and transition phases, enough is known about the system that fixed-price
contracts are more appealing to the acquirer and vendor.
The phase end is marked by a major milestone and a corresponding milestone review. The degree of formality of
these reviews depends on the project. The important thing is to take advantage of this milestone review to
achieve agreement among all stakeholders on the current state of the project. For more information, refer to Concept: Milestones.
|
Close-out project
This step is optional and must be performed only when the assessment period coincide with the end of the project.
Involve the team and stakeholders in a final assessment for project acceptance which, if successful, marks the
point when the customer accepts ownership of the software product. Gather and record the lessons learned to be used in
future projects. Complete the close-out of the project by disposing of the remaining assets and reassigning the
remaining staff.
|
|