Category Archives: ITIL

A Small Business And Sharepoint

Posted by on December 22, 2011 2 comments

I had a hallway conversation with the owner of a small business that provides outsourced IT support and technical services for other small businesses.

As old techies are wont to do, we were swapping war stories (in other words, technical issues we had fought and beaten in the past!) when he mentioned a problem that he was having at one of his small business clients. For this particular client he had installed a Microsoft Small Business Server product to give his client basic email, file storage, and printer services.

Now this Microsoft small business product also contained a basic version of a collaboration tool called Microsoft Sharepoint Team Services. First, I must say that this next part is incredibly unusual, but his client had found this Sharepoint collaboration software by themselves and were actually using it.

I made that incredibly unusual comment as some tongue in cheek humor! And that is because many companies explicitly invest money and time into these types of collaboration products and then attempt to drag their staff kicking and screaming into using them. And here was a small business that found it by accident and just dove in – head first.

My friend described how his client was using this Sharepoint collaboration tool for various types of documents and had placed huge amounts of data into the software. And this is where his problem was found, his client was experiencing software crashes, corrupted documents and various other problems. I had previously mentioned that I had implemented a 10 thousand document ISO 9000 PMF repository using that same Sharepoint collaboration tool, so he asked if I had any idea on the issue.

I had the privilege to tell him that I had a really good guess.

The ‘Express’ version versus the ‘Full’ version

For many years Microsoft Corporation has fairly successfully given some basic products away for free, but to get more advanced functionality commonly used in our businesses, you needed to pay for the full version of the software.

As an example, for years you were able to use a free copy of Microsoft Outlook Express  for your basicMicrosoft Office email needs, in fact it was installed by default on many computers when you purchased them. But for shared calendars and other more advanced functionality, you needed to pay for it and purchase a full copy Microsoft Outlook.

And Microsoft has done the same thing with this Sharepoint product. Sharepoint Team Services itself is a a freely available download for licensed Microsoft Servers, and when you install it? It  uses the Microsoft SQL Server Express database engine. Notice the word ’Express‘ again. It works, and is also freely available.

But similar to my Outlook example, these freely available Express versions of these tools have some limitations that do not exist in the full featured ‘pay for it’ versions of the same software. The full featured ‘pay for’ products are Microsoft Sharepoint Portal Server, and the full Microsoft SQL Server product.

And my guess about his clients issues was based on these limitations. Because one of the limitations in the Express version is the physical amount of data that you can place in the SQL Server Express database. If you reread the above paragraphs, note that this small business owner said that his client had put ‘huge amounts of data in it’.

I suggested he take a look and see if they had put enough data into the software to be running up against the limit of what that Express version of the database software could handle.

As a note, a couple of weeks later he told me they had.

The SMB Takeaway

I give this small business credit for their head first dive into the software, although they should have told their IT Services provider, as he did not know they were using it – it was not being backed up! Think what they could have lost…….

However it brings up a lesson that in ITIL terms we call Capacity Management. (My first post on ITIL for small to medium business is here)

Capacity Management is defined as meeting current and future business requirements in a cost-effective manner. In English, it basically means purchasing IT assets based on your expected usage not just today, but next year. As a bad analogy - if you have decided that next year you and your spouse are going to have a baby, buying the two seat sports car right now would be poor future planning or poor Capacity Management.

My friends client found the software by accident, but this goes beyond the one software tool shown above, if you are looking at purchasing any type of IT software or hardware, consider where you will be next year, and the year after that. Buying a new server just big enough to hold all your office productivity documents and spreadsheets today, what about the new document or spreadsheet you create tomorrow?

 

Culture Trumps Process

Posted by on July 27, 2011 No comments

Yes,I am advocate of IT Service Management. While there are several frameworks to improve ITSM, including ITIL. (IT Infrastructure Library) A few years ago I argued in this post titled; Do I Really Need ITIL To Improve IT? that there are options to improve IT Service Management that do not rely on these formalized frameworks.

