Does anyone like filling out formal weekly Project Status Reports? Anyone?

For most of us, that dull ritual of filling out the fields and columns and lines of space to record our “Progress Made' and “Anticipated Risks' was a weekly chore – something to be borne, with patience and forbearance, much like the humidity in Bombay. You could rail at it, but it remained unmoved, and it never went away.

Status reports, like other formal Project Management mechanisms exist for a reason though, and it is a good one. Like with any other tool or mechanism, its success depends a lot on how it is used – there are ways by which a Status Report can really add value, without sucking up huge amounts of time and effort. So for all those of you who are currently condemned to going through the ritual week in and week out, here's the underlying theory. My hope is that if you understand, you will tolerate better, and perhaps may actually derive more value from existing mechanisms, for yourselves and for your projects.

Imagine you are managing a small project for a client at a single location. (It could be any type of project – you may be doing a piece of research for a client, you could be an interior designer carrying out a renovation of a house, or you may be implementing an IT application for a small business). Your team is co-located at the client site and you are in daily touch with your team members, your own company leadership and your clients.

In your project plan / schedule, your list of activities includes all your project work-streams. Your house renovation work, for instance, might have activities grouped under various heads – civil, electrical, wood-work, plumbing etc. In addition to these 'client-facing' activities, there is an additional activity – 'Project Management'. This covers all the small tasks you do to keep the project running on schedule –actually making the schedule itself, updating the schedule, getting updates from your team and external contractors, responding to unplanned leave requests, alerting the client on any issues and deviations, escalating issues to your leadership, involving the client and your organization in finding solutions to specific issues, billing the client and getting payment.

In a small co-located project as above, you may rightfully treat these tasks as 'routine' – often not worthy of inclusion in your overall activity list on the Project Schedule. The updates are instantaneous, the resolutions are often of the 'walk across and sort out face-to-face' type, and your directives to the team are immediately known across the team. The Project Management tasks are all there, but they are not of a scale and complexity to warrant formal Project Management Mechanisms. You don't need a formal weekly Status Report – what would your electrical engineer put in it anyway, that you haven't found out through your daily interactions?

Now imagine a vastly more complex project, spanning multiple locations, with a larger team, several levels of authority and a much greater number of stakeholders – client and internal. For a project of this type, Project- Management-by-walking-across will be disastrous. The close visibility and instantaneous transmission of project course corrections are simply non-existent. There will be lots of cross talk and one-to-one correspondence, which are invisible to the Project Manager. Local issues could threaten to impact activities at other locations, and the Project Manager cannot be omnipresent. Therefore, in such a project, right from the planning stage Project Management tasks are treated as a separate work-stream, as important if not more than any of the individual 'client-facing' work-streams. The Program Management or Project Management office, if one exists, is often the fodder for much speculation in project teams executing activities on the line – 'What do they actually do?' goes the whisper. The reality is that without the PMO, the project can hardly run in a co-ordinated manner.

What formal Project Management Mechanisms actually do on such projects, is to introduce a steady rhythm of periodic, standard processes into project activities. Ground rules are laid, weekly deadlines established, escalation mechanisms set-up, course corrections documented and procedures for handling scope-change requests created. This rhythm ensures that all the phone lines across different locations are not jangling all the time – work units and locations are given a period of relative calm to actually execute the work, while issues are parked for resolution at an appropriate time, in an appropriate manner. For me personally, the realization dawned rather late that while I used to crib about the hour / two hours spent every week on the Status Reports, it was those “lost two hours' that actually allowed me to function at all the rest of the week.

The danger to guard against is overkill. The rigour and degree of complexity of the Project Management mechanisms needs to be matched (in fact driven) by the complexity of the project. Too simple / informal a mechanism on a complex project results in chaos and lack of co-ordination; equally too complex a mechanism on a simple projects results in loss of productive time and high levels of resentment. You don't want to spend all your time doing nothing but reporting on the nothing you're doing. I've been on a project where the manager insisted on a formal daily update, though we met at least twice a day. That project didn't go too well, I'm afraid.

There are a few other best practices on Status Reports (since I began with them) that I can share:

• As a rule, keep them simple: For most projects, a simple 1 pager should suffice. This can cover “Planned Activities', 'Activities Completed', 'Work-in-Progress' and 'Issues / Concerns'.
• Decide an appropriate frequency: Weekly updates should suffice for a majority of projects.
• Coach your team: On what goes in, and what should be kept out of a Status Report. Ideally, Status Reports act as Early Warning Systems – they provide advance notice of what might be a small concern now, but could escalate into something big, if left unresolved. Also, if there is a real crisis, you don't want your team member waiting to put it into a Status Report – you want him / her to pick up the phone now.
• Ensure you read and react to what's written on a Status Report: Not responding to something that is flagged as a concern on a report is the surest, fastest way to get your team to start thinking that this is a meaningless admin task.

 

Lastly, formal mechanisms exist for another reason apart from project complexity, and that's for documenting evidence or leaving a physical trail, just in case there are future battles to be fought, within or without. This reason ensures that even in your simple single location project, you end up having formal periodic documentation of some sort, though the project scope and complexity alone may not warrant it. Again unavoidable, like the weather.