August 6, 2012 | Author: PM Hut | Filed under: Communications Management
Communications for Change
By Dave Nielsen
Companies who have enjoyed some success in countering these campaigns have done so by treating the communities whose water the project could affect as stakeholders and treating communications with the communities as a project deliverable. An example of one such communications campaign involved newspaper ads which included photos and descriptions of all the equipment and materials used in the project. This approach presupposes that the materials and equipment in use does not introduce harmful chemicals to the drinking water. Communication with these stakeholders from the initiation phase of the project is another key to success.
Fracking projects are not the only ones that can fall prey to the fear of the unknown. Many IT projects run the risk of meeting user resistance because the effect of a new system on their jobs is an “unknown”. Users fear that their jobs are going to be made more demanding or that they will lose functionality with the new system. They may also fear losing their jobs as a result of a new software system making their jobs obsolete. Project managers responsible for projects which implement new software systems should take a page from the fracking industry’s book. The tools used to communicate may differ but the same principals that make the fracking communication effective can make communications for the IT project effective.
The first rule of effective communications is to treat the user community as a project stakeholder that must be communicated with. The primary user community will be immediately obvious, these are the folks the system must be rolled out to and who must be trained in its use, but look beyond that initial community. Are there any folks downstream or upstream of this primary group whose work could be impacted by the new system. Even if the work products are substantially the same, could slight differences affect their work? Could differing delivery schedules affect them? The use of process flow charts can help you identify hidden stakeholders. Don’t stop at the edge of the chart; check out the groups at the other end of those “off the page” markers.
Make communications with these stakeholders a project deliverable. Large extraction companies frequently employ whole groups of people whose only job is communications. They are seasoned veterans of project communications and can manage all aspects of this work from identifying stakeholders, to defining the best strategies, to composing the right communications. Smaller, less sophisticated, IT projects must manage this activity on their own. Make sure your project has a communications management plan, identify all the stakeholders and then find out what information each stakeholder group would be best served by. Another trick we can learn from the extraction sector is to engage these folks as early as possible, don’t wait until the week before implementation.
The stakeholders you must communicate with may include workers whose jobs will be eliminated when you deliver your new system. You may be tempted to discount these people - after all, they won’t be around to trouble you after your new system is implemented. Often the best and brightest of these folks get re-assigned to other jobs that you may come in contact with so treating them with respect is in your best interests. Even those who will leave the company will have an impact on those left behind. If the perception is that these people are treated fairly, included being kept informed, the effect will be positive. If the perception is that they are deliberately being deprived of information, the effect will be negative.
Now for the $64,000 question: exactly what do I say to people whose jobs will disappear when the new system is introduced? Firstly, don’t try to hide or cover up the fact that jobs will be eliminated; your dishonesty will be discovered and from that point forward you will have lost everyone’s trust. Work with your HR organization to develop information to be communicated. These are the people who understand which policies affect that type of communication. They should also be experienced with putting these types of communications packages together. Secondly, get all the facts around job eliminations. Which jobs will be eliminated? Which jobs will be opening up because of the change? How do workers go about applying for other positions in the company? Your HR organization should be able to help with all these questions. Include what you know about the project. What were the reasons behind building the new system? How will the new system benefit its users? How will it benefit the company? There may be information that is sensitive and can’t be communicated until the public has been informed. This information is usually of the type that would tend to influence stock prices. When you are unable to share this information, inform your stakeholders of the reason you can’t share it with them. It is very likely that communications for a new system that is part of a major change in business will be managed at the corporate level. Your communications should form a part of that larger plan.
Be honest in your communications. Give people the facts they are interested in or that they need. We are often tempted to gloss over any negative impacts the new system may have on the user community. We don’t deliberately mislead people but we tell people things we think they want to hear. Don’t be afraid to mix the good news with the bad. Frequently new systems require users to endure short term pain to enjoy long term gain. Don’t shy away from communicating information about the short term pain. Your user community is smart enough to figure out the value proposition. Just remember that once the cat is out of the bag it is very hard to put it back in. Know who has overall responsibility for communication in your company and always seek for their blessing of the information you want to communicate and the timing of that communication.
Timing is everything with communication. Being communicative with your stakeholders at a time when they aren’t particularly concerned with your project is wasteful of your project’s communication resources. Communicating a welter of technical details about the new system a year before implementation won’t be seen as honesty, it will be seen as noise and ignored. Good communications should give your stakeholders the information they want when they want it. This criterion must be balanced with the information available and when it becomes available. Communicate a description of the new system in a few sentences, along with the business reasons for choosing it in your first communications. You can also communicate changes to existing processes and procedures in very broad terms. This information should answer the question: how will the new system affect my work, but only at a very high level. Communicate project progress and any “wins” the project experiences during your build phase. Communicate the specifics of how the new system will impact work to specific groups of workers as the project gets closer to delivering.
Training on new systems is critical to their delivery of the value envisioned in the business case. Training sessions can also present you with opportunities to communicate to the trainees. Include the reasons the new system is being introduced with training in how to use it. Use the information you have available to support your communication and start out as you mean to go on. Let the stakeholders know when you will be communicating with them and if possible what you’ll be communicating (your communication management plan). During the initiation phase of your project you’ll have very little information available, but you will have the Business Case and Project Charter to use. The benefits, both tangible and intangible, the new system will bring to the organization is a good start and you should have that information to hand. You may want to tailor that information to suit your audience. Filter the benefits to make them specific to the group of stakeholders you are communicating with.
Slipping delivery dates for the introduction of a new system that will cause stakeholders some discomfort can leave these people feeling like they are being drawn through a knothole backwards. Realize that there are many different reasons that a final delivery date could change that have nothing whatever to do with the project or your management of it. The people who are paying for your project have every right to change the final delivery date when they have good business reasons for doing so. I wonder how many dates were changed as a result of the fallout from 9/11. Don’t paint yourself into a corner with your communications. Let stakeholders know that the delivery date chosen for the project could change down the road if business needs dictate. If you have to communicate a change in date, be sure to communicate the reasons for the change. Don’t just say the new Acme time tracking system will not be delivered on April 1st as originally planned, but on July 1st, tell the stakeholders that priorities have shifted to take advantage of a business opportunity that will increase revenue by 15%. This shift means that project work is being delayed and this will move final delivery to July 1st.
Treating project communications as a key project deliverable probably won’t eliminate all the fear and loathing of the new system you are building, but it should succeed in eliminating it for those stakeholders capable of viewing the project objectively. At the very least it will trigger questions that will provide you with an opportunity to refine the information you give your stakeholders.
Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt©. Dave was also the key architect responsible for the creation of the product. AceIt© has prepared Project Managers from around the world to pass their PMP® exams. You can find endorsements from some of his customers on three O’s web site (http://www.threeo.ca/).
No comments yet.