Are 67 Percent Of Your Projects Delivered On Time?
Are you able to get your projects done early or on time?
Yes – 67%
No – 33%
Software Development Times – Data Watch, Nov 1, 2010, Source: Evans Data
This report in Software Development Times caught my eye. When talking to software developers, IT managers and project managers in general, I usually get around to asking about how often they delivered their projects on time. The answers I get are pretty consistent.
They generally start off by saying they do OK. They deliver projects, or at least their part of the project, regularly on time or even early. I then ask about how the overall project went. How many days or weeks it was early or late, and did they ever have to replan a project?
Organizations that deliver on time have a tendency to know their numbers, such as how long projects took and how often they delivered on time. Those organizations that say things are going pretty well — but I ultimately find out that they are not — have a tendency to speak in very general and expansive terms. The one I always liked was — after getting the positive sweeping generality that they delivered on time and then I ask some probing questions — the suspicious pause and then the question “well, what do you mean by on time?” (For my answer to this question see Is Your Project On Time?).
The numbers reported in the Software Development Times were for open source developers working on open source projects while working their salaried job (so admittedly a unique bunch of people). While this may be a different breed of people, the number of 67% delivering their projects on time or early raised my “I’d like to dig deeper” senses.
As I related in other articles (see Knowing Your Project Management Average), even people who are well respected for their expertise and performance usually have a very hard time remembering how long things took to complete, what was worked on, and how well it went. I’ve read similar findings to these — reported at least as far back as the work of Peter Drucker in the 1960s. Once we measured actual task completion times, for example, the experts consistently underestimated how long the task had taken by two to four times even when they were directly involved with the work.
While I only know about these numbers by what was published in the Software Development Times, they sounded a bit optimistic based upon my experience and research. Experience also tells me that this kind of data is most accurate when coming from a reliable record of what really happened, and not exclusively from the memory of otherwise very competent but extremely busy and hard working people.
Are you keeping detailed objective records on how long it takes you to complete a project?
2 thoughts on “Are 67 Percent Of Your Projects Delivered On Time?”
Comments are closed.
I had a senior engineer come to me and matter-of-factly say that we could probably never really deliver a project on time. The project he was referring to was one we both worked on and one that would finally deliver on time.
One interesting observation is that the on time, successful, with good quality project – looked pretty much like any other project. The only initially visible difference was that when the smoke cleared, we were on time rather than months late.
The second big difference was that future projects built on this baseline all delivered on time and that quality issues went way down. Adding functionality no longer disrupted a fragile code baseline, but instead were dropped in, debugged and then quickly became stable (which prior to this was not normal).
I agree that even on-time projects often require 7×24 working hours at times. I will say that working 7×24 on a successful project is less wearing on the team than doing 7×24 on projects that end up months late and with fragile quality. Also, once we got to the point of delivering on time, the workload – while tough at times – was no longer as nutty as when the projects were always late.
So the “nature of the beast” is not always as inherit as we think but work will probably always be hard work – if we are to stay competitive.
– Bruce
I think a more interesting assessment might be, what hoops do you usually have to jump through to get the project done on time, such as burning the midnight oil at crunch time.
Many of these hoops can be addressed and even prevented with analysis and change, but unfortunately, that approach is FAR from the norm. The hoops are accepted as the nature of the beast.