June 3, 2005
Finding The Optimum Team SizeI'm regularly amused, and occasionally frustrated, when watching very large project teams attempt to build software applications.
Typically, on a team of 100 people, there may be as few as 20 people writing code. The rest will be analysing requirements, writing specifications, negotiating project plans, testing, or providing some kind of leadership at whatever level. As the teams get bigger, everybody seems to get busier. I make a point these days of asking managers if they think their project team is overstaffed or understaffed. Usually it's the managers of very large teams who believe they are understaffed. I don't doubt their sincerity. I imagine they really do feel that there's just never enough time to do everything, but I have serious doubts about the value of everything that they believe needs doing.
Productivity on any project ought to be measured as the speed at which the desired end product or end result is delivered. If your project's goals are to improve sales, then your productivity can be measured by the rate at which sales improve. Similarly, if your project's goals are to deliver working software - software that is useful to the end users - then productivity should be measured by the rate at which you deliver useful software.
Unfortunately, most project teams - and not just in IT - don't measure productivity in terms of the end product. They measure it in terms of the process they go through to deliver the end product. Harking back to the sales analogy, productivity might be measured by how many meetings you have with prospects and how many telesales calls you make in a month. But most sales people don't get rewarded for meeting prospects or making cold calls - well, not in any sane organisation.
The trick to productivity seems to be in recognising where value is created, measuring that value (even if only by relative priority), and focusing all your efforts on realising that value. In very large development teams, if you were to take a Matrix-style bullet-time picture of your project, and analyse what everybody on the team is doing at that momente, I'd be interested to see just how much of that activity is creating measurable value.
Meetings - especially management meetings - have enormous potential for sucking value out of projects. That's not to say that all meetings are like that. If the meeting helps you to remove an obstacle to productivity, or to better define where the value is, then that's fine and dandy. But how many meetings have you sat through that could be described in those terms? One thing managers are very good at is keeping people busy. Meetings, reports, plans, business cases, management proposals - these are all great ways to burn time on any project.
Indeed, burning time is a favourite topic of mine. In a past life I coined the term project heat to describe the energy lost on IT projects to the surrounding environment. A rough way of measuring project heat is to take an application, once it's been built, and estimate how long it would have taken a team of 4 good developers to build it from scratch. Then find out how many people and how much time & money was actually spent, and the difference tells you how much of that project's energy was lost as heat.
For example, I have seen a web application costing upwards of $40,000,000 and taking 2-3 years that I estimate could have been built by 4 developers in about the same amount of time. If we paid the developers $100,000 a year, then the total cost would have been roughly $800,000 (let's call it a nice round $1,000,000 for hardware, tools and other expenses). So the heat lost was in the region of 97%. In terms of value creation, that meant that just 3% of the activity on the project resulted in 100% of the value. That's the 80/20 rule taken to eXtremes!
I fondly recall just how busy everybody on that project was. They worked weekends, they worked long into the night. And they genuinely were very, very busy. But they were also very, very unproductive.
It's an effect that makes life difficult for SPI consultants. When everybody's working 60 hours a week and the schedule is slipping, the last recommendation many managers expect to hear is "you've got too many people". It's a bitter pill, and counter-intuitive to a lot of organisations who still cling to the long-since-debunked management myth that PEOPLE x TIME = PRODUCTIVITY
The human cost of overstaffing teams is the most disconserting aspect of all this. For a while, life is good, and the project is bountiful. Everyone goes home on time and there's plenty of cash in the project coffers. The customer even supplies lunch! But after a while, the sheer size of the team starts to make progress difficult, and the overtime starts to kick in as the schedule slips. Tired and disheartened, the final kick in the teeth is when the project gets canned, or some mean bugger like me strolls in and says "you've got too many people" - either way, people are going to get the chop. I hate it when that happens...
Ideally, project teams should never get that big in the first place, but - given the natural instinct when plans are ambitious and money is flowing to hire and hire (and hire some more) - how can we stop overstaffing?
One suggestion is to start with the absolute bear minimum capability to deliver working software. Just one developer working directly with the customer should do it. If you objectively measure productivity and quality, then you can start to incrementally add people to the team and see what happens. Experience suggests that the improvement in productivity with each new team member will diminish until productivity reaches a natural plateau where adding anyone else won't improve it, and may even reduce productivity and impact quality.
Again, this goes against the grain for many managers, who have been taught to set the team size based on the scope, budget and timescales of the project - starting with a complete team from day one. Since many managers still believe that PEOPLE x TIME = PRODUCTIVITY, these initial team sizes are often already far too big, as timescales are often unrealistically agressive.
Building it in a measured series of increments, you can grow a team to the optimum size where everybody adds enough value to justify their cost. You also have the hard, cold statistics required to clearly show that it really isn't possible to go any faster, no matter how much the customer is willing to spend. Leaving them with the far more powerful planning variables of time and scope to play with.
Posted 16 years, 3 months ago on June 3, 2005