Jason Druebert writing for CIO Update  reports about an organization with exemplary IT Service Management skills, then has to ask this question;

So how is it possible that the most effective Problem Management I’ve ever seen completely disregarded ITIL?

I urge you to read the full article looking at the possible answers.

 

ITIL, The Long And Winding Road

Posted by on June 13, 2011 No comments

I attended a stellar day of seminars courtesy of the National Capital Region chapter of the ITSMF. (IT Service Management) The seminars and keynotes were great and I will be writing a little more about them in the future.

There is one quick note that I wanted to make. One of the speakers at this event, an IS Process Manager for Jazz aviation gave a talk on their ITIL journey. I thought the talk was superb because it outlined in a hands on fashion some of the challenges and obstacles that existed, and that had to be overcome.

I won’t cover all of the steps they made, but wanted to point out this;

They started their journey in 2007.

Started the next phase by 2009.

And now in 2011 they may be getting somewhere close to starting the 3rd phase.

Four years and counting.

The SMB Takeaway

If some consultant or vendor tells you that ITSM or ITIL is a quick silver bullet, they are ITIL snake-oil salesmen.

It is a journey – not a destination, and it can be a long one.

The presenter made one other excellent point about this journey – your business does not stop while you make it. Stopping business initiatives and strategies for a four year IT improvement, even though it will be beneficial to the business, is a career limiting move.

An initiative like this is pretty much guaranteed to be a part time project as key initiatives and projects still must be rolled out across your entire business.

 

Designing Process Backwards Revisited

Posted by on March 9, 2011 No comments

It was just a couple of weeks ago that I wrote  Design Process Backwards. Simply stating that when building internal processes, look at the end result that you are trying to achieve first. Then work backwards from that goal to identify what can be done to achieve those them.

On the HDI blog, Aileen Diefenbach has written an excellent example of this in piece titled; Translating User Feedback.

Step 1, start with the feedback of people directly affected.

Step 2, identify and pair the feedback with appropriate processes

The above article is about implementing IT Service Management via ITIL, but the same framework holds for all business process designs.

35,000 Hours And ITIL

Posted by on December 20, 2010 1 comment

I just came across one page of a document that I was given several months ago and forgot about. Because it is only one page, I have no clue where to point a reference, and I did not want to just throw it out as the  number below  is just too staggering to ignore.

If you recognize this, please let me know so I can do a proper attribution. To quote one paragraph;

… the IT help desk was spending 35,000 hours a month closing trouble tickets. A closer look revealed that the same set of incidents was reported month after month because the cause of the incidents had not been investigated. An analysis found that the vast majority of the calls related to 10 user issues.

Think about that. Ten, TEN!  user issues relate to vast majority of 35,000 hours closing calls.

What does that look like? I don’t know what exact percentage vast majority equals, but lets back of a napkin check out some random numbers.

(for the below, I will assume a commonly quoted number of USD $10.oo per first level incident support call, the above quote is also measured in hours, I have no idea how many calls can be closed per hour, but I assume more than one, so lets just use the 35,000 figure)

At only 10% of 35,000 calls, that is $35,000 per month, or $420,000 per year.

At 25% of 35,000 calls? $87,500 per month, or $1,050,000 per year.

At 50% of 35,000 calls? $175,00 per month, $2,100,000 per year.

As it states vast majority, lets ratchet right up to 75%, $262,500 per month, $3,150,000 per year.

The whole concept of ITIL is that issues like this get identified, and the root cause resolved.

There is absolutely zero excuse for an IT team to be spending from a low of $420 grand to over three million per year on the same ten issues.

ITIL, Value, Culture

Posted by on November 29, 2010 2 comments

ITIL is crap.

That phrase is one of the frequent search terms that finds this blog. I have no clue why, as I have never used the term ‘crap’ before this post.

Of course the search term itself tells me nothing about the underlying issues those individuals are dealing with, but I am willing to bet that one of them is change.

