Reading Time: 4 minutes

This post in our series on project management processes will focus on the management piece to project management. If you’re new to this series, I recommend starting at the beginning. It’s important to understand that the project management piece is done during project execution. Some people like to combine execution and management, but it makes sense to consider them separately, since they are so important. While the management part is not totally about reporting, your life as a project manager will be much easier if you adopt a regular project management reporting process. Using raw data metrics to hold people accountable usually works better than using subjective data or biased observations.

Analyze key success factors so that you know where you stand.

Every project is different. If you started your project wisely, you identified one or two key success factors that could be measured. Chances are pretty good that it will be hard to measure them during the early days of the project. But you can focus on them, and determine what aspects of the project should be measured in the interim.

For example, if one of your key success factors was to finish within budget, you should be tracking your budget metrics regularly. The goal is to make sure that when you get to the end, you are not surprised by some metric or key success factor that you haven’t thought about in a year.

In team projects where there are a lot of independent contractors, some teams will focus on hours, rather than dollars. The reason is simple. No one wants to flaunt discrepancies in hourly rates. Another reason is that frequently estimates are quoted to the client in hours. So it’s important to understand the key metrics that you need to track.

When the focus is on hours, it’s typically an interim metric and there still needs to be some regular reporting on dollars to management.

Develop a reporting template so that the process can be streamlined.

Once you decide what you want to measure, you need to decide how often you plan to measure it. In a quickly moving project, you will likely want to measure your progress weekly. Other projects may only require monthly reporting.

One problem that I periodically have occurs when the reporting goes to multiple people, who all seem to want the reporting in different ways. You’ll just have to work something out that pleases most of the people. A template helps. Software that does it for you helps even more.

Use regular reporting so that you can hold members of the team accountable.

You should have a regular project management reporting schedule and stick to it. I periodically find that team members can be lazy about reviewing these reports unless nudged. So, don’t hesitate to disseminate the reports with a question that requires the recipient to look at the report and answer a question or two.

This might be particularly useful when you need more information on risks and issues. And if you aren’t meeting regularly, you should set up some kind of tickler system so that you can follow up with folks who haven’t responded.

Using reports to help manage your projects doesn’t mean that there aren’t other aspects of management that require something else. You will likely have periodic meetings where you discuss progress, risks, money, issues, lessons learned, and next actions.

Pick your battles so that you don’t run out of ammunition before the project is finished.

Projects have a lot of moving pieces and personalities. I’ve seen project managers get so consumed with progress and perfection that they annoy everyone. To some extent, that’s the job of a project manager – to stay on the team so that progress is made. But pick your battles and make it fun. Use raw data to hold people accountable, but be reasonable.

Develop a change management process so that you can keep scope within bounds.

In a world of rapid change, there will most likely be changes on your project. Expect that and plan for it. It will not likely fit into your weekly or monthly project management reporting. This is extra. You can read about how to set up a change management process here. Be clear about what constitutes a change on your project. If you’re trying to remain agile, not every tweak may represent a change that needs to go through a change management process. For example, does changing what ‘done’ means to clarify the deliverable constitute change? Does adding a deliverable necessarily mean a change? Suppose you eliminate a block of work? The question is often: did we change the budget or timeline? If you haven’t changed either, the change may be inconsequential. No one wants to be processing change orders unnecessarily. But you need a process.

We’re almost done. Next week, I’ll talk about closing a project. Stay tuned.