KnowledgeForward

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 .

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.

I’m packing my bags and heading for Vegas for the Microsoft SharePoint Conference.  If you are going, make sure to see my presentation on governance.  I’ll be standing up in front of 400 people, the majority of whom are “IT Professionals”, and telling them that the IT Pro role isn’t the right one to be writing a statement of governance!  Remember that scene from the Blues Brothers that starts with the band wondering why there is chicken wire in front of the stage?  That’ll be me.

Note: I say the IT Pro role, not any one individual person.  Someone who is an IT Pro, but wants to step outside that role because of the challenge or an interest in management would certainly be appropriate.

Hope to see you there!

Governance, Politics, and Diplomacy with SharePoint: Success Factors Beyond Technology

10/21/2009 10:30 AM (Room: Lagoon L)

Few concepts have generated as much interest to SharePoint implementers as governance. Unfortunately, few concepts have been as misused as well. Governance has been viewed as a project, a document, a synonym for “maintenance,” an admin manual, or a magic-bullet solution for SharePoint success. But governance is none of those things. Craig Roth will describe his frequently cited definition of SharePoint governance including which problems it addresses – and which it does not. Mr. Roth will also walk through an outline for creating your own SharePoint Statement of Governance and describe the skills necessary to create it.

Joel Oleson’s post yesterday entitled “SharePoint Documentation – Why Does it Stink?” blames the “continuous publishing model” for never-ending sprawl on MSDN and TechNet.  I think the governance documentation is lacking and for another reason – it’s written for the wrong people.First, a little history may help here. I’ve been preaching the importance of governance to shore up the increasing implementation failures I was seeing in SharePoint since 2004. I gave a presentation on the Microsoft campus to over 400 Microsofties about governance and why they should care (bottom line: because when SharePoint grows like weeds, the weed whackers eventually cut it down). I returned in 2005 and did another large presentation, this time including my definition of governance:

Web governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization

After that, I continued to talk about governance with my clients who were highly motivated to learn more about it, but the interest seemed to fade away at Microsoft.

Until about 2007 when Joel Oleson picked up the governance gauntlet and really got things moving. Joel had the respect both within and outside Microsoft to lend credibility to the idea that governance was of great importance to implementers of SharePoint.

But Joel is no longer at Microsoft (he’s at Quest, a Microsoft partner) and governance seems to have gotten derailed at Microsoft. Not that it’s ignored – there is tons of material on TechNet’s Governance Resource Center for SharePoint Server 2007. If anything, there’s a lack of editing oversight to massage the best materials into a single version of truth rather than allowing sprawl (a lack of governance for the governance site perhaps? Ha!). Joel’s blames the “continuous publishing model”, but I think it stinks for a different reason.

I’ve systematically looked through all the materials on the governance site and my conclusion is that Microsoft is targeting its SharePoint governance guidance at the IT Pro (Microsoft’s term for professional techies like programmers and sysadmins). The IT Pro role should not be creating a SharePoint Statement of Governance; it should be the purview of a business analyst and/or their business partner.

Note: I said the IT Pro “role”. I’m not saying techies can’t understand business stuff. Some with that role want to stretch themselves to other roles and have talent on the business side too. But the correct target for “how to create governance” materials is the “business analyst” role, which should not be forced on an IT pro that isn’t purposely trying to move into a different position. How do you know if your IT pro is one of the rare ones that should write a governance doc? Tell them they have 4 weeks to write the governance doc during which they will not write a single line of code or script, not open any API manuals or technical docs, their output will be narratively written (non-technical and non-procedural) textual content that goes through multiple levels of change/review/approval, and everyone they talk to will be business folks discussing things like policies, risk, and – most importantly – internal politics. If they say “that sounds great!” you’ve got the right person! Because that’s what it takes to write a SharePoint SOG.

What happens when someone acting in the IT pro role writes governance is that, like anyone, they concentrate on what they know. This means a few pages of business pabulum about goals and roles followed by dozens of pages of techie stuff they feel confident in the quality and value of such as topography diagrams, system settings, and operations/dev procedures. The definition now used is based on mine, but adds “technology” to the list of tools. Adding “technology” to the governance definition is a slippery slope. Technology should not be part of governance except as surfaced by processes – and even then sparingly.

The materials on the TechNet site quickly slip down that slope. For example, the sample governance plan gets into techie jargon by page 2, has a topography diagram on page 4, and the signoff sheet is just up-and-down the IT chain, which is no surprise since the role listing contains no executives. The video posted there has a guy saying governance is a “fancy word for the owners manual”. No, that would be called the “operations/maintenance manual”.  This isn’t about how to use the stereo in the car or remove the tire jack.  This is about (to extend the example) a family of cars and what tradeoffs have been made in the designs based on its goals, how it relates to other automotive families the brand offers, an executive statement granting authority to create five more cars in this family but only within given bounds to optimize value to the overall brand relative to others, what committees are authorized to make decisions within the governance framework, etc.

Governance does not equal a maintenance manual or ops manual. If the definition of governance is the hangup (“you think governance is x, I think it’s y – there’s no right or wrong …”) then please consider a mental tag instead: busgov. There exists a thing, busgov, that addresses SharePoint, has zero overlap with maintenance or operations manuals, and uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization. The author and audience of busgov is different than that of maintenance and ops manuals. Organizations that don’t do busgov may still succeed, but the likelihood is reduced and degree of success may be reduced.

The Microsoft materials have usefully taken the maintenance manuals up a level to force the IT pro author to think about a level above the bits and bytes with things like roles, business SLAs, and a quick acknowledgement of the business value that is the goal of delivering SharePoint. Great – but they may provide a false sense of security that “governance” has been taken care of when its pitfalls – the same ones that I was talking about in 2004 – have not actually been addressed.