All projects send out status reports or progress reports to various stakeholders at some regular intervals.
This ubiquitous project artifact is often handled in a very routine manner without sufficient realization of what could be possibly achieved with it.
Here are some basic best practices:
1. It is usual to fill it up a progress report with planned activities versus completed (in part or full) in the period of review. In most cases, these activities by themselves may not be meaningful to the stakeholders. The report is much more useful to the stakeholders if milestones are set up that convey to stakeholders in their terms what is achieved at that point and the progress is tracked and reported in terms of these milestones (in addition to or instead of activities).
The milestones are thus meaningful pit-stops for various stakeholders towards achieving their business objectives. Taken together, they show a logical build-up of the project deliverables and progress to the final denouement.
For example, in the WAN project of the last post, a milestone of the kind ‘Training Infrastructure ready for cities A, B and E’ would make more ready sense to the manager of the Implementation Team (see point 8). Instead the progress report talked about the status of the WAN links to cities A, B, C, D…
Practice: Report progress with the help of meaningful milestones.
2. In a project of wider scope, there are several stakeholder classes. The progress report must cater to the interests of all these classes of stakeholders. For instance, in a SAP rollout project, it is easy to miss out the training interests. If milestones are majorly relied upon to communicate the progress, a simple mapping of the milestones to the stakeholders would reveal: a) Are there milestones to cover all classes of stakeholders? b) For a given class of stakeholders, do their milestones build up logically towards the completion?
Though any inadequacy in this regard is pointed out as a deficiency in the progress report, note that this is something to be taken care of in the project plan itself.
Practice: Cover in the progress report interests of all stakeholder classes.
3. Feel free to invent your specific format of the progress report based on the type of project, the concerns of the stakeholders and the stages of execution. One size does not fit all.
For example, consider a project where a development team is loaded with ad-hoc work-packets from a user community. Each work-packet is taken up by a programmer and completed in a few days.
If the traditional progress report format is used for this project, the report would contain perhaps one line per work-packet with its scheduled and actual dates closely matching. This is hardly insightful. In these types of projects, at any point of time, the capacity and utilization of the programming team is of more concern. So the progress report could show for the week the available resource hours and blocked resource hours and a pending queue of the work-packets.
In one such project, the work-packets were streaming in from multiple groups of users whose demands for service were often conflicting. There was no strong governance mechanism in place for arbitration on priorities. In this project, this report was used very effectively to realistically set the users’ expectations by making the backlog quite visible. Many potential conflicts of schedule were preempted much before they came to a boil.
There are times when the format of reporting the progress used in one phase of the project is not suited in another phase of the same project. For instance, when a project nears completion, it switches to the work-packet mode. Here the rush is to get as many items through work-packets covered before the code freeze. At this stage, it does not make sense to talk in terms of scheduled and actual activities.
Practice: Align the progress report closely with the project needs and concerns. It is ok to come up with custom formats and switch from one to another when the perspective changes.
(concluded)
Tags: Best Practices, Milestones, Progress Report, Project Management
