Project status reporting – what’s worth focusing on?

One of the necessary evils for a project manager is to provide stakeholders with regular status updates.  There are likely as many variants on project status reports as there are deadly sins of project management, but are there some good practices that you can follow if your organization has not instituted standards for project status reporting (which I think is an issue but that’s a discussion for a future article!) ?

Here are some ideas to start with:

1. Think like your audience – this requires that you’ve done some reasonable quality stakeholder analysis to understand the PM maturity, “hot buttons” and level-of-detail needs for your stakeholders, but assuming you can draw on this data, use it!  If you are going with a single status report for all stakeholders, structure it to appeal to a broad audience – perhaps start off with an executive summary on the first page or section and then dive into the gory details later on.

2. Think in terms of yesterday, today and tomorrow – the status report should remind the audience where you’ve been, what has transpired in the current reporting period, and your forecast for the future.  For key performance indicators such as schedule, cost, quality or customer satisfaction variance, consider having three data points – performance in the last period, performance in this period, forecast for the next period.

3. Provide both objective & subjective information – while you can easily drown your audience in a variety of quantitative metrics (e.g. CPI, SV, CV, # of unresolved critical issues, burn rates), there is equal value in a good subjective description of the current state of the project.

4. Be consistent with subjective stoplights – remember that one person’s troubled project is another person’s healthy project.  Work with your stakeholder to define a consistent, objective approach for setting stoplights and provide a legend at the bottom of each status report so stakeholders don’t forget.

5. Focus on the rule of 10 and don’t overwhelm the audience with minutiae – report on the top 10 issues, risks, milestones and so on.

6. Use a business context for all content – present issues, risks and status updates in the context of customer deliverables or business value/impact.

“This is your Captain speaking” – Airline peeves for IT to avoid!

Having experienced first hand in the last couple of days some of the challenges experienced by hapless travellers, I have a few pet peeves with the airline industry that are applicable to IT…

1. Why is it that when a flight is cancelled, you can get more responsiveness from a remote telephone reservations agent than a local ticketing agent at the airport?  I was able to re-book my cancelled flight via the telephone in 2 minutes while other less fortunate passengers were at the mercy of a ticketing agent who could not seem to complete one re-booking in twice that time.  Consistency is key – whether your customers are dealing with your IT staff via phone, e-mail or in person, the message and degree of responsiveness needs to be medium-neutral.

2. Set expectations regarding regular status updates and be prepared to increase the frequency of communication when things start to go wrong.  Flight delays due to weather are par for the course, but when you are sitting at the gate (or worse, on the tarmac) waiting for clearance to take off, it would be nice if the flight crew would give regular updates at scheduled intervals, even if there was nothing new to report.  Project or operational activities should follow the same practice – establish standard frequencies for regular or routine communication and increase and focus these communications in times of crisis.

3. Tailor the message to the audience – very few of us know the real difference between an altitude of 10,000 and 33,000 feet.  From my perspective, either height is high enough to kill you.  Why increase the “signal:noise” ratio by communicating such information when there is so much more useful information that could be communicated from the cockpit?  I liken this to the tendency to use “techno-babble” when communicating with your customers – it adds little value to their day.

4. More for vendors than for internal IT departments: standardize policies & procedures wherever there is no benefit in specializing/customizing.  Why do some airlines allow you to use wireless devices the moment a plane touches down while others insist that you avoid this activity until the engines are off and the seat belt sign is extinguished?  Surely the same electronic equipment does not vary drastically from one company’s airplane to another one’s?

Whether in IT or in airlines, consistency & communication are key.

Strategic objectives – what an oxymoron…

A standard expectation for most of my clients that are adopting PPM practices is that over time, their portfolio will become better aligned with the strategic direction of their organization.  One approach to address this is by evaluating the alignment of individual projects to strategic business objectives.

While this is valid in theory, in practice, it usually breaks down (hence the name of my Blog).

An underlying assumption is that the organization has a well-defined strategic plan that a project’s alignment can objectively be evaluated against.

Unfortunately, most organizations do not invest the effort required to create, refine and maintain a strategic plan containing objectives that pass the SMART criteria test.

For example, a client may say: we want our company to be a “provider of choice”.  As someone on a project evaluation committee, this type of objective is open enough to allow almost any project to claim alignment.  On the other hand, if you apply the SMART criteria to the objective and state “We want our company to be ranked in the top five providers for Y based on X’s independent survey for the 2010 calendar year” we are in a better position to:

1. Expect a project requestor or sponsor to explicitly specify how they plan to achieve this objective.

2. Have a method of evaluating whether or not they did achieve this objective.

#2 is critical – without it, what’s to prevent project requestors or sponsors from over-inflating the value propositions for their projects?

So how do we translate this into action?

If your executives or board are unable or unwilling to define SMART objectives as part of their strategic plan, your project governance committee should launch an initiative to have these distilled from the “motherhood & apple pie” high level objectives – without this, don’t bother trying to evaluate alignment.  Sure, you can take a subjective approach to considering which high-level objectives a particular project may be strongly or weakly aligned with, but this can hardly be used to facilitate project selection or prioritization.