Why Managing Small Projects is Harder

April 17, 2008 by JurgenAppelo

Some people think that managing small projects is easier than managing big projects. They are right, unless the economies of scale require you to manage a number of those small projects at the same time. In that case, managing small projects is a lot harder than managing a big project!

Dedicated servers vs. shared servers

Many web sites are too small to run on their own dedicated servers. I know, I've built a lot of those sites. They usually run on shared servers (together with other web applications for different customers). As many system administrators know, management of a shared server is a lot more work than management of a dedicated server. On a shared server, the applications are fighting for the same resources (memory, drive space, database connections). And we must try to make sure that, when something goes wrong in one application, it doesn't bring down all the others too. Unfortunately, this does happen occasionally. One time it might be because of a Denial-of-Service attack against one particular site, another time it's simply because I screwed up again with one of my infamous infinite error loops. Customers often complain when problems with another site causes a failure on theirs. We then kindly suggest that they open up their purse and get themselves a dedicated server. Or, as a bus driver might say, "If you can afford yourself a taxi, sir, then why take a bus?"

Dedicated teams vs. shared teams

I see the same problems with software development teams. I have worked in a number of organizations where projects where too small to form dedicated teams. These organizations usually work with shared teams. The resources in a shared team have to be shared among different projects. The customers simply don't pay enough to give them the full attention of one entire team. Management of such a shared team is a lot more work than management of a dedicated team. The projects are fighting for the same resources, and you must try to make sure that, when something goes wrong in one project, it doesn't take down the other ones. But again, this does happen every now and then. Customers complain about it, for sure. We then kindly suggest that they buy themselves a dedicated team, which they never do. They prefer complaining over paying twice the fee. Just like ordinary bus passengers.

Agile methods assume a taxi, not a bus

There are many shared teams in the world, and not just in software development. Many hair dressers, car mechanics, accountants and lawyers work in shared teams. Such a team doesn't serve just one customer at a time. (Except for teams of lawyers with a customer the size of Enron.) Each team member usually serves a different customer, and resource planning can be cumbersome, because of the many cross-customer interdependencies. Unfortunately, every agile method assumes that customers have bought themselves the privilege of working with a dedicated team. It's as if they assume that people always take a taxi, and nobody takes a bus. It's a pity, because managing a bus is a lot harder than managing a taxi.

Can agile principles help a shared team?

Yes, I've seen that it is possible, but it takes a lot more effort. First of all, it takes one very strong project manager (or Scrum Master) to negotiate alotted time with many different customers (or Product Owners). Second, you have to translate all best practices for dedicated teams to the shared sitation. (Stand-up meetings are slightly different. Backlogs are treated differently. Iterations are very different. Pair-programming works in some cases, but not all. Etc.) Third, you have to educate anyone who thinks that you're "only doing simple projects". Because, when you can manage a number of small agile projects simultaneously, then you are able to manage anything!

Any bus driver can drive a taxi. But few taxi drivers can drive a bus...

Permalink