The Tightrope Walk of Customer Satisfaction

Good service makes customers happy, bad service drives them up the wall. Everyone knows this. Yet the reputation of customer service reps is a darn sight below that of tort lawyers and stock brokers. Comcast is being crucified in the media for its comically bad customer service and complete lack of internal alignment across its vast operations. A very painful process for a company anxious for approval to gobble up its largest competitor in order to rule cable in the US the way Sauron ruled Middle Earth. Why is it so hard to deliver good customer service? 

Because good customer service costs money. Large amounts of it, all the time. This means that there is a tradeoff between customer happiness and profits. These seemingly opposite aims must be held in perfect balance, or you risk falling off into either non-profitability or a damaged brand. Let's have a look at the tightrope.

Products and services are priced to include some measure of warranty and customer service. This surcharge is usually based on the expected number of defects and mistakes in the underlying business processes. 

To keep the price competitive, the 'service tax' is kept to a minimum. There is also a certain margin built into the sell price of goods and services to grow the company and show profit. Any activity that is not priced into the product or service itself is eating away the margin of the seller. This disincentivises gold-plating customer service, because it either makes the price uncompetitive or decreases profits.

Obviously, being too stingy has huge disadvantages, and in the age of Twitter it can kill your brand for good. 'Comcast' is going to mean comically bad service for a decade, even in the unlikely event the company manages to turn its customer service around. Conversely there is competitive advantage in having great customer service, because it makes your brand stronger.

Many companies create mechanisms to make sure they don't fall into the brand-killing abyss. Jim Collins wrote about Red Flag mechanisms, whereby the customer can truncate his invoice my crossing off unsatisfactory items. Lean Six Sigma places a lot of emphasis on the "Voice of the Customer" to make sure that feedback from the front lines is a big part of the decision making process. Measuring the Net Promoter Score gives feedback about how evangelistic customers are. The finance department makes damn sure that companies don't fall off the other side by providing service at a loss. Yet the fundamental tension between maximizing service and maximizing profit remains. 

There is of course a third way. Call it the Gmail approach. Call it Apple's baby-proof ease of use. Simply put, create a product or service that is so easy to use and so well-tailored to the demands and expectations of your customer that they are happy even without any customer service at all, or that they are able to perform most service themselves. Make support mostly unnecessary. This means really having your ear to the ground and be willing to do whatever it takes to deliver the right thing at the right time. It means lightness and agility to stay on top of changing expectations, not usually a large company's forte. 

This article, ironically, describes Comcast trying to do exactly that: deliver service that doesn’t need support. It did not protect them from the damage cause by mishandling the customers who did have to call. So even when your equivalent to the Genius Bar is barely used, it has to be very good and focused on having a happy person hang up, even when they don't want to be your customer anymore. 

The damage to the Comcast brand is done and cannot be repaired. The story however, can serve a greater purpose for monopolists and startups alike: give the people what they want, not just what you want to give them. Only a few true visionaries can tell customers what they want before they figured it out themselves, like Jobs did with the iPhone and Musk with the Tesla S. For everyone else, stick to the trenches and be quick on your feet. The battle for your brand won't be won any other way.

Separation of powers

There is a very interesting development in computing devices, namely the separation of interfaces from the rest of the computer. Cloud services, new devices like netbooks and new peripherals like Google Glass and Pebble smart watches divide the integrated computing devices of yesteryear into distinctly separate interface devices and processing devices.

Desktops, laptops and smartphones are all quite integrated, they are essentially complete computers in different sizes. Now that our computing is increasingly done in the cloud, our gadgets become focused on offering powerful, slick interaction with remotely hosted applications and content.

This trend has several interesting consequences. Interface devices like smart glasses, watches and portable screens can be upgraded separately from the silicon in the datacenter that provides muscle. Rather than shelling out for a Dell XPS or MacBook Pro with all the trimmings, it will soon be possible to buy an interface device like a tablet and use it for quite a while, without foregoing the benefits of regular increases in computing power.

Of course Apple and Samsung want everyone to buy a new flagship phone every year or two, but there has been a noticeable plateau of development in recent handsets. Adding gimmicks is not quite the same as new features, much to the dismay of Samsung's recently departed head of mobile design. It's high time that services and interfaces become the competitive differentiators, not the silicon underneath.

Using the same hardware for a longer time is also a lot more sustainable. Rather than tossing out a plasticy handset full of rare earths every year, having a trusty device to access online services for a couple of years saves tons of resources. Your 'internet device' could get a similar lifecycle to TV's, which have offered access to an ever wider array of services while being upgraded only once or twice per decade in most homes.

Service providers have a huge advantage over handset makers: customer data, workflows and online interaction with colleagues and friends become finely interwoven with the service over time. This builds very strong customer loyalty. I'm utterly useless without my Evernote and IQTELL subscriptions, for example. Also the R&D cycle of web services is a lot friendlier, allowing easy iteration of features and improvements with a constant revenue stream, rather than the billion-dollar gamble of developing a new device. There are good reasons to primarily sell services rather than hardware, and I wonder when the change of emphasis will occur. 

For now the iPhone remains a much more compelling product than iCloud, but only because the app ecosystem runs on the iPhone hardware rather than the iCloud platform. When Microsoft, Apple and Google have finished their current transformations there will be little to distinguish a desktop application from a mobile app from a web service, except the screen you view it on. That is when the time is ripe to complete the separation described here.

Storytelling

Recently, a former colleague re-joined the company for a special project. His nickname "Van Z" and past exploits were soon revived by long-time veterans, and to his amazement a lot of people he never met before knew of him and talents. This kind of company lore is great, it binds colleagues together in a shared understanding of what the company is all about in a much more fundamental way than the mission statement.

Babur & Companions
sharing tales around the campfire

The stories of past projects, remarkable customers and colleagues, and memorable moments are a living legacy of where we have been as people, as colleagues and as a company. These stories are repeated, embellished and woven together to reinforce what matters most.

