I’m happy to announce that my “Website Governance: Guidance for Portals, SharePoint, and Intranets” has just been published. It’s an update to my Methodologies and Best Practices document on governance which is the most popular document that I’ve written for Burton Group (out of 17), even though only came out in March of 2009 and therefore has had less time to accumulate document views than others I’ve written.
I updated the document based on some new ideas and clarifications that have been needed since its original publication. The main updates to the doc since publication are as follows:
- Clarified the alignment with IT governance and service management
- More detailed diagram of the document hierarchy
- Added option to define roles and assignments separately
- Added “cultural tenets” methodology
For more on what I’ve changed and why, click here.
Planning to be in L.A. in April? I’ll be speaking at the TEC 2010 conference in Los Angeles on April 26, 2010. Originally I was going to speak on SharePoint governance, as I’ve been doing since 2003. It’s still a topic that audiences want and need to hear about. But lots of organizations have made their first attempts at governance. So I’ve shifted to a presentation on SharePoint management instead to provide the next step.
There is lots of techie information on planning SharePoint management and operations, but I haven’t seen much conversation about a higher level framework for it. Here’s the description of the presentation:
What’s After Governance? SharePoint as a Service
Speaker: Craig Roth
Governance is an important first step in any SharePoint planning, but what happens after people, policy, and governance processes are determined? That’s when the second pillar of SharePoint planning comes into play: management. Craig Roth, author of a frequently cited definition of SharePoint governance, will describe what needs to happen after governance. SharePoint as a service is an approach, based on ITIL, that recasts SharePoint as a catalog of business-focused services. In this presentation, Mr. Roth will discuss why treating SharePoint as a service is better (yields more value) and fundamentally different than simply providing a set of capabilities.
I took a lot of vacation time at the end of the year for a big project – a complete home redecorating including wood floors, painting, furniture, and little stuff too. My wife and I started running into some disagreements about various decisions and had to take a step back to analyze the situation. I realized these issues seemed familiar. Of course – SharePoint governance! I just can’t get away from it.
My definition of SharePoint governance popped into mind and really helped clarify the problems that needed to be addressed. I’ll relate it here in the hopes that it helps to illustrate how to use the SharePoint governance process in light of a much smaller, simpler situation that most of us can identify with. My wife indulged me in this experiment. (Note: she is a very special woman with a strategic IT background and patience for my technology experiments. Do not try this at home!)
My definition goes:
Website governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization.
These were indeed the issues we faced. The ambiguity about who was allowed to make buying and design decisions and how each party needed to be consulted was causing frustration. Balancing the short range and long range was also difficult: Should we quickly acquire cheap stuff that we can replace in a few years or spend more time and money to get higher quality pieces that last? How much do we concentrate on furnishings that work safely for our baby knowing he’ll soon outgrow those needs? And the need to mitigate conflict – keeping the disputes from ever getting to a frothy head in the first place – was obvious.
It was validating to see how the same problems that the governance process addresses were the ones we were having. But how to solve them? Well, this definition is more than just a definition, but also illustrates how to proceed with solving the problems. Back to my SharePoint governance process, I knew I needed to create a statement of governance that we could agree to. It consisted of people, policy and process. I have posted it up here: Home Decorating Statement of Governance.
People: I started by defining a set of roles (designer, user, consultant) that clarified the responsibilities that needed to be assigned for each room. Then, for each room, we agreed on the ownership by assigning the roles. My wife is the designer of the living room, while I’m a user (but a consultant for the stereo setup). I’m the designer of the deck, with my wife as user.
Policy: We had some discussions about our overall goals for the house. Believe it or not, we hadn’t done this – we had just jumped into talking about specific colors and drapes and such. Once our policies were codified, we felt better about leaving someone else to make decisions without approval as long as those decisions adhered to the policy. In other words, the designer had freedom to make decisions, but only within the bounds of the agreed-upon policies. These policies included items such as the Pricing Policy (anything over $200 requires review), Babyproofing Policy (we agree that unless a room is designated as an adult area, it should be babyproofed), and Gender-friendly Policy (nothing too lacy or too football themed).
Process: A few processes were needed based on these policies. There’s one to determine the babyproofing room list, one for how to handle approvals of >$200 items, etc.
How did it work? Well, we’re still in the process of redecorating, but it’s already made both of us feel better about what we can run with and where to stay hands off. Conflict has been reduced. And I think we’ll both feel more ownership of the result. I think this experiment also shows that governance doesn’t have to be a big, bureaucratic sort of thing – this was self-governance between the parties involved. Finally, as with SharePoint governance, the process forced us to talk through a lot of issues that were being left ambiguous and that would have remained as underlying causes of many smaller disputes if left unaddressed. It’s the conversation and agreement that matters, not getting the document out the door.
In a previous posting (“Solution for Broken IT: Fix It“) I decried a trend I’ve noticed towards businesses taking collaboration and content needs into their own hands (via end user computing, consultants, or SaaS) rather than attempting to fix the relationship with IT. One example I noted was with SharePoint, where I said “Microsoft is increasingly marketing SharePoint to the business with as the DIY option of choice.”
Well, Microsoft denies any formal program to market SharePoint directly to the business (doing an end run around IT). But business folks are indeed getting pelted with SharePoint messaging from somewhere. Where is it? Entrepreneurial local technical salespeople? Active user’s groups? Self-appointed internal SharePoint evangelists? I’m not sure, but I wish I had the time to put on a disguise (a fake moustache and trench coat would do), hang out in a corporate business unit for a while complaining about how I wish I had a better way to collaborate than shared drives, and then catch whoever pops out of the woodwork …
2009 was the year that governance really took off in the SharePoint community as evidenced by SharePoint conference presentations, user’s group presentations, and bloggers. It’s been a major part of my conversations with clients and presentations to audiences using SharePoint since 2003, but I’ve never seen the energy around this topic that I have in the past year. That’s wonderful since I’ve observed that SharePoint installations that address governance upfront tend to have a much higher success rate.
Most governance conversations and presentations start from the definition to anchor the subject and then use it as a structure to drill into its portions. The community has mostly settled on some combination of the 3 goals and 3 tools in my definition, as outlined in our SharePoint Planning and Governance workshop:
Website governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization.
Over the years I’ve been happy to see my approach picked up by the SharePoint community via Microsoft and Joel Oleson. It can now be found in places as diverse as Tech Ed Africa, SharePoint Magazine on Facebook, IronWorks , Robert Bogue, Michael Sampson’s blog, and Sean Stecker of Ensynch.
And other guidance from our workshop (like how “SharePoint often overlaps with other installed applications in particular capabilities”, how use policy is about “what constitutes abuse or misuse of SharePoint” and provides “clear instructions on how and when users should work with SharePoint”, my definitions of the centralized/decentralized/federated models) has now crept into the standard decks Microsoft provides to the SharePoint community (usually without acknowledgement, but I’m sure there’s silent appreciation there!).
The definition has even taken on a life of its own by evolving in a few directions, and – aside from the shameless chest thumping above – that’s what I’d like to provide my thoughts on today.
One evolution I’ve seen is to add “to define a service” to the definition. I really like the application of service methodologies to SharePoint and have been doing quite a bit of research in this area. My 2007 workshop applied ITIL v3 to SharePoint and my paper on using ITIL to define “SharePoint as a Service” comes out in January. Still, I’ve decided to focus on service definition as a management issue rather than a governance one (more on that here).
Another evolution I see as more dangerous. A fourth tool snuck in at some point: technology. There are plenty of other SharePoint documents that will focus on technology, such as maintenance manuals, administrator’s guides, tuning guides, etc. Technology is a third rail of SharePoint governance. I tried injecting it for a short time and quickly backed off after seeing the energy it sucked out of the other 3 tools. It provides a slippery slope that enables those uncomfortable with the political and diplomatic challenges of defining people, policy, and process to focus on technology instead. Also, you have different audiences and authors for technical docs versus the statement of governance so it’s best to leave that separate.
I’ve been noticing a distinct anti-IT trend in vendor marketing lately. There has always been dissatisfaction with IT for everything from failure to understand business needs to technical elitism. But there are more options now for business units that want to get around IT. Especially for the technologies I cover: collaboration and content.
What are those options? Business units can avoid IT in roughly three ways:
- Do it yourself (aka “end user computing”)
- Hire outside contractors/consultants
- Software as a service
For example, Microsoft is increasingly marketing SharePoint to the business with as the DIY option of choice. With SharePoint 2010 coming out and their marketing machine in full gear, I am getting lots of comments from IT folks that their business partners are attending an external SharePoint seminar or have had sales people contact them directly. As one poignant example, I did an onsite governance workshop for an organization where SharePoint was growing separately in IT and the biggest business unit. Getting them on the same page would be useful, but unfortunately the business units couldn’t attend because they were all at a SharePoint training class they had enrolled in without IT! This is new – I haven’t seen anything remotely close to this end user push before.
SaaS and cloud offerings have pushed this button too. By just writing a check, capabilities can be delivered without a painful round of requirements gathering or project approval process.
I can’t blame vendors for doing this. There are perfectly good reasons to avoid IT that don’t amount to IT bashing. End user computing can enable the business to iterate on its own with the subject matter experts in control. SaaS can be more cost efficient and lower risk than a large IT installation. Consultants help even out peaks and valleys in workload without layoffs, and provide niche expertise. Hey, IT can be happy to work on the difficult problems that demand its skills while leaving the business to help itself for lesser needs.
All of these reasons are evident in Microsoft’s marketing for one SharePoint’s main capability areas, composites. “Composites – Business users need the ability to quickly create applications without involving the corporate IT group for each request.” Wondering why? Well, in the SharePoint 2010 guide handed out at the SharePoint conference, it goes further and describes how the line of business has custom needs that often result in IT becoming a bottleneck. “This common scenario results in a backlog of increasingly unmet needs in the IT group … By enabling users and decision makers to create [composites] it becomes easier to improve productivity along with the satisfaction in the organization of the company’s IT staff.” (sorry, can’t find a link to it online)
To me, it’s all a matter of intent. Using end user computing, external consultants, or SaaS when they are truly better alternatives than a properly working IT department is the right thing to do. But if the business is not happy with the service they get from IT (e.g., too busy, too bureaucratic, too incompetent), the first course of action, before figuring out how to do it themselves or write a check to someone else, should be to fix IT.
My suspicion is that there is often a combination of these two intents at play. Before the business gets too excited about getting needs met without IT involvement and before IT gets too excited about getting to ignore a swath of the business, a realistic assessment should first determine if something is broken .
In April of 2008, we released our advanced SharePoint workshop that describes how to offer “SharePoint as a service” by applying ITIL v3 to SharePoint. Alas, it’s taken a while to start publishing this methodology in document form, but I just submitted the first paper on this subject. It’s called “ITIL for SharePoint: Defining SharePoint as a Service using ITIL Service Strategy” and is due out in January.
Writing this document forced me to dig deeper into ITIL’s best practices. Many of them transfer directly to SharePoint (like much of the operations and service desk parts), so I didn’t want to waste time just restating them with the word “SharePoint” in front. And some don’t really apply at all, since SharePoint isn’t the type of service that ITIL was originally created for. But by picking carefully through the best practices (and sometimes reshaping them to fit) a few real gems emerge. Those are the ones I concentrate on in the paper and workshop.
In the process of writing my paper, several points became clear that go against the countervailing wisdom I’ve seen among SharePoint implementers.
Trying to squeeze the most from your SharePoint investment is probably not good for the company
What could possibly be wrong about trying to get the most return from your investment in SharePoint? What matters is the ROI of the company, not the ROI of a product. Just because SharePoint can do something doesn’t mean it’s the best tool the organization has to accomplish that task. As a parallel, the ROI on my $40 cordless screwdriver would increase if I used it for drilling all the drywall holes for my basement remodeling since it’s squeezing more benefit for the same investment. But that’s still silly if I have a corded electric drill nearby that’s much more efficient. When organizations get too excited about SharePoint, they risk cannibalizing value from other systems to the detriment of the overall collaboration portfolio.
Value is different than ROI
Conventional wisdom has convinced many SharePoint implementers that no metric can prove its worth better than the return on investment (ROI). After all, it’s actual dollars made compared to dollars spent – how much more real can it get? However, ITIL’s approach reframes the value equation quite elegantly by avoiding common SharePoint ROI problems (like the difficulty of proving the numbers and the distortion that perception introduces). What ITIL reveals is that SharePoint service providers need to focus on the portfolio’s combination of utility (what it provides) and warranty (that it is available to provide it) to ensure that value is achieved.
Management is different than governance
Governance is very important. I’ve dedicated significant portion of the last 6 years instructing everyone from Microsoft to government institutions to large corporations on how to apply governance to SharePoint. But management represents a separate pillar that is just as important. Executed properly, governance will provide the organizational and procedural structure that management requires to succeed. While practitioners conventionally blend management guidance into governance docs and use the terms interchangeably, there is a clear line separating them and two distinct efforts are required.
Offering SharePoint as a business service is fundamentally different than offering it as a set of technological capabilities
SharePoint demos like an app and it is tempting to treat it like an app, but more organizations are finding it’s really infrastructure. Steve Ballmer at the SharePoint conference finally used the “P” word: platform. So SharePoint is collaboration and content infrastructure. But users use applications. A service delivery methodology bridges that gap by packaging technical services into business services.
Users of SharePoint shouldn’t know what SharePoint is
Why does a business user need to know what SharePoint is? Conventional wisdom pushes the importance of “lunch and learns”, training plans, and rollouts. These are all fine as long as they are not for SharePoint. Proper service delivery will yield business services carefully crafted for particular uses. Those services are what the users need to understand. If an end user is asked if their company uses SharePoint in my ideal service delivery organization, they would answer “I don’t know. Never heard of it. But we do have a great Lab Research Tracking tool …” (where the tracking tool is a customized SharePoint list and template). Even though end users should be able to help themselves with SharePoint, that can mean end users initiate their own instance of the Lab Research Tracking workspace, not that they create it from scratch. And the service delivery methodology can stretch to include local service delivery points so that business services can be provided without having to contact IT or wait in their queue.
“Driving adoption” is a band aid for poor demand management
Conventional wisdom touts the importance of driving adoption before, during, and after rollout of SharePoint. “If you don’t drive adoption, you’ll fail to achieve the full potential of SharePoint”. Nonsense. A study of ITIL’s demand management process forced me to rethink this wisdom and realize that it is all backwards. If you took the time upfront to understand what the business needs and deliver it, you wouldn’t have to convince, cajole, or lure them to use your system. And the education required would be less as well since it would be targeted to business services rather than general purpose usage. End user self help can work once you attract users with specific business templates, after which adoption comes naturally rather than require “driving”.
Internally, SharePoint always has competition; users always have a choice
ITIL demand management recommends evaluating competition as a best practice. While it is written to apply to other external service providers, reframing it as internal competition yields important insight. E-mail will remain a substitute good for much of what SharePoint does. Competing – but disconnected – SharePoint installations can occur. And SaaS options abound.
The process of applying a service methodology has value for the organization beyond just the end result
Conventional project plans have governance and management as “something that needs to be done”, when actually they are “something that needs to be learned”. The process of implementing ITIL has many side benefits including better communication with the business, higher value, and knowledge that can help with other domains.
I just got back from an onsite visit to help a client work through their SharePoint governance issues, which includes talking about picking the appropriate spot on the governance continuum. This is almost always some form of federation. My definition of federation is “Groups in an organization recognize a central authority’s right to set high-level policy but retain the freedom to make their own decisions within the bounds of that policy.”
I’ve been asked before if federation can exist without a central authority. I realize in some technical domains the word “federation” is used that way, like with P2P federation. But for this domain, federation does imply a central authority.
When talking about federation and governance, my model is federalism, which the U.S. was founded on. Wikipedia calls federalism “is a political philosophy in which a group of members are bound together (Latin: foedus, covenant) with a governing representative head.” That’s how I seem to remember it from Social Studies class too, although that was a long time ago.
For final proof, please note the definition of perhaps the best known, most advanced federation: The United Federation of Planets. According to the Memory Alpha Star Trek wiki: “The United Federation of Planets (abbreviated as UFP and commonly referred to as The Federation) was an interstellar federal republic, composed of planetary governments that agreed to exist semi-autonomously under a single central government based on the principles of universal liberty, rights, and equality, and to share their knowledge and resources in peaceful cooperation and space exploration.”
BTW – Apparently the UFP had an anthem too. Click here to hear it.
Note: This is a cross-posting from the Collaboration and Content Strategies blog.
I just got back from Vegas where I presented on what SharePoint governance is (and isn’t) and how to create a SharePoint statement of governance. If you went to the conference, your logon will grant you access to the video in a few days I’m told. I’m not sure if or how it will be available to non-attendees.
For those who have seen/heard me present on governance before at one of our workshops or client briefings, there are a few enhancements I’ve made to my materials. They are:
1. Clarifying that my definition is a domain-specific definition, not a dictionary definition. I believe it tracks closely to what many have written about IT governance and is meant to provide guidance, not merely say “the act of controlling people.” or something like that.
2. The relation of the statement of governance to other documents that exist such as the maintenance manual, standards listings, and IT governance. Not just drawing lines between them, but showing how they relate and enhance each other.
3. The difference between governance and management (yes, there is a difference – and I didn’t make this one up!)
4. Announcement that my poster on “Creating a SharePoint Statement of Governance” is now free from the Burton Group website. Go to Free Resources and look for the link to the poster. Free registration is required.
At his keynote address at the SharePoint Conference, Steve Ballmer acknowledged that 10 years ago, if they had written up a list of what SharePoint is supposed to be on paper, that wouldn’t be what it is today. “Your feedback and input … the way you’ve driven us” has made SharePoint what it is today, thank you very much. For example, Internet-facing sites were not an original design point. In the same vein, Tom Rizzo said that SharePoint has been such a success that Microsoft has been overwhelmed.
Why is it the case that something far beyond a shared folder replacement couldn’t be envisioned in 1999 when Lotus Notes had already been around for years? Why did that feedback take ten years to result in better top down management and control that every serious portal product mostly had in 2003 and certainly in 2007? Why weren’t internet sites a design point, particularly when many of the stopping blocks (like limits on list sizes, farm management, and scalability) were also hassles for large intranet deployments as well? And why wasn’t Microsoft more optimistic ( = prepared) for SharePoint’s success given the history of Notes and early Plumtree success? This lack of optimism probably resulted in the 2003 and 2007 releases of SharePoint getting less R&D effort and sales attention than they deserved.
It’s easy to be a Monday morning quarterback, but I was in the press box for the 2001, 2003, and 2007 seasons and most of my fellow analysts were calling the same plays back then. I don’t recall anyone saying SharePoint wasn’t going to go anywhere, or that IBM would stomp it out, or that they shouldn’t make the product appropriate for business-to-consumer (B2C) deployments. All these things should not have been a surprise and absent from SharePoint planning.
Don’t get me wrong – I’m pretty happy with what I’ve seen of SharePoint so far. And it’s grown even faster than I personally thought it would. But I don’t look back at the winding path with nostalgia either. If I’m teary eyed thinking of what it took to get here, it’s not necessarily for the same reasons as Steve Ballmer and Tom Rizzo.