On Communications

“What obstacles do project managers face to successful completion of an Information Technology project?”

PMP: Technology Project Manager

“The largest obstacle seems to be proper communication. Frequently the technicians will assume things that the business people have no idea about, and the business people will assume things the technicians have no idea about. A good example is a recent project that I was brought into to solve a communication problem. The business people and tech had met, and determined that data feeds could be accomplished between the company and the vendor. The business people assumed the standard feed would work. The vendor assumed they would get the feed formated the way the rest of their clients sent the data. After several weeks of trying to determine why the feeds were failing, the collective they discovered it was a formatting issue in the feeds. This sort of thing was what I was brought into the project to resolve. Techs and Business people do not speak the same language, and assumptions are made on both sides. This leads to requirements that are not documented or incorrectly documented. This in turn cascades into variance in estimates, and impacts both schedule and budget.

Another item is that the charter is either not done or is not correctly linked back to core business goals. The charter should spell out why a project is being done. The project should tie back to departmental and organizational mission statements. Documents withing the project book should go into expected return on investment, potential risks and OPPORTUNITIES, stakeholder analysis (why is it good for the manager of this group and such), so that when support wanes for a project the PM has all these tools ready to keep the project going. Part of the risk and opportunity plan should be a reaction to possibilities script. So if there is an opportunity to enhance the ROI of another project that might occur, there should be a plan on how to do that if it does. Planning to mitigate the risks is only half of risk management. By taking advantage of opportunities we can not only enhance the value of a project to the organization, but maintain support for a project.

A solid grasp of scope creep and change management is necessary for an IT project to succeed. It happens to us all. One minor change can be absorbed, maybe even 10. Unfortunately they pile up, and before you know it the pile of minor changes don't link back to requirements or the project mission. It is far better to implement change requests for all changes. If the change is minor, the impact should be minor, but it gives a PM some justification when they say "We'd like to put that request in the next version of the product."

Some things that get skipped sometimes are:

- A formal communications plan
- Formal stakeholder analysis
- Exploration of other solutions (I like Ishikawa diagrams and FMEA, but their are other tools)
Lessons learned. (either never done, or never reviewed to take advantage of them)

The other main issue I see is an undervaluing of the PM resource. Too many PMs operate without administrative support. That's OK if you're the only PM, but as a department has more projects running and more PMs it makes sense to get administrative assistants in for them. Simply on the basis that the assistant can do things for them, which in turn allows them to do more PM work.”

MüTō Observation:

Communications is a fundamental Project Management tool. Motivating a Team, and holding parties Accountable are the other two tools.

But, Communications is the BIG ONE. No-one but the PM sits in a seat on a project with the ability to SORT IT OUT.