Intranet Introspection: Communication and Preparation

Monday, April 3, 2017

An image of a blackboard with instructions written on it.

To date we've discussed a number of steps to make your Intranet launch successful. From understanding requirements to gathering information to managing the project effectively, we've provided a high-end view of the process. Now, it's time to look at your project's rollout. And there are two key elements that you need to consider: communication and preparation.

Communicate

It's natural to be excited about a new project launch -- especially if you feel it's going to have a dramatic impact on your organization. However, you may want to temper that enthusiasm with the understanding that, in my experience, no project has ever gone 100 per cent perfect.

Some clients will want to do a big media announcement to support a public launch. Generally, we try to steer clear of that, but we appreciate the desire to celebrate what is often a significant milestone for a company. But setting a date to show the world introduces a fair bit of risk.

That risk needs to be mitigated by ensuring you have a really thorough testing plan in place -- well in advance of the launch -- to ensure all the bugs are worked out. And you're going to want to ensure that you've tested the capacity of your solution (and have people on hand to immediately address any challenges).

After all, few things kill the buzz of a launch like having your site crash from all the attention and traffic it gets from your PR efforts.

Internally, it's vital to get buy-in from your staff. They absolutely need to be invested in the process and feel they have significant input on the development. We all know, people are very vocal -- especially when they don't like something -- and if you just flip the switch without any notice, it's going to create a lot of confusion.

And, again, if you're going to announce a project launch internally, you have to be 100 per cent certain it's going live when you say it will. It's great to get buy-in and generate buzz, but that can quickly turn to frustration and disenfranchisement if the launch gets delayed.

If you do announce a launch and things go sideways, don't stay quiet about it. There are a few old communications adages that Jay has talked about in the past in relation to crisis communications.

Be honest
Be as open as you can be
Be willing to communicate both good and bad -- and reinforce the solutions for anything bad.

Tell your staff if there's a delay, do your best to explain as much as you can (and, if you can't say anything, explain why -- legal, contractual reasons), and just keep those lines of communication open. Nature abhors a void, so if you're not going to fill the "Why isn't this finished?" with an answer, people will make up their own reasons. And that's never a positive thing.

Preparation

Obviously, you're going to want to make sure you have a bulletproof testing plan in place in advance of the launch. I can't reiterate that often enough. Budget enough time and resources for user acceptance testing (UAT). And ensure you have a clear plan for what you're testing. Have a clear checklist handy -- ideally one that closely aligns to the Statement of Work. All of the functional requirements identified through the project, all detailed, need to be in the UAT.

A couple of weeks for UAT is best. You're going to want to test across user types and be thorough in what you do. And if you can, always budget for more time than you think -- after all, a day or two of extra testing can save you a lot of headaches down the road.

There are many steps in the development and launch process and you're going to want to ensure you have a solid communication plan in place.

How are you going to transfer knowledge? When are you going to schedule training with your editors and content managers? When will documentation for content management tasks be prepared? Where will it be housed? For those end users of your site, do you have a Help section or FAQ available for them?

At Echidna, our Project Managers help develop and schedule those elements for your team.

One thing I strongly recommend for any Intranet project is to staff up your help desk. No matter how well you've communicated your rollout, people will still have questions. That a 100 per cent, etch-it-in-stone certainty. Even if the answer's right in front of their eyes, they'll have questions. And more often than not, if there's a question, the person's first instinct is to call the help desk.

We've helped to set up "war rooms" in the past, populated by IT and communications people, that are ready and highly available to tackle any issues. If the site suddenly goes down, or there's an influx of calls and e-mails, you want to make sure that you have the people on hand to quickly and efficiently solve the problems. You need to ensure your vendor is prepared for this and that they're highly available during your launch.

And when it comes to scheduling a launch, it's best not to launch on a Friday or a Monday. Why? Well, Fridays can be a nightmare if something goes wrong -- many people are excited about the weekend and the thought of potentially staying late to fix an Intranet issue is not high on their list. Mondays? Internally, that's the start of the week for a lot of people -- it's better to let them settle in and get into the work-week routine. It's likely the same for your vendor, who will be using Monday to catch up on weekend e-mails and set the work plans for the week. In my experience, Tuesdays and Wednesdays are the best, with Tuesday morning launches providing the lowest risk. They're the easiest to prepare and staff for.

Up Next?

My post next week will be the final one in this series and we'll look at post-launch support and what you should expect from your site and your vendor. And, as always, I encourage you to go back and check out the previous four posts in this Intranet Introspection series.