The ITSM Diet

krispyI am undergoing a very personal transformational change right now. I am trying to learn how to eat in the real world and maintain a healthy weight. I had really let myself go.

No exercise, eating too much, eating the wrong things and not caring. The results: 360 lbs.; the inability to walk at least 50 feet without wheezing; acid reflux; and an impressive expanding waistline. I felt horrible. My body simply hurt all the time.

After much self-loathing, I made the decision to change. Now, I control my calories, carbs, fat and protein levels and I get 60 to 90 minutes of exercise in a minimum of 5 days per week. I made my health issues a “big rock” in my life (see Stephen Covey’s “Put your big rocks in first”).

The results: I currently weigh 320 lbs., I’ve lost 4 inches on my waist, and I feel a heck of a lot better.

The funny thing in all of this, people keep asking me what “diet” I’m using. Okay, here it is –  I eat less, make better food choices, and exercise as much as I can. Disappointed with my answer? I find that many folks are looking for me to give them some “magical” advice like “oh, I lost the weight by following the Krispy Kreme diet”. There are no silver bullets. You have to eat right and exercise.

So, what’s the point in relation to ITSM?

The point is this; you must build and follow a plan for an ITSM initiative to work. There are no simple solutions or silver bullets to make adoption easy. Be prepared to work hard, suffer some failures, learn from those failures and iterate, just like you do with a diet.

In order to be successful in ITSM adoption (or in your diet) I recommend following the key “exercise and eating” tips and advice listed below.

Don’t fall for hype

“Just follow our simple x step plan every day, and we’ll guarantee you will lose weight”

I’ve seen ITSM blog posts and consulting statements that indicate the same thing “…just follow our advice and you’ll be doing x process in no time” or “buy our product and we guarantee you will be ITIL compliant”. If it sounds too good to be true, it probably is. Any offering of a “quick fix” probably will not work. Think about the long term and what you want the program to achieve. Learn good habits.

Always evaluate

I don’t do “diets” but there are items within the multitude of diet plans out there that do make sense for for certain individuals. ITSM is no different.

If something works, adopt it. If it doesn’t, forget it. For example, Problem management as detailed in ITIL® doesn’t fit well with how my organization works. We therefore adopted LEAN 8-step method as the primary way to execute our problem management but use the information in ITIL® to ensure our process is as robust as needed.

Build a plan that works for you and helps you achieve your goals

There are many ITSM frameworks out there and no rules that say you have to use a specific one. My advice is that you read, learn, and research.

You may need to use ITIL®, LEAN, COBIT®, USMBOK®, and/or combinations of the aforementioned to build your plan. Don’t do something just because someone else says you should do it. Know what you are trying to achieve and select the appropriate framework to work toward it.

For example, my company uses many different frameworks along with ISO/IEC 20000, with ISO/IEC 20000 as an indicator of “world class” IT operations. Despite this, we have attempted on four different occasions to start the adoption process for Configuration Management. What we found is teams did not understand what to do with CIs or how to move them through a change process. We therefore took a step back and spent more time looking at our Change process, and are now starting to have tabletop discussions on moving a CI through a change.

In doing this exercise, we found our teams had different execution of change, different ideas on what a CI is, and different ideas on how to move a CI through a change cycle. These discussions gave us the opportunity to drop back and review all the frameworks for a “good fit” to help accelerate what we do.

If the plan is not working, change it

When exercising, eventually your body can become use to a specific exercise and become efficient in the activity. At that point, you can continue doing the same thing, but the results will not improve. An ITSM plan is the same. If your plan is not getting the results you desire, mix it up and try a different approach. Focus on a specific aspect and find the change that helps you get the results you need.

During the adoption of incident management at my company, we had team members onboard who had been doing incident work for many years and yet our design process kept missing key steps we needed to fulfill ISO/IEC 20000 requirements. Clearly we needed a different approach and so we went back to the beginning and built a checklist of items that the design team needed to complete prior to submitting deliverables. This helped us to identify the missing steps and fix the design process.

Measure

When it comes to exercising and being healthy, my FitBit gives me all types of data to help me determine if my behaviors match my plan. Data helps us measure where we are against our goals, which is important in any ITSM initiative.

What you measure is up to you, you cannot allow others to dictate what data you need to collect. Identify your goals, and collect and analyze data that helps you reach those goals.

At my company, we ask our service owners to identify “pain points”, the place where their team or their customers indicate something in the process doesn’t deliver the promised goods and/or causes them problems. We have found that focusing on a few key measures and “pain points” leads the service owner and their teams to think more holistically about the service and why they are doing what they do. This organically leads to continuous improvement, brainstorming and discussion about user experience.

Keep the goal in mind

It is easy to get discouraged when you go a couple of weeks without losing any weight, and the same is true in ITSM. Don’t lose sight of what you have done and where you are now.

Sometimes it may seem easier to follow the same path as you always have and get the same (bad) results to achieve quick “outcomes”, but how does this help overall? Remember, incremental improvements over time lead to reaching goals.

Relax

One of the toughest issues I have with weight loss is overthinking the situation – I can become my own worst enemy. The same is true with your ITSM plan. Work the plan you built, and if something doesn’t work so what? Try something new! Be mindful of your situation and don’t be afraid to change. It will all work out in the end so just remember to breath and relax.

And a bonus tip!

Be as transparent as possible in any ITSM initiative or project, routinely discussing your success, failure, trails, and tribulations. This will help you to stay grounded and on top of where you really are in your process/project. Use your measurements to remind yourself and others of the progress you have made and make sure you understand the deliverables and timeframes.

Final Though

ITSM adoption, just like maintaining a healthy lifestyle, can be tough. It takes planning and execution, measurement and analyzing data, and it also takes support. Remember, don’t fall for the hype; always evaluate; build a plan that works for your situation and change it as required; measure your progress; relax; and always keep your end goal in mind.

Image credit

Applying Agile principles to Service Management

rabbits
“A man who chases two rabbits catches none.”

Regular readers of my blog on The ITSM Review, or over at ScrumProUK know that I enjoy exploring the gap between the worlds of IT Service Management and Agile development methodologies.

Today I wanted to go back to basics, back to square one and start over by explaining why you – as a reader from the world of Service Management or corporate IT – should care about Agile principles and what it can bring to your organisation.

