Adequate communications with BOTH the customer and the project team is key.
Communications is a critical component of any successful project. It governs not only how well the project team works together, but also impacts the public perception of how well the project is going. Communications is a multi-faceted function that serves a variety of different purposes. I would like to focus on just two aspects of project communications; managing the customer’s perception of the project, and internal project team communications.
Managing a customer’s expectations of the project outcome is one of the most important jobs of a project manager. How often have you heard of a company having a real good earnings report, only to have their stock go down because they didn’t “meet analyst’s expectations”? For a project, not meeting expectations often results from poorly defined project requirements and deliverables, combined with inadequate communication of project status, causing the customer to assume capabilities that the project was never designed to deliver. Therefore, it is very important to explicitly communicate exactly what the project will deliver, as well as what it will specifically NOT deliver.
Keeping the customer apprised of detailed project status involves more than just holding periodic project meetings. These can be a big time waster if not properly structured and combined with other communications methods.
One ancillary communications vehicle that I have found useful in the past is to create/maintain a project notebook for each customer stakeholder. While each project will have different communications requirements, the following list provides some examples of the content that I have found useful in the past:
- a detailed description of the project requirements
- important project milestones and deliverables
- all meeting minutes
- significant communications with key vendors contributing to the project
- internal project memos
- change request logs
- analysis/tracking of major project risks and issues/problems
- tracking of key project dependencies – especially with outside entities
Prior to each Prior to each Prior to each Prior to each Prior to each Prior to each project meeting with stakeholders, I send out revisions/updates to the project notebook reflecting the latest project status. This allows us to focus the meetings on important project issues and not waste time on the more routine status items.
You might reasonably argue that some of this information could be considered project minutia that wouldn’t be very meaningful to a project stakeholder. However, providing this level of detail tends to build an element of trust indicating that you’re not holding anything back from the stakeholders. In other words, you are making the stakeholders part of the project team, dissolving the typical “them vs. us” mentality that often exists between the project team and the end customer. Providing this level of information to the customer goes a long way in preventing unrealistic expectations from arising.
The other area of communications that is often undervalued is internal project communications. There is a school of thought that communications with team members should be confined to just those areas that they are working on, the theory being that it helps people focus on their individual tasks at hand, rather than being inundated with information extraneous to their function. While there may be some truth to this, my experience has been that some of this “extraneous” information actually increases people’s effectiveness because they are more aware of how their efforts fit into the global scheme of things. Furthermore, potential integration issues between major project components tend to be identified earlier due to this increased awareness.
A secondary benefit is that a well-informed project team functions more like a team, has higher morale, and presents a more unified project “face” to the customer (i.e. no matter which project member the customer talks to, they get the same information).
In summary, open and honest communications with the customer and internal team members increases the chances of success. There is an old adage that if you don’t provide adequate information to people, they’ll make it up. Most projects have enough real technical challenges to deal with, without having to address issues caused solely by poor communications that could easily have been avoided.