The coffee corner in a great company culture is the campfire of its tribal identity, where colleagues confirm each others value and identity. Conversely, if the coffee corner where you work is the place to bitch about bosses and do some casual backstabbing you're well advised to work elsewhere, because the culture is showing severe symptoms of incurable decay.

My phone is keeping a track record of where I've been and what I've done, which is really useful for time writing and billing. More than that, it tells me my own story, helping me to remember and feel satisfied about the work I've done and the places I have been. It goes beyond the statistics of location and time to establish a narrative based on my comments and place names, and this is hugely satisfying.

Right now I'm working to lift our team reporting, daily standups and weekly review meetings to that next level of usefulness. As a project manager I need these reports and meetings to keep a firm grasp on our work. As a leader, I need them to reinforce what we are all about, which means that I need them to keep the narrative of our story as a project team alive.  Just like the phone app delivers more than bare stats, I want my project management to be about more than control.

What I find challenging is allowing the right amount of personalization and storytelling without fostering the kind of loose banter and improductive blah that clogs up far too many meetings already. In theory, meetings already work like this, which the confirmation of last time's minutes, the regular agenda items and a recap. In practice they're either really short and businesslike or really long and tedious, depending on the leader and the group.

My current approach is to frame each talking point in a narrative way, connecting it explicitly to what happened recently and what is about to happen. I also try to draw parables using existing company lore. Meanwhile the subjects under discussion are determined by the meeting agenda, and errant lines of conversation are pruned back with a meaningful glance at my watch. So far so good.

Raising a digital native

My son, with a mere 18 months to his name, is scarily good at handling his mom's iPad and my Lumia. My conundrum is whether to encourage him stacking wooden blocks over playing with the iPad and take the shiny gadgets away from him, or let him play Baby DJ as much as he wants.

My hopes for his future certainly include more mental than physical labor, which implies that being a digital native is more useful than being a very good stacker of blocks. Character development, however, certainly requires that he gets his hands dirty with all kinds of physical things to learn about the power and limitations of being a man.

I wrote my first story 1991 on a Kaypro II with an eight inch green-on-black screen, technology from my birth year 1984. It was about a talking pen who helped an old writer overcome his writer's block. It led me to a lot of experimentation with the various bits of software and files in my dad's library of 5,25 inch soft 'floppies' and started a lifelong passion for all things digital.

My parents, bless them, made a visionary decision a year or so later: They got a modern IBM personal computer and a dial-up modem, and they let me and my siblings access the internet for a short time every day. Back then that meant hours of Microsoft Encarta and minutes of using AltaVista. When I was ten the son of a family friend introduced me to Turbo Pascal. It was the start of my career in IT to this day, and the best thing to happen to my young mind since learning to read in English.

My son is growing up in a world where computers and internet access are taken for granted,  his understanding of the technological underpinnings of his universe will be more conceptual than technical.
The way he deals with devices, apps and content he likes even before he knows how to speak leads me to believe he will be as much more fluent with the use of this technology than I ever was. His understanding is not about how the technology works, but how to use it in order to satisfy his needs.

So where do I step in and set the boundaries on his digital adventures? There is so much literature on parenting that arguments can be found for or against any policy. My goal is to raise a boy into a man, and these days that means he needs to be proficient in the use of software and services to get where he wants to go.

Character is more important than ability for life's tough moments and choices, and I find it hard to asses how that aspect of parenting is changed by living in a partly digital world. Right now I believe that I should always give him as much access to technology and connectivity as he can manage responsibly. Of course what that means in the day to day toddling about with my phone remains to be seen. I don't have all the answers, no parent does. Perhaps our kids will be able to Google it some day, although I suspect that Google will mean as much as AltaVista by then.

Such is the way of things, including, regrettably, the skill set that allows me to determine what my son can and cannot do. The odds are good he'll be blogging some day about  how his decrepit father gets lost in the world of sensory immersion feeds.

Turing's Secrets

Alan Turing is famous for being the father of modern computing, the author of computing's peskiest problem, and for being gay. The first made him famous, the second notorious among the Technorati, and the third got him fired, chemically castrated and may have driven him to suicide. There's a lesson here for the modern day internet and for all of us.

You see, Turing told a police officer about his boyfriend in the course of reporting a burglary. He believed the burglary was a crime that need to be persecuted and the truth about his boyfriend was just background information. That backfired rather spectacularly in the moral confines of mid 20th century England.

Computing is founded on theories of what is computable, and Turing laid a strong foundation with his eponymous Turing Machine, which models what kind of problems are computable and how. An upshot his theoretical framework is that when you add sufficient complexity to computing systems to get to work on complex problems, errors will occur that are neigh impossible to detect and resolve. We know and hate these errors as bugs. Basically we cannot make computers complex enough to be useful without a lot of bugs.

Bugs in software contribute to many evils, from a blue screen of death on your office computer to Air France flight 447 pancaking into the ocean because the autopilot's error message didn't contain any useful information for the pilots.

Bugs are also the source of vulnerabilities in software, vulnerabilities that can be exploited by malicious hackers, state agencies and clever pranksters. Vulnerabilities can and do reveal the secrets we artlessly entrust to our computers, much like Turing entrusted the fact of his gayness to a cop. There has been much ado about the Heartbleed vulnerability recently, one that impacts the integrity of 'secure' connections. It turns out that for a number of years this assumed integrity was, in fact, absent and an unknown number of supposedly secure connections were tapped.

You see, it's not about what is recorded or by whom. It's all just ones and zeroes that we pretend mean something real. The internet is the most epic story we ever told together. The problem is that we cannot control how others interpret our parts of that story. Virtual deeds have very real consequences, and we cannot predict what those consequences will be.

