Hello from my room in a rather nice hotel overlooking the river Thames in London, where I am staying for the International SharePoint Conference ☺
This article is the beginning of the end as we move on to the final element of Art of SharePoint Success framework, Transition. Transition is the umbrella term that I use to include change management and user adoption. As a former colleague of mine used to say, it’s about moving the organization from the old world to their new world.
Unless you’ve been hiding under a rock, I am sure that you’ll know this is article 16 in the Art of SharePoint Success, a four point framework for ensuring a long term return on your SharePoint investment. The four elements of the framework are:
Why There’s No Such Thing as a SharePoint Project
One of my most often used clichés is, “There’s no such thing as a SharePoint project, there are only organizational change projects.”
No organization ever implements technology for the sake of the technology, and technology delivers absolutely no value unless its applied to an organizational problem or opportunity. The only reason for an organization to implement technology is to achieve change. Fact!
You’re free to try and come up with contrived scenarios in which technology is implemented for the sake of it, but you won’t be able to find one. We’ll all wait whilst you try…
Why You Really Need to Care about Transition
You’ve probably heard the statistic that 70 percent of IT based projects "fail"? This is based on well-established research by the Standish Group amongst others and although it’s a bit more complicated than the glib statement suggests, it is broadly true.
But that research is focused on project delivery. It doesn’t take into consideration whether or not the thing delivered is actually used, or delivers any business value. There appears to be less research in that area but I’ve seen at least one claim that of the 30 percent of projects that are successfully delivered only 13 percent of those are adopted. (I admit I am playing fast and loose with statistics, but it’s an interesting thought.)
Over the past five years I’ve met probably hundreds of clients who have told of change initiatives that failed because people didn’t use the technology. One London based client in the media and communications sector told me, “SharePoint exists in our business, but no one uses it.”
In 2009 I worked with a London based insurance firm who told me that they had spent over one million pounds (US$ 1.969 million) creating a portal for underwriters which aggregated information from several line of business applications. A year after launch only 3 percent of the user base were using the Portals. The rest were continuing to use the line of business applications.
In 2011 I was working with one of the largest banks in the UK which wanted to deploy an employee portal based on SharePoint 2010 Mysites, a project with a budget in excess of one million pounds. In one of the early project meetings I learned that they already had 44,000 SharePoint 2007 MySites deployed but, “No one uses them.” When I asked why it was thought that the new MySites would be any more successful I was told, “Because they are SharePoint 2010 and there’s lots of new features.”
You may well laugh but organizations around the world waste millions and millions of pounds in this way. They implement the technology but fail to transition the organization from the current state to a desired state.
SharePoint, Change and Change Management
SharePoint can bring a number of different types of change to an organization. It’s not unique in that respect, the same can probably be said of nearly all information technologies. But SharePoint’s potential as a catalyst for change is bigger than most other technologies. It can:
- facilitate changes in information centric business processes by enabling new ways of working
- be instrumental in changing organizational structures such as the evolution from hierarchies to networks
- enable a shift of power from formal positions of management authority to community based experts
- require changes in individual behavior such as a move away from sending emails and attachments to using SharePoint sites
- enable new relationships and interactions with customers, partners and suppliers through extranets, web sites and social computing
According to Wikipedia, change management is a structured approach to transitioning individuals, teams and organizations from a current state to a desired future state in a controlled manner.
A structured approach means that we have a plan. Transitioning from the current state means that you understand the current situation and know where you are starting from. A desired future state means you know what you are trying to achieve and will recognize when we have done it. A controlled manner means that you have some means of measuring your progress. If you don’t have all of these elements in place then you’re not ready to start. If you’ve read the Art of SharePoint Success then you should have the ideas you need!
There are different types of change and it can be helpful to understand which you are attempting. The following sections briefly discuss the main types of organizational change.
Organization wide versus sub-system
Your SharePoint strategy should determine the scope of SharePoint usage within your organization. Are you deploying a set of general capabilities to a wide audience? Or are you focusing on very specific use case?
If you deploy SharePoint using the services based model then you could find yourself working at both levels. For example, you may choose to deploy a team service or a portal service which is available organization wide, but your Business Impact team (remember the governance model?) might work with individual business units or process to find specific sub system level use cases for the services.
Transformational versus incremental change
A Transformational change is a radical or fundamental change to the organization. In my experience incremental, or gradual change is the secret to success with SharePoint, and this is the basis of the services model. Each service can be introduced as a distinct project.
Remedial versus developmental change
Are you trying to remedy a known issue or problem or are you trying improve or develop an already successful situation?
If you’re attempting the former, then your SharePoint strategy will probably be focused on developing a specific application or solution, probably related to a specific business process. Using SharePoint to resolve quality issues in your project delivery process is a typical example.
If you’re attempting the latter, such as improving the way teams collaborate within your organization, then you’re probably going to adopt the services based model.
For Next Time…
In the next and probably penultimate episode we’ll be discussing how form and function, and product design techniques such as user-centered design can help in achieving successful changes in behavior. In the meantime I am heading back over the International SharePoint Conference. Oh and I’ll be presenting at SharePoint Saturday Boston on April 28th, so if you’re there then please come and say “hi.”
Editor's Note: You may also be interested in reading:
- Driving Value with SharePoint Search by @buckleyplanet
- What Is This SharePoint Thing All About Anyway? by @jennifermason
- SharePoint Backup: It Ain't What It Used to Be, It's Better by @metavistech