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

The right amount of maturity

Youth is wasted on the young.-George Bernard Shaw

I was reminded of this fact today as I overheard a couple of young people calling each other "immature".

Immaturity is an insult, and certainly it's portrayed as a negative in most "maturity assessments", but how much maturity is good for you?


I have no answer to this, as a constant theme in this blog: you need to answer this for yourself, but this should provide a couple of thoughts:

People get more inflexible with time and so does a mature business process, this is great for providing consistent quality, but the world is not remaining constant, your mature process can become elderly very quickly.

Keep this in mind: one person's mature is another person's "past it", to remain youthful and vigorous a little risk can be a good thing!

The IT Skeptic has a longer post about this, also maybe not perfect but thoughtful none the less.


Read more...

Head in the Clouds? 8 things to keep in mind.

I can still remember the first time I saw a cloud on a diagram of a computer system, it was a long time ago and it looked something like this:


I asked a few questions at the time: Whats in the cloud? surely we need to know how the traffic is routed around?

I was told not to worry about it, that the cloud was only a cloud to us; to the network provider it was a well understood network diagram, they could at any point tell what was going where, but that we really didn't need to know.

The SLA was our iron clad agreement that we would have bandwidth and redundancy we had asked for. That the amorphous entity we were using was managed to our expectations.

The problem with SLAs is that they are an agreement not a guarantee, which we found out to our cost.

Today the cloud is the hot new thing... here are some principals for engaging your business in a cloud.

1) The cloud should only be a cloud from the outside, if the people running the cloud cannot describe it in more detail there are issues.

2) You need to really understand your requirements before doing business with any cloud.

3) SLAs are agreements not guarantees, if the cloud fails to meet their side of the agreement make sure you are still in business.

4) For SLAs to work well you need to be able to monitor them. It's likely the cloud can monitor the service they believe they are providing to you, can you do the same?

5) If you backup one cloud with another, it will behoove you to deconstruct both clouds to determine single points of failure, don't end up backing up one cloud with itself.

6) The benefit of the cloud is that it can change as needed, make sure the due diligence you do when first engaging in the cloud is repeated on a regular basis.

7) The cloud will meet more well understood structures at some point: networks, even USPS(!) ensure you have the right expectations from these services too.

8) The final rule is a truism: If something seems too good to be true it probably is, clouds are not miracles, don't commit until you COMPLETELY understand how it works and how you can use it.

This post may have come off negative in regards to cloud computing, I have tried to not comment on the capabilities of cloud computing, which I feel is still being defined, but rather try to encourage the thoughtful decision not to put too many eggs in too few baskets.

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

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

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

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