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...

Compatible

Response to Service Sphere's blog entry

ITIL compatible is a fairly general description, ITIL certified, either Pink or other is pretty much standard for any "helpdesk" software, if you were writing helpdesk software why wouldn't you?

However I would question how hard it is to be compatible, most of the big vendors' software is so flexible you could customize it into anything.



I too have seen great (and well loved) software leave the forefront, but I don't think that was due to the ITIL Borg, but rather the (big 4 vendor) empire striking back.




PS yes I know that last movie reference was a stretch :)



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...