.png)
Management is full of buzzwords, latest catchy phrases and clever (or not) acronyms, and Project Management is certainly no exception. Whilst technical jargon and PM terminology help those in the field discuss concepts and ideas, when it comes to communicating with project stakeholders, these specialist words should really be off-limits. There is little value in calling things using fancy, specialised or obscure words: what matters is getting yourself understood and make your message clear, simple (and relevant).
Here are a few examples from the field. To set the scene, imagine you are the project manager responsible for the delivery of a website supporting the launch of a new product range, and you want to address some key aspects of the project with your project sponsor, the Sales & Marketing Director.
About the methodology used to manage the project:
Don’t say: Project methodology used will involve iterative waterfall integrating Agile principles, allowing streamlined iterative software cycles through collaboration between self-organising, cross-functional teams.
Say: Website functionality will be released faster and in smaller chunks, and will involve extensive interaction and feedback from Sales & Marketing subject matter experts.
What’s different: The project methodology you choose is not relevant per se to your stakeholder and would mean likely mean nothing to her. Here it’s about making it meaningful and saying that her team will be heavily involved in the project , and that the new website site will go public soon, and in phased increments.
About testing the new website:
Don’t say: Testing plan and execution will be composed of several test cycles of UT, SIT and UAT with bug tracking and fixing prior to code freeze for technical deployment.
Say: The website will be validated first by the technical team, then by Sales & Marketing users before launching to the public.
What’s different: Avoid specialist acronyms (here Unit Testing, System Integration Testing and User Acceptance Testing) and focus on what makes this relevant to your stakeholder: here it’s about providing confidence that things will be thoroughly checked before going public, and that her team will have a responsibility in doing that.
About managing project progress:
Don’t say: We will use the PMO’s centralised PPM tool to monitor project plan and milestones achievements, and identify and track risks and issues.
Say: We will report project progress to you on a weekly basis and proactively engage you to resolve problems when required.
What’s different: You don’t need to talk about the tools you use because frankly your stakeholder won’t care if you are using a sophisticated software or the back of a packet of mints to monitor the project: it’s your job to track the project, whichever way you see fit. What matters here is to tell your sponsor that she should expect weekly reporting, as well as being called in to make decisions when needed. Oh, and of course you can kill the acronyms on this one (Project Management Office and Project Portfolio Management).
About project budget status:
Don’t say: CPI is 0.8.
Say: We are currently running over budget due to the need to add functionality to comply with legal requirements. Approval on additional budget or scope revision will be required.
What’s different: another case of staying away from specialised acronyms (CPI = Cost Performance Index, an efficiency indicator showing the ratio of planned cost of completing work on actual cost of completing work). Actually, here CPI is more likely to mean “Consumer Price Index” to your Sales & Marketing exec! Although I am an advocate of “less is more”, here this short piece of data doesn’t really inform the non-initiated. The number in itself doesn’t matter so much: what matters is to say what it means (we don’t have enough money to finish!) and what to do about it (we need a decision from you!).
Comments