PRINCE2 Stakeholder Communication: Why Nobody Reads Your Project Reports (And What to Do About It)
Your project is progressing nicely, your reports are going out on time, and your stakeholders have been receiving enough information to keep a small government department occupied for months.
So why does nobody seem to know what’s happening?
Worse still, why do people suddenly complain that they weren’t consulted about decisions you’ve been discussing for weeks?
If you’ve managed projects for any length of time, you’ll probably recognise this situation. You’ve done everything you thought was necessary to keep people informed. You’ve circulated progress reports, distributed meeting minutes, updated the project schedule and copied half the organisation into your emails.
And yet somebody still turns up at a meeting looking completely bewildered.
The problem is surprisingly simple. Sending information is not the same as communicating effectively. It’s perfectly possible to keep everybody informed without anybody actually understanding what’s going on.
PRINCE2 Project Management (Version 7) gives us a useful framework for avoiding this problem, particularly through its emphasis on people, stakeholder engagement and the Communication Management Approach.
But before we get into the method, let’s look at why perfectly respectable project reporting arrangements can go so spectacularly wrong.
The Curious Case of the Project Report Nobody Read
Imagine that every Friday afternoon you send your project board a beautifully prepared Highlight Report. It contains everything a conscientious project manager could possibly want: schedule information, expenditure figures, completed activities, emerging risks, outstanding issues and perhaps a colourful chart or two for good measure.
It’s a magnificent document. You might even be rather proud of it.
Three weeks later, a senior manager asks why the project is falling behind schedule.
You explain that a critical supplier has missed several delivery commitments and that the problem has been clearly identified in your last three reports.
The manager looks at you in astonishment.
“Nobody told me!”
At this point, you may be tempted to print the offending reports, staple them together and introduce them to the manager’s forehead.
Tempting though that might be, it probably wouldn’t improve stakeholder relationships.
What’s actually happened is that you’ve delivered information without ensuring that the recipient understood its importance. The supplier problem may have been mentioned on page seven, buried between a financial summary and a list of completed activities, but nobody recognised that a management decision might soon be required.
The report was delivered. The communication failed.
That’s the important distinction. Good project communication should help people understand what’s happening, recognise why it matters to them and take whatever action is appropriate. Sometimes that means making a decision, sometimes providing information, and sometimes simply understanding how a forthcoming change will affect their work.
Adding another fifteen people to your email distribution list won’t necessarily achieve any of those things.
What PRINCE2 7 Actually Says About Communication
One of the welcome developments in PRINCE2 7 is its greater emphasis on the people involved in projects. Earlier editions already recognised the importance of communication, but the latest version gives much more prominence to relationships, collaboration, leadership and the human side of delivering change.
And quite right too.
Projects don’t exist in a vacuum. They involve people who commission the work, people who manage it, people who deliver it and people whose working lives may be changed considerably by the results.
PRINCE2 describes this wider environment as the project ecosystem. It recognises that project success depends on understanding and working effectively with the individuals and groups involved, including stakeholders who may sit outside the formal project organisation.
A stakeholder might influence the project, be affected by its outcome or simply believe that the project could affect them.
That last possibility deserves particular attention.
Imagine an employee who hears that your organisation is introducing an automated booking system. Nobody has explained its purpose, so the employee concludes that management is planning to replace reception staff with software.
You know perfectly well that the intention is to reduce routine administration and improve customer service. Unfortunately, the employee doesn’t know that.
Within a fortnight, rumours are circulating, resistance is increasing and a perfectly sensible improvement project is developing a reputation for threatening people’s jobs.
The project hasn’t necessarily done anything wrong technically. But it has failed to communicate effectively with the people who matter.
And that failure can quickly become a very real project problem.
The PRINCE2 Communication Management Approach
PRINCE2 addresses this through its Communication Management Approach, which describes how the project intends to communicate and engage with its stakeholders.
In practical terms, it establishes who needs information, what they need to know, how communication will take place, who is responsible and how frequently it should happen. Just as importantly, it considers how the project will obtain feedback.
Because communication isn’t simply broadcasting information. It also involves listening.
The Communication Management Approach forms part of the Project Initiation Documentation, usually abbreviated to PID, and should be kept relevant as the project develops.
Notice that I’ve said kept relevant, not expanded until it requires its own filing cabinet.
For a small, straightforward project, a simple communication schedule may be entirely sufficient. On a major programme involving contractors, regulators, several organisations and hundreds of affected employees, you’ll probably need something more substantial.
PRINCE2 expects you to tailor its approach to the project. The objective isn’t to produce paperwork for the sake of paperwork. It’s to establish communication arrangements that help the project succeed.
Why Different Stakeholders Need Different Information
Here’s something that sounds obvious until you look at how many projects ignore it.
Not everybody needs the same information.
You wouldn’t normally explain a complicated technical problem to your company chairman in the same way that you’d discuss it with the software engineer responsible for fixing it.
Yet project managers sometimes send identical progress reports to everybody, apparently hoping that the recipients will extract whatever information happens to be relevant to them.
It’s rather like giving everyone in a restaurant the same meal and expecting them to sort out their dietary requirements afterwards.
A much better approach is to understand what different stakeholder groups actually need.
What the Project Board Wants to Know
The project board is responsible for directing the project and making important decisions within its delegated authority.
Its members need information that helps them fulfil those responsibilities. They want to know whether the project remains viable, whether progress is satisfactory, whether the agreed tolerances are under threat and whether any decisions require their attention.
They probably don’t need to know that a developer completed twelve programming tasks yesterday or that the project team has rearranged its shared filing structure.
On the other hand, they certainly need to know if a supplier problem is forecast to push the current management stage beyond its authorised time tolerance.
In PRINCE2, the Project Manager normally provides regular progress information to the Project Board through the Highlight Report.
A useful Highlight Report explains what has been achieved, what’s expected to happen next, what significant risks or issues have emerged and whether the stage is still forecast to remain within tolerance.
More importantly, it makes clear whether the board needs to do anything.
If there’s a decision to be made, don’t hide it in paragraph fourteen beneath a heading called “Other Matters Arising”.
Put it somewhere people will actually notice.
What the Delivery Team Needs
Now consider the people doing the work.
Their concerns are rather different. They need to know what products must be delivered, what quality standards apply, what dependencies affect their activities and what constraints they must work within.
They also need to understand what’s changing and why.
PRINCE2 normally uses Checkpoint Reports to provide progress information from the Team Manager to the Project Manager. The reporting arrangements are established in the relevant Work Package Description.
However, that doesn’t mean everybody must produce another elaborate Word document every Friday afternoon.
Suppose your development team is using an iterative delivery approach and already maintains a visual board showing completed work, activities in progress and outstanding problems.
If that board provides the information the Project Manager requires, it may be entirely sensible to use it as part of the agreed reporting arrangements.
The objective is to maintain visibility and control, not to generate enough paperwork to frighten the local forestry commission.
What End Users Need to Understand
Finally, consider the people who will use whatever the project delivers.
They may have very little interest in schedule tolerances, work packages or expenditure forecasts.
Their questions are usually much more immediate.
Will this new system make my job easier or more difficult? Will I receive training? What’s going to happen to the procedures I’ve been following for the last ten years? Who do I contact when something goes wrong?
These are perfectly reasonable concerns.
And if the project doesn’t answer them, people will often invent their own answers, which can be considerably more alarming than the truth.
For these stakeholders, a demonstration, a short workshop or an informal discussion may achieve far more than a thirty-page progress report.
The lesson is that effective communication depends on the recipient’s responsibilities, concerns and information needs, not simply on what the project manager happens to find convenient to distribute.
A Practical Example: Introducing a New Appointment Booking System
Let’s bring this to life with a fictional project.
Imagine you’ve been appointed Project Manager for a group of healthcare clinics introducing an online appointment booking system.
The business objective is straightforward. Patients should be able to make and change appointments online, reducing telephone congestion and freeing reception staff to deal with people who need additional assistance.
The project involves a sponsor, an IT supplier, clinic managers, reception staff and an operations team that will support the new system once it’s running.
Everything initially looks rather promising.
The supplier reports that development is 75% complete. The project schedule is healthy, expenditure is under control and the latest progress report suggests that the planned launch date remains achievable.
The Project Board is delighted.
Unfortunately, the reception staff are considerably less enthusiastic.
They’ve heard that patients will soon be able to change appointments online, but nobody has explained how this will work alongside the existing booking procedures. Some are worried about double bookings, others are concerned about dealing with complaints, and several are convinced that they’ll be expected to operate a system they’ve never actually seen.
Meanwhile, the operations team hasn’t confirmed whether it has the people or resources needed to support the new service.
So there you have it. A project that appears healthy on paper while several rather nasty surprises are quietly gathering in the background.
And as experienced project managers know, nasty surprises have an unfortunate habit of appearing just when senior management is expecting a successful launch.
How Better Communication Changes Things
The Project Manager decides to review the Communication Management Approach.
Rather than sending the same report to everybody, different communication arrangements are established for the different stakeholder groups.
The Project Board receives a fortnightly Highlight Report concentrating on overall progress, significant risks, forecasts and matters requiring management direction.
The IT supplier provides regular Checkpoint Reports covering technical progress, dependencies, outstanding problems and planned deliveries.
Reception staff are invited to short demonstrations every two weeks. Instead of trying to imagine how the new system might operate, they can actually see it working, ask questions and make suggestions.
The operations team participates in readiness reviews so that training requirements, support procedures and operational responsibilities can be agreed before the system goes live.
Any feedback that identifies a problem or proposed change is assessed and managed through the project’s normal issue and change-control arrangements where appropriate.
Now here’s the interesting part.
The Project Manager hasn’t necessarily increased the overall amount of information being produced.
Instead, communication has become more useful because it addresses the needs of the people receiving it.
The Project Board can direct the project, the supplier can manage its work, reception staff can prepare for the change and the operations team can ensure that the new service will be properly supported.
That’s the sort of improvement we’re looking for.
How to Build a PRINCE2 Communication Management Approach That Works
You don’t need a particularly complicated system to improve project communication. What you need is a sensible way of deciding who needs what, why they need it and how you’re going to make sure they receive it.
I would start by identifying the people who can influence the project or will be affected by its outcome. Don’t restrict this exercise to the obvious senior managers and departmental heads. Include the people who will use, operate, maintain and support whatever the project delivers.
In many organisations, these are the people who understand the practical implications of change far better than anyone sitting around the boardroom table.
Once you’ve identified your stakeholders, spend some time understanding their concerns and responsibilities.
Ask yourself what each group needs to know, what decisions or actions it may need to take and, importantly, what information the project needs from that group.
That final question is one of the most valuable.
Project managers sometimes become so preoccupied with telling people things that they forget to ask questions. Yet a five-minute conversation with somebody who understands the operational environment can reveal a problem that hasn’t appeared anywhere in the formal project reporting system.
Next, think about the best way to communicate.
Routine progress information might be perfectly well presented through a short dashboard. A sensitive concern may require a personal conversation. A new working procedure might be better explained through a demonstration than through an email containing seventeen attachments.
Choose the method that suits the purpose, rather than automatically repeating whatever the organisation has always done.
You’ll also need to agree how frequently communication should take place and who will be responsible for it.
A fortnightly Highlight Report might suit one project board, while weekly reporting could be more appropriate in a particularly fast-moving or high-risk environment. A delivery team might provide weekly Checkpoint Reports, while end users could attend monthly engagement sessions.
These are examples, not compulsory PRINCE2 frequencies. What matters is that the arrangements are appropriate for the project and agreed by the people concerned.
The One Question I Would Ask Before Sending Any Report
Here’s a particularly useful habit to develop.
Before sending an important project communication, ask yourself:
“What do I want this person to understand, decide or do as a result?”
If you can’t answer that question, there’s a fair chance the communication needs another look.
Sometimes all you want is to reassure somebody that the work is progressing satisfactorily. That’s fine.
But if you need a decision, make the request absolutely clear. Explain the problem, what it means for the project, the options available and what you recommend.
Don’t expect a busy senior manager to uncover the required decision by carefully examining every paragraph of a lengthy report.
And don’t assume that silence means agreement.
Check whether your communication has actually worked.
Ask stakeholders whether they’re receiving the information they need, whether it arrives at the right time and whether anything important is being overlooked.
You may discover that your project board would appreciate shorter reports, while the people preparing for implementation need much more detailed guidance.
That’s not criticism. It’s useful feedback that can help you improve your approach.
Finally, remember that communication needs change throughout a project.
During initiation, stakeholders often want to understand why the project is necessary and what benefits are expected. During delivery, they’ll be more interested in progress, developing products and emerging issues. As implementation approaches, attention naturally shifts towards training, operational readiness and what will happen when the project hands over its products.
Review your Communication Management Approach as the project develops, particularly when preparing for a new management stage.
An arrangement that worked beautifully six months ago may now be about as useful as a chocolate teapot.
Five Communication Mistakes That Can Cause Real Trouble
Over the years, I’ve seen plenty of examples of project communication going wrong, and most of them don’t involve particularly complicated problems. They usually involve perfectly ordinary misunderstandings that nobody notices until they become expensive.
The first is confusing activity with progress.
A report announcing that twenty-seven activities have been completed sounds impressive. But what have those activities actually achieved? Have they produced useful project products? Have they moved the project closer to delivering its objectives?
If you concentrate entirely on completed activities, you can give the impression that everything is progressing nicely while the really important work remains unfinished.
The second mistake is reporting problems without explaining their consequences.
Telling the Project Board that a supplier is two weeks late doesn’t necessarily provide enough information for a decision. The board needs to understand what the delay means for the stage, whether corrective action is available and whether agreed tolerances are likely to be exceeded.
And remember, if a stage or project tolerance is forecast to be exceeded, that requires escalation through the appropriate PRINCE2 controls. You shouldn’t simply wait until the next scheduled Highlight Report and hope the situation improves.
The third mistake is using technical language with people who have no reason to understand it.
Your development team may appreciate a detailed explanation of an interface integration failure. The manager of a busy healthcare clinic probably wants to know whether patients will still be able to book appointments on Monday morning.
Both need accurate information, but not necessarily the same explanation.
The fourth mistake is treating communication as a one-way process.
If people are never given a genuine opportunity to ask questions, challenge assumptions or explain their concerns, you’re missing one of the most valuable sources of project information.
And the fifth mistake is assuming that the number of reports you’ve distributed somehow measures communication success.
It doesn’t.
You can produce hundreds of reports, maintain a splendid document repository and send enough emails to overwhelm an entire department without improving understanding by a single inch.
A much better measure is whether the right people received, understood and acted on the information they needed.
What PRINCE2 Foundation and Practitioner Candidates Should Understand
If you’re studying for the PRINCE2 Foundation examination, make sure you understand the purpose of the Communication Management Approach and how it supports effective stakeholder engagement.
Remember that PRINCE2 7 places particular importance on people, relationships and communication. It’s not enough to know which documents exist. You should understand why the project needs appropriate communication arrangements and how those arrangements contribute to successful delivery.
You should also be comfortable distinguishing between two important PRINCE2 reports.
The Checkpoint Report provides progress information from the Team Manager to the Project Manager, while the Highlight Report provides regular progress information from the Project Manager to the Project Board.
Those are different reporting relationships, serving different management purposes.
For Practitioner candidates, things become more interesting because you’re expected to apply PRINCE2 to a particular project situation.
Imagine an examination scenario in which senior users complain that the technical progress reports they’re receiving are difficult to understand and don’t explain how the proposed system will affect their departments.
The Project Manager proposes increasing the reporting frequency from fortnightly to weekly.
Would that solve the problem?
Probably not. You’re simply giving people more frequent access to information they already struggle to understand.
A more appropriate response would be to review their communication needs and tailor the content and method accordingly.
That’s the kind of judgement the Practitioner examination is intended to assess. You’re expected to understand the method well enough to apply it intelligently rather than mechanically.
One other point is worth remembering. A stakeholder communication problem isn’t automatically a formal PRINCE2 exception. However, if the underlying situation means an agreed tolerance is forecast to be exceeded, the appropriate exception escalation arrangements must be followed.
The important thing is to recognise the real problem and apply the appropriate management response.
The Real Purpose of Project Communication
After all this discussion about reports, stakeholders and management approaches, the central message is remarkably simple.
Project communication should help people understand what’s happening, why it matters and what needs to happen next.
PRINCE2 provides a sensible structure for achieving this through its people element, management responsibilities, reporting arrangements and Communication Management Approach.
But the structure itself isn’t enough.
A beautifully written communication strategy won’t help much if nobody follows it, just as an impressive Highlight Report is worthless if the Project Board doesn’t understand what it’s being told.
The real improvement comes from knowing your stakeholders, understanding what matters to them and communicating in a way they can actually use.
Your Project Board needs information that helps it direct the project. Your delivery team needs clarity about its responsibilities and progress. Your end users need to understand how the changes will affect them and have meaningful opportunities to contribute.
And everybody needs to know that when they raise a legitimate concern, somebody is actually listening.
Get those things right and you’ll have done considerably more for your project’s prospects than simply adding another column to the weekly progress report.
Which brings us back to where we started.
If nobody seems to be reading your project reports, perhaps the first question shouldn’t be why people aren’t paying attention.
Perhaps it should be whether you’re giving them information that’s worth paying attention to.
Want to Become More Confident With PRINCE2?
If you’re preparing for your PRINCE2 Foundation or Practitioner examination, or you’d simply like to understand how to use the method on real projects, my Projex Academy PRINCE2 Masterclass is designed to help you build that understanding.
We explore the principles, practices, processes, management responsibilities and practical application of PRINCE2, concentrating on understanding how the method works rather than simply memorising terminology.
You can also read the Projex Academy article on PRINCE2 Communication and Leadership for further insight into the people side of project management.
Because good project management doesn’t have to be complicated. It needs to be understood and applied with a little common sense.
And when it comes to communication, a five-minute conversation with the right person may be worth more than fifty pages of beautifully formatted reports.
Dave Litten
Project Management Instructor, Projex Academy
