Checkpoint ReportHere you can find a simple Checkpoint Report template in Microsoft Word/Excel format, along with explanation on how to use it.
You’re the Project Manager, focused on running the Stage Plan. Every once in a while, it’s time to start working on a new Work Package. You and the Team Manager will prepare the Work Package and they will start executing it. Then, you expect them to send you progress reports about the performance of the Work Package; the name of that report is Checkpoint Report.
Do you know where we document the frequency of Checkpoint Reports? Is it, for example, in a management approach document? No.
The needed frequency of reports depends on the nature of the Work Package; some are sensitive, some are not. So, it’s not something generic that you can set for all. That’s why the frequency is decided for and documented in the Work Package document.
So, what happens is that you’re continuously receiving Checkpoint Reports from your Team Managers. You will check them to make sure that everything is fine. For example, you will combine the information to analyze the status of the stage. What would you do if there’s a deviation?
This is what you have to do:
Is the deviation above the stage tolerances? Then you should send an Exception Report to the Project Board and let them decide what to do.
Is it within the stage tolerances? Then you should decide how to recover from the deviation.
So, this is the context in which the Checkpoint Report is used, and understanding the context is the best way you can understand how to prepare a management product such as this. What do you think should exist in a typical Checkpoint report?
These are the main sections of the template:
Document information: this is the generic information about the document and connections with your Configuration Management system. Feel free to add more information here, but it’s best to keep it simple.
Approval: this section is for capturing approvals. There are multiple lines, because you may have multiple versions of this document approved. If you have a well-formed Configuration Management system to track approvals, feel free to remove this section.
Follow-ups from the previous period: we don’t want to leave issues hanging, do we?
Products: Here you can see my personal suggestion: a table for the products that are included in the Work Package, their current status, and their expected status in the next reporting period, along with their quality information.
Work Package Objectives: these are the six variables, minus benefits (because that’s about the whole project, not single Work Packages), with their target value, tolerance, current value, and forecast at completion. You will use these to evaluate the project, and it’s also a reminder for the Team Manager to escalate the issues to you if they go out of tolerance.
Issues and risks: this is where the Team Managers will update you on issues and risks that are identified in their work. Take them seriously!
Lessons Learned: and this final section is a reminder that lessons should be captured continuously, not only at the end of the project.
If you’d like to learn everything about PRINCE2, I can suggest our eLearning courses:
- PRINCE2® Foundation Online Course
- PRINCE2® Practitioner Online Course
- PRINCE2 Agile® Practitioner Online Course
The first 30% of all courses is free. You can start it right now and make sure it’s what you’ve been looking for before you buy.