Tax code can encourage SMaaP?

Expenditures in most US businesses are one of 2 types Operational expenditure (OPEX)and Capital expenditure (CAPEX), the following are the wikipedia definitions of the two, I should note I am not qualified to describe the US tax code in any usable detail.

An operating expense, operating expenditure, operational expense, operational expenditure or OPEX is an on-going cost for running a product, business, or system. Its counterpart, a capital expenditure (CAPEX), is the cost of developing or providing non-consumable parts for the product or system. For example, the purchase of a photocopier is the CAPEX, and the annual paper and toner cost is the OPEX. For larger systems like businesses, OPEX may also include the cost of workers and facility expenses such as rent and utilities

The Conventional wisdom in the current economic climate is that Opex is "better" than CAPEX, IE it is easier to spend some operational money, Capital expenditures usually require sign off. (see cloud computing)

However I have consistently run into a different issue, Operational expenses are very difficult to add to, and if a quick straw poll on twitter is anything to go by, I am not the only one.

Hiring a new manager for a "help-desk" for example is a decision with long term consequences and though the cost is quite small it is usually a hard slog to increase headcount, however buying a new software suite, implementing it and hiring the consultants to advise on its deployment are all capitalised and therefore require only single sign off at the inception of the "project".

This seems to be another incentive leading to SaaP "Service as a Project":

• Failure is not an option - the project must have "ROI" and this ROI must be defined in a return of capital. A real issue when your starting point defined by lack of financial data.
• Service is not a project - treating great service as a project that has an end has probably felled more ITIL adoptions than any other, understanding your customers and users, the service you provide, how it's used and making it great is way of life... not a project.
• Not everything is able to be capitalized - This is a real kicker, there are some things the cannot be capitalized, I believe this can incentivize some organisations to buy more software and spend less time staffing for the new organisation.

As always just a quick thought, let me know yours.



Read more...

Understand the goal before you set it

Thought: When running the race to great service: Experience counts.

When running a marathon or cycling "a century" for the first time, one usually does some serious practice. Over a period of months, you get an idea of your ability. When the inevitable question, "What time are you shooting for?" arises, the answer is suitably vague to avoid later embarrassment and also because it’s only possible set very general expectations.

Experienced professional athletes have completely different perspectives on goals. They have perfected their technique over time; they understand their fitness levels and where they are in the season, enabling them to decide to hold something back for the world championships or leave nothing in the tank at the last meet of the season. They will have a specific target time and race position.

In an organization embarking on an ITSM program for the first time, we shouldn't have the same goals as an experienced practitioner; we should have vague targets that will tighten up over time.

Single focus or multi-discipline?

The runner analogy is simple but unfortunately the IT management world is not: The practice of an IT manager is more akin to a decathlete; as a multi-discipline leader we must decide where we will get the most bang for our buck. But there are only so many hours in the day and so much money in the bucket, so where is it best to spend our valuable resources?

Start with the obvious questions:

How good is good enough? Do we really want to be world-class in a particular field?

These are questions only you can answer. As with most answers, they are usually more accurate with better more reliable information to base them on:

Do you have this information? How can you get it? Where will it come from? Is this the first step?

To get back to our analogy, even the novice runner practices, gets baseline data to build from, and understands basic but amorphous goals to aim for.

Putting this Thought into practice:

1. The first thing to do when starting an ITIL adoption is determine where you are starting from.
2. If you can't really determine that baseline DON'T PANIC, maybe that is a good first goal, it will be cheap with demonstrable results.
3. Once you have a baseline try to determine where you want to improve, (speak to your customers)
4. Now you have your starting capabilities and your chosen disciplines in priority you can work on your practice schedule and set some vague goals.
5. Practice makes perfect, as you move from beginner to amateur to professional you can and will get better; eventually you can start thinking about being world class (if you want).
   

Parting Thought

Only when you are world-class can you think about your position in the race, until then you are competing against yourself to your own goals – your first goal is to make sure your goals are the right ones.

Read more...

ITIL V3, LEAN and Consultation

A week ago I made a quick post related to the fact that ITIL should already be LEAN, and this got me thinking about the evolution of ITIL and whether it has taken a wrong turn.

In the early days of IT management there was no standard way of running IT, everyone did it differently but some did it with more success, it was these successful methods that formed the foundation of ITIL.

ITIL V2 built upon these into a wildly successful framework that has become the de-facto IT operations standard.

ITIL V3 is an update to V2, It was written by experienced ITIL professionals - ones with intimate knowledge of the holes in V2 and where it needs to be extended.

This is a valuable place to get some insight, however, ITIL was a success because it looked outside itself to see where others were running their IT organization using better practice; it took the worlds best IT organizations and showed us how they worked.

There are organizations that have taken non-ITIL paths to success, LEAN, 6Sigma etc; what have they learned? are we embracing innovation and evolution?

The challenge for V3 is the success of V2

The innovation in IT management is not only in the adoption of ITIL but will also come from elsewhere, ITIL needs to be open to success OUTSIDE the ITIL framework and bring this into the fold.

