Monthly Archives: July 2012

Are we

If you aren’t asking these questions rest assured someone else is….

  • Are we secure?
  • Are we mature?
  • Are we running OK?
  • Are we compliant?
  • Are we relevant?
  • Are we delivering?
  • Are we a barrier?
  • Are we too slow?
  • Are we included?
  • Are we coping?
  • Are we supporting?
  • Are we innovating?
  • Are we firefighting?
  • Are we resolving?
  • Are we in trouble?
  • Are we irrelevant?

How many YES answers? If we answer NO then what do we say NEXT?

What about these killers?

  • Are we THE PROBLEM?
  • Are we THE SOLUTION?

Oh and did we decide who is asking these questions? Perhaps they are sitting across the corridor and just because they haven’t actually asked us these questions doesn’t mean they aren’t thinking it 🙂



When something breaks in the cloud

I had an interesting exchange with one of my blog followers about Service Desk, DNA and Cloud.

They were making the point that at the end of the day one of the MUST HAVE outcomes of moving to the cloud is that IT Service MUST improve. It is a given. No negotiation. There is no place to fail. Jobs will be lost if cloud delivers a worse service. Pretty obvious of course.

They went on to say in their industry ( retail banking ) that reducing time lost to IT outages is the be all and end of all for measuring IT performance.  Time is money after all. Again no secrets here. They have very mature KPIs to measure IT service and now they are moving into the cloud with a lot of their backoffice services and front office value adds ( like a BYOD pilot of 5000 staff ) the one thing that stands out the most is how they monitor and report on FIRST TIME FIX. This embraces the end to end experience and knits together issues with end user devices, networking, back end and application interfaces. The true all up service delivery model.

Now First Time Fix was traditionally a KPI borne out of the break fix maintenance world where an IT supplier was monitored ( and paid on ) their ability to fix ( first time ) a printer, a PC or backup device. This ‘number’ became the focal point of monitoring a service contract and Service Delivery Managers were incentivised on achieving a higher first time fix ratio. it was the be all and end all.

It struck me therefore that these three words really do sum up the world of cloud from a service delivery perspective. Assuming a cloud decision is meeting the functional aspect of the service i.e a cloud CRM meets the sales and marketing outcomes, a Cloud DR solution meets IT governance, a cloud Business Process solution meets operational strategy and so on, then the day to day measurement must come down to this question – “when a problem arises (with the cloud ) how long does it take to not just fix the issue but resolve the issue for good ( first time fix ) .”

Trawling through IT helpdesk call logs is not a task for the feint hearted as one stumbles across repeat culprits from a user and IT ops perspective. You know the underlying issues that never go away. The little work around that gets the user back up and running but never gets resolved. A little like counting up all the pennies you find behind the couch at home, or collecting all the vouchers from the supermarket, these little repeat visitors can add up to make a bigger difference ( often negatively).

Performing a search on First Time Fix and Cloud does not reveal a wave of content around the paradigm shift for measuring this facet of IT service. I wonder why this is the case? Perhaps because the worlds of hardware maintenance and cloud service delivery are worlds apart,  leading to totally divorced discussions across IT suppliers. And for sure the two worlds are probably running separate distinct parallel streams that do not easily come together. For now. As the device market changes however to cloud based delivery the reliance on First Time Fix of the actual device will dissipate and the focus will shift to how IT Service Desks monitor and provide a similar high first time fix ratio for the end user 24X7, device independence, location independence and application type.

What is an acceptable first time fix? In the break fix maintenance world I hazzard a guess that 70% or higher is acceptable ( 7 printer call outs are fixed first time without the need for a second call out ). For a traditional IT Service Desk the figure may be lower ( 50-60% ) where the range of calls are varied and subject to ‘user intervention’ that generates a follow up call. But for cloud services? Surely the ratio will be a lot higher ( more than 80% )because the mistakes are fewer and the scale and resilience of the cloud platform reduces margin for error and logically reduces the number of errors and downtime situations. True or false? Interestingly because now the end to end journey for the end user is now blending old and new i.e. I may still use a 4 year old PC to access my cloud application, there is still the opportunity of the service not meeting this higher expectation of first time fix. The PC can still have a hard disk failure, or network issue which may not be ‘fixed first time’ no matter how agile and resilient the cloud service has been designed.

