Spending time on planning and reporting activities means that you and your team have less time available for ‘normal’ work. The problem is that you just can not ignore the need for control from your projects sponsor (or project board), but also can not fully give in to their needs because nothing would get done. It gets even more difficult when issues arise and the projects progress is stalled. The more uncertainties arise, the greater the need for control, the less time is available for getting work done.

The chart to the left shows the relation between time/effort spend on keeping control (horizontal) en time spend on production/progress (vertical).  The more time is spend on control, the less time becomes available for getting things done. (With ‘time spend’ I mean time spend by both project manager and team members).

The problem is that there is no fixed formula to determine the sweet spot between control and progress. It all depends on the projects environment and also has a relationship with the project managers personality.

Some action-oriented junior project managers tend to focus on getting things done and ignore the project board’s needs (point 1). If the project is small and predictable this shouldn’t have to be a problem. It becomes a matter of trust (a believe that things are going to be alright even though the progress isn’t made visible by plans and reports).
When the project becomes more complex, when the time between conception and delivery becomes too long, trust doesn’t cut it anymore and more reporting is demanded. This even might result in a killed project even though real progress was made.

Sometimes a junior project manager is more focused on methods and less on results (point 2). I’ve seen this happen on a project where PRINCE2 was followed to the letter, creating elaborate progress reports, while the actual project’s progress was severely constrained.

In my personal opinion there is no sweet spot in the middle (point 3). I believe that the project manager should continuously work on the projects effectiveness towards point 4,  reducing overhead and increasing the amount of time spend on creating solutions, while still meeting the project board’s demand for control.

Though there is no fixed formula I have a couple of tips.

Fit for purpose

The projects control/progress balance isn’t fixed. It’s normal that the need for control is higher at the project start, end and during phase transitions. Also it’s quite normal for projects to have easy and difficult times. It is wise to alter the amount of reporting when needed. Do not stick to the initial communication plan but discuss the reporting needs and change when necessary.

Delegate tasks

The number of teams and team leads should not only be determined by ‘span of control’. It is wise to determine the amount of attention the project board needs and determine the amount of time the project manager has left for operational project management. If there isn’t enough time to manage the project properly, hire an additional team lead or delegate more tasks without adding additional management.

Build trust

The greater the trust, the less need for reporting and accountability. An excellent manner to create trust is to deliver the project results in increments (Scrum) to demonstrate actual progress and keep progress transparent (lessons learned, burndown charts, velocity).

Synchronize operational and strategic controls

It is smart to synchronize the need for operational control (by the project management team) and strategic control (by the project board) so that both needs are based on the same data. I’ve often seen that the project board reporting demands are difficult to implement because these demands need additional administration. It is wise to discuss the reporting needs with the project board and decide on a common definition of status and progress that suits both needs. Also here I’ve some excellent experiences with some of the Scrum reports (especially project process based on velocity).

Informal progress reports

Another smart thing to do is to discuss the project status and progress informally and on a regular basis. In my experience the project board has much more questions than can be answered within a document or even during a project board meeting. This also works two ways, it reduces the need for an elaborate progress report (thus saves time) but also increases the project ownership. That is very important because an involved project board increases the chance on success substantially.

• The Executive is accountable for the project's Business Case.
• The Senior User represents the people whom will use the product. He is accountable that the product meets the needs of these people.
• The Senior Supplier represents the people whom will create the product. He is accountable for the quality of the product.

The project manager is NOT accountable for the project's success. He is only accountable for managing the project's process. His job is to execute the plan agreed on by the Project Board. As long as the project manager does not exceed his authority the Project Board is very helpful. Why?

• Accountability is not transferable It just isn't so. You might assign other people within the project. The fact remains that if something goes wrong, the people which are accountable bare the consequences. Not the project manager but his boss, not the team but the supplier's director.
• Accountability creates responsibility The project manager executes the project plan as approved by the Project Board. If something goes wrong the Project Board has the resposibility and also the 'power' to help out. Problems shouldn't be the project manager's problem. In fact they are the Project Board's problems, because these people are accountable. A bit of an oversimplification maybe, the project manager still has problems, but the principle is sound and very effective.
• The Project Board process is mostly an informal process The 'Directing a Project' process within PRINCE2 describes a number formal documents and procedures. It describes only the formal part of directing a project. The formal part isn't that important and should be executed as light (agile) as possible. The real process take place informally, in meetings and discussions and only if needed ('management by exception'). So this process doesn't take much time if executed properly.

To me Project Boards are agile because:

• they are the ultimate impediment removers;
• they let me focus on the project's process;
• take only a little bit of my time, since the process is mostly informal and would be executed anyhow (if the Project Board wouldn't exist the same progress reports would be asked);
• the distinction between Executive and Senior User for me is a much better fit than only a Product Owner (however sometimes the Executive and SU role can be combined within one person);
• the Scrum scoping and reporting processes are a perfect fit from a Project Board point of view, so there's very little need to amend the Scrum method.

I've managed a PRINCE2/Scrum project for 8 months now and the Project Board is really helping me out when problems arise. It's great!