The moral confines of this age mean that it is okay to work online, play games online and look at naked adults online, but it's not okay to incite hatred or threaten someone online. But what of the next epoch? Russia, China the US and the EU are changing our world, right now, as you read this. What is okay today might be hugely embarrassing tomorrow, or even land you in jail.

There is a huge amount of mistrust against the state agencies who are surveying the internet, but not nearly enough. It's as if we can't make ourselves believe that our shared illusion is real enough to shatter lives, even though it does so on a daily basis. Our passwords are weak and often repeated. Kids post copies of their passports on social media instead of faxing it because they have no concept of how dangerous that is. People download or stream illegal copies of music and film even though they know they shouldn't. And people are going to jail, as the EU is proud to report. Sometimes fairly, oftentimes not so fairly. We just don't know if what we do today incurs penalties tomorrow.

Remember Turing. Turing the genius for his work on computing and his wartime work cracking Nazi code. Turing the innocent for not being more circumspect about his gayness. Turing the persecuted for his inhuman treatment at the hands of righteous moralists. Remember the lesson his story teaches, so we may avoid his misadventures.

To the Left

The first time I heard about Shift Left is when I read an IBM whitepaper on the optimization of tech support. It was amazing, obvious and, for most IT organizations, way ahead of it's time. It took two years before I had a customer asking for this concept, and it's an instant hit with every IT manager who hears of it.

The basic premise that support tickets become increasingly expensive if multiple and/or specialized parties are involved in resolving them. It is therefore advisable to optimize IT infrastructure and support in such a way that the bulk of incident tickets can be resolved quickly and cheaply. The following picture sums it up pretty well:

ShiftLeft - Picture by OGD ict-diensten, used with permission.

If you take, from left to right, IT infrastructure, end users, IT support, system administrators, and technical experts, you want the largest volume of tickets to be resolved mostly on the left, rather than on the right side. After all, when something fails the end user cannot work. If it's not automatically resolved of fixed by the user himself, he just has to wait around while the service desk starts burning time and money. When the service desk cannot resolve the issue, the more expensive system administrators get in gear and start billing, all the while leaving the end user unable to do part of his work. In short, the further 'right' the problem goes before it's resolved, the higher cost in time and money. Hence, the drive to 'Shift Left'.

There are a number of things a company can do to enable this shift left. First is very good knowledge management, where the service desk learns to perform as much of the system administrators job as possible without significant error rates. Secondly, the end user can gain knowledge of how to resolve common problems on their own by making a knowledge base and relying on community support, training for commonly used devices and applications, and digital literacy.
Both the service desk and the end user need to be assigned sufficient rights to resolve common problems on their own for these two measures to work. Thirdly, modern IT infrastructure can be configured to be highly fault-tolerant, and if you switch to cloud services the issue becomes moot and you only have to worry about internet access.

The purpose is to optimize for quantity. Back-end systems can fail over to each other. Users can find their own 'any key'. The service desk is well able to execute common changes and resolve issues on it's own, given proper guidance and training. Sysadmins would much rather hack away at a difficult issue once in a while instead of being inundated in relatively common and easy tickets. Ideally, the cost, volume and resolution time of tickets is greatly optimized.

Thankfully the technology like cloud services are evolving to give a seamless experience even if single components fail. Digital literacy is increasing quickly and end users are quite happy with devices and apps that are intuitive to use and manage without reliance on IT support. As more people use tablets, phones and purpose-built apps to do parts of their work, the IT department takes on the role of a facilitator rather than a break-fix oriented club of technicians.

* He/his has to serve for all genders here :)

Finding an IT service provider to love

One of the niceties about cloud computing and having digital natives in the workforce is that your IT department can mature from being a cog in your organization to a lever for success. Instead of just knowing all about the bits and bytes, the department needs to be at home in vendor management. Part of this new role is delivering and governing IT services with one or more outsourcing partners through increasingly relevant frameworks like SIAM and COBIT. The primary capability of the New IT Department™, however, is building great relationships.

The secret to a great marriage is seldom in the prenuptial agreement. Having a great spouse who complements your weaknesses and enhances your strengths can take you very far indeed, as evinced by the infamous Underwoods on Netflix[1]. Conducting a marriage on the basis of legal paperwork is a poor relationship at best. A shared vision and ambition, however, is an excellent basis.

Traditionally, outsourcing IT services is about trading money for certain capabilities that your business needs to do its thing. As IT is something that you notice primarily when it breaks down, lags or fails to do what you want, IT outsourcing contracts tend to be heavy on performance clauses. These are supposed to warrant that most of the stuff will work most of the time, and get fixed quickly if it does break. This approach to contracting is utilitarian, defensive and ultimately anathema to what outsourcing can enable your company to do.

The magic of great outsourcing is finding a partner with whom you add directly to each other’s brand value and culture. Finding the right partner is worth a lot of time and effort. If your business relies on localized, region-specific service to your customers, don’t outsource to a large centralized offshore IT service provider. How could that ever be a good match? If your employees often work from home, by all means get an IT partner that is willing to go out there and deliver the same kind of service at home they can expect in the office. Do you expect a lot of acquisitions to integrate? Find the service provided who specializes in on-boarding and integrating diverse IT capabilities into a common standard.

It’s not doable anymore to have the IT department serve all your current and future needs at a reasonable price, unless you are in that sector yourself. You need a partner. You might as well find the one you can love. Best Value Procurement is an approach to contracting that helps to form the basis for a more holistic relationship than one based purely of price and service levels.

---

[1] To be clear, I don’t condone or extend the parable to the very skewed moral compass of the Underwoods.

Starbucks

By applying granular product management to IT services, providers can more easily maintain a service portfolio while meeting customer demand for tailored services. Starbucks' offerings consist of a limited number of coffees, additives and sizes. This allows customers to order a large variety of individualized beverages while keeping the logistics behind them manageable (although my go-to Starbucks' crew is clearly composed of espresso padawans who have yet to master efficient one piece flow).