However over time as the old is replaced by the new the reliance on these weaker points of access to the cloud will disappear and I envisage providing an IT Service Catalog that has exceptional high first time fix ratios. Consider your private first time fix ratio? I bet it is 90% or higher and that you can count on one hand the number of times an issue is not resolved either automatically or following a call/web chat/tweet with someone ( who you dont know ).

So Im interested ( as always ) whether people out there are measuring First Time Fix on their service desks and whether they have any evidence to back up this theory that moving to the cloud demonstrably improves First Time Fix ratios ( or not as the case may be.)


Agile is a better word than cloud

Let me indulge myself and try and demonstrate a link between the way our development colleagues lead the way by building their capabilities for dealing with the journey to the cloud, and how Service Delivery people could learn a lot.

You remember the time where managing a software project was often seen as a poisoned chalice. Scope creep, incomplete projects, limited value outcomes, disgrunted clients. The list goes on.

Big building block software projects too often started out building Solution X but ended up delivering Solution Y, but only after many months or years of effort (and cost). The infrastructure alone was a huge investment – storage, licenses, networking. However, clients became disastified and looking for a more agile and guaranteed way of getting their software built. Alignment to business goals was a dream – too often shattered by delays and bugs.

Step forward the Agile software development group of software development methods like Scrum, based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative ( business Stakeholder ) and any interested stakeholders as observers. In a brief session, team members report to each other what they
did the previous day, what they intend to do today, and what their roadblocks are. This face-to-face communication exposes problems as they arise. These meetings, sometimes referred as daily stand-ups or daily scrum meetings, are held in at the same place and same time every day and should last no more than 15 minutes. Standing up usually enforces that rule. Easy to use tools like PostIT notes can track the progress of this process that is easy to understand and drives behaviour.

Now consider cloud and the world of traditional IT  service delivery. How do they approach infrastructure projects? Not the same poisoned chalice surely? Perhaps 20 years ago it was not so but maybe it is now as we still face big building block infrastructure refresh projects that takes a lot longer to get signed off and even longer to come to fruition. Of course we still need them ( cloud isnt a panacea ) but there is a view that too often Infra Project X ends up delivering Infra Project Y just like the software projects of yesterday – some would call it like the old Waterfall approach. And whilst all this heavy lifting work of networking, storage, desktop refresh goes the cloud is becoming the analogy of Agile Software Development. Short sharp timeboxes of activity that encourages rapid and flexible response to change.

Remember also the big infrastructure necessary to support these application projects? Well the developers are already in the cloud using PaaS environments like Heruko, Appscale, Windows Azure, AppEngine.

Why is this important? Well for many IT operational and service desk teams the penny is still to drop. This word Agile spells an end to the traditional approach to deploying infrastructure – time consuming, costly, inflexible to changing requirements, inability to cope with busienss change. Oh and
it gets worse. Even after the infrastructure is deployed the organization’s ability to fulfill IT service are too often handicapped because of lack of training, skills transfer, time or full understanding on what the infrastructure was supposed to improve with delivering Better IT Service.

You see Im pulling this post back to the whole IT Service fulfillment debate where the DNA of a service desk ( ops team ) is challenged daily with delivering service that now spans cloud and internal infrastructures. Time is now of the essence. Businesses now need speed. Gen Y want their own
devices. Software needs just to be available without complex processes to jump through to get working. Talk of weeks to set something up ( even days ) is met with stony silence and disappointment. People want what they have been used to getting from software teams. Timeboxed, agile progress that delivers better IT service. Responsive, demonstratable and for a fair price. But can Infrastructure become the new Development team? Well there are some pressures as well all you – Self-service helpdesks. BYOD. Cloud file systems.Network visualisation. All agile approaches that are becoming mature and mainstream.

Again a word of clarification. I am not suggesting infrastructure and IT service is given up the cloud. Im not recommending an unconscious migration to the Public cloud vendors.What I am suggesting is that some best practices from the Agile development world can have a part to play for IT teams.

So what to do? I would befriend a developer and learn a little more about Agile. Believe me there will be some useful advice to help you work through your Service Desk DNA challenge and I reckon you will be better placed for the cloud journey. And remember when I say Cloud – I simply mean delivering BETTER IT – which is after all what the business wants. If it means you have to move everthing to Google then so be it. if it means you need to build your own private virtualised cloud then so be it. If it means you stay as you are but deliver more responsive IT then so be it.