I’m glad to see one commonly held misconception being broken down and disproven recently. The assumption that an organisation cannot be both Agile and IT Service Management orientated.

Even the oldest, most stubborn and most skeptical of Agile critics (his words!!) are coming around to the idea that an organisation that can excel at both disciplines. Hurrah. There is a growing Google+ community dedicated to it – Kamu: Uniting DevOps and ITSM.

To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.

Focus

“A man who chases two rabbits catches none.” ~ Roman Proverb

A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.

By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.

Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?

How can Service Management teams adopt the Agile principle of providing focus for their teams?

Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.

By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.

Alignment

“What if we found ourselves building something that nobody wanted? In that case what did it matter if we built it on time and on budget….” ~ Eric Ries, The Lean Startup

Agile teams work with the principle that plans will change; that we will understand more about the work once we near completion and that no amount of planning really prepares us for the road ahead.

This is true for software development projects where Agile is accepted but of course it’s also true for IT maintenance and operational projects too. How many of your projects delivered exactly as predicted on day one?

Knowing that business requirements will change frequently and that the assumptions made before work begins are normally wrong, Agile teams handle this by working in iterations.

By planning months into the future with “just enough” detail and by focusing in granular detail on only the next 2 week sprint, a team can easily absorb changing business requirements.

By meeting with the business on a frequent basis, by examining the overall plan (in coarse detail) and by re-prioritising against the current business requirements Agile teams achieve alignment with the business. They can plan for the next iteration in detail knowing they are working on the most important thing based on todays knowledge.

It’s no use being perfectly aligned at the start of the project and not having a system to cope with the ever changing demands. Changing requirements in a project are a good thing – it means we will have a better solution in the end.

Do your IT project teams try and control changing requirements… do you welcome them?

How can Service Management teams achieve alignment with the business?

By structuring work so that teams can focus in the short term but change direction to react to business demands. For Service Management teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.

Artful making

“I don’t test my code often but when I do I do it in production” ~ Internet meme

Earlier I mentioned Focus as a principle of Agile teams and that by concentrating on a small subset of work that is most important to the business we can train teams to deliver. Rather than having lots of work open and diluting the teams attention.

There’s another benefit in limiting Work In Progress with regards to quality engineering. Imagine a team that has no control over its work and everything is urgent. The team has no Focus and no Alignment with the business – no understanding of what is truly important.

That team is likely to produce low quality work. By trying to complete everything at once they’ll often do just enough to call it done. This results in risk lurking in your infrastructure; the worst kind of work that will leap out on you when you aren’t expecting it. Work you thought was done… but isn’t. Rework!!

Agile teams use the system of limited WIP as well as technical practices and standards to get work done once so they can move on to the next task.

Could you improve the quality of work by defining standards and shielding your team by limiting work in progress?

How can Service Management team promote artful making?

Have a “Definition of Done” for common activities. Not a huge, heavy operations manual that no-one will ever read but a collection of one-page definitions of what it means to be done with a server build, a software installation, a Problem ticket.

Make the definition of done visible and easy to use, your engineers will know when they are finished with a piece of work before moving on.

Self-organization

“None of us is as smart as all of us.” ~ Kenneth H. Blanchard

The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.

The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.

Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??

Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).

Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.

Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.

How can Service Management teams become more self-organising?

I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.

This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.

Rhythm

“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley

Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.

elvisBecause they focus on a subset of all possible work and they have quality standards they can deliver work of a high quality which deepens that trust.

Short time-boxes focus teams on an objective they have to meet – by self-organising they control the scope of work that is achievable within that sprint. When I started delivering work to a company using Scrum I asked my stakeholders which attribute of the work they valued most.

Was it the speed or the volume of work, or the number of features we delivered? No – organisations rely on predictability and working in set time-boxes, or sprints, makes your team predictable.

Compare this to projects that defer the delivery of value until the end of the project. Rather than release early and often they buffer the features and aim to deliver all in one large batch.

If that deadline is delayed two unfortunate things happen – firstly trust between the team and the business is eroded. And secondly the value represented in the features that are done but not released cannot be realised until all work is delivered.

Do you have a trust between the IT organisation and the business which is built upon a rhythm of regularly delivered work?

How can Service Management teams get that sense of rhythm?

I love the idea of working within constraints. It focuses the mind and makes people be creative. Even if you don’t work in software engineering define a series of 2 week “sprints” for your Service Management team.

Declare an objective for the two week sprint – “we are going to reduce the incident backlog to under 50”. Let the team self-organise and think about your teams objective for the next sprint.

In summary

Thanks for Tobias for his 5 attributes of Agile teams that I’ve expanded and commented upon. My aim here was to outline the benefits of Agile to teams outside of the world of software development. I hope that readers that work in IT Operations and engineering can compare the way they work currently against these ideals – all of which are simple and cheap to implement and realise.

Ultimately the ideas of focus, alignment, artful making, self-organisation and rhythm promotes a culture of learning – about the work you handle, about how the team performs and how you interact with the business.

Combine these 5 principles with the idea of regular, structured retrospection and I think you are well on the way to having a highly performing team.

I would love to have a discussion with you in the comments or on Twitter. Or come to the Kamu Google+ group and discuss with your peers there.

Image Credit 1

Image Credit 2

Taking a look at OBASHI in action

In this second article we’re going to look at how OBASHI fits in with other IT frameworks, standards and methodologies. If you missed part 1, read it here.

The modern business is a complex organisation. People, technology and processes work together to generate revenue and deliver business outcomes. Many businesses do not have a full picture of how all their component parts fit together. This creates risk, and can lead to real problems. OBASHI produces Business and IT diagrams (BIT diagrams) that are used to map business processes.

ownershipbusinessapplicationsystemhardwareinfrastructure

 The OBASHI layers of ownership, business process, application, system, hardware and infrastructure show the business process and the IT that underpins it. 

OBASHI can be applied to small, medium or large organisations. Larger organisations will need to factor in the number of stakeholders and the complexity of their processes and services when scoping the OBASHI project. They may benefit from using a tool to create the OBASHI outputs.

Smaller organisations will have fewer stakeholders, but may have more single points of failure in their processes as one person can have many roles. They may be able to produce their OBASHI outputs manually using paper or a simple flow chart application.

