CXO

How large IT departments waste time and effort

Is your IT department being efficient? Here are some ways you could be wasting time and effort.

A lack of self-awareness is OK for children and reality stars, but in the corporate world, the way others perceive you can you can mean the difference between getting an initiative funded and not. It can also affect your job security.

To those outside the IT department, it may not be immediately evident as to what goes into keeping all forms of electronic communication running smoothly, ensuring your servers are maintained, and upgrading software. You have to ask yourselves, are you really being efficient or are there instances where your department wastes time? Here are some ways that IT really does waste time.

IT poison

John Wyss, the Director of Product Management at Intuit, believes that the problem is in micromanagement. He says that, in an IT department: "Work items and progress is managed down to the most microscopic level. Cost estimates are compiled, prioritization and cuts are rendered, and workload is distributed carefully down to each productive resource." Most might consider this to be an example of best practice, tracking the progress of a project right down to the last detail. However, as Wyss goes on to say: "If you are building a bridge, a skyscraper or an aircraft, this is essential, because predictable progress and proper sequencing is more important than maximizing results. If you are trying to build software against a strong set of constraints, it's poison."

The devil's in the details

Wyss' point is that the constraints that tend to feature most heavily are the ones set by the budget and his belief is that too much of the budget can be spent on "process, tracking, trading of this work item for that, and the worst - lots of people debating whether to fix this bug or that - rather than just getting on with the work." If the devil is in the details, it seems he's nowhere more present than in the minutiae of software programming. But surely this is the result of bad project management?

Put the right people in charge

The real problem lies not in the strategies, but in removing the power to make decisions from those who are doing the work. By putting the IT engineers in charge of what they're doing, you're ensuring that they're working within the parameters of what they know, rather than within the confines of a template that, no matter how well-informed, simply doesn't cover all the variables.

Templates tend to be inflexible, which is why IT specialists can waste an awful lot of time trying to make their work fit your ideas. In short, it might be better to let them get on with the job and report back later. As long as the results are what you wanted, surely the details of how they got there are almost irrelevant?

In giving over the reins to those who know how to get the job done, you also communicate your faith in their abilities, which translates into better results. In addition, the shadow of accountability falls over that department, encouraging them to work together to ensure that your IT systems are the best they could be, without incurring time wastage.

11 comments
hamiltonriyon
hamiltonriyon

These are great suggestions. Like having a check up for your health having an outsider look at your IT infrastructure can find really help you get a good perspective on how to make your systems run the best way possible. Corsis offers amazing IT auditing & IT due diligence services that will do just that. Have a look at their website. http://www.corsis.com/

Englebert
Englebert

The finer the plan, the greater the chance of revision when something small goes askew. An inordinate amount of time is spent updating the nitty-gritty numbers rather than just getting on with the job. Some planning is good, just don't be consumed with it

Gisabun
Gisabun

I worked on a contract at one place. They bought "enough" laptops and desktops prior to the migration to Windows 7. But they bought the volume license version of Windows 7 and not the Enterprise - which killed off using Bit Locker. They also had no KMS. When i got there, they already went through at least a half dozen versions of the image create by [from what I was told] was in the end incompitent in making images. It took 3 months before glitches and other issues were settled. By then the image guy was either fired or left [depending on who you speak to]. So they weere stuck weith the image. Meanwhile some staff sat around and did almost nothing for multiple days at a time. In the end, because of more incompitence, they didn't buy enough laptops and had about 80 desktops too much - which they couldn't return. They ended up buying more laptops to fill the demand but without accessories.

santucciaj
santucciaj

"As long as the results are what you wanted, surely the details of how they got there are almost irrelevant?" Nope. Details are important so that when you have staff turnover, you know what was done, by whom and how it was accomplished. Otherwise, let the wheels continue to spin. Lead, don't manage -- you will be impressed by the results.

Systems Guy
Systems Guy

That is one reason why I have always liked and worked at, until recently, small shops. At small shops, the staff is more empowered to do things, i.e,. get the work done. Currently with meetings and paperwork required, it's a bureaucratic mess. We actaully have to work an extra hour everyday, and enforced by HR, to get our work done because of the time we spend in meetings, etc.

sbeighle
sbeighle

While I appreciate this perspective, it also assumes far too many things. First, it's very unlikely that any IT department is undertaking a single project at any given time, therefore what resources you have at your disposal are not focused only on that one project. Second, this article assumes that the customer knows exactly what it is that they want, which is rarely the case from my experience. As any project progresses more and more "what if it did this or that" comes into play, then your project starts taking twists and turns to the point that it looks nothing like what was originally planned for. That's ok, within reason and so long as it comes early in the project, but if you try to develop under the whimsical project management standard (WPMS...I hereby claim credit for naming this standard) your project is never going to be complete, resources will never be released to focus on other business needs, developers will become disgruntled because they never achieve a sense of accomplishment and the customer, the customer will just get annoyed by this project that never goes away.

Tony Hopkinson
Tony Hopkinson

What you should do is break it up, de-centralise. Don't know why this has never been tried before... Go ahead be a new broom, de-centralise. Get promoted, move on etc. The guy who replaces you will have a look round for sweeping opportunities and decide that efficiencies could be made (usually savings on people and or equipment) by rationalising all your vaunted disparate efforts under one umbrella. No doubt you'll be able to dig out the justification from some past effort in this regard. Boring...

lunchbeast
lunchbeast

Another example of another 'hey look at me' article by another inexperienced uninformed IT wannabe that really makes me question the garbage that's being given voice and audience by TechRepublic these days. Anybody who's ever worked on a big project where everybody is doing their own thing their own way has seen the danger of of this kind of hands-off non-management. Most often, the problems on IT projects originate from poor managers, not management in general. An unherded flock frantically running 50 different directions is just as counterproductive as a well-tended herd going the wrong direction. And no, I'm not a PM. Senior software engineer for more years than I care to remember. lunchbeast

pconaty
pconaty

Have to say i have not seen much micromanagement of IT shops in my experience. Projects maybe but the real day to day operational work is generally far more chaotic and reactive and that is usually where time and resources can be wasted. Generally because IT budgets are so constrained it can be hard to step back from the reactive stuff and spend time and money on getting automation and procedures in place that would allow your key IT resources to spend more time on high value project work.

Tony Hopkinson
Tony Hopkinson

Surely you mean if. :) It's a good point though. Small shops you have a few people working on the same things all the time. Most of the knowledge is in their heads. A big shop even with low turnover, you are liable to have a pool of people. So the next poor chump may not know the system, no documentation, they have to guess their way through it again. I'm a big believer in procedures in small shops, big ones, its not an optional extra.

Editor's Picks