Customers want services delivered exactly the way they want. The happiest customers are the ones who are made to feel like it's the sole purpose of the service provider to make them happy. Designing for the customer entails understanding this particular customer's challenges and filling in the gaps between its own capabilities and expressed wishes. Basically, this means tailoring every offer a service provider makes, especially in tenders where the scoring system is biased in favor of meeting certain precise demands made by the customer.

Designing with a predictable margin and realistic service levels in mind demands that services delivered to customers consist of standardized, well-understood components across the board. Giving a diverse customer portfolio diverse services means losing control of the risk profile associated with delivering those services. Margins, if existent, become unpredictable and service level compliance is a game of hit and miss.

The dichotomy between what the customer wants and the service provider needs is mitigated by breaking down service components into more granular elements. This allows a service architect to finely tune a particular offering by mixing and matching an array of service components and levels.

IT service providers need to have three or four different back-end architectures ready to implement with different benefits in terms of performance, scale-ability and cost. Several flavors of workplace will be on the menu equipment to satisfy factories, office-based companies and BYOD hipster firms. Anything from once a week visits by the geek squad to 24x7 support are layered on top and sprinkled with consultancy for roadmaps, optimization projects and training.

Each service component has a separate owner, development cycle, cost structure and documentation. It's good to have a clear policy to guide their development and a strict regime for rotating services into production based on their readiness. Because the effort involved in delivering each service component is well understood and the necessary elements for the transition plan are pre-defined, the principal risks for the service provider are easy to manage

Whenever a new tender is received the service architect breaks down the requirements and groups them in such a way that existing service components can be matched to each and the provider's bid comes together like Lego and pricing is a snap.

Innovation of services and components can easily be executed as co-development with existing customers as part of continuous service improvement initiatives.

Lean Six Service Management

IT services and processes are highly suited for optimization using a Lean Six Sigma approach. The inherent drive towards continuous optimization in ITIL and the excellent alignment principles of MOF are very well complemented by Lean Six projects*. The frequent misunderstanding of performance metrics and effective optimization in IT departments, coupled with the abundant management information handily collected by ticketing tools makes this area of the business a prime candidate for some black belt attention.

A practical example:

A certain mature and successful service provider supplies helpdesk services, system administration and infrastructure as a service to a customer, a large and professional organization. During the tender phase certain reporting standards and KPI's were agreed upon. The service is managed by these metrics, with the provider paying a malus fine whenever average performance falls below certain levels. These levels are defined and agreed in a separate service level agreement.

After a year it is clear that the services, on average, are provided at or above the agreed service levels, but that the occasional breaches in incident resolution time are a significant source of dissatisfaction for the customer. The service provider knows the traditional method to improve service in this area is to add resources to the team that resolves incidents, but this is expensive since the customer pays a fixed fee and the margin of the provider relies on resolving incidents cheaply.

At the customer's urging, the service provider brings in a team of Lean Six Sigma experts to see if there is a better way. The team knows very little about service management, but a lot about process optimization. The service provider watches with interest as the problem is defined, large amounts of data are requested and fed into spreadsheets and some over-caffeinated sessions ensue where one variable after another is scrutinised.

A few surprising truth emerge from the project. Instead of adding resources, the service provider is better served by re-architecting their incident management process to lower the time it takes to resolve incidents by a just few minutes each. Lowering the error rate of the resolver group turns out to be very important as well. Both of these findings are meticulously researched and presented to the supplier's management team.

It turns out that lowering the error rate and the process cycle time of the incident management process correlate very strongly to performing within agreed service levels, and to lower costs per incident. Adding resources to the pool actually turns out to have little effect on resolution time, and has a negative effect on the cost per incident. In hindsight, this makes a lot of sense to the service provider. After all, once there are enough resources to handle a regular workload, adding more people means that some of them will have little to do most of the time, and the team will be bigger, more complex and more costly.

Also, the project finds that the already low error rate of the service desk is a bottleneck. Errors engender a lot of confusion and necessitate double work, greatly increasing the time it takes to resolve the incident. The project digs into the factors that affect the error rate and find it can be lowered by creating more knowledge items for the service desk. These provide technical information and checklists to ensure incidents are resolved correctly.

By using Lean Six Sigma to optimise the service, specifically the all-important incident management process, the service provider gets far more than a happy customer. It matures beyond using a standard remedy for a common problem. Instead, the issue is managed by calmly considering the facts, gathering the relevant data and improving the aspects of the service which cause a bottleneck in the process flow. In this case, decreasing the time it takes to go through the process by a few minutes and unlocking more knowledge for employees turned out to be powerful solutions which would not have been found or implemented otherwise.

This example perfectly illustrates the value of 'Lean Six' for Service Management. Service levels are dependent upon many, often indirect variables. Customer satisfaction often has little to do with 'three nines' uptime, which needs to be taken for granted. Cookie-cutter solutions really are not good enough in the highly competitive IT industry.

An outside-in view  is the hallmark of a successful Lean Six Sigma project. By targeting the customer's dearest wish (resolve all incidents on time), considering supplier-side constraints (cost per incident), crunching the data on actual performance instead of agreed performance levels this project found the way to deliver the desired result, every single time. This is the sweet fruit of applying management science to the IT department.

*: Jack Probst and Gary Case published an excellent whitepaper on integrating Six Sigma and ITIL to practice continual service improvement way back in '09: http://www.best-management-practice.com/gempdf/sixsigma_itil_csi_wp_july09.pdf

Tools of the trade

For a company looking to take the next step in service management maturity, there are many great software solutions for IT Service Management Tooling. Many of them are cloud-based and can be used for a monthly fee instead of a large upfront investment in licences. This post explores some of the do's and don'ts in setting up new service management tooling.

