How to I cut down on all of the communications?

Question

I am new to Project Management. I am coming in on a project that was just implemented and is now in Post Implementation. The roles do not seem to be fully understood be everyone. Now, when something goes wrong, the world is emailing the world; consequently, everyone is spending their days going through emails instead of getting to the root and solving the problems. I need to streamline this process. My plan is as follows:

1. ID the Stakeholders
2. ID their roles & responsiblities
3. Create a communications plan where we ID the communications needed as well as their frequency, delivery method and who is responsible.
4. Create a master Issue Log that we can use to keep track of and prioritize issues as well as assign them.

However, once a given issue arises, I still feel like there will be 50 emails batted back and forth before it is understood and decided who it will be assigned to.

Any recommendations on how to cut down on the communications?

Answer 1

Any recommendations?

Yes, two.

1. If possible, deal with each issue directly, face-to-face. Direct communication makes it so much easier to set the expectations and explain reasons why these expectations are actually set. To some point it is against your idea to sort things out, document them and then follow the plan, but at the same time you will be building relationships which will likely prove to be invaluable when the next crisis comes.

2. Follow the plan of yours (or other similar) to sort out the communication. At the same time you may see value in showing everyone how communication buzz hurts the project team (although it doesn't have to be the case). Once you have it set up be ready to deal with consequences, because there likely to be some, meaning some people will expect to get some information even though it won't look like this basing on your communication map. Then, you can always retreat to the rule no 1: deal with it face-to-face.

Considering you are willing to listen to people having different opinion, these two should build the atmosphere of cooperation on one side and, on the other, at least support the trust in a way that limits cross-checking, thus reduces the volume of formal communication.

Answer 2

I agree with Pawel's suggestion (+1!), which is basically use emails for what they're supposed to be (in this context), i.e. making everyone aware of decisions / agreements rather than discussions.

Notice that communication is something inherited by company's culture, so if you're intended to buy in this fight, make sure you have enough time (and patience).

I`m used to a similar scenario, where an incident appears involving several third party partners. On such cases, no one wants to be held accountable for the issue. Usually, to sort things out, we have conference call bridges, hosted by a neutral moderator / facilitator where everyone has the opportunity to explain his/her sides and then an agreement is reached.

Based on the meeting's agreements, the moderator sends minutes to all attendees with decisions instead of discussions. Is it possible to also have several bridges from time to time until the problem is sorted.

Based on your concerns of having communication flowing properly, you could step up and suggest to be the bridge host (as long as you can be candid with everyone on it).

Success!

Answer 3

If it has moved to a post-implementation phase, you probably need to have some sort of ticketing system or bug tracking system. There are a variety of off-the-shelf software solutions that can be used to get a handle on who is working at what, tracking, e-mail alerts, dashboards, etc. If you added some detail on what industry, project, and other details, I'm sure people around here would have some solution ideas.

Answer 4

Your goal is not to cut down the communications. It is a symptom of a lack of a process to escalate problems, which is amazing that you went live without it.

You did not say what the project or tool is but a problem management process is quite extensive, is not cheap, and you can get a lot wrong if you don't build it well. You have to design the work flow, the controls, the service levels, how you will measure performance...all while keeping those costs at a minimum. All of this should have been done long before the project went live.

If you try to control comms now without a viable alternative IN PLACE, you risk creating other, more severe issues for the company and its work. This is a "fix one thing, break two others rule. For example, trying to have the communications flow through a single source, especially if that source filters, you risk a bottleneck, inappropriate filtering, bypassing, and most importantly exacerbated user rejection.

So do not focus too much on the symptoms. Stop the bleeding, but focus on the source.

Answer 5

I would organise a meeting/conference call between all the heads of departments.

I would then discuss the issue with department heads and suggest that all communication comes through them.

This way I'll enforce kind of a "filter" and delegate some of the responsibilities.

Additionally I would insist that we all agree on how we are going to report on these problems. I.e. come up with a simple document template that can be accessed through some kind of document sharing tool, such as Sharepoint or Evernote. Office 365 is fairly cheap for this (£5 per user per month).

Answer 6

I would also add - nominate a single point of contact. That way new problems do not get lost in discussions about existing ones. That SPOC should also be responsible for alerting the stake holders and arranging update meetings. Stakeholders wanting urgent meetings have a place to go and the same email dowesn't end up in 20 email boxes and then get forwarded in 20 different guises as each responds to all!

Also, as this is in post production, there should be a problem management/support team at least starting to trake control of this project. They would/should have such processes in place already. At the very least it needs to be controlled in a Live System context - it is no longer in dev.