Wednesday, June 27, 2007

IT Rule #5: Outsource deep technical expertise

When looking at your IT staff and considering how to deal with the ever growing load of projects that need to get done, the issue of outsourcing comes up. As it should. The first question to consider is: What might we outsource? The answer is not "whatever we can save money on". That way lies madness and the path to failure.

What might we outsource? Looking at the skills necessary in an IT department, I divide them into 3 areas:
  1. Knowledge of the business
  2. Knowledge of technology
  3. The boundary between 1 & 2.
Knowledge of the business should not be outsourced. At all. At best you can bring in hired guns as analysts. In order for them to be effective, they need to locate on site and be there long enough to actually learn enough about the business to make a difference. But they can walk out the door if they tire of being a consultant or of your business. It is far better, especially for SMBs, to have analysts on staff. If you are small enough, training your developers on analyst skills so they understand the business better.

If you shouldn't outsource knowledge of the business, then you really should outsource the boundary between the two either.

That leaves technology as a possible outsource candidate. Clearly, in order to handle the boundary well, your staff needs to have some understanding of technologies that you have installed and that may be useful down the road. But what you don't need to have on staff (or what you can give up if you need to for resource reasons) is deep knowledge of technology.

For example, your admins may need to manage windows servers and a network. That keeps them pretty busy, especially with projects to improve capabilities. But from time to time you have difficult windows problems and network congestion. Outsourcing that expertise makes sense. Bring in a top-notch network geek and have them fix the problem or look at the overall implementation and make recommendations. Teach your staff one or two things to help future issues and walk out the door.

Another example would be a database administrator. We have three developers with long to-do lists. Having any of them take the time to become DBA-capable would take away from their development effort. And since we have put efforts into making them better analysts, we lose that also. However, bringing in a part time DBA resource makes sense. Such a person knows the deep internals of SQL Server and can easily see things that we won't see. They can make recommendations, help us fix things, implement some monitoring tools, check in once and a while. We get a better DB and we don't have a to add staff to do it.

No comments: