After Hours

(This is in two parts -- not enough room) On the surface, the CEO has what seems like a reasonable idea. Unfortunately, it isn't that simple. He needs to understand that each system that is supported is somewhat like an automobile. One good mechanic can work on all types. But, is that the best way? It takes time to learn the ins & out of each automobile -- "regular" engines, rotary engines, deisel engines, etc. The emissions systems are different, and so on. To an observer, it might seemlike "a car is a car". A mechanic knows differently. Software has many similarities to cars in that regard. Almost any developer should be able to work on simple software -- reports, etc. When it gets more complicated, additional expertise is necessary. Knowledge on not only the technical side -- the language(s), the database system(s), communications protocols, intermodule communciations, etc., but also the business logic embedded within the software. Someone working on the accounting software, will eventually, learn a lot about accounts, and how they interrelate. The database guru won't, but does instead have a different set of skills. The CEO needs to be educated into understanding that just as cars are different, so is software. He's not totally off base though. It does make sense to rotate staff amongst the work for lots of reasons. But there is a cost. If Mary has 5 years on the accounting software and Bob starts handling it, Bob won't get things done as quickly, and will probably need some of Mary's time also. So two staff, with 5 years in each of their own areas that swap roles, would require more than the 200% to get the same work done as they did before the swap. If the CEO is willing to invest in that (youhave to come up with the plan/cost) then, yes -- he can get to the "pool", but cross training staff with more than one specialty is probably a more cost effective way to go.

Pools can work, but it would not be good to go to extremes.

If each person in the pool has to support many products, then they will not be as good with each product has they would if they were only supporting one or two.

Some products, like networks, require constant support and monitoring. It would be very confusing to have many people doing this. They would be stepping all over each other.

The last point, and this is the most important one, if you are launching and supporting a newproduct, there will be MORE work to do. I don't know if there would be enough to justify hiring new staff, but eventually you would have to do this.

I would probably be a good idea to form teams, and have each team specialize in one area: networks, desktop tools, programming, servers, etc.

One key factor I believe we need to know is how many systems we are talking of.
Also , are we developing in-house or are the systems developed by some third party ? - Will your staff therefore provide first level of support ?

I believe both factors help in opting between pooling and teaming. The good thing about teams is that staff may specialise in the systems and therefore may provide more efficient support. This is harder with pooling- however this again depends upon the degree of support which your staff intend to provide. That is why I believe that we need to know some further info to be able to qualify the options.

If you have a good relationship with the CEO, ask him if he would like to join the IT department pool. Use this as an example how, like business, IT has different skill and knowledge areas and no one can be an expert in all of them.

On the otherhand, if 25 out of 120 people are IT support staff and you continue to ask for more staff for every new system, perhaps the CEO has a point and your staff may be getting too specialized.

I find ratio of IT-staff to total-staff is somewhat high for non-IT company. Here is what you can do:

1. Frist develop short but job descriptions of each IT staff.

2. Then list all applications and work/functions (like operations, developer, support, Lead) with who is doing it.
E.g.
Developer Installer Operator ... .

Apps-1 ...(initials-with-skills-C-COBOL)...

Apps-2 .........as above .................

3. Now analyze the two lists produced above. You could find ways to re-organize the sections in IT. E.g. It may be good to combine Operations functions of related Applications or it could be easy to combine related Applications. Keep in mind individual preferances and try to accomodate them.

4. Based on decisions in step 3 - cross train wherever required. I think it is always good to have more than couple of people trained and experienced in critical areas if the business. Keep rotating IT staff till staff has real hands on areas they are supposed to know.

Hope this will help you in your problem. Let me know the results if you can.