Which options do we (seem to) have to be on time?

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.

Deceptive measures
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.

1. Hoping for the best - fatalistic
   Most projects take more time than expected. Your past project took longer than expected. What makes you think that this time it will be different? If you don't change something in the way you run the project, the outcome won't be different, let alone better. Just hoping that your project will be on time this time won't help. We call this ostriching: putting your head into the sand waiting until Murphy strikes again.
2. Going for it - macho
   We know that the available time is insufficient, but it has to be done: "Let's go for it!" If nothing goes wrong (as if that ever is the case) and if we work a bit harder (as if we don't already work hard)... Well, forget it. If the time really is insufficient, it won't happen.
3. Working Overtime - fooling yourself, your customer and your boss
   40 hours of work per week is already quite exhausting. If you put in more hours, you'll get more tired, making more mistakes, having to spend extra time to find and "fix" the mistakes, half of which you won't. You think you are working hard, but you aren't working smart, and the result is even less, at lower quality. As a rule, never work overtime, so that you have the energy to do it once or twice a year, when it's really necessary
4. Adding time - moving the deadline
   Moving the deadline further away is also not a good idea: the further the deadline, the more danger of relaxing the pace of the project. This is due to Parkinson's Law and the Student Syndrome.
   Parkinson's Law
   Work expands so as to fill the time available for its completion or People use the time given.
   Parkinson¹ observed: "Granted that work (and especially paperwork) is elastic in its demands on time, it is manifest that there need be little or no relationship between the work to be done and the size of the staff to which it may be assigned." Note that most of the work done in projects is 'paperwork', one way or another.

   Student Syndrome
   Starting as late as possible, only when the pressure of the Fatal Date is really felt (attributed to E. Goldratt²).
   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.

   A project of three students was about replacing a Microsoft Access task planning application with a web-based version of the same. The requirements were written down, with many screen shots, to show what of the original application to leave in and what to leave out. In their end-report they stated that "the requirements were changing every time". Actually, I, as the customer, didn't change anything at all of the requirements. The problem was that they continued to deliver things that were different from described in the requirements. I think they assumed that their solutions were better, and I, as the customer, had my reasons not to diverge from the original requirements. This made me aware that, where projects often complain that the customer is changing requirements all the time, it often could be that the perception of the requirements by the developers is changing, rather than the actual requirements!
   About halfway the project, I asked the students whether they would conclude the project successfully, with a good working application. I got the four deceptive options within one minute: - "I've a good feeling about it!" (option 1: hope) - "Besides, we have to be successful, so we'll make it happen!" (option 2: macho) - "And I'm working through nights and weekends to make it happen" (option 3: working overtime) - "Sorry, what we promised last week is not yet working properly, we'll deliver some of it next week" (option 4: moving deadlines).
   Working on a tool that was to support Evo TaskCycles, I suggested that they should try to work the Evo way, which they didn't. Not doing the most important things, not using TimeBoxes, not properly planning TaskCycles. Result: useless application, customer not happy = failure!

5. Adding people - a riskful measure...
   

   The Myth of the Man-Month

   
   A typical move is to throw people at the project, in order to get things done in less time. Intuitively, we feel that we can trade time with people and finish a 12 person-month project in 6 months with 2 people, in 3 months with 4 people, or in 2 month with 6 people, as shown in the figure.
   In his essay The Mythical Man-Month [SC1], Brooks³ shows that this is a fallacy, a fairy tale, a myth, defining Brooks' Law (1975):
   
   Adding people to a late project makes it later
   When I first heard about Brooks' Law, I assumed that he meant that we shouldn't add people at the end of a project, when time is running out. After all, many projects seem to find out that they are late only by the end of the project. If time is running out, the added people have to learn about the project and we have to tell them, spending valuable time unproductively.

   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.

   Putnam⁴ confirms 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!

   In a recent project that went too slow, the number of people was increased from 5 people to 20 people. The measured productivity increased by only 50%. It took project management some 10 months to decide to decrease (against their intuition!) the number of people from 20 to 10. When they finally did, the net productivity of the remaining 10 people was the same as with 20 people. They have been paying 10 extra people for 10 months with no contribution to the productivity! This was an expensive exercise, but it will probably happen again many times at many places.
   If you encounter a project with 12 people going too slow, what would your advice to the project manager be? "Decrease the number of people!" What would the project manager do? Increase the number of people? And then being surprised that the project doesn't go faster and probably slower. This is so contra-intuitive, that we have to actively fight our intuition in order to do what we should do!

6. Saving Time - The Measure that always works
   Fortunately, there are ways to save time, without negatively affecting the Result of the project, on the contrary! These techniques are collected and routinely used in the Evolutionary Project Management approach, in order to achieve the best solution in the shortest possible time.

   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:

     • The product
       Choosing the proper and most efficient solution. The solution chosen determines both the performance and cost of the product, as well as the time and cost of the project. Because performance and project time are usually in competition, the solution should be an optimum compromise and not just the first solution that comes to mind. We use Architecture and Design processes to optimize the result. We use DeliveryCycles to check the requirements and assumptions with the appropriate Stakeholders.
     • The project
       We can probably do the same in less time if we don't immediately do it the way we always did, but first think of an alternative and more efficient way. We do not only design the product, we also continuously redesign the project. We use Evolutionary Planning to control this process.
     • Continuous improvement and prevention processes
       Actively and constantly learning how to do things better and how to overcome bad tendencies. We use rapid and frequent Plan-Do-Check-Act (PDCA or Deming) cycles to actively improve the product, the project and the processes. We use Early Reviews to recognize and tackle tendencies before they pollute our work products any further and we use a Zero-Defect attitude because that is the only way ever to approach Zero Defects.
   • Improving the efficiency of when we do it
     Doing things at the right time, in the right order. A lot of time is wasted by synchronization problems like waiting for each other, or redoing things that were done in the wrong order. Actively Synchronizing and designing the order of what we do saves time. We use Evolutionary Planning with constant, active prioritization to control this process, with TaskCycles and DeliveryCycles to make sure we do the right things in the right order, and TimeLine to get and keep the whole project under control. Elements of these are Just Enough Estimation, Dynamic Prioritizing and Calibration techniques.
     

     Furrows of the electrician after the painter did his job

     Imagine a plasterer plastering a wall in a new building. Then the electrician comes in, carving a furrow through the plaster in the wall to fit some electric wiring. The plasterer returns to repair the wall. Then the plumber comes in, cutting through the plaster and the electric wiring, in order to fit some water tubing. The electrician and the plasterer come back to repair the wiring and the plaster. If only these people made a TimeLine of their plans before they started, they would easily have seen in which order they should have done things in order not to repeat any of their work. They're not stupid. They only didn't think.
   All of these elements are huge time savers. Of course we don't have to wait for a project getting into trouble. We can apply these time savers even if what we think we have to do easily fits the available time, in order to produce results even faster. We may need the time saved later to cope with an unexpected drawback, in order still to be on time and not needing any excuse. Optimizing only at the end won't bring back the time we lost at the beginning. Optimizing only towards the end also means that there isn't much time anymore to optimize.

7. Killing the project
   (recently added)
   Of course, if we see that we never will get a positive return on investment, we better kill the project now, rather than after we've spent 3 times the budget.