Progress reports are common in engineering. As the name suggests, they document ongoing projects. They might be one-page memos or long, formal documents. Such a report is aimed at whoever assigned the project. Its goal is to enable the manager or sponsor of a project to make informed decisions about the future of the project. Usually, progress reports are stressful. The sponsor wants a job done quickly and cheaply; the engineer needs to ensure accuracy and quality. A sponsor might cancel even a quality job if it is behind or over budget. As the engineer, you need to please the sponsor and do the job well. Yet, any project of size or significance is bound to encounter snags: additional requirements, miscommunications, problems, delays, or unexpected expenses. A progress report must account for those snags.
The original proposal for the project determines the structure: make use of original milestones or the timeline. With this in mind, the simplest structure is as follows:
- Introduction
- Work Completed
- Work Scheduled
- Problems
But a more comprehensive list of components will give you a clearer structure, even if you return to the simpler structure for the report itself. Beer and McMurrey’s [1] Detailed Structure:
- Introduction
- Project Description
- Progress Summary
- Problems Encountered
- Changes in Requirements
- Overall Assessment of the Project
- (This document adds:) Report Apparatus (titles, references, etc.)
1. Introduction: As always, first indicate the purpose of the report and its intended audience. Clearly define the time period covered in the report (see also titles). Then, explain the project’s objectives and summarize the major issues. Sometimes the summary can be a separate section from the introduction [2].
2. Project Description: In very short reports, the introduction might contain this section, but if it is under its own heading, readers who are familiar with the project can skip it. Someone unfamiliar with the project, however, needs summarized details such as purpose and scope of the project, start and completion dates, and names of parties involved [1]. Often this section can be adapted from a proposal or borrowed from a previous progress report.
3. Progress Summary: This is the substance of the report (so “summary” may be a misnomer). You want to discuss work done, work in progress, and work to be done. You might just use these as subheadings to structure the section. This would be a project-tasks approach. Other approaches are time-periods or a combined approach.
- Project-tasks approach: Focus on the tasks. Defined milestones can logically organize your discussion into this kind of structure. Also if you are working on a number of semi-independent tasks at the same time, this approach will work well [1].
- Time-periods approach: Focus on time: the previous period, the current period, the future. If a timeline (or deadline) is more important than milestones, then use this approach. Also, use it for projects with a simple linear structure.
- Combined approach: The two above approaches could be combined if, for example, under previous work, you break down what you have done by individual tasks. Or, under the tasks, you focus on what part is complete, what part is in progress, and what part is yet to come.
Your project (and sometimes your sponsor) will determine which of these three you use. If the problems encountered or changes required are time-related, then use the time-periods approach to your advantage; likewise, if the problems or changes relate to specific tasks then use the project-tasks approach. Another item that may be included here is a summary of financial data. This last item could be contained in a table or appendix, or an independent section.
4. Problems Encountered: As noted in the opening, snags are expected. Don’t hide from them; explain what they are and how they might affect key areas of the job (such as timing, price or quality). If the problem occurred in the past, you can explain how you overcame it. This is least serious; in fact, you look good. If the problem is in front of you (now or in the future), explain how you hope to overcome it, if you can.
5. Changes in Requirements: Here, you record the changes to the project: milestones added, new requirements, or schedule changes (good or bad). Even if these changes have not affected the ultimate goal of the project, you need to tell the sponsor how problems have been accommodated. Note: If changes are a direct result of problems encountered, sections 4 and 5 may be combined. This would lead to a modified organization: first problem and the change it required, then the next problem and change, and so on.
6. Overall Assessment of the Project: Since a progress report is not about a finished work, the conclusion needs only to give your professional opinion of how the project is going. Being unrealistically optimistic is as inappropriate as being unduly negative. Beware of promising early completion: a single setback can gobble up much time. Likewise, don’t overreact if you are behind schedule. You may also gain time along the way. Far more significant for the engineer is to explain anything that may change the expected quality of the final product. Keeping in mind your purpose can help you focus here: your goal is to enable the manager or sponsor to make informed decisions.
7. Report Apparatus: A long progress report will include all the apparatus of formal reports: letter of transmittal, title page, table of contents, abstract, appendices, references. Only the most common will be addressed here.
Title: whether on a separate page or merely as a header, the title sends an important message to the reader. It needs to be clear and concise. Sample good title:
PROGRESS REPORT: Manufacturing Custom Relief Valve Assemblies XYZ Company
Reporting Period: April – July 1997
Subtitle: Note that the subtitle in the above example incorporates the dates covered by the report. This makes handy reference for a reader, particularly on a large project where more than one progress report may be necessary.
Appendices: In a short report (less than 10 pages) keep appendices to a minimum. It is always appropriate, however, to lodge financial data in an appendix if it does not fit elsewhere in the report. An important guideline is that it is only worth including an appendix if you mention it in the guts of the report. Otherwise, leave it out altogether.
References: Systems of referencing vary widely within engineering disciplines. (See Online Handbook / Accurate Documentation for information about two of these systems (IEEE and Author-Date) and a Bibliography Builder, which formats bibliography entries automatically for you)
[1] Beer, D. and McMurrey, D. A Guide to Writing as an Engineer. Toronto: Wiley, 1997.
[2] Markel, M. and Holmes, H. Technical Writing: Situations and Strategies. Scarborough: Nelson Canada, 1994.