Communications, Communications, Communications

It seems appropriate to initiate a blog about project management best practices with a discourse on communications.  I certainly have plenty to communicate.  I look forward to sharing my thoughts with you.  May you find some of them interesting to read.

The description of this blog documents my intent and will drive the selection and direction of content.  I will present here my thoughts on PM best practices;  I invite your feedback, critiques, support, and disagreement so that we share a discussion;  and I hope that from my humble contributions someone finds a gem and takes a step to improve their organization.

So what does “communications” have to do with best practices?  Communications isn’t a best practice.  Communications is just sort of what happens when we project managers do what we’re supposed to do.  Publish a project schedule?  That’s communications and fosters communications – team members and stakeholders either accept it or they object, and the ensuing discussion improves the schedule and everyone’s understanding.

Project plan (and, notice that project plan is different than the schedule).  Negotiating the plan (and the component plans for managing costs, resources, risks, vendors, etc.) causes team members and stakeholders to understand how each role contributes to the ultimate result.

A well-prepared project status report is a key communications tool, providing a snap-shot of the project state (relative to plan), accomplishments, issues, etc.  The status report is like a diary, providing a continuing narrative of the project state.

The risk register, issue log, change requests, EVM graph, deliverable acceptance form, and everything we as PMs produce are just there to force two or more people to see the same content presented in concrete form and either accept it or talk.  By publishing the content, you prevent misunderstandings and misaligned assumptions.  I’ve been amazed over the years how many project problems have been avoided just by forcing two people to talk to each other.

Each of these documents are best practices for a reason – projects work better with them.  They’ve been proven by experience.  That is, when they are used projects are likely to be more successful than when they are not used.

So I’m going to communicate.  I’m going to share what I’ve learned.  Maybe somewhere in my ramblings you’ll find a gem that helps you on one of your projects.  Until then…

Communicate, communicate, communicate.