Best Practice: Title: Creating Effective Project Status Reports
Best Practice: Title: Creating Effective Project Status Reports
Best Practice
Title: Creating Effective Project Status
Reports
1. Abstract
This document is intended to outline the best practice processes for creating project
status reports for NetSuite implementation projects, including:
2. Audience/Roles
NetSuite, Inc. All rights reserved. Specifications subject to change. This document is provided for information purposes
only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor
subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and
conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this
document and no contractual obligations are formed either directly or indirectly by this document. This document may not
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our written
permission. The NetSuite logo is a registered trademark of NetSuite, Inc. Other names may be trademarks of their
respective owners.
Page 1 of 4
3. Template
The project status template is an external facing document that should be produced
following regularly scheduled project status meetings with the customer. The best
practice for average projects is to have the status meeting held on a weekly basis.
3.1.
Status Summary
The status summary should list all NetSuite jobs related to the customers
implementation, including end user training and change orders.
The four boxes to the right of the job should include a standard red, yellow,
green classification:
GREEN
YELLOW
RED
The Overall status classification assigned to the job should typically match the
overall Job status in NetSuite.
The status classifications are broken down into three smaller classifications:
o Scope
o Time
o Resources
Following the job summary is a box where project managers are encouraged to
populate an overall description of the job status.
The status report classifications of Scope, Time and Resources do not need to
match the job status in NetSuite. Instead, these can be used as a tool to
invoke action by customers by raising the status to Yellow or Red to support
identified issues and focus attention on problem areas.
For Example: Inadequate Customer Resources
Job No./Name
Overall
Scope
Time
Resources
JXXXXX | Implementation
GREEN
GREEN
GREEN
YELLOW
Insufficient customer resource time commitment is causing concern on the project. Customer deliverables
will start to fall behind unless a resource plan is put into place.
Page 2 of 4
3.2.
A set of standard milestones are set out in the template and should be
considered the minimum set of milestones to be tracked. These can be
updated and expanded as required depending on the scope of the project. The
default milestones defined are:
o Business Requirements Document Signoff
o Project Plan Approval
o Configuration Complete
o User Acceptance Testing Sign Off
o End User Training Provided
o Data Migration Complete
o Go Live Date
o Project Completion
A section is provided to allow the project manager to define the responsibility
for each milestone:
o Shared Both NetSuite and the Customer are responsibly for the
completion of the deliverable.
o Customer Only the customer is responsibility for the completion of the
deliverable (Example: Data migration was not included in the scope of
work)
o NetSuite The customer is not responsible for the completion of the
deliverable, NetSuite has taken sole responsibility.
At the start of the project the Target Dates should be included in the project
plan with the Actual Dates updated as project milestones are achieved.
A fourth column is provided to allow the project manager to specify
Completed beside all milestones that are achieved.
A space is provided after the summary to allow a description for any changes in
the dates or achievements of the milestones to be explained. If no changes
were made to the dates then it is recommended that the following statement is
included No have changes were made to the deliverable dates listed above.
3.3.
Milestone Summary
Key Issues/Risks
This section of the project status report should be used to communicate and
document any issues/risks related to the project. The format of this section
includes the issue/risk title, issue/risk description and an audit log style
section to track changes to the issue/risk.
The reason an audit log approach is recommended is that this allows
stakeholders to understand the progress of the issue/risk.
The most recent update should be bolded to allow for easy identification when
reading the status report.
When documenting the issue, it is important that the PM includes the risk
mitigation strategy as part of the update/next steps.
A best practice for closing out key issues from one status report to another is
to turn a closed issue/risk to a lighter grey in the week that it is closed. Once
recorded in this fashion then the issue/risk would be subsequently dropped
from future reports.
Page 3 of 4
Example:
Outstanding Script Approval
CLOSED
N/A
01/29/2008 Update:
Approvals received. Key Issue Closed.
01/24/2008 Update:
Added to Issue List. Joe to contact Jane about clarification on
Script and approve.
3.4.
This section of the status report should be used to identify all key
accomplishments on the project during the last status reporting period.
3.5.
Accomplishments
Upcoming Schedule
The upcoming schedule section of the project status report should include a
listing of all key events that are expected to be completed in the next status
period on the project.
An alternative to listing out the events and customer deliverables is to copy a
summary level snap shot of the project plan into the status report.
4. Customer Presentation
Page 4 of 4