Examining our love-hate relationship with IT

Isn´t it IT’s job to embrace the business goals and deliver technology as a service in support of core activities and overall efficiency?

Following a recent discussion with a colleague about the tenets and pitfalls of a new service agreement between the IT-department and the system owner, my mind kept turning over this question:

• Is the IT-department more focused on making money than on making things work for the organization? Followed closely by:
• Is not our cost center budget model seriously flawed?
  And finally:
• Is there a better incentive or IT-management model?

In search of an answer

First stop Harvard Business Review where I found the frank and engaging post by Susan Cramm: “8 Things We Hate About IT“. Reaction: apparently we are not alone, and our flawed operating model and strategy execution is not the exception, but the rule.  I present a few slightly modified excerpts from the points that especially resonated:

8 4 Things We Hate About IT

IT’s bureaucratic governance process rivals the tax code in complexity and inhibits rather than promotes innovation. (From 8 things… #1 – IT Limits Managers’ Authority)

Molasses moves faster. IT projects and planning move slowly, often taking 3 to 4 times longer than necessary (see point above). In-process projects are always 90% done. “Completed” projects don’t have agreed to functionality, and the team that promises to deliver missing functionality in future phases are always mysteriously MIA. (From 8 things … #4 -Their Projects Never End)

Condescension not collaboration. When you try to brainstorm with IT about how to apply new technology, you get paternalistic responses. When glitches emerge, functional specialists defend the reliability of their piece of the byzantine infrastructure. (From 8 things … #5/#7)

The perpetual struggle. No matter how much you spend and how hard you work, you never have anything to celebrate and little to look forward to as the promise of technology seems perpetually beyond your reach. (From 8 things… #8 – IT Never Has Good News)

The blame game

It is tempting to rally behind the sentiment of Cramm´s introductory quote:

“In the quest of getting things organized, they are introducing a bunch of bureaucracy and, in the process, they’re abdicating their responsibility for making sure the right things get done.”

But I won´t. Like many of those readers who commented on the above article, I like and respect my colleagues in  the IT department. It is the system that is broken, not the people in it.  And it is only fair to also include the valid points from the Cramms´s sequel presenting  IT’s point of view on corporate management.

I can definitely attest to the following:

5) The user community is unskilled and ungrateful – The IT department often provides on the job training to an ungrateful user community even though much of this tedious work could be eliminated if they mastered the basics of the systems that support their business.

7) IT is hardworking – IT works long hours supporting old technologies that the company can’t afford to upgrade.

It also needs to be said:

The model we have is the model we built. The IT-department is a cost center that fills orders and builds things to spec, because that is what the organization has asked and allowed it to be.

Sure, it may seem rational and responsible for an a cost center manager to couple costs and the income for the services it provides. It may seem prudent to invest in things actually in use or in demand, upgrading what you have is easiest. But doesn´t this reactive model cost the organization money in the long run?  In my experience:

1. Policies are good, but policy period, without some degree of pragmatism is detrimental to progress.
2. New technology can save money, often by saving time.
3. New technology is often necessary for new kinds of activity, and lack of it may stifle innovations concerning core tasks in other areas of the organization.  This can cost the organization both money and prestige, even long-term success.
4. Allowing real, and completely valid concerns about maintaining the portfolio of IT-services and applications to always win the day will have negative consequences.

Are we anywhere yet?

So how much closer are we to finding some good advice?  Authority and governance is the  big issue and no one seems to have the silver bullet, but McKinsey´s Marina Levinson makes and illustrates some good organizational principles.

Governance  principles

Processes must use fast-cycle innovation and be tied to long-term interests
In particular, Levinson suggests “deliver tangible business value within 90-day increments” … and “build quickly while also looking at least two or three years ahead.”

Foster mutual understanding and complementary skills in both camps
Core business areas need people to be IT savvy, and IT experts need a knowledge of the business. “[You need] IT leaders who challenge [the business]” … and “each cross functional process has a sponsor at the senior or executive VP level…with operational leader whose responsibility includes that business process”, says Levinson.

The motivators and values need be top-line and customer focused
Prioritize systems that allow you to get closer to customers and partners.

Embracing these principles involves a paradigm shift.  And therein lies the rub, as realistically this problem is complex and improvement isn´t possible through grass-roots effort alone.   Some changes are needed and my colleagues may even agree, but many of our leaders have not reached the same conclusion. We are talking about a strategy shift, and a change in organizational culture.

Always look on the bright side

In true Monty Python fashion let´s conclude with a look at the bright side. We are taking small steps in the right direction:

1. Some units in our IT-department are increasingly embracing agile development methodology.
2. Business process reviews have been initiated on a small scale.
3. Some discussion of the ICT organizational model, have taken place.

Recommended reading:

No Scrum, No More -  Why are we not scrumming? (Select*, Geir Berset - Feb. 11, 2010).
Pssst: it´s not negative to SCRUM, rather it´s about adapting SCRUM itself to fit even better.