Directions for using
template:
Read the Guidance
(Arial blue font in brackets) to understand the
information that should be placed in each section of this template. Then delete
the Guidance and replace the placeholder within <<Begin text here>>
with your response. There may be additional Guidance in the Appendix of some
documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
Author |
|
Author
Position |
|
|
Version: 1.0
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft
and Visual Basic are either registered trademarks or trademarks of Microsoft in
the
Change
Record
Date |
Author |
Version |
Change
Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
Name |
Version
Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
Name |
Position |
|
|
|
|
|
|
|
|
Document
Properties
Item |
Details |
Document
Title |
Milestone
Review Report |
Author |
|
Creation
Date |
|
Last
Updated |
|
Status of Milestone Deliverables
Summary of Actuals versus Planned
Review of IP Used and Generated
Recommendations and Actions Items
[Introduction to the
Template
Description:
The Milestone Review Report summarizes the observations and findings of the
project’s Milestone Review. This process is undertaken at transition points
throughout the project to ensure quality and make necessary adjustments. A
Milestone Review allows the project team to assess two aspects of the project:
how it is being conducted and the quality of the project’s output. It provides
an opportunity to learn from the project work that has transpired to date and to
use that learning to improve the project.
The
Milestone Review Process examines the current project status, identifies what
has been successful to that point, pinpoints any problems or quality issues,
determines the lessons learned, and makes specific recommendations on how to
proceed.
Milestone
Reviews should occur at each point where the team and customer must agree to
proceed, thus signaling a transition from one phase into the next. These points
are typically identified as Major Milestones. Additionally, doing reviews at
interim and internal milestones serve as checkpoints for the project teams. The
Project Post-Mortem, the final milestone review, rolls up a full assessment at
the project’s conclusion.]
[Description:
The Summary section presents the report’s key elements in a brief paragraph and
describes the method(s) used to conduct the Milestone Review (meetings,
conference calls, surveys, etc.).]
<<Begin text here>>
[Description:
The Status of Milestone Deliverables section lists the deliverables that should
be complete at the point of the Milestone Review and identifies their status. If
this is the project’s first Milestone Review, list all deliverables to that
point. If it is a subsequent Milestone Review, list all deliverables created
since the last review. Status conditions include “complete,” “in progress,”
“deleted,” and so on. For deliverables still in progress, a more granular metric
that describes either “percent complete” or the sub-deliverables that are
complete is useful.
Justification:
This communication enables the customer, the project team, and other
stakeholders to make informed decisions about the project and other related
activities.]
<<Begin text here>>
[Description:
The Summary of Actuals versus Planned section documents for each deliverable the
estimated time and resources and the actual time and resources used to date.
This section also shows the calculated differences between the estimates and
actuals.
Justification:
These comparisons identify potential problems as well as those areas that may be
ahead of schedule and enable the project team to adjust the project
plan.
This
data is also valuable to help quantify assessments on equivalent tasks later in
the project or when bidding on similar projects in the
future.]
<<Begin text here>>
[Description:
The Ratings by Category section reports the quantitative measurements taken on
the important dimensions (categories) of the project. Both the project team and
the customer can provide these ratings.
A
category rating is an indication of two factors:
·
Assessment
– how well a category is working for the project
·
Impact
– the importance and effect the category will have on the project’s
success/failure
The
categories include project processes (risk management, communication, quality
assurance, etc.), technical documentation, technical processes (interface
development, testing, etc.), project structure, project documentation (project
plans, progress reports, etc.), methods and tools, and
product.
Each
indicator (assessment and impact) has a ratings scale. The ratings for each
indicator are multiplied to determine each category’s overall
rating.
For
example:
Assessment |
Not
going well |
Going
well | ||
|
| |||
|
-2 |
-1 |
1 |
2 |
|
|
|
|
|
Impact |
Low |
High | ||
|
| |||
|
1 |
2 |
3 |
4 |
Category |
Assessment |
Impact |
Rating
(A*I) |
Risk
Management Process |
1 |
3 |
3 |
Communication
Process |
-2 |
3 |
-6 |
Interface
Development |
1 |
2 |
2 |
Quality
Assurance Process |
2 |
1 |
2 |
Justification:
The team evaluates these category ratings to determine source causes and to make
improvement recommendations. This information also provides input to the ongoing
risk management process. Categories with low ratings tend to have associated
risks needing identification.]
<<Begin text here>>
[Description:
The Lessons Learned section identifies three main
items:
·
Things
that are working well and should continue as elements of the
project
·
Things
that need changing, either because they are not working or could be
improved
·
Things
that should not be repeated or should be
discontinued
This
section is developed by examining the Deliverables’ status, Planned versus
Actuals comparison, and Category ratings and then
determining:
·
Why
were we successful? What contributed to that
success?
·
Could
we improve on that success as we continue with the
project?
·
What
risks did we successfully manage? How?
·
Why
was there a problem? What went wrong?
·
What
were the signs that should have warned us? Are there new risk factors we should
identify for future projects?
·
What
should we have done differently?]
<<Begin text here>>
Justification:
This information may be useful to other projects and should be shared with
Microsoft staff and partners.]
<<Begin text here>>
[Description:
The Readiness for Next Milestone section describes how well the project is
positioned to achieve the next milestone By analyzing the Deliverables’ status,
Planned versus Actuals comparisons, Category ratings, and Lessons learned, the
team can assess how much adjustment needs to be made to the project in order to
reach the next milestone. Examples of this assessment
include:
·
If
the current deliverables are late, can resource adjustments be made to meet
deadlines?
·
If
the project processes (communication, change management, etc.) are not working
effectively, can they be amended in time to facilitate
efficiencies?
Justification:
This information ensures that the project team identifies the necessary success
factors and actions required to achieve the next
milestone.]
<<Begin text here>>
[Description:
The Recommendations and Actions Items section makes specific recommendations
(derived from the lessons learned section) on how the project should be
adjusted. These recommendations are prioritized based on their relative value to
achieving the project’s goals. The recommendations should focus only on high
priority issues and be connected to the rated
categories.
Recommendations
may include alternative methods for performing work, best practices to apply to
project protocols (risk management, communication, etc.), adjustments to project
plans and structure, feature trade-offs, and so on.
Justification:
Action items are derived from the recommendations; they identify the specific
individual/group responsible for taking the action and the time target for
completing the action. Action items should be those things that have the
greatest positive impact on the project. One of the action items should be to
update the risks and issues document with new or changed items that fall out of
the milestone review process.]
<<Begin text here>>