1.0 Title: Progress Report
a.k.a. Status Report
2.0 Purpose: This format is for general purpose project task reporting between a project owner and a contractor – or for a resource group or task manager within the owner’s organization. It is assumed that the author has a reference plan and a Statement of Work that they are updating on good faith so that any issues which should be identified are and that any recommendations for corrective action are to the benefit of both parties.
However - it should be noted that much of the effectiveness of a report to the project owner depends upon the questions asked and the information needed. In some cases owners don’t want to hear bad news – so vague questions can help avoid this. In some cases the reports will be used against the reporter in arbitration or even in court. In these cases one should not expect data or comments that are prejudicial to the reporter’s later defence.
3.0 Usage: This form of a status report is the most general and is intended for the most comprehensive use in project management
4.0 Frequency: In most projects a monthly update is the norm. Weekly updates may be used for scrum type projects and quarterly may be used for summary level updates but other formats should be considered.
5.0 References: There are numerous references for project management and progress reporting methods. For general information the Project Management Institute is good. Details of the calculations are (suuposed to be) part of the DD key code definitions pages.
6.0 Responsibility: The contractor's Project Manager is generally responsible for producing the report - while the Owner's Project Manager is generally responsible for accepting the report
7.0 Ownership: The status report generally becomes the physical property of the project owner once accepted. However, copyright tradition would indicate that reuse or modification of the content for purposes beyond the contract for which the work was done is not acceptable.
8.0 Effort: The time required to produce a report varies greatly and can be as little as one hour for projects with functioning information systems to several days for multiple people for projects that require a lot of manual data gathering and poorly defined procedures.
9.0 Risks: Any project which does not review its status regularly will probably be quite different from the one which was approved. Usually not for the better.
10.0 Contents
10.1 Project Information
Sufficient background information about the project should be given so that the informed reader does not have to follow further references to know exactly which project us being referred to or where the report fits in with other reports. The following items are a relatively complete – if not exhaustive – set of data references which may be part of the project background information;
10.1.1 Project number <dd:pm kc:projnum >
10.1.2 Project Title <dd:pm kc projname >
10.1.3 Project Owner <dd:leg kc:owner >
10.1.4 Contractor Name <dd:leg kc:sub >
10.1.5 Contract Number <dd:pm kc:wo >
10.1.6 Status Report Number <dd:pm kc:statrepno >
10.1.7 Status Report Date <dd:pm kc:statrepdate >
10.1.8 filename <dd:mm kc:filename >
10.1.9 Author <dd:pm kc:statrepauth >
10.1.10 Approving Authority <dd:pm kc:statrepappvl >
10.2 Job Status
Sufficient information should be given about the state of the project at a point in time so that a true picture of the work complete vs. work remaining is given.
10.2.1 Summary <dd:pm kc:statrepsumry >
10.2.2 General Update <dd:pm kc:statreptext>
10.2.3 Project Data Update
10.2.3.1 Status <dd:pm kc:projstatus>
10.2.3.2 Planned Start <dd:pm kc:projstartpl>
10.2.3.3 Actual Start <dd:pm kc:projstartact>
10.2.3.4 Planned Work Complete
10.2.3.5 Actual Work Complete <ed
10.3 appendices
- an updated list of deliverables - CDRL <km3?>
- an updated project plan - pm7
- an updated Human Resources plan
- an updated cash flow
- resource logs (in support of invoice)
11.0 MetaData
12.0 File Handling Policy