Wednesday, March 12, 2008

Project management shouldn't involve crystal balls

One of the hardest things to do is to predict the future. The best practice is not to do it. But, sure enough, software companies often become fortune tellers for their customers. They need to tell them that if the customer gives us this money today, they will receive great fortune in only 12 calendar weeks!

So, it's time to make a plan. And a plan begins by writing a specification. Often called a spec – but only because the actual thought put into the document amounts to a speck of detail. Anyhow, a plan arrives at a promise to fulfill. Great people actually fulfill their promises. Most people miss a few things unintentionally. But no matter how well we fulfill our promises, we take the specification and turn it into an estimate of hours, as if we were perfect machines that input a task and output productivity, 8 perfect hours a day.

Or, a perfect 7.5 hours in Austria, which really means 8 hours a day except for 6.5 hours on Friday.

So, most companies assign such plans to a group of people to pull off. The first analysis tends to be something like this: our estimate says n hours, we have m people, and they tend to work at l hours per week. So, (n ÷ l) ÷ m calendar weeks!

I have never seen such a system work where you have multiple people, or for those math-inclined, m > 1.

So the next step turns into a process I like to call task deification. People turn their project into a series of interconnected tasks. One leads into another. And all roads lead towards a Microsoft Project Gantt chart, or some other surrogate. The reason behind all of this work is that you can easily visualize a way to parallelize your tasks.

Task deification isn't a horrible idea, it just doesn't work. The first mistake is assuming your task breakdown is unambiguous, and everyone will do it at about the same pace. If you have done this sort of thing before, it becomes easier, because a group of people will eventually all learn the same things. We work in software, however, and software has a underlying feature that the cost of manufacturing multiple units is practically nothing. So why would you ever solve the same problems twice? Sure, it happens, but chances are, the more you do of the same thing in software, the less significant that thing is.

The other reason task deification sucks is that it inverts the focus to tasks from where it should be – the people doing the work. On the website of Edward Tufte I found a wonderful approach to changing your overall scheduling view. Basically, you exchange axes of the Gantt chart from tasks over time to people over time. I like this approach, because you think first about the people.

People do strange things, especially in software. One programmer might need quiet time, away from disruption, to read about a platform they haven't used before. One QA tester may only understand your product as a black box, and not understand every place it can be broken. One programmer might develop higher-quality code, and another might need someone else to write the documentation. What you need to see are these people and how they operate together. Your tasks will then get great detail when written from the perspective of the person that must do them, instead of the vague specification written by one person.

If the person writing the specification is the person doing all the work, you will have very few problems. Otherwise, you need to step back and look at everything from your people. Projects are made by people. Multiple people do not become one machine. A team is just an organization of people, typically unorganized.

Towards better software projects

Over time, I've discovered a few principles to planning software that actually work.

  • Design until you can break the problem into chunks, each that will be less than 16 hours of work – the infamous "couple of days".
  • You only need to be definite about the next month or two, but you need to think, and design, to the whole.
  • Any other person that might do the work better understand all of the details of this chunk.
  • Plan to adjust; but don't let that be an excuse to ignore details.
  • The person that does the work should define the task, or at least complete it.
  • A volunteered idea is always better than an assigned one.

The thing most companies completely mess up is getting their workers to volunteer. They put themselves in a situation where they have to plan everything up front. And thus, their employees lose all the potential energy and excitement of seeing their one of their ideas come to fruition.

No comments: