More on Creating Faster Cheaper Projects

Hal posted his take on creating faster cheaper projects. I see that I did not make my assumptions clear in my original post. Hal had three problems (at least!) with my post:

  1. Fewer people increase the length of the project.
  2. The longer the project, the more the requirements will change (No disagreement from me!)
  3. Organizations must be able to respond to market needs.

Let me address the idea that fewer people increase the length of the project. In my original post, I meant that you could start with fewer people, adding the people you need when you need them. Here’s a picture of a real project that finished “on time,” because the date was the primary release criterion, but we only delivered about 75% of the requirements.

We started off with just a few people, but when we needed people, they were unavailable. This is the case where Hal’s advice is absolutely correct. In this project, we’d originally planned for 666 person-months, and spent 878 person-months, about 1/3 more for 1/4 less product. When you can follow Hal’s advice you should (and I’m quoting him here):

Promise the end conditions at the first responsible moment and then commit to all the intermediate actions and start at the last responsible moment.

But here’s the situation I meant to address in my original post. Let’s assume the organization does not sufficiently differentiate between project priorities, i.e. not performing real project portfolio management. People are assigned to the next project as they come off previous projects, similarly to the graph above. Since each project requires more people than anticipated, each project starts late, with too few people. Soon, all of the projects are starved for people, and all of them require more people and more time for fewer deliverables.

I’ve seen other situations, where everyone was assigned to the project on Day 1. Only a few people can actually do anything useful on the project for a while (and of course, this varies with each project), so the other people take energy away from the project and don’t add anything useful.

I think Hal and I agree more than we disagree, but I’ll leave that for him to decide 🙂 In organizations with weak project portfolio management or prioritization among projects, I’ve seen projects succeed when they started with only the people required at the beginning of the project and no more. I’ve also seen projects succeed when they started when some of the people were available, so that more people could enter the project at an appropriate time. The longer a project is starved for people, the longer (and more expensive) it is for the project to be successful. The more unnecessary people added to the project too early, the longer and more expensive the project is.

The later you start projects, the more frantic the project pace is, leading to more defects and more rework. And, the more likely that people have uncleared “commitments” to other projects, which leads to more multi-tasking.

So, I’ll stick by my original idea (Hal, thanks for the nudge to be more explicit): If you want cheaper or faster projects, start them earlier. Don’t starve a project and expect to “make up” time when you add more people. Don’t expect to get away with understaffing a project either — it will take more time and more people in the long run. Don’t overstaff a project if you started it late, you’ll have to settle for less product in the same time. Staff projects so that the necessary people are assigned when the project needs them, and let them commit to a reasonable pace. Then you’ll have projects that cost what they should cost and take as long as they should — not too expensive or too long.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.