Bio and Publications

Tuesday, January 12, 2010

FW: Eight Things Business Hates About IT

Eight Things Business Hates About IT. Plus eight things IT hates about business.

I suppose.

While there are 8 things identified, they seem to boil down to 2 things to fix: Replace bureaucratic with Agile; replace Keep The Lights On Management with any other way of budgeting.

While Agility is not a panacea, it does address a lot of problems in more active, engaging and solution-oriented ways.

1. IT can be bureaucratic. That's IT's dumb reaction to failed projects -- add more process. While it seems obvious that projects don't fail for lack of process, that's the standard remediation. The pithy management summary is "The Project Is Out Of Control." But it isn't a lack of process. It's a lack of clarity and milestones that are (a) irrelevant (who needs a detailed design document, really?) and (b) too far apart.

Good point. Something to fix. Use Agile methods.

2. IT can be condescending techies. Whatever. That's a consequence of the huge technical complexity. If non-IT people want a "simplified" explanation, it's going to sound condescending. I don't like this one.

Rotten point. Hard to fix.

3. IT can be reactive. When IT chooses the low-road of "Keep The Lights On Management", it elects to be reactive.

Good point. Something to fix. Spend more time with the business and less time in the server room.

4. IT can propose "deluxe" solutions. Sometimes. Programming is a hobby and too many folks in IT really enjoy their hobbies. But. Managers on both sides (IT and business) both pad projects with stuff that will "add enough value" to justify the costs. It's equally bad on both sides. I reject this as an IT problem per se.

In some cases, this is really a consequence of #1. By forcing projects to be Big, Complex Affairs, solutions get padded.

Duplicate. Agile methods and incremental delivery can push the deluxe features out far enough in time that they don't impact this year's budget.

5. IT doesn't deliver on time. This is a consequence of point #1. IT often adds process where none is needed. Delivery on time is easy, if IT simply delivers incrementally. Customer IT departments have said that a partial solution was of no value, and refused to entertain the idea of risk and cost reduction through incremental ("Agile") delivery. The end users who were in the meeting had to disagree with their own IT people over this -- and agree with us -- that incremental delivery did create value.

Duplicate.

6. IT doesn't understand customization. This is also a consequence of point #1. A too complex, overly bureaucratic project can't tolerate customization (or change).

Duplicate.

7. IT doesn't support innovation. What? That's point #3 again.

8. IT inhibits business change. This is also a consequence of point #1. A too complex, overly bureaucratic project can't tolerate customization (or change).



3 comments:

  1. What do you do when Agile gets wrapped up with process. It seems that sometimes people get hung up on moving cards around and making a processes to impress the "customer" instead of actually getting things done. What do you do when you're one of the IT employees stuck under "processes and tools" instead of "individuals and interactions"?

    ReplyDelete
  2. I do find the distinction between IT and business to be absolute rubbish.

    Do you reckon that in the first 20 years after the Phone was invented they had books warbling on about 8 things business hates about phones?

    Damn right. IT is business. it's as much part of a business as accounts or HR or sales. business that don't see that are the ones that gripe and complain and deliver late and inferior projects.

    You show me a condescending techy, and I'll show you inept middle management, less than fully trained staff, or another "business" problem, they normally go hand in hand.

    One more thing. Agile is not a silver bullet or the cure for all ills. Agile is a way to let you arrange your activity to respond better to change. that's it. it's not IT specific, it doesn't need scrums or issue management or user stories. Those things have their place, and if they're usefull do it. but if you're claiming to be agile and it takes you 3 months to realise you're working on a dud feature you're an idiot.

    As for what you do do if you're stuck under processes and tools. Leave. The company is going to fail eventually anyway, might as well get a head start.

    ReplyDelete
  3. Lessons in IT from Howard Stern

    BW: http://www.businessweek.com/technology/content/jan2010/tc20100120_473287.htm

    ... my $129.99 Sirius radio cost more like $460.26 and at least five hours of my time ...

    ReplyDelete

Note: Only a member of this blog may post a comment.