Effective Project Communication: Not Just What, but Why
A project manager recently asked me to review an executive status briefing he prepared. He was warned to be brief but was worried his message might be lost.
He listed tasks completed in the prior month, tasks expected in the coming month, schedule, budget, and risks. What he didn’t do was make the information meaningful.
Giving executives data without context and meaning is dangerous for both project manager and executive. Executives walk away without valuable information, and the project manager does not get the action or attention that would be helpful. Worse, should problems arise later, the executive can honestly say, “Why didn’t you tell me?” while the project manager can respond earnestly, “But I did!”
Business executives will often not understand the sometimes arcane language of development. The burden of making the status meaningful is on the project manager.
In this status report, a bullet indicating “Requirements sessions complete” was terse and mostly meaningless. It sounds like a milestone has been reached, but the significance would be lost on most non-IT executives. I suggested an addition:
“Requirements sessions complete. We have finished a series of meetings with the users to understand the business problem, and we will capture this information in a work product called a requirements document that we will publish next month for the users to review. Once that document is approved by the users, it will serve as the baseline agreement with our vendor about the problem to be solved.”
This item is not quite as terse, it explains the significance of the milestone, and it describes a work product that will be produced next month as a consequence and why careful review of that work product is important to the project.
This dovetailed nicely with a risk that was shared. The original wording from the PM was:
“If Records Division cannot provide the promised resources next month, the schedule may be affected.”
I thought that risk statement wasn’t impactful in the context of the project. Again, I suggested a change:
“If Records Division cannot provide the promised resources next month, their review of the requirements document may be delayed or incomplete. This could affect project schedule by delaying the vendor’s development efforts, or impact solution quality if it results in undetected misunderstandings or omissions in our agreement with the vendor about the problem to be solved.”
This is a little longer, but it explains to the busy executive the significance of the information. Remember, most execs don’t worry about your project every day. They worry when you give them something to worry about. In this case, the language of the risk ties directly to the previous bullet emphasizing the importance of the requirements document.
Explain progress in words business executives can understand. Explain setbacks or risks in business terms that clearly indicate the consequences of the event or risk so that executives can prioritize their actions. Never put an executive in a position where they can earnestly say, “Why didn’t you make this clear to me?” If you do, you have lost their confidence, no matter what your status report says.
