Black-box project management
Par Olivier Azeau le 3 novembre 2006, 22:06 - In English - Lien permanent
I love metaphors on project management. I just read a good one by Tom Looy : "How Long is a Piece of String?". You can get an estimate by looking at it but you will get a more accurate value by measuring it with a ruler. Estimating is not an easy job, especially when it comes to predicting when a piece of software is done. In the early stages of a software project, when you can barely estimate and certainly not measure anything, fixing scope, cost and dates is impossible.
Years ago, I was appointed software project manager for the first time. Being a software developer, I intuitively knew that I should be careful with scope, cost and dates issues. I was reluctant to draw a full gannt chart too early in the project because I suspected that people would rely too heavily on it. The projects director I was reporting to told me : "This is not a way to run a project. You must list every task for the project, estimate them and put them in the chart then you will get a release date. From there you will start tracking the team progress". I complied with the order.
Any experienced project manager obviously knows what happened : as the first tasks were not completed on time, the release date started to slip.
The estimates were indeed very bad. Half of the developers had just graduated from university and relying on their estimates was the worst thing to do but the rookie project manager didn't know that.
Now imagine this project is a big black box with 3 levers...
Years ago, I was appointed software project manager for the first time. Being a software developer, I intuitively knew that I should be careful with scope, cost and dates issues. I was reluctant to draw a full gannt chart too early in the project because I suspected that people would rely too heavily on it. The projects director I was reporting to told me : "This is not a way to run a project. You must list every task for the project, estimate them and put them in the chart then you will get a release date. From there you will start tracking the team progress". I complied with the order.
Any experienced project manager obviously knows what happened : as the first tasks were not completed on time, the release date started to slip.
The estimates were indeed very bad. Half of the developers had just graduated from university and relying on their estimates was the worst thing to do but the rookie project manager didn't know that.
Now imagine this project is a big black box with 3 levers...
The first one is labelled 'product'. It shows the number of features implemented by the project weighted by their associated quality level (which is either explicit or implicit).
The second one is labelled 'cost'. It represents the global cost of the project from hardware to human resources including the productivity of each resource.
The last one is labelled 'duration' and is the release date.
As a project manager, you only have 2 hands so that you can grip 2 out of 3 levers and watch the 3rd one move freely...
Listing every possible task for the project means that you set a list of feature and decide some quality for each of them : the left hand is on the 'product' lever.
Estimating these tasks means that you evaluate a cost for each of them : the right hand is on the 'cost' lever.
Now you can start watching the 3rd lever (the release date) moving upwards !
Of course, time is money. If you don't want to see the 3rd lever being stuck centuries from today (which would mean a project that has no way of ending), you've got to move the cost lever upwards for paying the resources extra time.
This is exactly what happened in my first project.
At some point, people said that we could not afford releasing after a given date : we had to catch this damned 'duration' lever and hold it tight.
We had to choose a hand to do the job. As somebody had promised a list of features to the customer, the left hand was not available. The right hand had to let the 'cost' lever go freely and grip the 'duration' lever.
Guess what ? The 'cost' lever started to move upwards !
People were pushed to stay later and come to work on week ends "to give some fresh air to the project", in the general manager own words.
The productivity fell as developers got depressed. They were indeed paying the cost rise.
The customer had to pay too. In this period, I was asked to find every possible woolliness in the customer requirement documents in order to get some extra cash. "Hey Mr Customer ! What you want now is not exactly what you wrote, You've got to pay for it !"
No need to say that when the cost rose too much someone said "Stop !". The right hand being on the 'duration' lever, the left hand had to stop the 'cost' lever before it hits the ceiling...
Cost and duration were now in control. As it was still impossible to tell the customer that features had to be dropped, the quality level dramatically fell as the free 'product' lever went downwards.
Eventually, features were dropped and someone had to explain to the customer why this project was a death march.
Most of the time, holding the 'cost' and 'duration' lever from the beginning is the most sensible solution because :
I once read that "project plans are either lucky or late" but, actually, project plans are either lazy or late : fixing a scope does not bring any guarantee that the product will be available on schedule and budget and in the same time, it makes no sense to stick to a scope when there's some room left.
That being said, sometimes feature can be really mandatory (e.g. safety issues). In these cases, focusing on cost and duration is meaningless because being late is less important than being out of scope.
In the end, the only thing we should care about is knowing, at any time, where our hands are, which levers are in control and which lever is currently moving freely so that we can have a look at it.
The second one is labelled 'cost'. It represents the global cost of the project from hardware to human resources including the productivity of each resource.
The last one is labelled 'duration' and is the release date.
As a project manager, you only have 2 hands so that you can grip 2 out of 3 levers and watch the 3rd one move freely...
Listing every possible task for the project means that you set a list of feature and decide some quality for each of them : the left hand is on the 'product' lever.
Estimating these tasks means that you evaluate a cost for each of them : the right hand is on the 'cost' lever.
Now you can start watching the 3rd lever (the release date) moving upwards !
Of course, time is money. If you don't want to see the 3rd lever being stuck centuries from today (which would mean a project that has no way of ending), you've got to move the cost lever upwards for paying the resources extra time.
This is exactly what happened in my first project.
At some point, people said that we could not afford releasing after a given date : we had to catch this damned 'duration' lever and hold it tight.
We had to choose a hand to do the job. As somebody had promised a list of features to the customer, the left hand was not available. The right hand had to let the 'cost' lever go freely and grip the 'duration' lever.
Guess what ? The 'cost' lever started to move upwards !
People were pushed to stay later and come to work on week ends "to give some fresh air to the project", in the general manager own words.
The productivity fell as developers got depressed. They were indeed paying the cost rise.
The customer had to pay too. In this period, I was asked to find every possible woolliness in the customer requirement documents in order to get some extra cash. "Hey Mr Customer ! What you want now is not exactly what you wrote, You've got to pay for it !"
No need to say that when the cost rose too much someone said "Stop !". The right hand being on the 'duration' lever, the left hand had to stop the 'cost' lever before it hits the ceiling...
Cost and duration were now in control. As it was still impossible to tell the customer that features had to be dropped, the quality level dramatically fell as the free 'product' lever went downwards.
Eventually, features were dropped and someone had to explain to the customer why this project was a death march.
Most of the time, holding the 'cost' and 'duration' lever from the beginning is the most sensible solution because :
- If you hold onto 'product' and finish below expected schedule, your customer misses the opportunity to get some extra features
- If you hold onto 'product' and finish beyond expected schedule, you're late and the customer is not happy
I once read that "project plans are either lucky or late" but, actually, project plans are either lazy or late : fixing a scope does not bring any guarantee that the product will be available on schedule and budget and in the same time, it makes no sense to stick to a scope when there's some room left.
That being said, sometimes feature can be really mandatory (e.g. safety issues). In these cases, focusing on cost and duration is meaningless because being late is less important than being out of scope.
In the end, the only thing we should care about is knowing, at any time, where our hands are, which levers are in control and which lever is currently moving freely so that we can have a look at it.
Commentaires