So why are you in IT?

The ASL BiSL Foundation’s annual Focus on Demand conference was sandwiched between two tragic events: the untimely death of Remko van der Pols, founding father of the ASL and BiSL frameworks, and the abhorrent massacre in Newtown. Events like these tend to put things into perspective, with the ‘why’ question taking central stage. Traditionally, when asked for the corporate justification for their activities, IT folk have tended to defer to the business. Whether it’s a project or a process, if the business wants it, they’ll do it. They’re order-takers. But every day my conviction is growing that “we’re just taking orders” or “we’re just following the process” isn’t good enough. Charlie Araujo brought this up during the BookStore simulation. Playing the role of the business, and irritated by the incessant questions that were being fired at him, he said “I don’t want questions, I want solutions!”. The questions should be implicit. If not, then you’ve lost the plot.

As a response to the criticism of  enterprises prospering at the expense of their communities and being a major cause of social, environmental and economic problems, Harvard Business School’s Michael Porter came up with the concept of ‘shared value’. He believes that business can escape from an outdated, narrow approach to value creation. They can bring business and society back together if they redefine their purpose as generating economic value in a way that also produces value for society by addressing its challenges. Just as this shared value approach reconnects company success with social progress, I believe that IT can play its part by looking beyond the demand-supply interface and involving itself more in influencing IT decisions for the better. Using IT to benefit society. At the end of his keynote, Chris Dancy used the word ‘humanity’. Why not? Think big.

Yes, of course it’s the enterprise’s responsibility to make these choices. But it’s also your personal choice to work for that enterprise. While the current climate can make this seem like a cheap shot, each of us can take a stand in our own arena, taking our individual circumstances into consideration. 

Five challenging but rewarding steps. 1. Think about your core values. 2. Understand the specifics of your business. 3. Understand the generic opportunities that IT offers. 4. Combine the three. 5. Sell it. Daniel Pink talks about three factors that determine job satisfaction: autonomy, mastery and purpose, and all of these apply to the five steps. For IT, there’s more to ‘purpose’ than achieving high customer satisfaction, independent of whether the customer’s in healthcare or gun running. So why are you in IT?

Ban the SLA

Business people just don’t get it. 

This strange stuff that we IT folk force-feed down their throats. 

Like SLAs. 

All very high-ceremony, with formal procedures for this and that, most of which seems inside-out if not inside-in. Subtle differences between incidents, problems and service requests. 

"I REALLY DON’T CARE – JUST HELP ME GET BACK TO WORK INSTEAD OF ME WASTING MY LIFE TRYING TO WORK OUT HOW TO AVOID DEALING WITH YOU."

They only play along with this SLA nonsense because they know that it’ll cost them even more time and energy to get us to change our ways. So then we get into discussions about response times and resolution times with us saying

 “No we can’t possibly guarantee a resolution time because one of the widgets is out of support”.

And they say “Yes but all I want to know is what kind of a delay will I have when there’s an outage”

… “Oh, we couldn’t possibly say – it depends on so many variables” …

 “But you’ve been doing this for years, surely you know what to expect?”

And so it continues, ending up with both sides adding preconditions and exceptions and penalties. This reminds me of the build-up of nuclear weapons half way through the previous century. And the Ban the Bomb movement and nuclear disarmament. 

I believe that the time has come for the Ban the SLA movement leading to an Anti-Ballistic SLA Treaty and a Strategic SLA Limitation Treaty (SALT), leading in turn to Service Level Agreement Termination (SLAT) and SLA disarmament. 

An interesting alternative to SLA’s is the Service Charter. Not the same Service Charter as defined by ITIL 2011 as “A document that contains details of a new or changed service” but a high-level document that sets intentions and general expectations. Deakin University in Australia has a good example and, strangely enough, most service charters seem to be used down-under. It’s only fair to state that that a service charter is not detailed enough replace the contract between business and IT, but it is certainly a more fitting instrument to lull them into a false sense of security before launching our all-out service level attack.  

Note: James Finister prompted me to write this for his blog.

Service catalogues - the business perspective

From a business perspective, the following categories of IT services appeal to business managers in the sense that they fulfill a business need: 

• Build or acquire, and then deploy functionality that supports the business processes (this is typically delivered in a project that combines applications, data, infrastructure and facilities to provide the required functionality) 
• Ensure that the functionality is operational and fit for use (this addresses availability, performance, security, continuity etc. and the corrective en preventive maintenance that is needed to keep providing the current functionality)
• Provide operational services such as providing a new user with access to the information systems (including supplying devices such as laptops and smartphones), running an IT function that is too technical for a user, e.g. a batch run, and supporting the users when queries and problems occur
• Change the functionality when business processes change and to improve how current business processes are supported (often delivered in a new release, and executed in a project when the risks justify it) 
• Advise about the consequences of proposed changes and which changes should be considered, and advise about longer-term choices, such as adoption of social media technology and when to replace an application
• Decommission the functionality

More on this topic in my white paper 'Service catalogues - the business perspective'.