The Wrong Question
I was recently asked by a client how often I should be reporting on my project.
My response was along the lines that I believe the client was asking the wrong question. As I explained at the time, before you think about reporting on a project, you need to work out how you’ll plan and control your project.
If you don’t first gain control of your project, you will merely find yourself answering everyone else’s ad-hoc requests and taking blame. The idea is to position yourself so that you are providing good information that is easily generated from the controls you are exerting.
To avoid disappearing down this abyss of constant tedious requests, you need:
- Good structure – having your governance and stakeholders properly assembled to the right roles and using a good methodology
- Solid, well structured plans – how you create these has a big influence on how easy they are to monitor and control
- Intelligent controls – run controls as “cycles with cycles”
Before I could answer questions about the frequency of status reports, I needed to explain what I mean when I tell people (in my very best Yoda impersonation):
Good structure leads to good control, good control leads to good reports. Into the structure, the dark side we must not let.
OK, I made up the last bit, but you get my drift I hope. Having your project and your stakeholder audiences structured properly is critical to successful reporting.
I understand you may not have total control over the structure of your project as sometimes your business may force a regime on you. However if it is at all possible to influence structure, using a recognized methodology may help you to do some "upwards management."
If you can establish a small project board that has real decision making authority, you should be able to then position potential gate-keepers and stone-throwers into roles such as project assurance or project support. This is vital – what you’re doing is using the authority of the real decision makers of the project to corral the potential trouble makers into their own domains. You know the folks I’m talking about; the chief engineer who also wants to block your project finances in favor of his pet project … that sort of thing.
Getting these structures right takes some effort and sometimes some head-butting. What it provides you in return is a channel through which all information goes and clarity about who has authority to ask for information from you.
I try very hard not to be too prescriptive in the way people should manage projects, but I’m afraid that when it comes to planning and scheduling a project there are some golden rules that will allow you to control your project.
Always build a strong Work Breakdown Structure (WBS) and apply costs to the products and services within that WBS.
- Base your schedule around that WBS so that you can clearly see the delivery (or not) of products and services
- Include costs of effort in your schedule and reconcile your schedule to your budget, and
- Run your financials from the WBS – but DO NOT break down your WBS according to cost accounts (these can be cross referenced).
Doing these things may be a bit painful at first (it gets easier as you practice it). However, by doing so you can use your scheduling tool for its intended purpose – to help you control the project! This will save you enormous amounts of time later. Indeed, one of my clients claimed that setting up his schedule properly saved him 60% of his monitoring and control effort later.
Now I’m a great fan of the PRINCE2 methodology and, in particular, I’m a fan of the concept of Management by Exception, which sits at the core of its control philosophy. This means that once the project manager sets out his or her plan for a period of the project and the stakeholders are structured as above, those stakeholders then refrain from re-directing, suggesting changes for, agitating, watching over the shoulder of and threatening the project manager.
Another PRINCE2 concept for which I hold a lot of zeal is that of Stages. That concept suggests the project should be divided into management stages, which represent the extent and duration of approval held by the project manager. There’s only one reason for my enthusiasm for this method – it works!
These are two intelligent concepts you can bring to bare on your project. Then you are in a position where you can establish the right control routines to support effective reporting.
One of the keys to getting these right is to remember that each control you put in place should feed the bigger picture. If it doesn’t then you have to think about why you are bothering with that control. Now, Forrest Gump may have thought life was like a box of chocolates, but I think life as a project manager is more like a bunch of pepperoni pizzas…
Effective Control Routines
PRINCE2 recommends a number of levels of control routines designed to ensure the right people get the right information at the right time. These routines can be thought of as cycles within cycles, and are:
- Checkpoint – the internal cycle that reviews status of individual products or deliverables, risks, issues and requests for change
- Highlight Reporting – the cycle for reviewing and reporting information of interest to stakeholders such as budget, overall status, risk exposure and issue status for major issues
- Stage Planning and Reporting – a cycle based on division of the project into manageable chunks that represent the level and duration of authority held by a project manager
- End Project Reporting – based on reporting the outcome of the entire project compared to original plans
You can, if you wish, add your own daily routines to this model. Between them, these controls should largely generate the only reports that you need to provide during the project. Each layer of control should examine the same basic information – progress on deliverables, risks, issues, costs/budgets and potential changes. The difference should only be the level at which they are examined.
The checkpoint routine should be managed for each work package and go into quite some detail. Only the salient points – total cost, impact of changes on schedule, key risks and issues – need to be brought up to the next level which examines the status of the project from month to month. Likewise this information is used to report the end of each stage or phase of your project. Managing in this way allows you to keep one set of key data about the project and do all of your reporting from that.
OK, that’s probably Nirvana, but if you are including progress, budget outcomes, product status and quality, key issues and risks in your control cycle from the base level, there are few reasons why you should need to provide other reports.
And for the not so perfect world …
I’m well aware that many corporate cultures have every interfering busybody demanding some report in their own special format, but what I am saying is that in many cases, if you get on the front foot and provide reports in this way you can often head those requests off before they arise.
If you find you're regularly asked to report a specific item, like days off due to Occupation Health and Safety incidents, for example, collect that information at the basic Checkpoint level of control. This allows you to make it part of your routine, rather than an add-on that you have to deal with each time.
- The Pepperoni Pizza Diagram is an original creation by the author
- PMI (Project Management Institute) (2008). A Guide to the Project Management Body of Knowledge (Fourth Edition). PMI – ISBN 9781933890517
- Question Mark Image: sxc.hu/7rains
- OGC (Office of Government Commerce) (2009). Managing Successful Projects with PRINCE2 (2009 ed.). TSO (The Stationery Office) –ISBN 9780113310593