If you’re from an ITIL background, it’s tempting to look at OBASHI and think “oh it’s just configuration management”. This isn’t true – OBASHI includes the bigger business picture as well and supports conversations outside IT.

OBASHI in the wider environment

The decision about whether to adopt OBASHI shouldn’t be over-complicated.  It’s not an either or decision – if you’re already doing ITIL, or COBIT, or ISO20000 you’re not going to throw away what you’ve got in order to adopt OBASHI. Instead, view OBASHI as a complementary methodology.

OBASHI will take inputs from your existing environment – if you’ve already got a service catalogue, or an asset register, then these will feed into your OBASHI project.

OBASHI diagrams can be tailored to the audience as required, masking complexity where it’s not needed and helping to make accurate business decisions quickly.

OBASHI and ITIL

I know a lot of ITSM Review readers are from an ITSM background, so it’s worth looking at OBASHI and ITIL in a bit more detail. From an ITIL perspective, Service Strategy and the processes it includes help an organisation to create and manage a service portfolio that will meet long-term business goals. The business and IT diagrams that OBASHI creates can help the organisation to prioritise investments, plan based on accurate information, and make sure IT services align with business processes.

In the Service Design lifecycle stage, new and changed services are designed. These services must meet business requirements for quality and cost, and must not have any unexpected negative impact on existing services.OBASHI can help to identify cost savings where existing services and components can be re-used, where appropriate.

Service Transition is the lifecycle phase that moves new or changed services into the live environment. OBASHI can help organisations to map their current state and also their desired future state.Change impact assessments can be carried out quickly and easily using the diagrams that OBASHI creates.

In Service Operation, live services are operated and maintained and support is offered to the business when incidents occur. OBASHI models can show the impact of downtime, who needs to be contacted in the event of downtime, and the cost to the business of a loss of availability. If customers can see we are working effectively to get them back online, we can maintain customer satisfaction – even during an incident.

The continual service improvement stage of the ITIL service lifecycle looks for improvement opportunities related to services, people, processes, structure. It’s well accepted that we need to understand something before we can improve it, and OBASHI helps to provide that understanding of the organisation.

“Premature optimisation is the root of all evil” Donald Knuth

OBASHI and Projects

Many organisations have a mature project management capability.  OBASHI can provide support during the key stages in a project’s lifecycle, including:

  • Forming a project board
  • Writing a business case
  • Risk and quality management
  • Communication
  • Project planning
  • Project closure

OBASHI diagrams help to identify stakeholders, map current and desired dataflows, and are inputs to project planning and impact assessment. OBASHI supports project management and helps projects to deliver on time, on budget and at the right level of quality.

Getting Started with OBASHI

So, who should use OBASHI and why?

The short answer is, any type or size of organisation that wants to understand and optimise their dataflows.

Think about these statements:

  • Our organisation struggles to prioritise investments
  • Our risk and impact assessments aren’t based on accurate data
  • The business thinks IT doesn’t understand them
  • The business sees IT as a cost centre, not a valuable part of the organisation
  • We need to make cost efficiencies
  • We’re adopting Green IT/virtualising our infrastructure
  • We’re struggling to manage legacy applications/technology

If any of these relate to your organisation, OBASHI is going to be a very useful addition to your toolbox. It’s the only methodology that creates a common picture for the business and IT to work from.

Resources

To learn more about OBASHI, you can visit the official OBASHI website, where you will find some excellent case studies and presentations that you can tailor to your organisation.  Additional resource can also be found on the training website. The OBASHI training scheme is run by APMG International, and Foundation training is available both in the classroom and online.

You can view the list of OBASHI training providers online and also read up about the formal certification.

OBASHI® is a registered trademark in the United Kingdom and other countries

ITIL is a registered trademark of Axelos Ltd

PRINCE2 is a registered trademark of Axelos Ltd

 

And the winner is…

kindleWe recently gave all you lovely people the opportunity to win a Kindle Fire in return for writing a review on

Rob England’s (a.k.a ‘The IT Skeptic’) latest book “Plus! The Standard+Case Approach: See service response in a new light”, and today is the exciting day when we announce the winner!

With all of the reviews in, Martin Thompson took his place at the judging table and began reading through the submissions. I had to tell him twice to remove his grey wig and remind him he was judging book reviews not auditioning to replace Judge Judy, but we got there eventually…

A massive congratulations to…

The winner of our competition and proud new owner of a Kindle Fire – Karen Ferris!

Karen’s review was chosen because it gave the most succinct description of the Standard+Case concept, a summary of the book and a reason for reading it.

The Review

I must admit to being sceptical (no pun intended @theITSkeptic) when Rob started to talk about the Standard + Case approach, and the use of ‘Case’ when faced with incidents, requests, changes etc. that we do not have a ‘standard’ model for dealing with.

I couldn’t see that handling these situations, as a ’case’ was different to how most of us manage this today. However, having read Rob’s book, the penny certainly dropped! This book is an eye-opener and a must-read.

Rob is not proposing that Standard + Case (or S+C) is a new practice but is an approach for formalizing what happens today when there is no formalized approach available.

This book describes the rigour required when dealing with response situations so that all instances of service response are managed, reported and improved – not just the standard ones. We often have models or procedures to deal with the things we have seen before and know how to deal with. We have categories, workflows, checklists and templates etc. We have the guidance provided by ITIL. But what happens when we are faced with a situation that is unfamiliar? As Rob says, what happens when we fall into that fuzzy cloud that says ‘resolve it’? ITIL gives some guidance for these situations within Problem Management but goes little past root-cause analysis. This book fills the gap.

What is also exciting about this concept is the use of gamification to offer challenges to service desk personnel and the ability of S+C to provide a career path for service desk personnel within the service desk. This has been a challenge for most, if not all, service desk managers who see staff come and go as the service desk is just seen as the doorway into the rest of IT.

I cannot recommend this book highly enough to anyone involved in situation response. It is an easy read and Rob provides a step-by-step approach for adoption of S+C as well as a S+C Tale, which we can all relate to, and brings S+C to life.

As Rob states in his first chapter, “The Standard+Case approach will improve your service response without a great deal of impact or investment in your current ITSM practices and systems”. This is why everyone should consider S+C.

