IT support teams organisation

[herman_g]

I had to read about ITIL, it was a book that had empty pages on it, but it was full of text. Magic!

If I had a dev firm, I'd never allow ppl with these convictions around it. I've seen process-based development "work" (about 7 years ago first time), it lacked everything I chose sw development for; barely usable software being the end result for 3 times the cost they could have achieved with carefully picked devs.

It's about having well-paid, well-motivated stars on your team, nothing more.

It's hardly ever about the managers, it's usually about your seniors.

In fact, the best I've seen out of managers was when they surfed the web all day and came back with ridiculously huge margins for the project.

Agree 100%.

Management is really the only unnecessary overhead in most development shops.

Experimentation with various management models only ever prove to be spanners in the works.

[JoJoGabor]

ITIL is overkill but it does have some good elements. In order to implement it successfully you need to cherry-pick the bits that you need. The Change management processes are particularly useful. Usually its getting the dev teams to adhere to them thats the problem

[malvolio]

OK, so I'm a managerial type with a specialisation in Service Delivery, so I may be slightly biased. But....

ITIL is best practice, not a methodology. As long as you stick to the basic 10-step cycle and use consistent terminology, you don't need vastly detailed processes, general priniciples will do fine.

Deve teams, though - they have this quaint idea they're the leaders in IT. One day they'll twig that they are the bottom of the food chain: no matter how good they are, without someone to release their work, track issues and manage changes, they'd be nowhere...

Always remember a quote from the 70s, when a local reporter was talking to a colleague of mine: "So, you're a 'Computer Programmer' then? You write 'Computer Programmes' I suppose. Tell me, where do you get your ideas...?"

[herman_g]

Deve teams, though - they have this quaint idea they're the leaders in IT. One day they'll twig that they are the bottom of the food chain: no matter how good they are, without someone to release their work, track issues and manage changes, they'd be nowhere...

Don't get me wrong - a truly good manager is worth his weight in gold. As long as he knows his place and spends the least amount of time interfering with my productivity.

Hell, I have only filled out a time accountability-type timesheet ( was with Cap Gemini - real management experimentation-types ) on one contract since 1997 - the good ones quickly realize my work cannot be broken into various accounts and just fudge the numbers accordingly.

I find I have my best success when I deal one or two levels above my immediate boss. They seem to be the only ones that can truly relate to contractors on a personal level.

Far from "bottom of the food chain", my salary has been a constant point of contention with immediate managers as it has been far higher than theirs since the early '90s.

Your bottom-of-the-food-chain comment tends to tell me you are well-versed in the the onshore-offshore ratios of the "global delivery model".

[MPwannadecentincome]

Anywhere I go, the most successful projects are where they have the best developers and the least interference from management.

IT Depts are not just about developers
creating the software is only half the story....

[malvolio]

Your bottom-of-the-food-chain comment tends to tell me you are well-versed in the the onshore-offshore ratios of the "global delivery model".

No, I'm speaking organisationally. There are three major groups of IT staff, but no one is any more or less senior/importnat/deserving of moolah than any other. Coders are there to develop the basic tools of the business according to given design requirements. Service delivery puts those tools in front of the business, ensures they work as required and that the buisiness knows how to use them and manage changes without breaking things. Managers ensure the necessary resources are in place.

Think about it. Which one is closest to the business, day-to-day? It's deffo not the dev team and it's not the management, it's First Line support: you know, the know-nothing geeks on NMW...

[BarbarianAtTheDoor]

IT Depts are not just about developers
creating the software is only half the story....

Yes, you're right, they're not alone. But they are the most critical bits in the process though, as in "most likely to fail if not done well".

I can easily do support work, not the other way round.

You don't need geniuses for support, you need processes there. Real developers however, are artists if they are any good.

[BarbarianAtTheDoor]

There are three major groups of IT staff, but no one is any more or less senior/importnat/deserving of moolah than any other.

Oh yes, they are. Everyone depends on what devs do, in fact it drives both other team's results. Tulip sw-> Tulip support -> failed project.

We do take over support from time to time when the tulip hits the fan, we also do BA work when needed. It's no big deal.

[malvolio]

Oh yes, they are. Everyone depends on what devs do, in fact it drives both other team's results. Tulip sw-> Tulip support -> failed project.

We do take over support from time to time when the tulip hits the fan, we also do BA work when needed. It's no big deal.

You're trying to convince someone with 20 years development experience and 15 years in Service Management. who has built effective departments and made broken ones work. It's only my opinion, but I venture it's a pretty informed one.

tulip s/w is built from tulip designs which are written by badly managed development teams. tulip support is becuase the s/w is not properly documented and has not been tested against the needs of a totally dumb business user before being sent for release, and becuase supportability has not been considered (something ITIL has only just realised, 20 years too late). Business users rarely, if ever, see development teams, which is one reason they're happy to offshore them, they have no idea how valuable an in-house dev team really is..

Most broken departments in my experience are because nobody accepts that the other teams are every bit as important as their own. As you are trying so ably to demonstrate

[BarbarianAtTheDoor]

I don't care about broken departments, I care about broken projects, and I've never-ever seen a project fail for anything other than development. In my book, if support cannot be done on the software by a trained monkey, the devs cocked it up.

Failed projects are always down to either the requirements being bloated and the devs not realising this and telling the BAs early enough (devs' fault) or incompetent devs, which also results in unmaintainable software.

Anyhow I slice it, projects fail on the developers.