A common mistake made by both small and surprisingly large IT departments (who should know better), is to merrily start implementing a shiny new tool and expect some positive effect. This without exception leads to an infamous IT project that takes way longer than planned. When it succeeds in its primary objective, the implementation itself, it fails to achieve any positive net effect on the department. Tooling vendors tend to over-emphasize the capabilities of the tool and understate the need for a thorough preparation. Preparation for new tooling involves at least prior alignment to end user expectations, proper demand and supply management within the customer's IT department meticulous process design and a lot of training.

Many IT service providers have responded defensively to this trend of ad-hoc implementations at their customers. Providers prefer to rigidly adhere to their own well-developed processes and tooling and prevent working with a variety of bad implementations across their customer base. Especially larger IT service providers are able to enforce their approach of standardized services and service levels on customers. However, enterprises are not consumer-level mobile phone customers and often respond poorly to this take-it-or-leave it treatment, leading to a low renewal rate on contracts.

The best results are obtained when customer and service provider are well-matched and can develop an approach respecting the suppliers need for consistency while enabling the customer to make large improvements in process maturity and make use of customised solutions. Tooling is very much secondary in this approach, being implemented near the end of the transition phase after services, processes, organization and accountability have been defined and aligned between customer and service provider. Once this alignment is in place, tooling can be set up in one of two ways: a shared instance or connected instances.

A common approach is to set up a single instance of the tooling that everyone, from end users to service resolver teams can use over their respective computer networks. This works well as long as customer and service provider agrees to use a common set of processes, which may well be in the case of co-development mentioned above. Rights management tends to be an issue in this kinds of setup, as it involves authenticating users and sharing protected data on two different domains.

Because by and large the available tools are based on ITIL and provide roughly the same options it's often possible to create a coupling between two instances. This allows customer and service provider to exchange ticket information between their respective ticketing systems. This way everyone can keep their own way of working while providing the requisite connectivity at a tooling level. Care must be taken to allow for data exchange in the SLA times, and reporting on the end-to-end ticket lifecycle can be challenging. If both customer and service provider are large enterprises with mature processes and able to build and maintain such a link, it is often well worth the investment. I'm still waiting for the IT service management bus which will make transitions and links between tools a much more pleasant exercise.

In short: do not skimp on preparation and try to find a good match between customer and service provider, this will greatly benefit service quality and help to defray indirect costs due to inefficient service delivery.

Fundamentals

It's commonly said by my IT Service Management compatriots that there are too few management benefits to be fully compliant to frameworks such as ITIL and COBIT. They're held to be much like the pirate code in Disney's Pirates of the Caribbean tetralogy, more like guidelines than actual rules, yarr.

The truth is, these frameworks are not enough, or rather, they are only a small part of what the IT department needs to deliver excellent results. The frameworks and good practices have been over-emphasized as a way to 'professionally' manage an IT department at the expense of general management practices which are much more urgently needed from a business perspective.

Running an IT department is like running any other business, or part thereof. The secret sauce of a great company or a great IT department is all in having good people and managing them well. That the good people in the IT department happen to be of the geek persuasion and tend to focus more on technology than process is no reason to throw management science out of the window and solely rely on IT industry inventions like ITIL.

Many IT departments and managers tend to fall on the spectrum between total ad-hoc troubleshooters and fairly compliant best practice fanatics, but the thoroughbred business manager is a rare find. A team of cherry-picked staff  in the IT part of the business is even scarcer, and that is a crying shame.
The worst cases have an under-qualified team of admins report to the facilities manager. This is the IT management equivalent of stuffing your servers in a damp broom cupboard. No disrespect to the facilities guys who may be doing an excellent job managing the facilities, but IT services are rather dissimilar to their field of excellence.

The time when IT merely supported the business is long gone. IT is the business, in the the sense that there is no business to speak of when the IT is not perfectly in order. Gartner is very clear about it, business who don't get that they cannot afford incompetence in this area are playing a loser's game. If you give CEO's the choice between going without their headquarters, their car park or their IT infrastructure for a week, I guarantee they will not choose to be without the IT. The services delivered by the IT department or outsourcing partner fall squarely within the must-have category. This means that the management of these services can be left to Petered-out sysadmins as much as the corporate finance department can be left in the hands of anyone once certified in Excel 2003.

What the IT department needs is a good manager (a great manager if you can find one), a good team and an equal status to your finance and HR clubs, preferably in a tightly run shared service center with direct access to the executive team. That is no more or less than what your business needs these days. Only when those conditions are met the IT service management frameworks become useful good practices. There's always room on the wall for one more ISO certificate, but without good general management practices it won't do much good.

When advising my customers on IT strategy I draw upon some accessible management classics such as Jim Collin's Good to Great, Mastering the Rockefeller Habits by Verne Harnish and Daniel Pink's Drive to underpin my holistic IT management proposals in line with the views presented here. Have a gander.

Old kids on the block

Last week I took a deep breath and then took the plunge: I'm on a Nokia Windows Phone and I'm loving it. For years the iPhone in various iterations was my constant companion. Increasingly, Apple's blatant disregard for users slowly etched away the glossy feeling of being an Apple fan boy and my disaffection grew. When a software update broke the Wi-Fi on my 4s and the fix took months, without a single word of apology from Apple, the spell was broken.

 It took a while before I found my new portable brain externalizer and communications hub in a bright red Nokia Lumia 920. I feel like a guy who drove a Prius and switched to a Humvee. It's BIG, obvious, it's floor-denting solid, and it feels powerful and secure and at the same time wholly irresponsible to own and operate. The spider web that long adorned the back of my 4S is a physical impossibility with this thing, and I hope it lives up to the reputation of the Nokia's of yore. Of course, it guzzles like a Humvee too, demanding top-up charges between my long trips across the Netherlands.

 Windows Phone 8 is nice, especially since I got used to live tiles already on my Windows 8 laptop. The OS makes me feel like it’s putting information at my fingertips, literally. iOS is getting stale. I still think that tiles are an interactive redux of desktop icons and not a truly revolutionary interface, but they’re a darn sight better than Apple’s icons and badges. So 2007.
