Reply to: IT support teams organisation

[MPwannadecentincome]

Not if you know how to choose your people. It would also have the added benefit of weeding out people unfit for this sort of job.

You don't have to be the sucker paying for nothing.

When I see an incompetent team, my first thought is, "the hiring manager should be fired".

Great advice if its a greenfield site or if the place if full of contractors and budgets and HR policies allow the manager to get the 'best'.

Not so great if the poor manager has inherited a team or has been given the leftovers from more lucrative projects or has been told by HR "no way can you pay anyone that much for a developer".

So weed out where its possible, where its not you have to work with it.

[BarbarianAtTheDoor]

As really good dev teams are the exception not the norm, then some process is required.

Not if you know how to choose your people. It would also have the added benefit of weeding out people unfit for this sort of job.

You don't have to be the sucker paying for nothing.

When I see an incompetent team, my first thought is, "the hiring manager should be fired".

[MPwannadecentincome]

Processes are for people who have never seen a really good dev team.

As really good dev teams are the exception not the norm, then some process is required.

My first question is what happens if your superstar dev dies in a car crash mid project? Can the project still deliver? That's what processes are for.

Often are really good dev team is really just one person and a few others doing things around the edges - and if something happens - boy does everyone sit up and notice then! Unfortunately the processes in these cases are only as good as the superstar's willingness to follow them - a bit of catch 22 here.

[Gonzo]

I must admit to being slightly perplexed by the 'Dev vs. Support = who's best?" debate.

I agree with Barbie, but am baffled by him at the same time..

Of course you need good developers, in the long run it's better (and cheaper) to prevent bad design and bugs than to fix them down the line. But when software stops being 'sexy' to developers (ie, once it's written and tested) and they've gone onto the next dev project, it still needs to be released and supported for the benefit of customers (who are paying our day rates, ultimately). And don't forget software does bugger-all without it sitting on a server, probably playing with a database, talking down the wire to another server somewhere else, maybe even saying hello (wirlessly) to a laptop....

It's not a case of who wins the race in a dash to the finish, it's a team race - if the baton gets dropped by anyone the race is lost...

This is a really interesting topic (if you are a sad bastard like me) but I don't really want to hijac the thread.

In my experience all devs have an over-inflated sense of their own abilities so jump at the opportunity to operate in an Agile environment (because it is like the old days when everyone was baffled by and in awe of what they could do and gave them free-reign to do what they liked).

My first question is what happens if your superstar dev dies in a car crash mid project? Can the project still deliver? That's what processes are for.

[BarbarianAtTheDoor]

I didn't intend to make this about the support team, the point i was trying to make all along was that since the biggest fluctuation in quality is on the dev side, you have to concentrate on that first and foremost.

I don't think we could get by without DBAs or infrastructure ppl, I think that DBAs and the latter mess up less than we do.

[cojak]

I must admit to being slightly perplexed by the 'Dev vs. Support = who's best?" debate.

I agree with Barbie, but am baffled by him at the same time..

Of course you need good developers, in the long run it's better (and cheaper) to prevent bad design and bugs than to fix them down the line. But when software stops being 'sexy' to developers (ie, once it's written and tested) and they've gone onto the next dev project, it still needs to be released and supported for the benefit of customers (who are paying our day rates, ultimately). And don't forget software does bugger-all without it sitting on a server, probably playing with a database, talking down the wire to another server somewhere else, maybe even saying hello (wirlessly) to a laptop....

It's not a case of who wins the race in a dash to the finish, it's a team race - if the baton gets dropped by anyone the race is lost...

[BarbarianAtTheDoor]

Glad its no big deal. Can I hire you to solve all my problems please? You seem to know everything.

Sorry, sitting in a contract until mid next year, but would be happy to sort your problems out, done that before, in fact, i used to work for a firm specializing in rescuing botched outsourced projects.

Without being too sarcy ; it looks like you are coming from an 'agile' type perspective and I completely see the value in that but it annoys me sometimes that agile is seen as the new be all and end all IT.

You couldn't be more wrong.

There is a good argument to be made for agile methods but I do think that things should become more process driven at release time and once services are actually doing something useful in production. This is where ITIL really comes in to its own.

Processes are for people who have never seen a really good dev team.

One quote I heard recently was something along the lines of so many times genius is replaced by process.

Indeed, if quality is not of utmost concern, and if the fact that it will cost you 2-3 times as much as picking the right devs is not a factor.

The rest of what you were trying to say, I just couldn't make out from the static.

All these buzzwords are for people who don't want to face up to the facts, which are:

