See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos.

In my last articles, I put forward the following positions:

You have to go fast
Not everybody is going to be happy when you bring change

Now I want to explore how to go fast, particularly as it relates to resourcing.

Most people have heard of Parkinson’s law, "work expands so as to fill the time available for its completion”, there is also a lesser known corollary, Horstman's law: "Work contracts to fit in the time we give it."

Applying both laws, and a concept that time is a fungible commodity in IT programs; consider 2 options

Option 1: The small team

Limits what can be done
Forces a focus on critical scope
Minimizes complexity in the program
Limits scope creep for practical reasons
Reduces costs from “start” to “production”
Pushes incremental scope into phase 2
Because of the minimized scope, the program completes more quickly
Because the project is done faster, real users get to use the new systems sooner
Because users get the system faster, real phase 2 needs are understood sooner

Option 2: The big team

Allows the concept of “we want the ideal system” thereby increasing scope
Allows “edge case” scope creep thereby increasing complexity
Increases “inside the box” thinking, “we do it this way - make the new system do it that way”, “we are paying for what we want”
Increases the costs to get to a “production” system
Increases the time between start and users getting their hands on the system
Increases the amount of time to get to real “phase 2” needs because of the focus on edge cases

I acknowledge that it may seem less palatable or seemingly sensible to run small teams at big problems, because of the forced compromises along the way, but the downsides of a large team are seldom understood, never discussed by vendors, rarely acknowledged as they are happening, and not well understood, even in retrospect, even after an embarrassing program failure.

So now let’s think about resourcing, in the process of setting up a team to do a major technology program, one has a number of possible options:

Pull together an internal team
Hire an external team as future permanent employees
Hire large scale systems integrator consultants
Hire vendor related consultants

Of course you can blend any or all of the above, but each has its pluses and minuses.

Pull together an internal team

An organizations’ highest performing people are needed to run the business, and they’re unlikely (in the extreme) to be released for a relatively long time for a program whose success is, at this point, questionable (remember most organizations have tried big projects before and have a high failure rate. Putting lower performing people into what amounts to a heart transplant for the organization will produce correspondingly low performing results.

Hire an external team as future permanent employees

This gives you additional talent, with “new world” skills, but less understanding of your business, and leaves you to manage the communication and activity discontinuities. Plus are these people really going to settle into the stable new world after the system is live, how is this being planned for?

Hire large scale systems integrator consultants

This almost always runs counter to my experience of success, and is by far the most expensive. I believe that this is because the personal career drivers for the senior people are not well aligned with the customers’ success. Most Buck from the client cannot be well aligned with clients’ best bang for their Buck.

Hire vendor related consultants

This always seems attractive, “one butt to kick” is often quoted, but I have found that big systems development firms treat their consultancy arms as a bit of an afterthought. The effect I have seen is that they are knowledgeable, but not invested in going quickly or invested in their clients’ interests.

The outlook for all of the above options is pretty grim, and realistically some element of blending is always going to happen, so how do we make this work.

I believe that a key part of success is to do 2 things right from the start:

Align personal team members' interests with the outputs desired, i.e. getting the programs' key tasks done as quickly as possible, encourage the race to get live, and
Lay out a longer term vision of how all of the resources benefit in the longer term from the program, i.e. show that there is a longer term need to resolve the compromises made along the way, where business benefit can be incrementally earned by progressive improvements in the program output.

To achieve both of these things, the team needs to be no larger than that which will eventually be required to manage and support the system, and it may well be smaller, ready to either absorb resources released from the previous system, or increase organically based on the backlog of tasks developed after the program go-live To do the program, all it needs is a small team!

Going all the way back to Steve Jobs’ comment at the top, I have found that you can develop A-Plus players, by building small teams, and setting great goals.

"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." - Margaret Mead