Up front I was afraid of a dearth of useful apps, but it turns out most of my mobile friends are ported. Evernote, LinkedIn, facebook and Twitter have decent (if not amazing) representations. Weave turns out to be a nice news and feed app. Nokia's included navigation app HERE Drive is very good, easily beating the iPhone's maligned Maps app.
The phone itself is fast. Apps load quickly and disappear as fast when you’re through with them. The browser provides easy access to my favorite haunts. The e-mail app is decent, with swipe-able columns to hold your unreads, urgents and miscellaneous unmentionables. Sound quality is great for conversations. Music will never be great from something with the size and frequency reach of a phone speaker, so I won’t even discuss it.

The vaunted camera fails to amaze, as the automatic settings lead to over-processed images with saturation and contrast at levels that make me feel the picture is rotoscoped by Van Gogh. Sure, it takes pictures in murky conditions where the iPhone fears to tread, but that’s not where I usually hang out anyway. In plain daylight, it needs a firm hand on the exposure and white balance settings. The Lumia 920 could have done without all the feature phone fuzz about the camera, then its resolution and low light performance would have been a pleasant surprise.

Overall the Nokia is great. It exudes quality, usability and a bit of cheek. It’s a strong statement that the old stalwarts from Kägeludden and Redmond are back in the mobile game and making a difference. Me? I'm not even looking back.

Supplemental Thoughts

It's easy to forget that IT is essentially non-essential. It does not feed us, clothe us, provide us shelter, guidance or love. However, it does help us provide these things for ourselves and each other. Information and communication technology have been transformative in many industries. It has changed our lives so much that it is seen essential, but is it?

I recently discovered an App to track information relating to newborns. Growth, regular feeding and the like can be logged, compared and shared with other caregivers. A very nice replacement of a paper log, but not transformative, and certainly not a step towards better parenting. This is true for many examples of information technology.

Facebook does not make us better friends, SharePoint does not make us better employees, and iPhones do not make us better communicators. They all do enable us to do what we were doing in novel and often more efficient ways, but these are improvements of quantity rather than quality.

Sometimes I indulge in a Steampunk thought experiment where I try to envisage a world of continued industrialization without transistors and IC's. Of course I would have a different job, knowing all about electron valves and copper instead of about silicon and glass fiber. I'd pop a message to friends of mine by telegraph instead of twitter, read books by gas-light rather than on my iPad and worry more about copper than rare earths.

At the core I would not be all that different. I would have the same core values, the same attitude to life, work and family and the same lessons to learn in my time here. I would be essentially the same without information technology. And that is a comforting thought.

FTL FTW!

Man oh man, CERN does it again. In this article the physics lab announces that they confirmed their earlier finding of faster-than-light neutrinos.

If this finding is again confirmed by new and independent experiments it implies an enormous paradigm shift in our understanding of the universe. Nothing goes faster then light, and if something seems to outspeed c* it's a flaw in either measurement or understanding. Ineffable c is the limit, period, or so we thought.

The scientists involved are commendably cautious in their refusal to speculate on the cause of this spectacular result. It will require a lot more testing by different people in different facilities to underpin this revolutionary outcome. Then, and only then, can we safely assume that our standard model is broken, special relativity is fatally flawed, and we do not begin to understand our universe to the degree we thought we did even three months ago.

Exiting times! Had I the funds and the time I'd go back to university in an instant to study physics. It has not been this cool and exiting since Feynmann taught at Caltech. I hope the find is verified. FTL FTW!


* c denotes the speed of light in a vacuum, 2.998×10^8 meters per second.

Worms

Having an Apple computer was once a rare and nerdy distinction. Nowadays it firmly pegs one as an average wealthy consumer, much the same way as a family car and a nice suburban home might. Pity.

There's only one way from the top and it is inevitable that Apple-tiredness sets in. My moment came last weekend, when deciding between a new Mac to replace my 5 year old MacBook or buying new furniture, and I decided to spend on the latter.

Even a year ago this would have been unthinkable. Regularly mocked as a fanboy in the days of the PPC processors, my love for Apple computers is a well known trait. What happened?

Seeing a Chromebook in action. It's not its extremely bad video performance, nor its very limited offline usability. It's not its cheap, plastic look and feel either. What uttely charmed me about the Chromebook is its edgy 1.0-ness. The fact that few people who are not serious webheads would consider using one regulary. The fact that it's new, niche and not a Mac.

I still love my iPad, and I will continue to use my old and trusty MacBook until it's good and dead. However, I doubt that the latest and greatest from Cupertino will be as utterly compelling to me as once it was. With mass adoption of Apple devices and the death of Steve, Apple has somehow lost the savvy edge. Maybe I just woke up from deep reality distortion field hypnosis. I don't know.

Either way, I'm in the market for something with a Penguin or a Pokeball. Apple has to do a really convincing job with its rumored 15 inch Air to tempt me back to the Mac.

IT's added value

Amidst the bearish sentiments and imminent collapse of the Greek economy it's a good moment to reflect on the business case of the IT department. The good news: the IT department is definetly necessary. The obvious news: it has to demonstrate more added value to its company. The bad news: IT guys are not good at demonstrating value, because they're necessary. Performing at SLA levels is not added value, that's the agreed minimum. Yet soon enough some nice finance guys come knocking with cutback plans, and a requirement to show one's worth.

The IT department does have a strong process orientation in common with its financial department brothers, and a penchant for metrics and service level agreements. However, this will not be enough to prevent the finance guys from pulling a Cain on many IT department jobs when it's crunch time.
Factor in aggressive competition between IT service providers, outsourcing and offshoring alternatives, and cloud computing, and before you know it the entire department is Abel. Doom scenario? Of course.

