I had the opportunity to visit one of the business areas at an IT organization I know well recently, and innocently asked about their dealings with the company’s IT group.
“Don’t really want to deal with them”, was the answer.
On probing, it came out, grudgingly, that the IT did do good work, but they were slow, made the user get involved in far too many internal processes, were bureaucratic to the core, and most of the internal practices were incomprehensible to their business area.
I’d like to say this was a single occurrence, but it’s not.
Most IT groups get a reputation for being hard to understand and deal with.
“Almost like they put everything in Braille”, said one marketing Vice-President trying to get some data analysis done, “rather than in terms we can understand.”
She then shoved the request form across the desk and asked if I could help decode it. It was a mass of options, most of which seemed (at least to me) to be unnecessary.
I helped her fill it in, then started to think about why this is happening.
There’s little doubt that the emphasis on security and compliance over the past few years has been a part of this situation.
Much of what we hear about and see, when it comes to simple requests, has to do with the requester proving they have a right to access something, or stating (for yea/nay approval) what they need it for. The custodial responsibility, in other words, is being over-fulfilled.
Another issue has to do with the size of IT, and the number of parts it is broken into as a result.
The boundaries between architecture, planning, strategic relationships, solution development and infrastructure are not always clear to outsiders.
Often the user feels overwhelmed with the sheer number of people from IT they have to deal with. (Often this is because the parts of the IT organization really don’t trust each other.)
Worse, it’s never clear who to talk to this time to get something done.
There’s a great deal of pining for the old days when your development project manager was the primary point of contact — for anything.
Often, too, conflicts between the parts of IT seep into project meetings, planning sessions and the like.
Few of the relationship management groups are acting like true account managers, co-ordinating in advance.
Sometimes the differences of viewpoint are clear. Most of the time, they are arcane — and the person from the business is not clear whether staying out of the fray actually works in their interest or not.
Finally, there are no shortage of IT groups today that have only one set of processes — often, overly complex — for every piece of work.
Much of what the business wants can be simple, but everything needs an approved project number (we have work breakdown number requirements for chargeback or team assignments), sign-off on designs, etc. even when the request is small.
In one organization, an employee came in one day with a self-purchased iPod Touch, which they wanted to use on the company’s WiFi (so they’d have access to the Internet and their mail during meetings). “Turn it over to us so we can test it” was the reply.
No person willingly surrenders their property for weeks (the estimate in this case was that “complete testing would take about six weeks”) simply to be able to do something they do without incident across the street in the coffee house.
Yes, the IT group can be its own worst enemy. The question is: will the effort to see their practices through the eyes of the client happen?
However, the other question is: who won’t you serve?
There’s been discussion lately — from far more than those who read and believed Nicholas Carr’s writings — about the future of the corporate IT group.
Most IT groups are well configured to do three things:
- Run and maintain what exists;
- Handle automation-type projects, where the process is well understood; and
- Support individual or personal technology, but at a device and operating system level.
These, however, are not typical of the demands being placed upon the business going forward. In turn, the business needs IT to be in the “information” business more than in the “technology care and feeding” business.
What they are is typical of the “IT has become a commodity” argument, whether this is raised from an outsourcing perspective or from Carr’s “there’s no competitive advantage” point of view, made because the packages in use are all pretty much the same when it comes to automation-type support.
So, how does IT change — and what does it need to do that it isn’t?
First, IT must recognize that the demands for new services won’t come automatically.
Today IT is in competition: many demands can be handled with PC-level software, or software as a service.
What has held this back is a maze of security protocols, compliance issues and a lack of pressing needs until recently.
But security and compliance mean little when the business is ready to move forward. IT must either have already established that it is ready to deal in new kinds of services — or the work will go elsewhere.
Second, the hallmarks of the change are:
- A loss of the “process myopia” of the last decade, and, with it, a loss of the “package myopia” that came with it;
- Moving up to “how to use” rather than “fix when broken” when it comes to user support;
- More diversity in the IT ecosystem: users have it at home, and want it at work;
- Much more consultation and deployment assistance; and
- IT run as part of the business (which means with financial targets [not budgets alone!] for the portfolio and service set).
Getting beyond “we’re in control” and “we only do big” will take hard work, to build the credibility that makes the demand come IT’s way.Advertisements