What can we do if what we think* we have to do doesn't fit the available
time, or if we want to do things in less time?
There are several ways we see people use to try to finish a project earlier, most of which seem intuitively right, but don't work, on the contrary. This contradiction causes people to think that we have to accept late projects as a fact of life. After all, they did their best (most people do!), even took measures (correct measures according to their intuition), and it didn't work out. As Deming [Q1] said: "Doing your best isn't enough." First you should know what to do, have an approach how to do it best and a mechanism to constantly improve that approach and then you do your best. There are, of course, also measures that do work.
Let's first do away with the 4 deceptive measures. Deceptive measures are measures we see applied in almost every project, but they only make things worse. It's surprising that people don't learn and keep using them.
Starting as late as possible, only when the pressure of the Fatal Date is really felt (attributed to E. Goldratt2).
When you had to study for passing an exam, did you work hard three weeks before, or mostly the night before? Be honest.
At the new deadline we probably hardly have done more, getting the project result even later. Not a good idea, unless we really are in the nine mother's area (see next), where nobody could do it, even with all the optimization techniques available. It's better to optimize what we can do in the available time before the deadline. The earlier the deadline, the longer our future afterwards, in which we can decide what the next best thing there is to do. So the only way a deadline may move is towards us.
The Myth of the Man-Month
The effect is, however, much trickier: if in the first several weeks of a project we find that the speed is slower than expected, and thus have to assume that the project will be late, even then adding people can make the project later. The reason is a combination of effects. More people means more lines of communication and more people to manage, while the project manager and the architect or the Systems Engineer can oversee only a limited number of people before becoming a bottleneck themselves. Therefore, adding people is not automatically a solution that works. It can be very risky.
Brooks' Law with measurements on some 500 (software) projects. He found that
if the project is done by 2 or 3 people, the project-cost is minimized.
With 5 to 7 people the project-duration is minimized, at premium cost because
the project is only 20% shorter with double the amount of people. Because Time to Market
often is of huge economic value, this is probably an economic optimum.
Adding even more people makes the project take longer at excessive cost.Because there is a critical path of things that cannot be parallelized, the project duration cannot arbitrarily be shortened. We call the time in which nobody can finish the project the nine mothers area, which is the area where nine mothers produce a baby in one month.How can those mega-projects, where 100's or even 1000's of people work together, be successful? Well, in many cases they are not. They deliver less and later than expected and many projects simply fail. There are only few companies left in the world who can design airplanes, at huge cost of time and money and usually with huge delays. The only way to try to circumvent Brooks' Law is to work with many small teams, who can work in parallel, and who synchronize their results only from time to time. Every small team should be adequately managed, otherwise the overall management will be the bottleneck.
If you think Brooks' Law won't bite you, you better beware: it will!
There are many dimensions of saving time:
Improving the efficiency in what (why, for
whom) we do
Doing only what is needed, not doing things that later prove to be not needed, preventing mistakes and preventing working on superfluous things. Because people tend to do more than necessary, especially if the goals aren't clear, there is ample opportunity for not doing what is not needed. We use the Business Case, Stakeholder Management, and continuous Requirements Management to control this process. We use the TaskCycle, to weekly decide what we are going to do and what we are not going to do, before we do it. This saves time. Afterwards we only can identify what we unnecessarily did, but the time is already spent and cannot be regained.
Improving the efficiency in how we do it: doing things differently. This works in several dimensions:
Furrows of the electrician after the painter did his job