• A very good developer produces 10 times as much as a mediocre one (but really, they are just not comparable, one does the job, the other doesn't)
• The manager's competence is secondary to even the mid-level devs'
• That sw support is basically done by developers who either never had a chance to prove themselves or blew it earlier
• That overwhelmingly the good ones will end up rewriting the codes of all the others just to make it work
• The most important person is the one making the hiring decisions

I've been working on this field for 10+ years, and I only realised the above after ~5, I used to believe that devs should be replaced by processes and that we're all doomed because of India.

TBH, I'd love to see that happen, I could swipe the floor with all these shops with my own firm.

Trouble is, most firms where they know what they're doing have already moved away from this, realising how incredibly costly it is to have something rewritten 10 times over, eventually by someone who knows what he's doing.

I can easily name 3 dev shops where they learned this the hard way, you guys are touting a 5 year old lesson, just like how middleware has only recently been gaining ground in this country.

The UK in general is technically miles behind from the rest of Europe I've seen.

No offence, but where can I get a proper SIP service-provider in the UK for my mobile phone?

[malvolio]

Happy to help explain in more detail, for a sensible fee. Knowing where you're going is as important as knowing how to get there. Drop me a PM if you're interested.

[gables]

You can't, which is what most people miss. There is a cycle of 10 core processes in ITIL2 (and something similarly cyclical in ITIL3), all of which are interdependent. You might consider implementing very skeletal processes in some areas but you can't implement the full solution until you have effective processes at all ten points. So get the basics in and evolve them together.

And start with a Service Catalogue. Until you know what you're supporting and what supports it, you're going nowhere. Don't do the usual mistake of starting with Incident and Change in isolation: it won't work.

The invoice is in the post...

oh tulip!

[southseas]

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.

Glad its no big deal. Can I hire you to solve all my problems please? You seem to know everything.

Without being too sarcy ; it looks like you are coming from an 'agile' type perspective and I completely see the value in that but it annoys me sometimes that agile is seen as the new be all and end all IT.

There is a good argument to be made for agile methods but I do think that things should become more process driven at release time and once services are actually doing something useful in production. This is where ITIL really comes in to its own.

One quote I heard recently was something along the lines of so many times genius is replaced by process.

While I appreciated the sentiment I couldnt help but think - penetrating insight or double edged sword?

Also the concept of a service is sometimes confusing to some. They like to talk of a product and stories which will build that product. aka scrum.

Semantics and all fine and well I suppose - but wouldn't it be great to start off with a service catalog that actually shows what IT services (products if you prefer - but I dont like the term) are provided to the customers and use that as a high visibility starting point?

I think agile should be wrapped in something like ITIL for some good loved up synergy.

But hey - im just a wandering philosophizing mercenary a long way from home

[malvolio]

Supposedly we're looking to implement four ITIL processes...

You can't, which is what most people miss. There is a cycle of 10 core processes in ITIL2 (and something similarly cyclical in ITIL3), all of which are interdependent. You might consider implementing very skeletal processes in some areas but you can't implement the full solution until you have effective processes at all ten points. So get the basics in and evolve them together.

And start with a Service Catalogue. Until you know what you're supporting and what supports it, you're going nowhere. Don't do the usual mistake of starting with Incident and Change in isolation: it won't work.

The invoice is in the post...

[gables]

Indian call centres.

Look up ITIL for service management and service delivery.

Look up SFIA for the rest of the IT department.

Look up CMMI for what is achievable.

ITIL and SFIA are best practice and they provide a framework for what to do and who should do it. Personally I think SFIA is the dog's bollocks for a IT Department Head. CMMI informs you of what is realistic change based on where you are starting from.

For £1,000 / day + VAT I shall come and talk to your management if they ask me. If you refer me, I'll do it for £600. It'll take me a year to implement it and they'll need to spend £20k - £100k on training and £20k - £50k on software. At the end of 12 months they will be a tulip hot IT department.

KPMG, Deloittes et al will set up a PMO or PPSO and charge (2 + 1.5 + 3*1 = 6.5K / day for 4 days per week for 40 weeks) about £1,000,000 to do the same thing.

HTH

Trouble is that year's cost will buy us a new SAN, which would be preferable to a tulip hot IT department

Supposedly we're looking to implement four ITIL processes...

Interesting read regarding the dev bashing, but we don't have dev in the same way you guys envsion. What I detailed in my first post is the 'tech support' side of things, there is another part that is the 'business' end of things, although that bit also includes the service desk and 1st\2nd line support.


So; were the replies in posts 3 and 5 it? no other comments regarding actual team organisation?

[malvolio]

Same root causes, though. Poor design, lack of attention to potential causes of failure, insufficient redundancy or capacity, poor integration and regression testing, too early release...

Agreed you have to draw the line somewhere, but usually we will accept in service hiccups and bug fix releases. Testing can never replicate real world conditions at the hands of real-world users. However, big failures are a different matter.

[JoJoGabor]

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.

You're fogetting infrastructure type projects, say a network implementation, a virtualisation project, a SAN implementation. You can't blame failures in this type of project on developers. Its usually flawed architecture that maes these fail.

[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.