Sometimes it’s not the things you do that cause problems, but what you forget to do.
Miss a utility bill, and you might be trying to read in the dark. Miss a car payment, and you could end up walking to work.
Here are seven elements that, if missed, might doom your SharePoint implementation:
Define the goal
Sometimes we get so engrossed in our activities and projects that we forget to look at the horizon and set goals. It’s all too easy to succumb to the pressures of the daily deluge of information and just keep plodding along; however, that makes it difficult to define goals.
In implementing SharePoint, are you trying to get communications out quicker? Are you trying to increase the number of stories or reduce email? I’m sure you’d like all of these results, but what do you want—or need—most? You should remember the broader picture of why you’re putting forth any communication: Is it to improve employee engagement and/or efficiency?
Even if you know what you want, how should you define success? Is it processing 100 articles through the system? Is it reducing emails by 20 percent in the first month? Perhaps you need to measure the number of people using the intranet to get information. Success probably isn’t a single measurement; instead it’s a set of metrics—a dashboard, to use the current coinage. To define the dashboard you need to determine the metrics that are important to you—and the right values for your targets.
If a 5 percent increase in views is a good benchmark, after the initial implementation spike, what percentage of the staff should start to use the site immediately? Whether 10 percent or 50 percent, it depends on your organization and situation.
Metrics are often ignored when SharePoint replaces an existing intranet. It’s seen as a technology replacement, with little need to reevaluate what success means. Given that SharePoint has different capabilities that are advantageous, isn’t it worth revisiting your success metrics?
When you’re launching an intranet—even if it’s just a technology replacement—there are no social norms. You’ll have to help people understand what they should and shouldn’t be doing.
Viewed from another perspective, governance is all about risk management. The reason for governance is to minimize the risk of loss and, in some cases, to take advantage of opportunities. You’ll want to work with IT to determine which risks are most important—such as consuming too much storage or preventing “naughty” words—along with how you want to instruct users to behave, and what you’ll do if they don’t.
If you don’t define governance ahead of time, users will get tired of doing something only to be told later that they can’t, and the resentment toward your SharePoint implementation may become insurmountable.
SharePoint can do a lot—but when you try to accomplish certain things with it, you realize that at some point a function was disabled or, perhaps, was never turned on. This breeds frustration.
Often, IT organizations will activate only those features that people have asked for and little, if anything, else. Work to move the pendulum so that you turn off only those things that are too risky to manage. You’ll reduce frustration, increase utility, and keep users coming back.
Engage all the stakeholders
You may be asking yourself, how many stakeholders do I really need to get involved with this change? If two or three stakeholders are really invested, isn’t that enough? Unfortunately, in many situations the answer is no.
Your best bet for success is engaging all the stakeholders in instilling an urgent need to change. Whether it’s a low employee engagement score, frustration about how long it takes to convey information, or the amount of time wasted by employees’ reading low-priority emails, find a reason why everyone in the organization can—and will—support SharePoint. Together with a solid plan, it can push the organization forward—so make sure that everyone knows that.
The fateful launch day comes, and the employees open their new intranet home page—and promptly wonder what the heck happened. Calls stream into the IT help desk to learn how they can reset their home page back to the Dilbert website. As a technical matter, you’ve got 100 percent adoption—everyone went to your new intranet home page before wandering off to do something else. For most organizations, that isn’t a successful launch.
A successful launch is one which is communicated—and one that sets expectations about the changes that are coming. Though it may not seem like SharePoint is a big change—particularly if you’re replacing an outdated intranet—you can’t just hope that folks will like the change.
Build on momentum
Perhaps you have a plan for the perfect launch. It involves rainbows and puppies and all the information the organization clamors for. You have a liftoff and short-term success. However, the question remains: Will your SharePoint implementation be successful over the long haul?
That depends on whether you’re going to have an ongoing program to support its use, reinforce the right behaviors, and communicate growth of the solution. Too many organizations treat their SharePoint implementations as a project that has a fixed endpoint.
However, just as there’s no end to the stream of news that you need to communicate to the organization, there’s no end to the need to continue to build on the momentum you have and to reinforce the right behaviors.
Robert Bogue is the author of 22 books including, “The SharePoint Shepherd’s Guide for End Users-2010,” which is also available in a Wiki version as The SharePoint Tutor. Find out more about SharePoint made simple at SharePointShepherd.com or follow his blog at ThorProjects.com/blog/.