In this blog, I primarily write about  ITSM & ITIL, but it goes beyond just ITIL. In any internal business process change program, either via a framework such as ISO or Six Sigma, or a home  grown solution, there is one significant issue we all face.

People hate change. Period.

There are probably a dozen ways that any process based initiative will fail, I will leave all those to smarter people than myself.

But in mid-market and smaller organizations, when it comes to change,  there is often one particular event that is never seen; consequences.

Change & Consequences

Any initiative that looks at changing how people work requires new structures, new roles, adequate governance and clearly defined ownership. And each of these requirements implicitly (or explicitly if necessary) makes it clear what the responsibilities are, and the consequences if those responsibilities are not performed.

If there is a lack of responsibility and consequences, people instinctively return to the old way of doing things (i.e. the Rider & the Elephant in Switch by  Chip & Dan Heath) As an example, a particular device frequently acts up? Often the  famous ‘standing 10 count’ is used. (Turn it off, wait 10 seconds and turn it on again.) That may work, but there is zero knowledge obtained in how to fix the problem permanently. And the root of ITIL problem management is to do that, fix it permanently.

When it comes to managing change, the scale may be different for huge enterprises, but the problems exist in all businesses.  People need to understand the message that the old band-aid and scotch tape method of IT service is not happening any more. People need to understand that the elephant is no longer in charge.

To get that change into the IT culture, there needs to be consequences.

Benefits of ITIL – Executive Briefing

Posted by on September 1, 2010 4 comments

Chris Dancy of ServiceSphere (@servicesphere on Twitter) tweeted this excellent 10 page (PDF) Executive Overview of IT Service Management (ITSM) and ITIL.

The PDF contains a succinct, and brief overview of the benefits of improving IT Service Management, with some easy to understand demonstrations of visual signs of poor ITSM.

If you are an executive wondering what the fuss is about with ITIL and ITSM, this document is a great summary.

Note, if you have been following this blog for a while, you will note some terminology changes compared to what I have written. This is simply because my experience has been with Version 2 of the ITIL framework, and this document summarizes ITIL utilizing the newer process terminology contained within Version 3 of the framework.

If you are looking into ITIL, I highly recommend checking out ServiceSphere at the above link, on twitter too!

Resistance To ITIL?

Posted by on February 12, 2010 2 comments

Resistance? To ITIL?

That can’t be true!

Everyone knows ITIL processes can improve IT service support and delivery costs, improve internal IT service management processes, and even make coffee in the morning!

You can laugh now! Everyone does not know that ITIL can improve internal IT processes. (OK, the part about coffee is untrue as well!)

But for SME’s looking at ITIL, first, it is a journey. And like all journey’s it involves change in the way people work, and changes in what they may be responsible or accountable for. And like any change, we as humans can resist change when we don’t understand the WIIFM. (What’s In It For Me?)

Along that concept, Ann All at ITBusiness Edge has a great article that I want to pull two bits from.

First, your IT team may be as resistant (or more so) to change as anybody else in your organization.  For some technology staffers, it may simply be not understanding the business implications about what ITIL can provide. And for some it may be because they are addicted to the glory of heroic  IT acrobatics, after all, avoiding any incidents or problems in the first place is hardly glamorous. And some technology staff can simply see it as an unnecessary inhibitor or overhead to their getting real work done.

The warning here is that an announcement that ITIL is going to happen on Friday! – Sorry, that won’t work. Like any organizational change this journey will be slow, require 10 times the communication that you thought necessary, and has to be taken in small, incremental steps. (You can try to do it all at once, but unless your teams and your people thrive on ripping the guts out of your business and rebuilding it from the ground up, you will have a hard time of it)

The second piece I wanted to emphasize, is that implementing ITIL processes are not an all or nothing exercise. I know that I have written a lot about this, but here is one excellent example. As the article referenced above states about one journey into ITIL;

… didn’t invest in a new tool until nearly three years into its ITIL initiative,

