Selling MOSS (The moral of the story)

I hope that you had a bit of fun with my first “choose your own adventure” story. (Do yourself a favour and read that first!)

Writing that one was most fun. Did you suddenly think of the names of current and former colleagues as you read it? 🙂

Anyway, now it is time for you to sit on my virtual knee and listen to the moral of that story because believe it or not, I actually had a really important point to get across.

The two catalysts…

Recovering CPA Mike shares similar views to me in a lot of areas. He wrote about possible reasons why SharePoint initiatives rarely have any decent form of ROI analysis performed on them. He talks, among other things of a ‘first wave’ of technology buyers, not used to ROI analysis. He also mentions the whole “must have” mentality of popular technology.

He’s dead right on both counts and my additional take on it is this.

Right now, there are only two types of SharePoint projects I seem to be working on. Those that are initiated via the IT department, or those that are initiated because a new CEO or senior manager is a previous SharePoint user and wants it.

I suspect that for the next 6-12 months, these two will be quite predominant catalysts.

The latter is actually my preferred scenario, but it does cause me some short term pain. In this scenario, the IT department usually is caught “on the hop”, to some extent, as they have usually very little SharePoint exposure or awareness.

The short term pain is based around me having to fast-track SharePoint product understanding at at infrastructure, application and governance level. This has to be performed among all the different IT department hearts and minds. This is not as straightforward as it may seem. Often IT people can actually take longer to ‘get it’ then non IT. As I demonstrated in the light-hearted version of this post, there are various different hearts and minds that have to be won over in different ways. (Some will never be won over).

But the nice thing about this scenario is buy-in is generally assured. When CEO’s say they want something, it generally gets done and I get to skip a lot of long, boring meetings with little outcome.

I’ve seen this scenario screwed up also, but that is for another post. This article is all about the other scenario – the one that carries more risk, despite best intentions.

If You Build It, They Will Come?

So here we are, no matter how it came to be, the IT department has seen SharePoint and likes it. (Well, not everyone in IT but those who have a say in it :-).

[ Snip the many meetings, arguments, dogmatic agendas and general whining to get to this point ]

The strategy for moving forwards seems to be oriented around the proposition of that Kevin Costner movie, “Field of Dreams”

“If you build it, they will come”

(Oh god ! Now I have admitted I watched a Kevin Costner movie! Please don’t worry as I am cool – I listen to Opeth 🙂 )

What I mean by  the “If you build it, they will come” mentality, is the commonly adopted premise that if you can demonstrate how IT uses a tool like SharePoint to improve how it goes about managing its affairs, then it is a shoe-in to sell to the rest of the organisation, right?

I beg to differ, for many reasons. But let’s take a closer look on why this approach is so often used right now.

Products, Products, Products (and some definition of terms)!

I.T departments are service providers. They operate, manage and are accountable for IT Services. IT Services are provided by IT infrastructure and the governance of that IT infrastructure.

IT Infrastructure is all of the “products” that combine in various ways to provide the IT services. Examples of infrastructure include your physical servers, network devices, storage area networks and UPS. Examples of infrastructure include also applications like Microsoft Exchange, SQL Server, Apache webserver and operating systems such as Windows 2003 and *nix.

IT departments are good at this stuff (in theory anyway) because they tend to see the IT world as the management of products that provide service. They look at how these products interact and have a very good understanding of the dependencies, risks and day-to-day management of these products. My former world used to be Cisco networks, Active Directory, SQL Server, Exchange, Redundant storage, backup agents, etc. I cared little for the Information Assets being provided by these IT Services because I was rarely a user of those Information Assets!. If the IT services were available, then I knew that the information assets they facilitate were available and that’s all I was accountable for!

So is SharePoint is just another product then? Let me ask you this? How many IT departments do an ERP install by themselves? Not many!

Information Assets

Aha! I just used a new term before. “Information Asset”. I originally came across the term in when I worked with ISO17799/27001 a few years back. However I don’t quite think the ISO definition is ideal because it also uses the “Asset” term for IT products and services as I have defined them in the previous section. (I have always found this much harder to explain to people when calling everything an “Asset”).

So instead, we will stick to my previous definitions of IT Services and IT Infrastructure and use this definition for Information Asset which I like much better.

“An Information Asset is a definable piece of information, stored in any manner which is recognised as ‘valuable’ to the organisation”

The above definition you will note does not talk about information assets in terms of the services that provide it. Instead it is focused on it’s intrinsic value. Below are 3 characteristics of information assets with intrinsic value

• Information assets are recognised to be of value to the organisation.
• Information assets are not easily replaceable without cost, skill, time, resources or a combination.
• Information assets form a part of the organisation’s corporate identity, without which, the organisation may be threatened.

