Program Management

Overcoming IT skepticism: 7 steps to creating a new culture

Marybeth Fraser
Bob Woods

Depending on which study you believe, IT projects fail from 37 percent to 60 percent of the time. That’s worse than the 2011 Redskins — we are still a little sensitive about that. But even more disturbing is that three out of four participants don’t expect their IT projects to succeed, and a stunning 78 percent of stakeholders believe the players are out of sync with project objectives.

In other words, nobody’s surprised that IT projects are delivered late, over budget or, worse, scrapped before being implemented. Insufficient resources and unrealistic deadlines all play a part in those shocking numbers, but the No. 1 reason for IT project failure is communication failure. And although there’s a reason we’re still working out kinks in new technology, communication is an important element to master.

A communication campaign should be the foundation of any IT project. People, not process, should drive all technology innovation. Before the first programmer is hired and the first keyboard pecked, a communication plan should be in place.

However, most project communication efforts skim the surface, focusing only on the implementation of the project. Worse, they completely forget to focus on the stakeholders and users. Even those who make valiant attempts to keep all parties in the loop still suffer lapses in communication. Why? Because nobody bothered to get to the heart of the project. Nobody determined the real motivations, the real triggers that would inspire users to adopt the new technology.

Technology adoption requires behavioral change. That’s why we’ve developed a seven-step communication process that should accompany every new IT project. This User Adoption Communication Model not only keeps IT projects on track, but when used with rigor, it can change the IT culture. Imagine: an IT project that people believe in. And it all starts with a strategic and intentional communication program.

Here’s how it works.

Step 1: Gather data. Determine where all the players stand before the project begins. It’s vital to get into the stakeholders’ heads to find out what they’re thinking and feeling and to uncover the barriers to adoption. In a Government Accountability Office report last year, auditors found that the most common reason for success on the rare seven successful IT acquisitions was that "program officials were actively engaged with stakeholders." The first and most important question should always be "Why are we doing this?"

In other words, what is our mission and vision? It’s not as simple as you think. Gut-level truth needs to emerge. And it all starts with precognitive data gathering that uncovers truths that people often aren’t able to communicate. It gets to the heart — the subconscious and emotional truth — where behavior-driven decisions are made. To develop confidence and trust within the user community, it’s impossible to skip this all-important first step.

Step 2: Take a stand. The reason only 22 percent of stakeholders believe the claims of any IT project is because time after time promises are made and not delivered. To break the cycle, a leader must clearly announce and communicate a specific goal and a specific date. It’s important to announce exactly what the first project goal is and be crystal clear on when you’re going to meet it. Yes, it takes courage. Yes, it takes backbone. But it’s the only way to effectively change expectations and create a new, more positive culture.

Step 3: Break it down. Needless to say, you’ve got to deliver — on time and exactly as promised. That’s why it’s so important to start with something small, something that will prove naysayers wrong. You’ve probably heard it called agile development. It values individuals and interactions over processes and tools. It follows incremental, baby steps. It’s evolutionary, with continuous testing, adaptability and, above all else, communication and collaboration.

Step 4: Empower early adopters. You know who they are. They’re the vocal opinion leaders in your community, the ones willing to give new IT projects a whirl. Develop their confidence and trust. Don’t just blast information out there and hope it sticks. Get them involved in the conversation. You will be pleased when their positive influence extends to others.

Step 5: Recognize those who deliver. OK, so you’ve delivered on your first promise. Don’t be surprised that your stakeholders still aren’t convinced. That’s all right. It takes time to change the culture. But now’s the time to celebrate that first accomplishment. Recognize the conquering heroes. Pass out certificates. Take pictures. Create videos. Post them on the Web. Write articles in the department newsletter. Sure, you’ll still have skeptics, but everybody should know that objective No. 1 came in on time and on budget.

Step 6: Get feedback. Four to six months after meeting that first goal, take a survey. Ask users, “Did we deliver on our promise? Does what we delivered work?” Give them the opportunity to bellyache if they want. But listen. Let them have their say. If they’re pleased, pat yourself on the back and keep going. If not, listen to what they say and fix any problems. In either case, be transparent and communicate the accolades or how you will fix things and by what date.

Step 7: Start the process again. Make another small goal. Take a stand, break it down, meet the goal, recognize the players, and get feedback. And then repeat it all again until the project is finished. By the fourth time objectives are met as promised, people will actually be excited about new IT projects.

About the Authors

Bob Woods is president of Topside Consulting Group and former commissioner of the General Services Administration’s Federal Technology Service.

Marybeth Fraser is president and CEO of Fraser Consulting.

Who's Fed 100-worthy?

Nominations are now open for the 2015 Federal 100 awards. Get the details and submit your picks!

Featured

Reader comments

Thu, Jan 3, 2013 Bill Harshaq Reston VA

Suppose the stakeholders you have in 1999 differ from the stakeholders you have in 2001? The average tenure of political appointees at high levels is about 2 years or so, and in my experience, anything planned by the predecessor is automatically tainted for the successor.

Thu, Jan 3, 2013 Phil Steinschneider

The biggest secret to delivering on-time and on-schedule is to have both top-down and bottom-up delivery dates. Management always wants things on a specific day, but the people who are actually doing the work don’t believe they can deliver by that arbitrary date. The real delivery date lies somewhere between where management wants it to be, and where the "factory workers" believe it can be.

Wed, Jan 2, 2013

This is a great article.....but one thing it fails to mention is "documenting" those goals, requrements, and end state. It is called accountability. No matter whether it is agile development, you need to "say what you do, do what you say, prove it, and improve it."

Sat, Dec 29, 2012 Brian Wernham London

I agree - Risk assessment can be prone to 'groupthink' - if most IT projects fail then why do risk assessments always border on the wildly optimistic? Look at this example of optimistic reporting at the US DOD: http://brianwernham.wordpress.com/2012/12/29/the-dod-caught-with-its-pants-down-a-revolution-in-risk-assessment-needed Brian

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