It is not all or nothing.

People, process then finally tools.

They built their methodology in bite sized pieces, then started looking at service management software tools to help them.

Not the other way around.

You can get updates to this blog by clicking the RSS icon on the Home Page!

ITIL,SaaS, And Blood Red

Posted by on December 29, 2009 2 comments

Confession, When I read the post I reference below, the title reminded me of a tune by a fave band of mine, the BoDeans, So I stole the title for this post from a song of theirs titled; Black, White and Blood Red.

Anyway, I have written before that ITIL is a framework of best practices, it is not a follow the dots prescription that every business can use to do things the same way.

As a rough analogy, a recipe presents you with each ingredient, their order of mixing and a required temperature that will provide a consistent result for everybody that uses it. Whereas the ITIL processes present a recommended end state, with some guidance on methods that can help achieve it, but like a football game, the individual plays can be different for each business.

In this post titled SaaS and ITSM – a Marriage Made in Acronym Heaven? Stephen Mann takes a fairly deep look at some research on the delivery of IT Service Management (ITSM) via Software as a Service (SaaS) rather than on premise tool sets.

Note that if you are just getting your feet wet improving ITSM, Mr. Mann’s post is pretty high level. However he presents one good lesson I never thought of, that lesson is that since every business may have a different ITIL path that they are following, care has to be taken when choosing tool sets that the tool can fit your internal processes. As Mr. Mann states;

In Butler Group’s opinion, a SaaS solution must be architected such that the customer is able to self-customise its ‘application instance’ (to reflect in-house processes)

This is a good thing to watch for as beginning a journey towards improving ITSM is hard enough working on improving your own processes, without adding the complexity of being forced into someone elses process models.

UPDATE: Christopher Dancy pointed to a much more in depth look at SaaS & ITIL here; http://www.servicesphere.com/blog/2009/6/4/saas-30-and-itsm-match-made-in-heaven.html

You can get updates to this blog by clicking the RSS icon on the Home Page!

The Definition Of Insanity

Posted by on November 19, 2009 No comments

Can be defined as doing the same thing, the same way every time, and expecting the results to change. (try W. Edwards Demings’ red bead experiment!)

Building a process oriented business is not a set it and forget it operation. It is defining and monitoring the desired outcomes. And identifying that if a desired outcome does not happen, that you have an opportunity for improvement.

In other words, if the desired outcome fails, what can we do to reduce the risk that it will fail next time?

In talking about process, you need to look specifically at what breaks. You need to look at the why, and the how of what went wrong. Is it a people problem? A process problem? or a system problem?

(within the context of ITIL I give some samples starting in this post titled; ITIL And The SMB Part 3; Incident Management)

Although please note that you do not need to go the ITIL route to become more process oriented.

It can be easy to overlook;

When something fails, there is an associated cost. That cost could be rework, lost time, maybe even lost business. Costs can be soft as well, for example, reduced customer satisfaction.

As an example of improving process efficiency, the large package delivery companies load their trucks in a first-in, last-out manner based on the drivers delivery route. This simple step reduces the amount of time finding the correct packages for offload at each stop, and reduces the risk of missing something. And of course missing packages can negatively affect customer satisfaction.

The More Things Stay The Same

When you start building a process oriented business (not just as an IT function) there are two critical pieces to start with;

1) Define the optimum outcomes. A process is nothing without a business outcome. This defined business outcome is also the measure that you can use to improve and monitor your processes.

2) Continually monitor and improve your processes. There are always opportunities for improvement. There is an old saying in music, that the spaces between the notes are just as important as the notes themselves.

The SMB Takeaway

Like the spaces between the notes, process optimization often comes hidden in the areas as work migrates from one individual or group to another.

Improving them, or identifying why something did not work, you need to understand – you need to look at the what the why and the how of what you are trying to perform.

Was it a person error? a process error? a system error?

You can get updates to this blog by clicking the RSS icon on the Home Page!

WordPress Mobile