That’s the ticket. Let’s get a great project management tool that will help us get everything done faster. We’ll complete all our projects quicker and finally deliver more of them on time!

If we increase productivity then we will get things done faster! Or will we? Jason Borenstein addressed this curious question in Work Life in the Robotic Age, Communications of the ACM, July 2010:

Ruth Schwartz Cowan recognized years ago that the introduction of electronic devices in the home did not free women from the burden of doing household chores. As Cowan states, “What a strange paradox that in the face of so many labor-saving devices, little labor appears to have been saved!”

The common intuition here is that if a person is given something that is labor saving then we will have more time. The fallacy here is what I call the Benson Bylaw which is that many people regularly work at a quality deficit. When given the ability to do more, people then take as much time doing the same job as they had in the past but now doing it more completely.

I lived through the great Integrated Computer Aided Software Environment (ICASE) era of the 1990s. This is where we would get software development tools that would practically do the work for us. The great need, as it always seemed to be, was to get projects to deliver on time. Since ICASE was going to do so much of the work for us, we would start delivering our projects on time. It didn’t happen that way, at least not where I was. What did happen, however, was almost as earth shattering as if we did suddenly deliver on time. What happened? The quality of the software improved dramatically. What we did do, we did better, but not necessarily significantly faster.

Now wait a minute. If we can do the same work in less time then clearly the total time to complete the project should be less. What were those people with the expensive ICASE tools doing? Was Parkinson’s Law having an impact? Were they just filling up the available time saved by automation? Clearly no. The quality improvement showed where the extra effort was going. Why did they do that? Why didn’t they just complete their efforts earlier when given the means? The Benson Bylaw, of course.

People would very much prefer to do a good job. They will however, being good troops and wanting to be team-players as well as keep their jobs, do the best work they can in the time given them. There is a simple way to test this. Give a team the needed amount of time (and no more) and they will deliver on time and with good quality.

I’ve done this “experiment” on teams in the federal government, US military, international military and the commercial world. If an organization had a consistent track record of not completing projects on time we then looked at past projects, computed the average time it was actually taking to complete the projects and then gave the next team the average project time to do their project. These projects were the types that were repeated regularly such as software maintenance, software development and consumer electronics development. One characteristic of these projects — even as no two projects were exactly alike and many were very different — was that the average time to actually complete a project was longer than any past project’s “approved” schedule.

The impact of setting a schedule in this way was always amazing. The team delivered on time, often for the first time in the recent memory of the organization. At one organization they admitted, after delivering clearly on time, that their past “on time” deliveries were usually of the 2nd or 3rd replan of a project that was overrunning its schedule.

The second, always surprising, effect was that quality — usually based upon the customer’s feedback — improved significantly. Not just a little. Noticeably. Dramatically. It was normal after achieving the “dramatic” improvement in quality for follow on projects that built on this product (as we do in software) to then readily deliver on time even with a significant increase in delivered functionality. Delivering sooner often faded as a goal and instead “how much can we safely cram in” became the key decision. I had one customer who originally did not want to take our new software because in the past it had been too buggy and this disrupted their business processes. Now, they still did not want to take our new software because while it ran fine in their tests it had so much new functionality that it might disrupt their established business processes!

Keep in mind this happened using the average schedule duration (e.g., nine months) from past completed projects. “Average” generally means that half of the projects completed on or before this duration and half completed after this duration. What does this mean? It means that when using an average for all projects we should expect to miss our deadlines half the time. It never worked that way. We did in some cases miss by a week or two, but because the past deliveries were routinely missed by months, a week or two was never seen as a miss.

How was all this possible? First off, the organizations that used the “average” made very painful and often highly resisted decisions to do so. This meant that they had to accept schedules that were longer than they had used in the past. They also had to accept that the problems causing late projects were not strictly for the reasons claimed in the past such as poor project management, scope creep, staff turn-over, insufficient experience, etc. Instead they effectively had to admit that the problems might be rooted in their consistent management decisions to use unachievable schedules.

Secondly? The Benson Bylaw. People work at a quality deficit when given insufficient time. So when the teams were finally given a reasonable amount of time, a time they could actually complete the project in, the quality deficit was significantly reduced. (See In Project Management 9 + 3 is not 12, for why adding time by slipping a schedule is not the same as allocating the full time up front.) While using the “average” schedule duration doesn’t account for the real differences in each project, the average in these organizations was almost always longer than any approved plan. Using the average all but guaranteed that quality would improve simply because more time was given. We found that people did not arbitrarily fill up the available time. Instead, they did the best work they could in the time available.

Improving productivity will often not result in faster project completion. Instead, we will often find that the quality of the work done, in the same period of time, will increase. This may in fact be better than delivering a project faster.