Cloud is not the answer nor the question.
Agile is the answer to the question.



Visualization in IT is the new news. Well it is for me because it gives me a chance to bring out my old friend  – the Rubik Cube – so I’m going to give it another airing.

Here’s the thing. Or the question.

“How do I move to the cloud and yet deliver a better IT service than ever before for a lower operating cost”. Got the answer?

Try it this way round.

“How do i take all my issues, worries, projects and barriers and turn them into a something I can visualize as a way of explaining to others the way forward?”

Completing a Rubik cube ( or in my eyes the job of solving IT transformation from traditional to cloud ( or more relevantly from good to better/best IT service ) can be achieved in two ways.

1. The eyes closed, frantic,  random, heroic ‘fiddle with it and eventually it will be solved’ approach











2. The algorithmic, methodical approach following a series of small changes (with constant check and recheck)











Have you tried both ways? Like me I bet you have tried the first way more times than the second. Why? Because its fun to try and crack the cube in this frantic guns blazing approach . Because you believe its cool and if you by magic complete the puzzle all your friends will be amazed and your stock will shoot up a few notches. Hero aren’t you?

Now hold this thought and apply it to your IT operation. Sure you have a 3 or 5 year strategy. You have to have one of those. Corporate governance demands it. It will probably be an impressive Word document or PowerPoint slide deck. However if you are honest every day seems like a battle to complete a new Rubik Cube puzzle as you blast away at issues that you thought you had ‘solved’ yesterday.

Every day you do this (or your IT teams do).  You ( they ) excel in this environment.  Its in the job description. Everyone is used to this heroic nature. But there is a problem that is deep routed and one that may suddenly accelerate out of control ( a bit like the lights going out while you are playing with the Rubik Cube).The problem is change. Or transformation. Or simply maturity. Or more importantly it is an event occuring in the board room where you may not have a voice. It is called Cloud. This simple word is dangerous to your Rubik Cube puzzles. Cloud changes the rule of the puzzle. It demands ( via the business people ) that you solve the puzzle once and for all. It means you have to figure out a way to solve the puzzle so you can find a more worthwhile game ( or job ) to deal with. Oh and the more senior you get the more cubes you have to juggle and solve each day.

So my point is that using this childish analogy we all need to find a way to complete the puzzle in a more methodical fashion.Now you dont need to be a university professor or mathemetician to do this. All you need is a plan. Remember the Plan Do Check Action ( Deming ) approach? This is all you need. Solving a Rubik Cube is pretty much easy once you implement PDCA. What this means is that whilst you may have your long term strategy you now have a way of getting there that is pragmatic and realistic. A way that helps you knock over the low level issues that act as barriers to cloud adoption. The niggling problems that start small but then grow to massive ‘big deals’ if you dont fix them for good. I wont list them exhaustively but things like :

  • Dealing with service level contracts with cloud providers
  • Handling password management between clouds
  • Identifying and measuring IT fulfillment activities i.e. issuing new access accounts, configuring new devices, provisioning new applications
  • Dealing with problem and incident management with cloud applications
  • Demonstrating and measuring ‘performance’ end to end
  • Managing assets i.e. devices, licenses
  • Classifying services spread between clouds
  • Communicating what ‘norm’ or ‘Good’ looks like to the end user
  • Monitoring costs and working out what Per User Cost looks like now compared to before

And I have only scratched a very easy to scratch surface!!

And before you say i have yet again oversimplified the world of IT infrastructure let me say this. I do not mean literally that just by thinking about rubik cubes and how to complete them will make everthing OK. Nor do I mean that its an easy thing to do. What I am saying is that if you are honest in your understanding of where you are and where you have to get to then the Rubik Cube is an idea. It could be a game of chess. Anything really. Visualisation is slowly becoming a way of turning IT problems into something you can see, talk about and use as a way of moving ahead.

BTW my next post coming up is another slant on this evening’s rant ( and many of the others that went before it ) as I discuss how the world of application development and their Agile ways of cutting code is actually a very worthwhile example that Infrastructure people can take a lot of practical advice from.

BrummieRuss 🙂