Status Report

Status Log > Status Report

Project Information

TODO: Copy this file for each status report. Fill in the information below. Email a notification to stakeholders when this report is made available.

TODO: Edit the rows in the following table. In some rows, multiple samples are given, you should select and edit only one.

Project:	PROJECT-NAME
Status Report Date:	YYYY-MM-DD
Next Internal Release Number:	X.Y.Z
Release Date:	Original estimate: YYYY-MM-DD Current estimate: YYYY-MM-DD Change Since Last Report: No change Change Since Last Report: Slipped 2 days Change Since Last Report: Saved 4 days
Resources used this period:	PERSON-NAME: 18 hours. PERSON-NAME: 15 hours. PERSON-NAME: 10 hours. PERSON-NAME: 12 hours.
Status Summary:	Project completed. This is the final status report. Low risk. Project on track. Medium risk. Problems are being dealt with. High risk. Advice from management and stakeholders needed. Project canceled. This is the final status report.
Related Documents:	Project plan > Resource needs QA plan Glossary

Process impact: Frequent status reports help keep stakeholders informed of project status so that they may correctly set their expectations. Reasoned explanations of small changes in schedule are much better than major unexplained slips later.

Detailed Status

TODO: Provide 1-4 paragraphs describing what has happened on this project. Replace the sample text below with your own words.

TIP: Many developers get themselves into trouble by giving estimates of percent completion that are based on feelings rather than facts. It is best to use objective measures such as percentage of features, UI screens, or function points implemented, or percentage of unit tests passed. Beware of scales where 100% is not the same as being finished: e.g., "we are passing 95% of unit tests" can be misleading if those tests only cover 60% of the features. Don't say what you think your manager wants to hear if it is not true, even if you think you can make it true by working harder.

This week we focused on...

Two major problems have been uncovered...

We are approximately 30% of the way through the project plan, and running about 2 days ahead of schedule...

The reason for the change in estimated release date is...

We recommend changing the schedule or WBS to add...

To stay on schedule, we have slipped enhancements issue 92, issue 101, and issue 129 to a later release. These issues were selected because ...

Completion of COMPONENT is on hold until we hear back from DEPARTMENT-TEAM-OR-VENDOR.

This week team members spent a total of 6 hours on TIME-WASTING-TASK and were re-tasked to work on COMPETING-PROJECT for 8 hours.

Project Metrics

TODO: Track a few simple metrics that help to give objective measures of project progress, quality, and remaining work. Focus on long-term metrics for the overall project, not progress on individual tasks. Optionally, note deltas from last status report and explain reasons for changes. The values should ideally be computed by tools such as the issue tracker and unit test runners: be careful not to present subjective, wishful thinking in objective terms.

Metric	Description	Expected Value at Release	Current Value	Comments
Open issues	Known issues requiring developer work	No high priority issues	17 defects 8 enhancements
Resolved issues	Fixed issues that must still be verified	No high priority issues	0 defects 2 enhancements
Closed issues	Issues completely done	N/A	34 defects 3 enhancements
Code written	New code for new features	100%	80%
Unit test coverage	Statements exercised in unit tests	100%	30% (up 9%)	Starting with business objects first
Unit tests passed	Unit tests that we currently pass	100%	90% (up 17%)	Still failing some file import tests
Performance results	Seconds needed for 1 million records	20	57	Only simple optimizations have been done so far.
QUALITY-GOAL	DESCRIPTION	CRITERIA-FROM-SRS-OR-QA-PLAN	CURRENT-VALUE	NOTE, QUESTION

Risk Management

TODO: List 3-10 of the top project risks that are still outstanding. This list may be copied from an updated risk management worksheet or a previous status report.

We could face major difficulties with the technology chosen for this project. CURRENT STEPS TO AVOID/MITIGATE.
We could have low quality that demands significant rework. CURRENT STEPS TO AVOID/MITIGATE.
We could incorrectly assess our progress until it is too late to react. CURRENT STEPS TO AVOID/MITIGATE.
There may be a misalignment of stakeholder goals or expectations. CURRENT STEPS TO AVOID/MITIGATE.

Upcoming Activity

TODO: Provide a few bullets describing what you will do before the next status report. The text below is just a sample, replace it with your own words. Link to open issues in the issue tracker whenever possible.

Fix issue 130
Fix issue 133
Verify issue 102, issue 103, issue 107, and issue 109
Conduct regular team meeting: Tuesday, 1 hour
Conduct review meeting: Wednesday, 2 hours
Make major progress on COMPONENT
Update DOCUMENT
Work through next release checklist
Continue functional testing
Revise our integration procedure
Release version X.Y.Z

Tracking to Plan

TODO: Copy the WBS from the project plan and paste it here. Add a new column for actual effort spent so far by all team members.

Step	Description	Planned Hours	Spent To-Date
1.	Preparation
1.1.	Developer training	60	0
2.	Inception
2.1.	Requirements gathering	60	0
2.2.	Requirements specification	40	0
2.3.	Requirements validation	20	0
3.	Elaboration
3.1.	High-level design	10	0
3.2.	Low-level design (break down by component)
3.2.A.	Object design	20	0
3.2.B.	User interface design	20	0
3.2.C.	Database design	6	0
3.3.	Design review and evaluation	10	0
4.	Construction
4.1.A.	System implementation
4.1.A.1.	Implement Component 1	50	0
4.1.A.2.	Implement Component 2	50	0
4.1.A.3.	Implement Component 3	50	0
4.1.A.4.	Implement Component 4	50	0
4.1.A.5.	Integrate Components (mostly done during component implementation)	5	0
4.1.B.	Technical documentation (break down by component)	20	0
4.1.C.	User documentation (break down by component)	40	0
4.1.D.	Testing
4.1.D.1.	Test planning	20	0
4.1.D.2.	Test code implementation (break down by component)	60	0
4.1.D.3.	Test execution	30	0
4.2.	Implementation review and evaluation	20	0
5.	Transition
5.A.	Release packaging	8	0
5.B.	Documentation for other groups	6	0
6.	Reflection
6.1.	Postmortem report	20	0
	Total

TODO: Check for words of wisdom for additional advice on this template.

Company Proprietary