This page is powered by Blogger.


 
  corner   



HOME

ARCHIVES

SEARCH

Contacting Us
Recommendations
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Forums
Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
CamWorld
Ed Yourdon

 

Thursday, January 24, 2002

 

If I had to point to a single root cause of the traditional problems between IT and the business it would be: IT too often works in a vacuum. What I mean by this is we tend to initiate projects with little understanding of how the business we are charged with supporting operates, and we only cut the business process owners and their people in after we're well into the project.

I was involved in two such projects during the past two years that illustrate this:

  1. Project 1: The project objective was to develop service level agreements for an international company. The client would not allow any contact with business process owners or end users during the project. The project was doomed from the beginning, and after the first service level agreements were developed it was painfully apparent that:
    • there was no connection between what IT was promising and what the end users needed
    • the service level agreements addressed technical issues and did so in a language that one could not expect a business person to understand - I had a hard time understanding what was being promised, so I know that someone without my 25 years of IT experience was going to be bewildered
    • none of the consultants or the sponsor's people working with them had any clear idea of importance to the business of each application for which an SLA was created
    The client mercifully performed euthanasia on the project.
  2. Project 2: I was the lead on this one and the objective was to develop service level management processes for a large Middle Eastern corporation. I came into the project six months after it had been initiated, but the service level management piece had not started. Although I've spend my life roaming all over the world, particularly throughout Asia, this was my first time in the Middle East. I quickly learned the basics of the culture, and had a fundmental fact validated: regardless of the human cultural differences it's the company culture that matters. Moreover, it matters little in which country you're working, or the internal politics and unique culture of any company, IT remains IT. In other words, end users and business processes are secondary to technology. The challenge was to convince the decision makers that I could not possibly develop a service level management strategy unless I was allowed to interview business process owners. This request was finally granted and the resulting deliverables and recommendations were aligned to the business. That it took as long as it did to convince the project sponsors does not reflect poorly on the company's IT management as much as IT the world over. As an aside, I had a great deal of assistance from company employees who were overseeing our performance on the project and also discovered some existing best practices in service level management that had been implemented long before I arrived. There's hope for IT yet.
The moral of this is that no IT project, and especially any service level management initiative, should proceed without first discovering what the business and the rank and file users of the systems and tools we're supposed to be providing need. These needs, a.k.a. requirements, must be known and understood. Also, we exist to serve the business, not the other way around. Remember, we're the revolutionaries who are going to wage war against IT arrogance, and that's how we want the those whom we serve to see us - as enlightened members of a service organization who are revolutionizing the meaning of service and support, and not as elitist technocrats who don't understand why we exist and whose attitudes are revolting.