It’s so easy to get lured by the latest and greatest technological bauble. Oh how they sparkle! Or to find opportunities to leverage a great product with, what is perceived to be, the perfect problem. Over the years, I’ve been caught in this trap. I’m searching for the perfect solution for my actual problem and instead I end up trying to mold and shape the problem to fit some dazzling new product.

Another trap to which IT folk are particularly vulnerable is we tend to think the right technology will simply fix things, but we should know by now this perspective is short sighted. Often, the problem will hemorrhage if the solution does not have the support of the right people within the organization.

With so many pitfalls, how can we “do” a large scale IT project right for a change?

A Tale of Two Collaboration Servers

During the fall of 2009, our company migrated our email platform from Lotus Notes to Google Apps. The greatest success we had wasn’t that everyone’s mail and calendar entries were in place on the cutover date. It was that we, as an organization, decided on which platform months before, we agreed that training was vital (nearly 80% of the organization signed up for a class), and we knew that there would be bumps in the road.

Bottom line, we were as prepared as possible every step of the way. Here’s how you can be, too.

Realism Reduces Pain

With any large-scale IT project we’re changing the culture, and changing culture has pain points! It’s vital to recognize up front what effects, both positive and negative, your project might have on your company with respect to the technology involved. Because eventually, everyone is going to find out in the end anyway. Make it a point to identify which parts of the the culture you’re changing and who that will effect the most.

Know the Players

In the book Creating Contagious Commitment, Andrea Shapiro identifies a few key, not-necessarily-on-your-team-or-in-your-department players in large projects. Some leaders can be advocates while others can be resistors. Wisely, she focuses on identifying and building advocates when it comes to change within an organization. Advocates are people who believe in what you’re doing and will work on your behalf to forward the idea. On the opposite end, resistors are people who can overtly or covertly detract from the solution. While leaders build support for the project through growing advocacy and minimizing resistors until support reaches a tipping point. It’s also important to turn that idea or project over to your advocates. If you are truly building advocacy, they will do the heavy-lifting.

Listen As If You’re Actually Listening

When evaluating a key technology that will affect a group (or the entire organization), get their thoughts on it. We gathered a number of key people in our organization who are specifically effected by email on a daily basis. We also asked some of our biggest critics of the previous system to share their pain points, as well as what they needed from a new system. It was difficult to listen to because the criticism was toward everything I had supported in the past. But, this was moving us forward. And finding answers to their pain points became quick wins for us along the way.

We could easily figured out what would work best cost-wise on our own. We were capable of determining which solution would be the easiest to support, deploy, etc. As a department, we could have locked ourselves away in our silicon encrusted tower on high and decided on the day to cut over without feedback from anyone else. Instead, we invited our advisory “team” to help us plot a course. In turn, they recognized they had a voice in the decision and they used it wisely.

If you want a successful project, find a key group of people and talk to them. Learn about how they work. Listen for what is working, what isn’t working, and what they would like to change. The more diverse, the better! People are more apt to appreciate you and buy into the cultural shift when they feel genuinely heard.

Seeing Is Believing

When we began to evaluate mail systems, my boss suggested an idea that I initially resisted. He wanted us to create what was essentially a Consumer Reports chart, listing the features that were important to everyone.

Each system we evaluated had a response next to the feature and how well it performed along with a visual icon. A green check noted that it worked really well. A black check signified that it was satisfactory. And, a red X meant that the system did not comply with our request. Any time someone asked about what we were considering, I could pull the chart out and show them. They immediately gravitated to the icons and saw which solution would work best. This visual piece to our research helped everyone see we did our homework and the reason why Google Apps was the best choice.

During our evaluation, we knew it would be difficult to equip everyone with a working demo. We were fortunate when it came to Google Mail; most people in the company were already familiar with it. We did get an opportunity to grab about 30 accounts and setup dual delivery to both Lotus Notes and their test account. Any time you are able to create an opportunity to allow others to play, it’s worth it. The idea may create extra work; but it gives others an opportunity to test drive things in a safe environment.

We also were able to field a number of questions that we didn’t anticipate, which gave us the opportunity to prepare answers (or correct issues) before launch. That’s a big win!

Communicate Your Excitement

Once the decision was made to move to Google Apps, we began a communication plan in two offices. We conveyed excitement but also a sense of reality. “Things might be bumpy,” we told everyone. And it was exciting! The whole reason we were doing this was because we wanted to improve the daily work-lives of our co-workers for the benefit of them, and of course the organization as a whole! It would be a lot of work, but it would be worth it.

Mitigate Experience Gaps With Outsourcing

We enlisted the help from Cloud Sherpas, a Google re-seller, to help us migrate data from Notes to Google Apps. As the schedule ticked down, we provided handouts and tutorial videos. Training classes were mandatory. We redirected traffic on a Friday night and showed up early Monday morning with bagels and pastries for everyone. We camped out in our video conference room and were available to anyone in either office with a question. It was remarkable that people who were so passionate about email were also extremely patient and understanding the first few days.

Are You Prepared for Success?

So, who are your advocates? Is there a project that you’re working on that affects them? Are you able to get some honest feedback? And can they recommend others who might be affected?

Obviously, you can’t approach everyone in the organization, for every project that comes across your LCD. I’m not suggesting you turn every decision you make over to everyone, or that you spend hours and hours in planning meetings. But, think about how much easier, and more successful, rolling out a new piece of software, phone system or platform would be if the proper plan was in place and a significant portion of the ground-work was a shared responsibility by a network of advocates within your organization.

What has your team done to ensure that your large scale IT projects are actually a success for a change?

[image: nikk0314]