In a previous blog I identified effective communications as being a strong contender for differentiating great project managers from the average. Soft skills training can play a valuable part in upping the communication skills for even the most seasoned project manager. However I also believe that coaching can also play a helpful part in raising the communications bar for junior project managers commencing their careers. Coaching can be a valuable and fulfilling experience for both parties and is especially useful in demystifying for the rookie some of the soft skills attributes that make great project managers. Coaching could incorporate some of the following communication topics: –
1. Don’t rely wholesale on formal methods of project communication
Formal project communications fulfil a vital role in managing projects but they are only a small part of what should be happening in a project manager’s communication cannon. Thinking about the type, format and frequency of informal communications with all of your project stakeholders will be a critical success factor in gaining trust, insight and knowledge of both the real progress of your project and stakeholder perception of its performance.
2. Don’t use project management “geek speak”
Project management has its own phraseology and this can become intimidating and confusing for many people involved with your project during the initiation phase. It is very temping for recently accredited (e.g. PRINCE2) project managers to demonstrate their newly found proficiency in the project management vernacular. They can often over use project method terminology in an understandable attempt to demonstrate their proficiency. However, whilst PIDs, end stage reports, critical paths, GANTT charts etc. may be familiar to your hard core project crew this esoteric language could immediately put barriers up and cause confusion with your wider business audience. Even to the project hardened it’s surprising how the continuous use of project management acronyms and jargon can create barriers and an unnecessary perception of bureaucracy. For business communications project managers should focus on explaining what these products really are, their use and their benefits. For example, explain that the PID=Scope; Gantt chart=plan etc. This can quickly demystify the approach and its products. However, there are times when you can’t avoid using some project management terms, which may not be fully understood by your audience. You will need to explain and illustrate their meaning using business language and real world examples. Textbook definitions won’t be that helpful.
3. However, do attempt to use the established business jargon
I am not advocating the over-use of generic management bs terms but simply using established and meaningful business jargon can be helpful in order to establish relationships with your stakeholders. This will also demonstrate an understanding of the business culture that the project manager is operating in. Every company and sector has its own unique set of terms and acronyms and these play a vital role in establishing clear and agreed definitions of terms of business and its operations.
4. Make sure your stakeholders understand the importance of managing risks and issues
One of the key project management concepts for your project board and senior users to understand is the difference between, and importance of, risks and issues. To a seasoned project manager these are the cornerstone terms that underpin much of what they do on a day to day basis, both in terms of action and communication. The management of risks and issues can absorb a lot of project manager’s time and they will need stakeholder’s help in their remediation and action. Don’t assume your business audience, or even your technical teams, will understand either their importance or the difference in their meaning. Explaining these terms and their relevance to the project should not be a semantic exercise. The project manager is reliant upon other people identifying risks and managing issues so giving them an understanding of these terms and their responsibilities will pay dividends down the line.
5. Managing expectations
Coaching junior project managers in how to manage expectations should be a priority in their development. Great project managers demonstrate superb judgement in managing different expectations across a wide set of stakeholders and throughout the whole project lifecycle. Ultimately, good expectations management is a key determining factor of whether a project is judged a success. We have all seen technically brilliant projects delivered on time and within budget but fail to meet customer expectations. Conversely, we will have all seen technically mediocre projects surpass customer’s expectations. Both extreme outcomes are in my view both common and are down to the quality of expectations management. Managing expectations must be seen as a priority and is dependent wholly on effective and targeted communications, both informal and formal. Managing expectations is relevant to each project phase, or put more simply, relevant to a project’s beginning, middle and end. Each phase will have specific challenges and require specific focus.
Project beginnings:- This is a key stage in managing expectations with the project sponsor and end users in particular. There will be the inevitable pressure from the sponsor to “just get on with things quickly”. Project managers may also experience “ground hog day” discussions of “why do we need all this paperwork before we can get stuck into doing stuff?”. During the initiation stage project managers need to show real patience, humour and cunning in restating the agreed and established project approach and in parallel grinding out an accurate scope and meaningful and realistic plans. I once recall a senior project manager using finger puppets to illustrate to his sponsor the necessity of effective project planning. Luckily the sponsor had a great sense of humour. The point is not necessarily to use finger puppets to illustrate the necessity for getting the initiation stage right, but to use any means available to re-educate your sponsor and pushy end users in the necessity of getting this stage right in terms of scope, assumptions, approach and risk. Managing expectations at this stage are vital. For example under-estimating the project plan because of a lack of rigour will put the project on the back foot from day 1.
Project “Middles” – The “doing phase” as it relates to managing expectations warrants a blog of its own and it is here.
Project “ends”:– Managing expectations during the “beginning of the end” stage is probably the most important from a customer point of view. By the “beginning of the end” I mean that period in a project when technically the project is nearing closure. Testing may not have commenced but all major technical challenges and risks will have been mitigated and there is some confidence in going public with the project release date. In some respects this is the stage when project delivery teams should be getting huge pats on the back. Technical challenges have been overcome and plan slippages will have been clawed back. Whilst there is some way to go the risk of technical failure will have reduced significantly. However, it is at this point that expectations must be managed with all stakeholders. It’s a time to re-tell, remind and re-invigorate the project involving the project sponsor, end-users and other beneficiaries. The scope may have dodged and dived a fair bit since the original project conception, so reminding everyone directly involved exactly what is going to be delivered, when, and why certain decisions i.e. changes in scope, have been made if there has been any deviation from the original conception. If expectations are managed at this stage then the final launch should hold no surprises for any stakeholders and expectations would have been met. Ignore these activities and go-live can be a hairy affair from a stakeholder point of view. You don’t want to be answering questions like “I thought the system was supposed to do x and now its doing y” on go-live day.