Site icon IT World Canada

When to use contractors and consultants, and when to train

a team working together

Too many organizations look at a new initiative, and immediately reach for the outside market for talent. While bringing in new skills and experience with the new technology you’re implementing is a good thing, you can do too much of it.

For instance, one large financial services institution that I once worked with on a project began a multi-year major technology overhaul, by effectively blocking over 80 per cent of their large, diversified, and generally talented staff from any of the positions that would deliver the change. This is a good way to build a staff that loses its relevance, loses its initiative, and starts to put roadblocks in the way of what you’re trying to do (indeed, that was the outcome).

Contractors should be used when a variable labour force is required: for example, we have 100, need 150 for two years, then fall back to 100.

No rule, though, says the contractors need to be assigned to what’s new. Assigning them at least in part to maintenance and “hold the fort” work while your people grow — alongside others of the contractors — into new roles creates a far more motivated permanent staff, and ensures that skill transfers promised actually take place.

Consultants should be used to bring new thinking to your organization. They are your stimulators — but who’s being stimulated if the consultants lead the contractors, not your people?

One of the key reasons we fall into this trap routinely is because there’s little slack left in the organization. Assigning someone to what, for all intents and purposes, will be a learning experience means that some key piece of work will be undone, or at the very least put at risk.

Too many IT managers have “managed risk” by simply refusing to take it on. Then they decry their staff’s inability to do new things. All too soon, they’re in the outside services trap, where everything new is done by outsiders and the existing staff is seen as an expensive group of “business as usual” types.

Managing risk is what an IT manager is paid to do, and that means managing the risk that maintenance work goes wrong because the experienced staff member is off doing something new while a contractor holds down the maintenance fort.

Managing risk is what you’re also required to do knowing that cross-training your people makes them potentially more mobile. Yes, one or two might take the opportunity and run. If you’re providing a stream of opportunity, though, most will stay and enjoy it.

One key exception to this is when the skills involved don’t need to be retained: a one-time creation of what will be a black box maintained externally (converting from, say, configured servers and storage to a hybrid cloud model built around pre-configured components is a one-time change where the vendor takes on maintenance). In that case, turning the entire project over to an external team may make sense.

But for most of our work, bringing our people along is the right thing to do. Are you doing it?

Exit mobile version