This is a game-changer and I think Rob’s best work yet.

Thank-you Karen for your review both from us at ITSM Review and from Rob, we hope that you are your new Kindle Fire will be very happy together.

And to all the others…

I’d also like to take this opportunity to thank everyone else who participated and got into the community spirit with this competition (ok so maybe you was all doing it for the Kindle Fire but we’ll pretend otherwise…).

A thank-you also from Rob, not just for writing the reviews, but but for taking the time out to read his book in the first place and for recommending it to colleagues and peers. By helping to share his ideas hopefully more will implement them within their businesses and ultimately improve their approach to IT Service Management.

And finally…

If you haven’t read Rob’s book yet then not only did you miss out on the opportunity to win a new, shiny technology gadget but you’re also missing out on some great insight and advice.

Don’t just take it from me either, I’ll leave you with some other quotes:

“If you are quite new to ITSM or have not yet been fully converted into an ITIL ideologue this book can be nice introduction to an alternative, the author may say complementary, method to ‘process’ management.” – Stephen Alexander

“While not specific to IT, if you are an IT manager, CIO, Service Desk manager etc. etc. read this book and look to embed a Standard + Case approach into your IT organization.” – Mark O’Loughlin

“After you have read this book you will have a good ground and recommendations for how to manage Standard+Case covering pointers for how to think considering tools, policies, classifications, strategies etc. it’s a must for anybody that wants to take the next step in support evolution.” – Mika Salo

Plus! The Standard + Case Approach: see service response in a new light is a fast, complete and clean read introducing Standard + Case approach by Rob England.” – Rui Soares

“The important thing that Rob teaches us in this book is not about the existence of Standard and Case… we knew this since a long time ago in ITSM. The important concept is that we need structure, policies and resources properly balanced to manage both kind of responses, instead of keep trying to use a single set of policies, procedures and tools for everything.” – Antonio Valle

“It’s a good read and recommended to anyone involved in IT support and perhaps those involved in non-IT support. Are you prepared to become more effective?” – Stephen Mann 

“I would encourage strongly giving Rob’s model a try if you are struggling to get organized in the service response area.” – David Lowe

“I will be using many of Rob’s ideas as I work with my customers, and I recommend that you do the same.” – Stuart Rance

Image credit

The $6BN Gorilla

One of my personal indicators gauging the success of an enterprise software vendor in a market is the ‘grumble factor’.

This is an anecdotal measure that says – you can usually tell who is doing well in a market by the volume of other vendors grumbling about them. Successful vendors in the ascendancy are often accused of being ‘aggressive’, ‘discounting all over the place’ and ‘killing the market’ etc.

This is certainly the case for ServiceNow. One close competitor named them ‘The Gorilla in the market’.

On a recent analyst call with Frank Slootman, President and CEO of ServiceNow, we learned that the Gorilla is now weighing in at healthy $6BN market cap on the NYSE scales. Mummy Gorilla is very proud.

Summary

  • Last quarter revenue $102.2 million, 80% increase compared to the second quarter of 2012, and an increase of 19% from the first quarter of 2013.
  • Added 138 new customers in the second quarter, 1,778 total, customer renewal rate of 94.2%
  • ServiceNow were not in the black for the quarter. All resources are said to be feeding the machine.

(Source)

ServiceNow have slowly doubled their original entry price of $18 [See image below].

ServiceNow Stock price since IPO, June 29th 2012 (NYSE: NOW) Dowsing Rods say go long.
ServiceNow Stock price since IPO, June 29th 2012 (NYSE: NOW) Dowsing Rods say go long.

Realistic Cap?

$6BN? Really? The scope of the market says $6BN, but do ServiceNow have sufficient competitive differentiation to warrant $6BN? It’s not like their offering is totally unique, despite what Frank might be telling investors:

“Our customers are actually frustrated because it’s tough to negotiate with a vendor who doesn’t have much competition, you know,”

Hmm.

Slootman has been keen to dress down any ‘dotcom’ hysteria over their market capitalization in recent interviews. ServiceNow are clearly not shooting for any ‘best place to work’ gongs anytime soon:

“We don’t do all the lattes and back rubs and all that. My favorite perk is high-equity value,”

The ServiceNow public listing was said to restore credibility to the technology IPO process after Facebook’s listing [See image below]. Note the recent Facebook jolt in price when it was revealed mobile ads were working.

Facebook [NASDAQ:FB] IPO MAY '12 vs. ServiceNow [NYSE:NOW] IPO JUNE '12
Facebook [NASDAQ:FB] IPO MAY ’12 vs. ServiceNow [NYSE:NOW] IPO JUNE ’12
My final hobbyist chart tracks ServiceNow versus older enterprise software industry stalwarts. Most striking is the flat green line. Medic?

ServiceNow vs Industry Stalwarts (HP, IBM, CA, BMC)
ServiceNow vs Industry Stalwarts (HP, IBM, CA, BMC)

ONNAMA (Oh no not another marketing acronym)

Frank made it clear, via their “SRM” vision that the Gorilla is done shaking the ITSM tree for now and is going to beat it’s chest in other verticals such as HR, Finance and Facilities etc. Let’s apply what we’ve learnt and use our ITSM logic in these other disciplines. I like the sentiment but I’m not convinced by the market definition. I’m not sure ServiceNow are either. Thank goodness.

“So is Service Relationship Management a new software “category” No. Or at least we think not. It’s just a term that ServiceNow is using to help customers think beyond ITSM”

Maybe we could just call it… err, IT? Have we not always done that? Let the good stuff permeate the enterprise based on solid reputation and successful execution against business outcomes, not silly definitions.

The Next Salesforce.com?

Business Insider touted ServiceNow as the next Salesforce.com. If Salesforce.com is aiming to own the mindshare of the CMO, ServiceNow has the opportunity to own the IT service delivery plumbing and mindshare of the CIO (or perhaps even COO if Bill gets his promotion). But they have plenty of competitors on their heels vying for this space.

For this journey ServiceNow will need to be a lot more ‘App’ and a lot less ‘Toolkit’. Market trends say Mr HR director wants to build and deploy his own solutions. Not get bored waiting for IT to deliver it. IT can own the plumbing, governance and can help automate but ultimately departments will want the freedom to do their own thing, building and fiddling themselves. Salesforce.com got there through the use of ‘Editions’ and converting their platform to a marketplace for niche apps to plug into.