"Best practice" is an endless quest, ITIL needs to ensure that it embraces developments in the Service (and IT) managmement field, that it dosen't get caught in a cycle of perfecting the processes it built in the 1980s while the industry moves on.




Read more...

More comments to my Previous post

I do not think the "Helpdesk" or ITSM tool space lacks innovation, but it is hard for smaller organisations to compete with the large vendors.

The speed at which they gobble up the niche players to add to their offerings is making entry into the market hard.

I have hopes that the CMDBf standard may actually allow more niche tools to compete on a level playing field, we shall see.

Every year though when I go to conferences I see new software offerings that I had not previously heard of, I think the market is working fine and innovation seems to be alive and well, whether having a "standard" like ITIL to work from has helped these tool creators, or hindered their creativity I cannot answer.



Read more...

ROI, CBA and how to analyze value

Thought: How is my business going to benefit from an ITSM program?

My answer to this would be that companies that take on a systematic evaluation of how to run their IT dept will see improvements in service, will be able to focus resources in the areas that the customers care about, will be able to really understand the quality of service that is being delivered.

Before we get into the question at hand, I would like to give a little context and definitions:

Investopedia:

Return On Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. To calculate ROI, the benefit (return) of an investment is divided by the cost of the investment; the result is expressed as a percentage or a ratio. The return on investment formula:

Wikipedia:

Cost-benefit analysis is a term that refers to a process that, whether explicitly or implicitly, weighs the total expected costs against the total expected benefits of one or more actions in order to choose the best or most profitable option. The formal process is often referred to as either CBA (Cost-Benefit Analysis) or BCA (Benefit-Cost Analysis).

So we have two similar and popular methods of determining if a project is worthwhile, or which of a variety of flavours of project are most worthwhile. Neither of these two methods in their basic form can help us determine the value of a ITSM program as defined above until we can actually assign a monetary value to the service improvements.

Typical methods.

The methods I have seen to "justify" an ITSM project are:

1) Reduction in outage time/number of outages (MTTR/MTBF)
This choice seems easy, implement good incident and problem management processes and we should reduce MTTR etc. the issue here is most organisations setting off on an ITSM journey don't have the cost of these outages, and the ITSM program is probably the solution to that. Catch-22.

2) Reduction in costs due to efficiencies.
This is really headcount reduction but could be software licencing due to CMDB implementation, again it's very hard to understand the real savings associated with good ITSM practices.

3) Service improvement/time to market
This is a true goal for most ITSM initiatives, but how do we quantify this let alone monetize it?


So there we have it, ITSM a great goal but hard to justify, and even if we "wing it" and make some numbers up we risk missing, or just faking the results.

So I am left with this question: how can we determine and demonstrate the benefit of an ITSM adoption, in terms that mean something to most businesses (IE cash).


Read more...

SAME

In my previous post I mentioned that I was looking for more information on how to manage IT in a model that is a little less complex....

I have been poring over the SAME document created by Jan Van Bon and Wim Hoving, and I have to say I think it's excellent.

This model seems to capture the realities of managing IT in a simple and easy to understand fashion, though I haven't put this into practice I can see the potential for forming a logical structure around the complex IT organisations and running decisions through the model to see where they fit best.

One of the only negatives I would mention about this piece is the comment that "Information support" is merely a supporting activity akin to HR or Finance, and though I agree with this, I think that provision needs to be made in the model for businesses where IT is the product, where delivery of information is the profit center.

This is only a taster of the full SAME model - I assume this and more will be covered in the full version.

In an ITSkeptic comment recently Jan said:

there's plenty more where this came from. It just hasn't all been published yet, and some of the published material is copyrighted so I can't simply provide it publicly. Most of it is all over the books my team produced with a huge team of experts, in the ITSM Library, a series of books previously published for the itSMF. I'm currently writing 'the ultimate book' on this subject, and a team of authors is writing a series of books on detailed topics, all in the same (SAME) architecture. These titles will be published by Van Haren Publishing, independently from any formal body.

There's one publicly available article I wrote for CEPIS/UPGRADE, titled "This is NOT Governance".
More relevant articles can be found on my company's website, but since that is all in Dutch, apart from one other article on the Process Management Matrix (PMM): here is a shortcut to an English translation of that article. It will tell you how to avoid one of the most common pitfalls when introducing process management ("failing to remove the responsibility from the previously responsible line manager, when introducing new process managers").

I look forward to the "ultimate book" on this subject.

Read more...

How Complex does this need to be?

So.... ITIL has 5 main books covering 27ish "processes", CobiT has 34 processes some of which overlap providing a governance structure of what should be being done, with ITIL explaining (somewhat) how. ISO 20000 details more standards that completely overlap with ITIL and CobiT. LINK

None of these three really cover project management, and nowhere that I can see is there a real prescription for how to manage IT technology or Organisational structure.

It is somewhat of a theme on this blog that this stuff can't be this difficult... is running an IT department really this complex?

What are we really trying to achieve?

All the frameworks call it different stuff but basically we do the following:

