Recently I accepted a new position as a Software Development Manager, not working with SharePoint; this is an exciting new challenge for me, as I’ve been fully immersed in the technology for some time now. I started working with SharePoint at IBM 5 years ago, and since then I’ve worked with various deployments pretty much coast-to-coast in Canada, from Vancouver to Ottawa to Halifax. I wanted to make a post reflecting on 5 years of working with Microsoft SharePoint, and discussing at a high level some of the observations I’ve made of the various SharePoint deployments I’ve worked on over the years in order to help others understand what makes SharePoint a success (or failure).
Governance
“Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.”
― Joel Oleson, 10 Steps to SharePoint Success
Governance has always been a hot button topic in SharePoint, and will be for some time; in my opinion, lack of Governance is one of the primary sources of frustration and failure for every SharePoint deployment. This conflict is tragic, because at its heart Governance is the simple act of planning and setting expectations, something which everyone acknowledges must be done, but all too often do not actually do.
For many organizations, Governance is the opportunity to take a moment before implementation and actually think about:
- How do we intend to use SharePoint?
- What are the limitations of our SharePoint deployment (technical, human resources, knowledge, or self-imposed)?
- Are there legal implications we must adhere to, and how do we do that in SharePoint?
- What specific challenges will be addressed by specific features of SharePoint?
- What are the expectations for the various stakeholders (Executive, IT, trainers, end users, etc)?
#5 is a big topic, because this is where a lot of conflict comes into the organization. At some point, someone will think it was someone else’s job to fix/ prevent something bad that happened, and if you don’t have some kind of written policy or process, you’re asking for a round of the Blame Game, and that’s just poison in any organization.
Setting Objectives
A common objective when deploying SharePoint is “increase collaboration and communication”, “provide document sharing”, “use SharePoint as a development platform”. I would argue that these aren’t objectives, they are aspirations, because they are exceedingly difficult to measure through hard data (user surveys are difficult to count), and they represent broad, amorphous goals. Sure, there may be 400,000 documents in SharePoint, but that’s a storage metric, not a collaboration metric that indicates how, when, and if people are actually using those documents and to what effect. How can you measure if someone is communicating more effectively? Perhaps you could infer that by seeing that people are performing more work in shorter periods of time, but maybe that’s just the espresso machine you installed last month.
An objective is something that can be measured, well, objectively, and contains two critical ingredients:
- What you are trying to do
- What will tell you that you did it
Good examples of objectives are: “Use InfoPath, SharePoint, and SharePoint Workflows to reduce TPS-421A form processing time from 5 days to 3 days.”, or “Reduce meeting minute approval time from executives from 20 days to 10 days”.
Objectives can be on the micro-scale, but tie into the broader strategy of SharePoint as defined by your Governance. As objectives are met, those successes should be celebrated, and similarly if objectives are not met, those failures should be analyzed, lessons learned, and finally addressed; either way, there must always be new objectives developed and added to the list.
Simply put, if something cannot be measured, it cannot be managed. If a system – any system – SharePoint or otherwise – cannot be managed, then you have real and serious problem on your hands.
Make the Technology Work for People, Not the People Work for Technology
There’s a common saying among a lot of SharePoint admins I’ve worked with that people have to learn to do things “The SharePoint Way”. I spent much of the early part of working with SharePoint trying to get people to change how they work towards The SharePoint Way, with mixed success. Sometimes people have been doing a process for 5, 10, or even 15 years, and they’ve seen technologies like SharePoint come and go. You can’t expect to make people’s processes change overnight, particularly if they haven’t been sold on SharePoint. When I started to see real success, it was because I accepted that people have a process that can be fit into SharePoint, and that SharePoint can be adapted to fit people as well – in essence, finding a middle ground between people and technology.
When you start showing people that what they do can work in SharePoint, and often much more efficiently than without SharePoint, you not only make people more productive, you often find internal champions that are willing to promote and teach others when SharePoint administrators aren’t around.
Finally
It’s an exciting time for SharePoint and Microsoft. SharePoint, like so many other services and applications, is jumping headfirst into the cloud. Yammer stands to change SharePoint in a fundamental and overwhelmingly positive way. With Steve Balmer leaving the big chair, and other leadership changes at Microsoft, there are some great opportunities for positive change and development – particularly in the cloud and mobile arenas.
While I may not be working with SharePoint day to day as I have been for years, I look forward to seeing how the technology changes over time and continues to meet the challenges of the various organizations and businesses that deploy it.
