I'm minded to start up such cheap tactics as including the names of minor celebrities such as Paris Hilton and Miley Cyrus simply to catch some incidental drive by traffic.
As a jobbing project manager, one of course does get a reasonable level of exposure to the catalogue of general (and often dubious) apocrypha that accompanies the day to day cut and thrust of managing change.
An example of such apocrypha would be "...all projects succeed and all projects fail. Just to varying degrees of both..." which is possibly a little trite, but I quite like it all the same.
One such example which I don't like is "...you pay a project manager to worry so you don't have to...". I've never liked this terribly much because in theory a very talented worrier is suddenly a sought after commodity and I'm not one of those.
And then there's this little gem "...you pay a project manager to communicate..". Simple, undisputed fact. I like it.
Perhaps because I'm a little left of centre about these things, I've always thought that Alex Alexander Milne's "The King's Breakfast" contains many allegories useful for the project manager. There's some stakeholder management, some requirements management, setting of expectations and supplier management all in a few simple lines intended to amuse children. There's even some remarkable insights into value management. (Okay - that last one is a bit of stretch
So perhaps now is an opportune time to elaborate a little on the title of this post. One of the challenges faced by the PM is summoning the language, the agility, wit, poise and timing to communicate effectively. Don't get me wrong, the PM isn't unique in having these challenges but the PM is certainly likely to be in the room when;
- The sponsor asks for dairy products from the cow;
- The supplier questions whether it is an Alderney or a Friesian from which the afore mentioned dairy products should be derived and;
- The site foreman explains that no amount of coaxing is going to persuade an angry bull to give up a pint of the white stuff.
If this isn't delivered or can't be delivered it's likely to be the PM's phone that starts ringing.
So what useful steps can taken up front to guard against the prospect that either you can't or don't communicate as required. And, to understand the expectations and, where necessary to inform them.
- Process and procedure. I'm not going to labour this one, I hope rather that it is self-evident. If you don't have process and procedures, make sure you can report on whatever alternative is in place. And by the way, I'm not altogether sure what that alternative is Semantics aside, there's usually a way to navigate around aspects of work that are inherently not susceptible to process. Wrap process and reporting around them and 'go up the stack' to ensure that the entry and exit points are understood within an overarching 'flow of process'. Acknowledge that there may be elements of the overall flow of process which are able to be more accurately and more precisely reported upon than others.
- Validation and verification. Make sure you're doing the right thing. And make sure that thing is done right.
- Nomenclature and language. Make sure that you're all singing from the same hymn sheet. Make sure your inputs are capable of supporting the required reporting outputs. Do not make assumptions that the data will just join up. Define it to the required level of detail and perform the requisite static testing and prototyping to ensure that it all stacks up.
- Create standards, generate and publish a configuration management policy which is aligned and supports your overall reporting aims.
- And perhaps most importantly make sure you, as PM ,are in the room to inform the discussions to make sure these steps are taken and that the necessary resources are allocated to the tasks.