Missing ITAM Savvy

As an ITAM specialist I was disappointed to see little mention in the roadmap around ITAM features, building on the first elements in Berlin. I look forward to looking at this in more depth. This is a significant hole in the ServiceNow portfolio.

The strategic partnership with BDNA can only be considered a short term band-aid unless it is truly embedded in the platform. BDNA have good content to offer but it’s not exactly aligned to the ‘Cloud IT Company’ rhetoric. The last time I looked at BDNA it required the install of an Oracle database and whole rack of kit to run it.

Salesforce.com swallowed up a small army of tech firms to bolster their current $26BN valuation and market dominance, I expect ServiceNow to do the same. Watch this space.

Images from Google Finance

IT Knowledge Management – Spreading the Word!

Anyone with experience in IT support knows the importance of knowledge in reducing resolution time. Anyone with math skills can extrapolate business value from rapid resolution. Despite its obvious benefits, Knowledge Management (KM) remains a frustration for a vast majority of enterprises. Why?

Because organizations continue to approach KM as a monolithic publication effort with ancillary inputs from Incident and Problem Management.

By combining principles from Knowledge Centered Support (KCS) with the ITIL framework and a few basic workflows, an enterprise with the right cultural mindset can make KM work with far less effort.

The Objective of IT Knowledge Management

IT’s need for Knowledge Management is not complex. Although ITIL lists five objectives to KM and KCS and boils it down to the “creation, use and evolution of knowledge”, this article, because of its focus on IT support, is more specific:

The objective of IT Knowledge Management is to create, maintain and make available concise and actionable information to users and IT support groups in order to resolve service disruptions quickly and respond to customer queries satisfactorily. 

The challenge is to collect, maintain, and make that knowledge accessible.

Flailing and Failing

How well are IT organizations managing their knowledge? Do support agents have rapid access to current knowledge for a vast majority of customer contacts?

Does the enterprise require waves of knowledge initiatives to address a stagnant knowledge lifecycle? Is there a group of knowledge authors scrambling to review and update solutions?  Are stale solutions common?

Gone are the days of separate knowledge applications run by a core team of authors. The monolithic approach to KM works no better today than it did 10 years ago but many organizations continue to flail about in an attempt to write the definitive support encyclopedia.

For organizations to achieve the objectives of KM, they must move toward distributed, open-source authorship.

If solution content originates at the point of problem support, where should authorship take place? This past weekend, I spent hours on the phone with a satellite TV provider trying to fix a problem on a secondary satellite receiver. After two hours, I noticed that the coax cable had a little red device on it and mentioned it to the support agent. “Oh my Gosh!”, she cried. “That device blocks the receiver from communicating with the parent receiver.  The instructions should have had me check that right away”. When I asked how hard it was to update the solution, she replied that she was already doing it. This is how to make KM effective.

One must drive content to the lowest possible level and implement a flexible, role-based approval mechanism that deploys the updated solution with minimal fuss.

Knowledge Management is Integral, Not Additional

Most organizations have implemented one or more repositories of “solutions” and most of those organizations struggle to encourage adoption by users and authors. The ineffectiveness of Knowledge Management derives from just a few basic misunderstandings:

  1. Centralized authorship simply does not work.
  2. If we look at Incident and Problem Management as recipes, Knowledge Management must be a primary ingredient rather than a garnish.
  3. Because the Service Desk is the face of IT and depends so heavily on an effective Knowledge Base, agent input must be dynamic and empowered.
  4. The Knowledge Management workflow must be flexible to support distributed authorship and review.
  5. Authorship and article utilization deserve meaningful rewards as an incentive for adoption.

To address these issues, one needs to employ a mixture of wisdom from several sources.  There are a number of standards for Knowledge Management.

So Many Knowledge Management Standards

Knowledge Management does not make standardization easy.  While this article discusses IT Knowledge Management, a standard cannot ignore the management of content and documents across the enterprise.  In general, the standards with broader scope will offer less prescriptive guidance for IT managers.

(ITIL) – ISO/IEC 20000 – ITIL’s approach to Knowledge Management is academic.  Though the inputs from Problem Management and Incident Management are clearly defined, ITIL is tentative in demanding the required participation and ITIL provides scant guidance in establishing a workflow.

Knowledge Centered Support – though not an official standard, KCS is comprehensive and its approach maps best to the real world.  KCS emphasizes that KM must be incorporated into the process flows of both Incident and Problem Management.  This paper draws heavily on KCS.

Other Standards

Though this article focuses on ITIL and KCS, there are other standards worthy of mention:

Standards Australia International is Australia’s non-government standards body and is a member of the International Organization for Standardization (ISO). The SAI publishes “AS 5037-2005 Knowledge Management – A Guide”.

European Committee for Standardization has published standard “CWA-14924″ in five parts.  Part 1 lays out a framework and basic KM steps (Identify, Create, Store, Share, Use) but is weak on workflow guidance. There is considerable guidance on project management.

British Standards Institute publishes “PAS2001:2001 Knowledge Management”, a high-level document with limited value for process design and implementation.

KCS Plus ITIL

Though ITIL is weak in Knowledge Management guidance, the overall framework encourages integration. As the document “KCS Overview” states, “KCS is not something a support organization does in addition to solving problems, KCS becomes the process for solving problems.”  While ITIL talks about inputs and outputs, KCS incorporates Knowledge Management into the processes used for solving problems. When organizations “implement” ITIL, Knowledge Management is often a separate implementation driven by the Service Desk.  As for Incident and Problem Management, the processes and tools may allow integration but typically act as feeds to the monolithic Knowledge Management team.

Because the typical implementation of Knowledge Management relies heavily on one or a few core teams of authors to generate content, the process flow includes numerous points of review and approval. Each point represents a bottleneck.

When Knowledge Management drives rather than follows the problem resolution process, it transforms itself and its dependent processes into an elegantly simple and self-sustaining engine for efficiency.

Below is the simplified workflow for solution creation (with KCS states noted):

graph1
Figure 1: Knowledge Article Creation

This simplified flow relies heavily on issue responders (i.e. Service Desk, technical support) to initiate and update the “solution”.  For this to succeed, the tools and processes of the responders must efficiently enable contribution. Furthermore, the organization must meaningfully reward such contribution.

This approach is in stark contrast to the monolithic Knowledge Management group where a small number of “authors” provide solutions to issue responders. One need only tour the Service Desk of such an organization to gauge the success of such an effort. Support personnel maintain their own notes with yellow stickies, notebooks, and heterogeneous repositories. Hop rates (call transfers) are high. FCR (first contact resolution) is low. Customer satisfaction suffers.

Knowledge Creation Baked into Incident and Problem Management

In the “Knowledge Article Creation” diagram, steps 4 and 5 are pivotal.  Within these steps, the agent must have a quick way to create or update solutions. A single tool should allow the agent to respond to calls, create incident records, search knowledge solutions and update those knowledge solutions. The approval process should be simple while allowing for variation of depth.

graph2
Figure 2: Service Desk Role in KM

In figure 2, many organizations are concerned that step 8 (Document Solution) will encumber the responder, thereby increasing service costs. In the absence of prudent guidelines, such concern is well founded. One can address this concern by limiting input in step 8 to simple solutions and updates. Anything more should be deferred to a sub-process for Solution Review (step 10). Step 10 can be distributed across numerous organizational units, allowing the responder’s department to update the solutions upon which they depend. Basically, step 8 only works if the workflow and toolset enable the responder to complete the task very quickly.

Solution Creation Reward System

Rewards, an important contributor to Knowledge Management success, are based on Key Performance Indicators such as those listed below:

  • Most articles created/updated in past 30 days.
  • Highest average user rating in past 30 days.
  • Total articles deemed “useful” by at least 90% of users in past year.
  • Most articles used to solve a problem in past 30 days.

For a reward to have meaning, it must be deemed of high value. This does not mean that it must be expensive. Although, recognition is a major component of any reward, the organization can budget for gifts such as gift certificates, parking space, cash, merchandise, CIO lunch, group outing, etc. Be creative and make it desirable for employees.

Solution Creation and the Challenge of Outsourcing

By asking support personnel to create and update solutions, some organizations introduce a conflict. When an enterprise measures the value of an agent by call volume, what incentive does the agent have to take the time to produce solutions?

There are three parts to this answer:

  • First, it may be necessary, especially for service desk agents, to limit the time spent on each solution.
  • Second, the organization can use both call volume and solution updates as measures.
  • Third, keep the solutions simple.  The “KCS Practices Guide” provides excellent guidelines on article composition. More importantly, the KCS approach relies on both “Solve” and “Evolve” to maintain article health. Thus, an agent can start the article lifecycle with a quick but readable note and later, others can enhance the article with updates.
graph3
Figure 3: Consortium for Service Innovation

Let’s look at two examples:

  1. Quick Solution Update – an agent deals with an incident where the solution is correct but the steps are slightly out of order. Without delaying the resolution for the customer, the agent has already begun the update. The call ends and the agent spends less than five minutes to complete the update. Next call.
  2. New Solution – an agent cannot find a knowledge solution for the incident but is able to resolve the incident with quick input from another source. Recognizing that the issue is likely to recur, the agent take five additional minutes (after the call) to document the steps taken during the call and submit the solution for review. If the solution is incomplete, the reviewer can prevail upon the agent or another SME to enhance it. For the agent, such work would have no impact on call volume measurement.

Solution creation becomes more complex when suppliers are involved. Although the execution remains under supplier control, the client company should provide contractual incentives (and penalties) for knowledge participation based on KPIs. From past experience, it would be prudent to measure both knowledge contribution and knowledge quality while also reviewing the supplier’s workflow to ensure capability. This arrangement often requires an additional approval mechanism at the supplier level.

Key Takeaways

This is very broad guidance.  For more detailed instructions on KM project management, I have found CWA-14924 (mentioned above) to be comprehensive.

    1. Find the Right Partner – clearly, an organization needs more than a librarian and a tool. Consider partnering with an experienced service company. Your partner should have wisdom in the areas of ITSM strategy, solution taxonomy, Service Catalog, workflow design, Knowledge Centered Support, and ITIL Service Transition. Ideally, the partner can also provide deep technical expertise for implementation.
    2. Establish a Value Proposition – yes, this should probably be number one but, frankly, the right partner makes this much simpler and will often include such assistance as part of pre-sales. The point is to build an Initial Business Case. This is not terribly complex as it is often based on call center efficiency – an area where organizations typically maintain lots of measurement data. Again, the partner should assist with supportable expectations for improvement.
    3. Build a Coalition – combined with Knowledge Management thought leadership, present the Business Case to key decision makers and stakeholders in order to build a coalition for the initiative. Although the audience will participate in further planning, the overall initiative depends heavily on the enthusiasm generated here.
    4. Design a Knowledge Management Strategy – this is an opportunity to strengthen the coalition and spread the good news. If there is consensus that Knowledge Management is crucial to effective IT support, then any strategy will address the inclusion of Incident Management, Problem Management, and Service Desk in the Knowledge Management strategy. The strategy will address taxonomy (Service Catalog, Request Fulfillment and CMDB involvement), integration and task prioritization (roadmap).
    5. Toolset Review (optional) – the KM strategy may have identified issues around the current toolset(s). Which tools support the integration with (or perhaps subordination of) Incident and Problem Management? Which tools provide a flexible workflow? Does the business case support the replacement of current tools? How will tool replacement impact outsourcing arrangements? If called for, evaluate and select replacement software.
    6. KM Implementation– This step deserves its own separate article. Aside from the usual and extensive project management advice, the following points are worth noting:
  • Develop a comprehensive Communication Plan to market KM.The KCS requires a cultural shift to a distributed and empowered communication model.
  • Provide meaningful rewards for solution creation, update, and utilization.
  • The key to success may well be the changes in Incident/Problem Management.
  • Be wary of timelines greater than 4-6 months. If that seems incredibly short, either the scope or the supplier is off track.
  • This project is well suited to an “agile” approach (iterations rather than a big push).

Conclusion

Niels Bohr, Nobel physicist, philosopher and unheralded hero, wrote:

“An expert is a man who has made all the mistakes which can be made in a very narrow field.”