1. Plan our future
   
2. Design stuff to get us there
3. Build what was designed
4. Support what was built
5. Report on our success and improve. (I may consider this part of support but it matters little)

Now when I read through all of the 34 processes that are detailed in CobiT I actually agree that they are all valuable, so this post isn't really a comment that CobiT or ITIL are wrong.

Maybe it does have to be this complex, maybe this complexity is real, and what we need is more professionalism in the field of IT management to control all these moving parts.

I would be interested in hearing any opinions and in the mean time I will be out there looking for the dummies guide to building a world class IT organisation, let me know if you have written one.



Read more...

Public domain

Most professions are governed by a set of best practices that are not only well known but in many cases the law of the land, Doctors, Lawyers and Engineers do not sell or hide the rules that constitute the foundation of how they do their job.

A new medical procedure is peer reviewed and though the technology and the procedure are patentable one does not have to license the information to demonstrate, practice or write about the procedure.

A rising tide lifts all ships, and a rising quality of work in most professions is shared.

The recent discussion on the ITSkeptic website brings the ownership of ITIL into sharp focus, all the content though seemingly freely given to the OGC by vendors, consultants and organisations is not public domain. The training materials derived from the ITIL published materials is licenced.

Now, I am no expert in what it takes to create or manage ITIL or how the APMG or the OGC do business, but it would seem to me that the wider the information can be spread the better. I understand there needs to be controls around the quality of any "standard" but does this have to come with such a heavy hand?

In my opinion ITIL should be "by the people for the people", it would seem to already be "by the people" we just need it back. (preferably at cost)



Read more...

Great Article

The DITY newsletter this week is an excellent piece written by Hank Marquis, in it are some very practical steps, (6 rather than the ubiquitous 10) to improving availability.

The great thing about this article is that he not only details the six steps, but also details (with links) to how each step should be completed.

There is no tool vending going on here either, as he puts it:

All it takes is a spreadsheet, or paper and pen.

Enjoy.
Read more...

How different are we?

When it comes to rolling out a new tool based on the ITIL framework, a bulk of the expense comes from customizing the tool to fit our own unique way of running our IT organization.

Should we be so unique?

Most IT organizations are not business differentiators, they are cost centers tasked with providing commoditized service: e-mail, databases, storage, etc. Why should we be so unique? I know there are IT teams on the cutting edge, providing industry-changing technology solutions, but surely this is a fairly small percentage.

So if we top and tail the landscape, remove the languishers and the “bleeding edgers”, and just take the middle 50 percent, why are we so different from each other? The tools are almost interchangeable, and we all use very similar software.
Why don't we have the same policies, governance, processes, etc.?

Is the effort we put in to be different from each other worth it? Are we bringing value to the party?

When building an internal wall that will not be visible to anyone unless it fails, is there any point in going outside the basic, standard and cheapest design and implementation?

I would be interested in hearing other opinions on this.

Read more...

CMDBf

The announcement today of a standard CMDB specification for the federation of data across multi-vendor environments is a good one.

I have not yet read through the full spec - at 70+ pages it's a few nights work for me, but the working group of companies is satisfyingly complete.

About time really, how long have the vendors been fighting with each other leaving us as casualties? but I digress, I think this (in theory) is a step forward in the population and maintenance of a real CMDB, though I do think it's interesting that they do not call this a CMSf.

All we need now is for all the vendors to adopt this spec quickly, follow their own guidelines, and leverage this to achieve the full potential of the CMS.

I imagine we are a few years away from seeing any impact from this announcement, but I have been wrong before.
Read more...

Service Management Scalability

An Introductory Overview of ITIL V3 says that "Change Manager" is not a defined role but rather:

"It is not anticipated that a typical organization would consider a separate group of people for this role, rather there is a flow of experience and skills meaning the same people may well be involved in multiple lifecycle stages."

Firstly I would question this statement, I believe that its very hard to manage the checks and balances of due diligence for changes without a strong change resource directing the traffic, answering questions and producing reports etc. In my experience I have not seen any organizations that have managed to forgo this role, in fact during ITSM conferences I have probably met more "Change Managers" than any other.

The tool vendors probably have a solution for this, I am sure there is some software that will "remove the need for a dedicated change manager", not to be a skeptic but I will believe it when I see it.

If we take this as a given, I think there is an issue of scalability of roles in ITIL, it's hard to wear multiple hats, change Manager/Problem lead/Unix sysadmin: probably not a fun job, and pretty difficult to hire for. Do you really want your expensive EMC expert approving RFCs?

A large IT organization has the benefit of resources but even then vacation and training etc. mean that consistency becomes an issue.

ITSM is not cheap, the "tools" cost a considerable amount of money, adoption is hard and time consuming, hiring for service management roles is not trivial, neither is the total person hours devoted to greasing the wheels of the service management organization.

The scalability of the roles defined in the ITIL framework is not helping small IT organizations adopt, or large organizations reap the "ROI" they believe are coming... I believe there are solutions to this THOUGHT of mine, but that's for a later post.
Read more...