Sunday, October 12, 2008

October 13, 2008 – Back to the Basic: Communication – When

Rarely do you hear a project sponsor say, “There is way too much communication going on here.” Unfortunately a common complaint is the lack of communication. True, the loudest complainers are often those that opted out of the weekly status meetings and never responded to your emails. You are left wondering when it is appropriate to connect with them.

When to Speak Up. This weekend I was listening to The Tech Guy on a local radio show. Google is piloting a new gmail feature that checks your sobriety before letting you hit the send button. You have a minute to answer math questions correctly to proceed. Evidently too many drunks were waking up in the morning with a hangover AND some explaining to do. For the record, late night may not be the best time to send an email. Sleep impaired judgment can make the worst email look like Shakespeare.

Status. Many factors go into how often you need to get the word out on your project’s progress. The list includes:

  • Project length – Quick hit projects may be over within a week so weekly meetings are useless. For projects in excess of a year, weekly status meetings are too frequent during slower development phases.
  • Development type – Agile project development requires daily, fifteen minute, standing meetings. More traditional projects don’t.
  • Location of resources – Co-located teams communicate hourly. World-wide teams require more structure behind their interaction.

End Users. It has been my experience that the biggest potential failure in communication is with end users. We engage them to get requirements, flash some screens by them for User Acceptance Testing, and finish by dumping the product on them unannounced. Instead of being the central focus they are nearly an afterthought.

Use touch points throughout the project to build to the product release finale. Electronic Arts and other entertainment related industries go all out. When EA Sports released “Tiger Woods PGA Tour” the world knew months in advance and they gave it a media show kicked off. Major motion pictures splash billboards, previews and internet sites long before opening night.

Instead of the implementation date being just the point you are pushing your team toward, start a count down for the intended recipients. “NEWS BULLETIN: Only 47 Days until Dallas goes Digital!” Tease them with the features they will get.

Road construction has the main route to our house torn up. A typical construction sign reads, “Reduced lanes from September 15 to November 10. Use alternate routes.” That says “Your life will be painful for then next 2 months.” Instead they should say, “On November 10 your pothole problems will be gone.” Or “Coming soon: An extra turning lane to get you home faster.”

No Surprises. Ever the optimists, project managers tend to hold out on reporting bad news in the hopes they can right the boat before it sinks. If you foresee problems, raise them as risks as soon as possible. Be proactive in avoiding and mitigating them before they become issues.

Rarely does an issue spring out of nowhere to crush a project. By not warning management ahead of time you eliminate any leadership they may be able to give (additional funds, better people or different priorities) and make them look bad at the same time. Not a good combination. Managers tend to remember such things. With advanced warning the Titanic might be retired to the docks in Long Beach, CA instead of the Queen Mary.


Alec Satin said...


It seems to be a big cultural shift in most IT organizations to include end users/customers throughout the process. There seems to be a (sometimes justified) concern that they will find something wrong and want to change the requirements.

Have you faced this perception? If so, any thoughts on how to change it?


Thomas Cutting said...

The objective is to get them involved early just for this purpose. You want problems to be raised as soon as possible. They are cheaper to change in the design stage than during testing.

The key is to have a strong Change Management process that reviews each perceived problem and request to determine the cost to budget and schedule. Then put the decision back in the Sponsor's court for which changes are accepted.

If you wait to the end the result may not be usable.