On the Checkpoint Report

Keeping track of and reporting progress on your project is one of the key reasons why you were hired. One of the key mechanisms for this is “checkpoint” or “status” reporting.
Tool Downloads
> Checkpoint Report Template

It’s really up to you how often you wish your team to report in however, typically they can be held bi-weekly or weekly. When the pressure is on checkpoint reporting can be daily or even more frequently.

A project gets late one day at a time

The goal of the checkpoint report is to deliver a summary of team member activity on current work packages and the analysis of the impact on stage and project tolerances. This is a key input into you project Highlight report for the Project Board.

The relationship between reporting requirements and team morale

Project Managers also need to be aware of what reporting and the perception of too much reporting can do to team morale. Assuming you’ve recruited a team of self-motivated professionals, too much reporting can be perceived as a lack of trust in team members, a distraction from the job at hand or worse still, lack of management skill by the project manager.

A note on report structure

Always put the first things first

This template is obviously based on the OGC PRINCE2 template however you may wish to consider putting your report on tolerances at the top, as I have. I’ve always found my executives and/or programme managers will always want to know their risk position first then deal with the status of delivery.

On the Business Case

The business case is the single most important piece of project documentation, it is a living document – the soul of the project – and should be updated and evaluated throughout the project life-cycle as part of the strategic planning process in order to allow senior management to decide which:
Tool Downloads
  > Business Case
  • Projects offer best value for money
  • Projects will best achieve strategic priorities

The business case is the repository for the WHY, HOW and WHAT questions:

  • WHY do we need to do this? (the justification for the project)
  • HOW much is it going to cost? (the investment required)
  • WHAT will we get out of this? (the anticipated benefits)

If you can successfully answer these questions it will go a long way to ensure your project enjoys continued stakeholder commitment.  Download the Business Case Template for more in-depth commentary on how to write a solid Business Case.

On the Acceptance Criteria

We’ve all heard it before yet everywhere you look around there are still projects being delivered “an hour late and a dollar short and under-spec”.
Tool Downloads
> The Acceptance Criteria
> The Project Brief

Begin with the end in mind

The acceptance criteria is essentially the “blueprint” on what the final product should look like, of course taking into account the needs of the senior user and the customer quality expectations.  this information is documented as part of the Project Brief in Starting up a Project [SU4] then refined in the Project Initiation document but if you have a serious deliverable you may want to consider producing a separate document (which is why we created a template for you :))

A note on defining criteria

There are many ways to define your criteria but the important thing to remember is that all the criteria need to be measurable and realistic.  I would suggest using the S.M.A.R.T. method and the following format to assist you in defining, in detail, the acceptance criteria. 

Acceptance Criteria Name
Description of measurement to be applied

  • Current level
  • Acceptance level (at handover)
  • Further level – [Target date]
  • Final level – [Target date]

The further level and final level criteria are optional in the Acceptance Criteria template and could be used if you can forecast refinements to the final product once it is handed over to operations.

Follow

Get every new post delivered to your Inbox.