COMMENTARY

The limits of communication

Patrick K. Chapman is director of federal IT programs at a global accounting and consulting firm.

With a slew of efforts in technology reform, consolidation and modernization under way, the federal landscape is awash in promises of increased operational efficiency and more effective management of large-scale IT programs. Each of those efforts typically brings with it a number of internal and external communication tools designed to sell its benefits to a broad range of constituents.

What frequently escapes those attempting to win support and move efforts forward, however, are the expectations and risk those communications can generate.

Effective communication is a critical element of almost any IT implementation. A lack of consistent communication with end users and other stakeholders is cited as a key factor in many failed IT initiatives. Therefore, the prevailing opinion of many IT managers these days is that there is no such thing as too much communication. From hallway posters to internal websites touting future nirvana, the IT organization or project team blasts users with the benefits that are coming just around the corner. In practice, however, those activities frequently introduce a number of additional risks to IT change efforts through one simple effect: They unnecessarily raise people’s expectations.

Few IT efforts fully deliver their intended benefits on initial release. In many cases, the initial functionality is only a small subset of the grander plan. But with expectations fully set on the final capabilities, what might be a promising and productive start is instead viewed by users as a failure because it doesn’t meet their expectations.

Leaders often advise or instruct project sponsors to sell the benefits to users to achieve interest and buy-in, but once those expectations are set, the inability to meet them only strengthens a culture already skeptical of major IT investments. For example, one federal organization recently spent months touting the features of a soon-to-go-live financial system. Unfortunately, the new system’s interface proved difficult to use, and many promised features were dropped in the initial version to get it in production on time. Users were not kind in their feedback on the new system, and almost everyone who commented cited the original promises that had been made.

Communications regarding how long something will take come with similar risks. Hard dates for large-scale IT efforts are rarely met in government, and their broad communication early on adds almost no value to the organization or initiative. It makes more sense to communicate key milestones as dates get closer, which increases the likelihood of their accuracy. In another example, an agency hung a large poster in 2005 that spanned an entire hallway and showed the two-year implementation plan for a reorganization effort. It was designed to demonstrate the thought and effort that went into the planning process.

The poster was still a fixture in the hallway in 2010 while the reorganization effort continued, but its only real purpose was to serve as a reminder to employees of the failed promises of the organization’s leaders. Almost no meeting related to the reorganization occurs without a mention of the timeline on the poster.

Over a period of time and a series of projects and initiatives, failed promises and missed dates reduce or destroy an IT organization’s credibility. Unless early communications are absolutely necessary, a better approach would be to simply deliver results, focus any communications on near-term logistics, and then communicate the heck out of the project’s success and benefits. That approach lowers risk and increases the credibility of the IT organization and individual project members as people who can consistently execute and deliver.

Reader comments

Thu, Jul 7, 2011 Mike Tinnon Texas

Good takes and insight provided in this article. I also like Brian's comment about under promise and over deliver!

Wed, Jul 6, 2011 Brian Turner

We've learned the hard way to under promise and over deliver. However, I wonder if, during the conduct of the projects, keeping stakeholders advised of risks, issues and the tough choices a PM makes (e.g. reducing scope to stay on budget) would help? Most PMs I know would never lay bare their decisions like that but, perhaps of if people walk in the PM's shoes for a bit, they'll realize why projects don't turn out as they expected.

Tue, Jul 5, 2011 Jon Washington

The author points to a problem I have seen over and over again. I think his proposed approach is much better not just for improving the credibility of the IT shop with its customers but also improving the moral of the IT shop itself. This approach allows them to focus on what they can control and allows them to get some momentum.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above