The I.T Department and Intrinsic Value

IT departments are generally inward facing in that they often know the least about the information assets that have real intrinsic value to the organisation. They know all about the IT Services and Infrastructure that provides those services however.

But for many other sections of the organisation it is the other way around. They have no significant understanding or appreciation of the IT services or infrastructure.  Nor should they – it’s your job! The majority of non IT staff are accountable for increasing the intrinsic value of the organisations information assets. So long as you in IT ensure the confidentiality, integrity and availability of the IT services that support the information assets, you are doing your job. ( Nobody will appreciate it, but you are still doing your job 🙂 )

A Tool Looking for a Problem

So back to my premise. The IT department likes SharePoint, sees its potential and thinks it could be good for the organisation. So let’s use it for our own internal use, and then use this as a showcase of how it can be used elsewhere in the business to improve the way things run in the business.

Improve what? By how much and how soon? What is current the problem that is resulting in operational wastage and therefore reduced earnings per share? How much is it costing us per annum? What percentage of improvement can we expect by this investment and how much confidence do you have in your estimates?.

I’m sure you can answer this in terms of internal IT service performance via quantifiable evidence like frequency and reason for helpdesk calls, number of helpdesk staff over time, staff retention rates, backup/restore stats, etc. But you are exceedingly unlikely to be able to answer it from anywhere outside of IT.

So what problem do you want to solve for the business? At a macro level its easy to say, “SharePoint has this wonderful feature X that does this and it will solve so many problems”, but it’s not enough… not by a long shot

and who are you to talk anyway?

IT Departments also more often than not, do not exactly have the sort of quality control and organisational efficiency that they would like to have. If your helpdesk queue has 167 outstanding jobs, with poor clearance rates and turnaround time. Your existing infrastructure is poorly documented, change control and configuration management is questionable. Staff are unhappy, turnover is a problem and politics/dogma gets in the way of progress.

So, you are not exactly setting an example here. Will yet another tool solve a bunch of problems that essentially people/process in nature?

More importantly, will the business take you seriously? What is your track record like?

Improving the approach (you can still fiddle a bit 🙂 )

So fine, use SharePoint in IT. (I’m not against it – I’m just cautioning against the ‘typical’ IT approach of the tool before the problem.). But do yourself a favour and define a problem to solve first. The problem MUST, MUST, MUST be a measurable one and it can’t be trying to bring about world peace. So instead of writing

“We need a change control process” or “We need a new helpdesk system”

define a quantifiable goal such as:

“Reducing helpdesk calls per day from the current average of 140 per day to a goal of 70 per day in 4 months (50% reduction)”, thus saving us $1,240,000 per annum”

Don’t pull the savings estimate out of your rear end either! State your assumptions on how you came up with this figure. Gut feel almost always is not good enough. (For what it’s worth, I have blogged a little on doing this last year, but a lot more is to come!)

Now you have a clear goal to achieve and you can discuss how to achieve it. You will have to do an analysis/measurement phase, where you mine your data (or embark on a collection phase if you have none), to determine the causes of the high cost . You will examine the processes and systems that have allowed this to happen and slowly weed out the candidate causes until you hit the one or two that have the most impact on the problem.

Interestingly, using our helpdesk example, you may find that the root cause is not the helpdesk per se, so putting resources into tracking helpdesk calls in SharePoint is of less value than optimising the flawed process causing the calls. That process may not be an IT owned process – interesting eh! It may be that you use it for a non-IT business process problem after all!

Anyhow, the goal is that you will be able to provide a re-engineered and optimised process. With the help of a tool like SharePoint, along with training and a degree of cultural change, you can work to achieve this goal. Chances are, the SharePoint bit takes less time than the analysis/data gathering/data mining and process optimisation phases.

So after 4 months, you can easily quantify whether you achieved your goal and if you did, you utterly rock and the entire team can go to the pub for the afternoon!

Conclusion (Now we are getting somewhere!)

Now you are in a much better position to go back to the business with a SharePoint proposition, demonstrating how in 4 months, you were able to use it to help you optimise a business process that has saved/made money.

This is what business wants to hear! In addition, this now gives you the sort of springboard and model that can be used to examine other problem areas of the business. You have also kicked a goal via your departmental staff learning how to manage the SharePoint IT ‘service’, and its various infrastructure components. That is one less cost you have to factor in with your financial models 🙂

Phew! I think I am just about done!

My personal interest in process optimisation stems from my interest in improving the bridge between financial justification of technology and the technology itself. I intend to write more on techniques for process optimisation in further blogs and how I went about setting up an IT portal based on elements of ISO and ITIL. For those of you that find this information useful (probably not so much the tech guys :), please let me know.

regards

Paul