As I never seem to exhaust my capacity for error, I doubt that I am an expert in much of anything. Still, this article is an attempt to share a response to a series of missteps in Knowledge Management. If you have not already done so, I advise that you at least read the “KCS Overview”. If, as I maintain, we have been wrong-headed in our KM struggles, this may help set you on a more reasoned path. We should, in light of today’s emphasis on social media, understand that knowledge increases in value as the number of synapses (contributors) increase. In essence, I entreat you to spread the word!

 

What exactly is "OBASHI"?

Obama
OBASHI has nothing to do with President Obama!

A year ago, asking the question “what is OBASHI®?” might have got you some interesting answers.  A sneeze, a martial art, and rather brilliantly ‘OBAMA bashing’ are all suggestions we’ve had.

In the last 12 months, however, I’ve seen a turnaround. OBASHI is getting recognised for what it is – a simple, easy to adopt methodology that maps dataflow through a business and supports meaningful conversations about investment, improvement, and business outcomes.

I’m also really happy to see that this recognition is coming from the folk in ITSM who actually work with the business. Consultants, outsourcers and business relationship managers are all starting to realize how OBASHI can help the business/IT conversation move forward.

Background to OBASHI

“A process cannot be understood by stopping it.  Understanding must move with the flow of the process, must join it and flow with it”.  Frank Herbert

The OBASHI methodology allows organisations to clearly understand what is involved in supporting their business processes. Simple, powerful information can be used to support business decisions, financial decisions and strategic planning.

OBASHI creates visual maps of businesses and parts of businesses. The maps are simple, visual references that can be understood by staff at all levels. The maps help businesses to understand:

  • How the business works
  • What assets and components make the business work and support its business processes
  • What inter-dependencies exist between assets
  • How data flows around the business

OBASHI produces Business and IT diagrams (BIT diagrams) that are used to map business processes (see image below).

The OBASHI layers of ownership, business process, application, system, hardware and infrastructure show the business process and the IT that underpins it.

OBASHI’s origins

“When we try to pick out anything by itself, we find it hitched to everything else in the universe”.  John Muir

The OBASHI methodology was originally developed in 2001 by Fergus Cloughley and Paul Wallis. It was inspired by the computer models used within manufacturing and process industries to control and simulate the operation of infrastructure and plants.

The costs and values of manufacturing flows can be mapped, allowing the assets that support them to be optimised in a way that encourages maximum business profitability.

OBASHI develops and builds on the existing methods for costing and valuing the flow of data in the process control industry, and applies it to the flow of data in all sectors – including IT.

OBASHI is used to “help business professionals easily understand the ‘dollar per second’ value of dataflow that supports their business services and processes, in a simple and meaningful way. OBASHI is the basis on which they can make better informed and more accurate strategic, operational, tactical and technical decisions.”

Context

OBASHI is an interesting methodology because it applies to all types, sizes and sectors of organisation. It’s not targeted at a particular audience or area like ITIL® and PRINCE2®, and can be easily understood by business or IT focused staff.

For me, the value that OBASHI brings is in the way it enables business and IT conversation.  ITIL (maybe because of its name) can be perceived as being ‘IT focused’ – OBASHI is open to anyone. I feel that treating the business and IT as separate entities is a big mistake for the modern organisation – IT runs through and enables every business action and business process.

Building up a library of dataflows mapped using OBASHI helps business and IT staff to have conversations together about risk, impact, investment, strategy and growth.

Who is using OBASHI?

Early adopters of OBASHI include one of the world’s leading Formula 1 motorsport teams and the UK’s Civil Nuclear Constabulary, but perhaps one of the most interesting users of OBASHI is the global Legal Entity Identifier (LEI) project.

obashi.jpg
OBASHI Business and IT Diagram

At the behest of G20 group of nations and the Financial Stability Board, the Global LEI project has been created to proceed with development of a unique identification system for parties to financial transactions. For the past 12 months over 100 institutions from around the world have been working together on the project.

The largest financial project in the world, the Legal Entity Identifier, is a fundamental requirement if the process of addressing the systemic risks that caused the 2008 financial crisis is to have the best chance of success. The LEI will also help participants and regulators to analyse, quantify and understand systematic and operational risk across banking and other industries.

Operating in an environment where regulators and financial institutions operate within and across different jurisdictional boundaries, each with their own unique requirements, OBASHI provides:

  • A Governance framework language for LEI policy and system design
  • A Programme Management tool to help national, regional and political variations, both technically and operationally
  • A practical, easy to create model of all the relationships and dependencies between all the business and technology components of the global LEI system

OBASHI is being used to create and maintain clarity in the LEI project – a ‘Common Language’ for technical and non-technical people, from diverse nationalities and business cultures, to understand and communicate about the project. With OBASHI the stakeholders can see how people, process and technology will be required to fit together to make the Global LEI Systems operate, this is helping them make the best-informed decisions.

When the LEI system is up and running it will be used to identify any and every participant, in any and every financial transaction globally.

Set this into a global operational context of thousands of implementations, each jurisdiction conforming to regional legal and regulatory requirements, capturing data in multiple languages and scripts, and all of that being used to update data in every other local LEI system and you start to appreciate the scale of the project.

Although the LEI project takes complexity to the next level, it’s easy to see that most businesses are becoming increasingly connected and complexity rises accordingly. Creating clarity and being able to communicate clearly will become ever more important.  This is where OBASHI is very useful.

Resources

To learn more about OBASHI, you can visit the official OBASHI website, where you will find some excellent case studies and presentations that you can tailor to your organisation.  Additional resource can also be found on the training website. The OBASHI training scheme is run by APMG International, and Foundation training is available both in the classroom and online.

You can view the list of OBASHI training providers online and also read up about the formal certification.

OBASHI® is a registered trademark in the United Kingdom and other countries

ITIL is a registered trademark of Axelos Ltd

PRINCE2 is a registered trademark of Axelos Ltd

second blog will follow on where and how OBASHI fits in with other IT frameworks, standards, and methodologies, as well as taking a look at why an organisation might use OBASHI.

This article was written by Claire Agutter, Director and Head of Online Training, IT Training Zone Ltd with contribution from Fergus Cloughley, Director and CEO, OBASHI Ltd.

Image Credit

Customers are not your top priority

TrainsThere is this myth that IT (or any service provider) should be utterly focused on customers; that a customer obsession is the secret sauce to IT success; and that unhappy customers mean we in service have failed.

Railroads don’t bear this out.

Railroads in the USA have fought tooth and nail with their customer base for decades.  After the Second World War, freight customers decided the railroads were screwing them. Government legislation progressively regulated and price-controlled the railroads into the ground, until the whole system was on the verge of collapse.  Only de-regulation with the Staggers Act in 1980 freed the railroads to operate economically again and put them back on track (sorry) to their currently-thriving state.

And now the customers are complaining about freight rates again…

Meeting the needs of the business

If railroads were customer-obsessed – as the modern fad would have it – then they would provide all sorts of specialised rolling stock tailored to their customers needs / wants.

It certainly didn’t start out that way.

Originally a customer could hire a boxcar, reefer (refrigerated boxcar), flatcar, gondola, hopper, or tankcar.  That was pretty much the choice: not tailored to the customer, just a choice of a few basic shapes. Was a hopper car or boxcar shaped that way because the customers wanted it?  No, they were that way because they worked best internally for the functioning of the railroad. All sorts of loads fit uncomfortably in gondolas or boxcars, but that is what the customer got regardless of any complaints. Automobiles were chained on flatcars and car parts struggled in and out of boxcars for decades before the specialised rolling stock came along.

As the 20th Century progressed, railroads built special rolling stock to meet customer needs: automobile carriers, the aircraft body-parts carriers, trailer trains.  But you still couldn’t really say they were customer-focused.

The trailer train is a case in point: the Santa Fe railroad worked closely with the Hunt trucking empire to develop “intermodal” rolling stock to meet a customer need: to transport truck-trailers cross-country on special flatcars.  But the trailer train design was about moving truck-shaped loads on a railroad, not making trucking easy.  They still needed to drive the trailers carefully onto the flatcars and chain them down (and eventually they craned the whole thing on!).

When railroads introduced covers for coal hoppers, it wasn’t about looking after the customer’s coal – it was because coal dust was destroying the rail ballast.  Until then the railroads were perfectly happy to have a percentage of the load blow away and the rest get wet and icy.

In recent years, railroads have realised the best profits are in large volumes of single loads in dedicated unit trains, instead of mixed freight, and as our societies have become bigger and more industrialised warranting those unit trains, specialised rolling stock has become more common: for coal, ethanol, automobiles, logs, and of course containers.

But in general, railroads have always built general-purpose rolling stock that best suited their purposes not the customers.  Customers had to make do, with some highly profitable exceptions.

Finally, the container took the customers challenge away by introducing a standardised unit of shipping and now both parties are (generally) happy, but that didn’t stem from any railroad initiative to please the customer.

Customers are the source of revenue not the masters of the business

Railroads spend billions on infrastructure development every year (most of which is not driven by customer).  A railroad will occasionally run a rail line up to a big customer, but most of the time lines are laid for geography first and being close to economic density second.  Individual customers need to (re)locate close to the railroad or arrange local freight.  If a customer wants a branch built up to their coal mine, power plant, or factory, they usually have to build it at their own expense.

Railways are as quick to cut services as to provide them, depending on their own interests.  Governments have to legislate to force railways to run passenger services, and have done so for half a century in most countries.

The fact is, railroads are focused on moving stuff as efficiently, economically and reliably as they can, with enough surplus to keep up the massive infrastructure investments, for maximum profit.  The customer is only there to pay for it all.

Airlines are the same.  While a few airlines like Emirates differentiate themselves by chasing the customer who wants to be cared for, most airlines today clearly regard economy passengers as “self-loading freight”.  Emirates has long been accused of all sorts of unfair government support; they burn petro-dollars as a PR flagship for a “progressive” Dubai.  Most airlines (and their governments) can’t afford those levels of service anymore and instead simply stay competitive.

Telcos are a third example, with telco customer support being legendarily bad (although New Zealand Telecom have made leaps and bounds to improve).

Customer service level is a business decision

What do all these industries have in common?  They are commodities, in a race to zero on price.

You can rave all you want about Apple or Zappos.  These are companies who have chosen to differentiate themselves on service quality.  That is a conscious decision on their part, and certainly in Apple’s case they charge like a wounded bull to pay for it (and scam on paying taxes in your country too, unless you live in Luxembourg, but that is another article).  I don’t see Google, Amazon, Samsung, Microsoft, or HTC going broke, despite the fact their support sucks.

The level of love and attention you give your customers is a business decision.  It is a dial an organisation sets from “scum” to “master” depending on the strategy and current state of the business.

The governors of your organisation make the decision as to how important customers are, hopefully for good business reasons. The executive managers decide how that translates into levels of customer care, and that translates into service policy.  It is not for any of us to decide otherwise.  If you over-service the customer you are wasting money and putting the future viability of the organisation at risk.  This is true whether you work for a commercial business, a not-for-profit, or public service.

New Zealand Telecom lifted its game because its service had become so utterly awful as a monopoly that the government decided to deregulate and break Telecom up.  They had nowhere else to go: they were universally hated and they were too bloated to compete on price or agility.  Their competitors continue with the staggeringly bad support because they know it doesn’t cost them much business (see my case study about bad customer service).

Railroads are the same.  They know they need to deliver reliably and they know they need to listen to customer’s needs.  Some of the small railroads even specialise in customer service.  But in the main it is all about cutting a hard-nosed deal on price.

Don’t get confused…

Don’t confuse listening to needs with customer love. Any canny organisation follows its market: that is pure self-interest.  Railroads built specialised automotive rolling stock only after decades of complaints about dents and dust.

Don’t confuse good service availability with customer love. The only thing customers want from railroads, airlines, and telcos is that they work reliably.  We bitch about their rudeness and uncaring attitudes but we don’t switch because in the end it all comes down to price (or lack of options).

So don’t be led astray by vendors, analysts, pundits or consultants who tell you to spend more on customer care; and don’t let anyone tell you that you are failing in your job if your customers aren’t inviting you to barbeques at home.

Our job is to meet the goals of our organisation and to protect its ongoing viability.  We do as much for our customers as we need to, as we are instructed to, in order to achieve those goals.

Image credit