Saturday, June 15, 2013

DevOps – how to find the constraints in your IT services? Part I

http://blog.devopsguys.com/2013/06/14/devops-how-to-find-the-constraints-in-your-it-services-part-i/

Friday, June 14, 2013 11:44 AMDevOps – how to find the constraints in your IT services? Part IDev Ops GuysDevOpsGuys

One of the key quotes in "The Phoenix Project" was, for me, "Any improvement not made at the constraint is an illusion".

"Any improvement not made at the constraint is an illusion"

The logic is clear – any improvements in delivery upstream from the constraint just causes more work to queue up at the bottleneck constraint, and any improvement downstream just means more idle time for the downstream resources as they wait for work to be released from the bottleneck.

So, how can you identify the constraint(s) in your IT services?

Well, in the Phoenix Project is obvious – the constraint is "Brent", the uber-geek with his hands in every project and too much un-documented knowledge in head. However, in your organisation the constraints might be much more subtle and may need a more methodical investigation to uncover.

I am sure that the business process re-engineering and Six-Sigma experts out there have a wealth of methodologies to discover these constraints, but the purpose of this article is to outline a pragmatic approach, derived from first principles, that you can use to get started. (p.s. if you ARE a business process re-engineering and Six-Sigma expert please feel free to point us to relevant techniques and models via the comments!).

Where should you start? Clearly, your focus needs to be on those IT services (people, process and technology) that are key to your business success and contribute the most to your organisation's strategic objectives. (BTW one of the other key lessons from the Phoenix Project was how many "mission critical projects" actually had no real linkage to the company's strategic objects or business plans).

So, step #1 is to dig out your organisation's annual report and most recent strategy presentation and make sure that YOU know clearly what the organisation's goals are. This is your "BS filter" for the rest of the rest of the process… if someone complains about an IT service but can't link that service or project back to a key business objective then put that one the bottom of the pile!

The next step is to do a bit of exploratory research with your key business users (note, business users, not IT staff!) which should quickly provide you with a list of "Top Ten IT services that get in the way of the business success". This list might include services that you DON'T currently deliver e.g. "if we had a more flexible and responsive laptop support team e.g. "like a genius bar" where our mobile sales teams could get their laptop problems fixed fast and get back on the road selling to our customers.".

Step #3 is to try to validate these subjective opinions with some objective data.

Now, assuming you have some type of helpdesk logging system you should have a ready source of data about the performance of your key IT services. If you DON'T have some form of logging tool then find a way to start logging your work, immediately, even if it's just one big shared Excel spreadsheet. Personally, I like Service-now.com and have used that very successfully at a number of sites but the key point is "you can't manage what you can't measure" and to have any hope of demonstrating improvement you need to be able to measure the before & after impact of whatever changes you make.

"You can't manage what you can't measure"

What sort of things can you look at? Well, things like which tasks/services/processes are used the most? Take the longest? Breach the SLA's the most (days overdue)? Who in your team has the most items assigned to them? Which systems/services have the lowest availability? All of these (and many others) should start pointing you in the right direction for things that need improvement.

So, now you have a list of the stuff that's most important to the business, backed up with objective data about how frequently the issues might occur, how many users are impacted and that should enable you to make a first pass at what's important and where to start first.

So, write them up on cards, stick them up on your Kanban Board, and move your top pick to "in progress" and start working on the detail of finding and fixing the constraints in that service.

How we'll do that step will be in Part II!

-          TheOpsMgr

 

Photo: Flickr/bjornmeansbear


 


No comments:

Post a Comment