So, plan V for value. The hidden power of an IT department is continuous service improvement. One clear way to demonstrate value is to provide clear metrics on the improvement of IT operations over time. If the department can show it delivers better warranty and utility to the business than last year, preferably saving dollars at the same time, it's a good show. I'll briefly discuss seven areas to measure and report on. For all of these area's, the real power is showing the trends over time.

People, IT operators
People are the core asset of the department, not computers, systems or processes. Measure their performance and show it front and center. Not only is it the most important data, but it's the easiest to relate to for the alpha-educated. People-related KPIs show not just how well employees perform, but displays the vital statistics on the department itself, its health and wellbeing. Overtime and sick days are writings on the wall to experienced executives.

Users
Our dear problems between keyboard and chair are of course second in line to be measured and reported on. User-related stats and KPIs show the value of the department to the business like nothing else. Basically, it shows how much work the department makes possible elsewhere. Show how many users to a single operator. Show how fast a new user is up and running with a new computer, phone, account, software etc. Show the department as an enabler.

Partners and suppliers
If you have mastered the exact art and subtle science of multi-vendor contracts, devote time to playing them off against each other. The opportunity is to create competition for quality, and the pitfall is to allow competition for price. Therefore measure and report on your partners and suppliers the same way you do on your own department, focus on the people and the quality of work delivered, focus on the value to the business. Make no bones about who gets more pie when it's time to re-negotiate those contracts.

Incidents
Incident metrics are real measures of quality for an IT department. For an operational report on the department level, this data would be perhaps second in line. When it comes to reporting added value, it's a bit lower in the list but therefore no less important. The business wants to know its uptime, its operational risks and the speed and efficacy of its solution mechanisms. Incidents per timeframe or average resolution time alone are not going to cut it. Showing a breakdown of self-service desk resolved incidents versus operator-resolved incidents and their respective severity, now that is showing why they pay the big bucks. A short story on the emergence and resolution of a major incident does not go amiss either.

Changes
Change management is absolutely vital, but the related data is almost unbearably boring. Standard changes / request fulfillment can be reported on by average time to fulfillment and closure. Non-standard changes are mainly interesting for how well they are executed. Therefore report the numbers of change-related incidents, and if it's a tight ship then the trend should slant to the lower right. A well done report harks back to the section on users: show the department as a business enabler by providing insight into the business changes enabled by IT Change management.

Configurations
Now, and only now, do we get around to the original raison d'être of this whole ITSM bit: the computers and other configurations. Lots of things to measure, lots of ways to demonstrate value. Show the reliability of the standard configurations, their total cost of ownership. Show how much discount was brokered in volume agreements with large manufacturers. Keep in mind that this stuff is really boring. Internally, maintain comprehensive data on the fleet, the stock and the various costs. Externally report the basics. Configuration-related metrics are important for driving operational excellence. Stock-keeping and supply chain management are arcane sciences of their own, which IT guys may underestimate. The larger your operation, the bigger the issue. Smart contracts can keep the onus largely on the supplier side.

Miscellaneous metrics
There are many more things to be reported on, according to preference. Some nice forms of report padding are storage size / cost versus utilization and my personal favorite: e-mail. Mail volume / related incidents / cost of mail solution per user / per e-mail are all eminently relatable for decision makers. Odds are the report was received by mail and is acted on with e-mails, so it's an appropriate and ironic salute to the IT-dependency of the company.

PR Metrics
Last and least are what I call PR-metrics such as customer satisfaction. I am gleefully swearing in church by saying this. If all the above measures are signs of a well-functioning IT department, then this happy user stuff should be completely superfluous. Conversely, of there is trouble in any of the above areas the customer satisfaction will be adversely affected.
Measuring customer satisfaction as your primary KPI is like measuring how close you are to port, while neglecting to measure your course, speed and prevailing weather. Sure, it tells you how well you are doing, but does not tell you a blessed thing about how to get better. Therefore measure and report all the rest first.


The bottom line
Never forget who holds the wallet and show your results to that guy. Everyone else is just filling a chair. It's not important how well you or anyone else thinks you do, it's important how well he thinks you do.
Secondly, don't think for a minute that this is too much paperwork. On good days, this paperwork enables operational excellence. In the bad days ahead, it's survival.
The bottom line of any executive decision is cost versus (expected) profit. Know your cost, show your profit.

The call of the cyber sirens

The promise of new technology can be a real siren's call to an IT department. New windows versions, new storage systems, a better process implementation can seem so incredibly good that the business case seems to write itself. Then comes the implementation project, and reality serves cold coffee for breakfast.

Jim Collins (Good to Great) once likened smooth operations and steady improvements in great organizations to a flywheel. It turns steadily, and with steady increments it can go faster and faster. Great results come from evolution.

Similarly, the most important function of an IT department is to support the central process of the company by ensuring the utility and warranty of its IT assets. In short, keep it ticking over nicely. Improvements are always welcomed, revolutions are not.

The cloud, (internal) social networks, Bring Your Own Device (BYOD) support are al great phenomena with a lot of promise, but at the same time they are silly fads that have yet to prove that they can add to your company's bottom line. Yes, they add billions to Apple and facebook, but the odds are your company has a different focus altogether. Readiness for 2015 does not mean equipping all employees with telepathy chips over the next six months.

Once in a while the sales pitch is just too good and an IT department saddles up, corrals some consultants, and goes to work delivering tomorrow, today. Research says at least 30% of IT projects fail, costing businesses green stuff without ever delivering on their promise. Some estimate as many as 68% of IT projects are doomed. Most participants are even aware of this, never expecting a hyped up IT project to succeed at all. What happened there? Lack of ambition? Steady improvements? Nope. Finance forgot to tie Odysseus with a nice tight budget.

