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 .
Governance doesn’t have to be paternal and forced on groups by higher powers. Here’s a quote from an article in the Oct 15th 2009 issue of the Economist (“Reality bites“):
In 40 years of studying how common resources—from lobster fisheries in Maine to irrigation systems in Nepal—are actually managed by communities, Ms Ostrom found that people often devise rather sophisticated systems of governance to ensure that these resources are not overused. These systems involve explicit rules about what people can use, what their responsibilities are, and how they will be punished if they break the rules. In particular, she found that self-governance often worked much better than an ill-informed government taking over and imposing sometimes clumsy, and often ineffective, rules.
I haven’t read Ostrom’s research, but I’m guessing that self-governance meant that governance occurs between small groups, not that every individual is self-governing. That’s an interesting finding, since governance is often assumed to be top-down and bureaucratic. But it doesn’t have to be. According to my governance definition, the goal of governance is to to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization. A higher level authority may not be required to address these goals if a community can do it themselves. Indeed, if the higher power doesn’t know enough about what they are governing to put good rules in place, it’s better to simply give the group a mandate to put people, process, and policy in place, but to let them create their own rules.
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.