On the other hand there are a lot of businesses doing amazing things with technology, step by step bypassing their impulsive competitors to reach a level of sophistication beyond any of them. The aforementioned book contains examples of companies progressing steadily from old-skool a-technical companies to operating their own custom satellite systems, one small step at a time, never trying to go from 0.1 to 2.0 in one giant leap.

In short, IT departments might do well to instill a motto, "we live to serve" or something humble like that, and make sure that they run the smoothest IT operation rather than the most cutting edge. DevOps, anyone?

Creeping elegance

Programmers tend to be perfectionists, and are familiar with a phenomenon known as creeping elegance. While writing code, it becomes an obsession to write it as tersely and elegantly as possible, which comes at the expense of time, readability and focus on the final product.

Projects can also experience creeping elegance, in this form an insidious variety of scope creep. Say there's a process optimization going on in a very basic environment. Little documentation, lots of informal procedures, opaque and implicit knowhow ingrained in the employees, organic structure, the works. The project brief states that the goal is to document knowledge and procedures, design and roll out a standardized process, and train employees in the new and formal way of working. The allotted time is nine months, 5 internal people are put on the project for 20% of their time, and three consultants are hired.

A year later, a cold cup of coffee overhears a debate about indentation in the new documentation template, mixed with comments on the frequency of detailed status reports. The cup quietly reflects that, just like twelve months ago, neither the template nor the report are used operationally, but once the project is done they will surely be things of awesome perfection, terrible to behold and a slap in the face of any IT department who gets by with a lesser standard.

What happened? Creeping elegance. It's very hard to decide when to stop once you're improving something. At what point has enough knowledge been documented? When is a process good enough? That's undefined. It's not like a building plan where you're done at some point, when the building stands tall and happy tenants are preparing dinner inside.

Operationally, this is easy. Continual Service Improvement (CSI) is the name of the game. Steady progress. But when improvement becomes a project, it's very hard to keep the creeping elegance genie in the bottle. The only solution is strict timelines, and a project manager with enough common sense to nip creeping elegance in the bud. When the sand runs out in the hourglass, whatever is agreed on is delivered as the final product, and operational CSI takes over. Mission accomplished.

Oops

While updating labels on all posts I accidentally re-posted some old material as 'new' posts. My apologies. The latest post is called The keys to the Kingdom.

Cortland, and why we don't use free software all that much

1. Coding is fun
2. EULA's are a farce, people wouldn't ever buy something else under the terms & conditions attached to software
3. It's great to have your name on something good, something you made or contributed to
Ergo: create free software. Any questions?

Well, I do have a couple.
I like getting paid for my work. Lean software development is cool, getting leaner developing software is not. How to monetize?

Someone who can do something I can't, or can genuinely do it way better, is welcome to add to my code. Everyone else should bugger off. How to maintain quality & ownership of an idea / some software?
Nothing is ever truly perfect. Who is going to take care of support issues once I finish uploading this baby?
In Rand's The Fountainhead the story's famously egotistical protagonist agrees to design a housing project for free, his price is to see it erected exactly as he designed it. Subsequently, some less-that-stellar architects proceed to do a mashup job on his blueprints by adding their own 'enhancements' and the result is not at all what he intended.

What I understand is that creation can be its own reward, and when you're busy doing something great money becomes merely a means to secure the resources you need to keep creating, rather than the reward for the work you do.

What I also understand it that sometimes you got to have it your way or not at all. Especially when any alteration would detract from the whole.

In this vein of thought the GPL seems an evil thing that lets other people appropriate the fruits of your labor, mess around with them and go on the internet going all 'look what I made'. Terrible.
However, this is not the reality of free software. The reality is that great people do great things which are then made even better by other people. Why?

Because of the free market of free software leads to incredible competition and a very, very good insurance against quackery. People can't fork, edit, relabel and sell software they didn't make because they will be called on their bullshit instantly. Also, anyone who screws up your good code will not be able to distribute it as widely, because customers will favor your better product.

Now the major weakness here is technological literacy. If I'm a car mechanic such as a good friend of mine I'll buy a highly customizable car that I can trick out how I like it, and that will outperform cars many times its cost. However, if I am an average Joe I'll buy whatever requires the least maintenance, or the product that has highly available support. The same goes for software.

Once in a while I'll try a new Linux distro, feel all warm and Tuxy and nostalgically use all seven bash commands I know just to recapture the cool. However, as soon as I run in to a problem that requires me to debug spit-and-ductape solutions for playing video files or scare up obscure drivers from exotic repositories I tend to grab that OSX disk, real practical like, and restore my mac to it's rightful smooth usability. So even though I'm at least somewhat technologically literate, I tend to prefer forking over my hard-earned dough for good software, instead of free stuff that needs more attention.

Free software can and does perform flawlessly in many critical environments such as servers, but the wizards in charge of those systems are second to none in setting them up and maintaining them in such a good state. As long as your mom doesn't use free software on the house computer with the same ease as she uses any appliance, we're not where we should be in terms of usability and all our freely distributed creative efforts will see niche use at best. Granted, this is a higher standard than being merely as usable as Windows, but that was kind of the point of building something else in the first place. And given that 0900-FIX-MY-FREE-STUFF won't be answering your calls, free software cannot be the future until everyone, including mom, becomes more savvy about the stuff they (could) use.

Yes, there are seem to be some counterexamples with free browsers and such being built and working well. Their development is actually funded by multi-billion dollar corporations like AOL, Google, Microsoft and Apple. Mozilla too stays afloat on grants and cooperation agreements with the likes of Google. It is really properly organized and funded development by professionals, only the product is distributed for free. The development certainly isn't. Nothing wrong with that, but it doesn't fit in a discussion of romantic basement programming by clever peeps on a creative jag.

Recap: Making free software is fun and we should all do it for fulfillment and major kudos, using free software is at times not so great. Until we're all better hackers, free software is going to stay in its established niches. Shame.