“I would often talk excitedly about some project we completed that was on time and had good results. Folks would say “yeah, we did that too.” In my naive enthusiasm I would then pepper them with questions on what they did and how they did it. I would get horrified looks and then they would often flee. I would come to discover that too many of those other on time projects were more noise than substance. How could a simple notion such as “on time” be so complicated?”

I wrote this in the Project Manager Networking Group on LinkedIn as a lead in to my Project Management Tools article on “Is Your Project On Time?”

I loved the response from Michelle Albanese, Senior Manager at eResearchTechnology, as it went right to the heart of what many people see during a project:

“On-time is [like] beauty. It is in the eye of the beholder. Most managers think if it got done around when we thought and everyone was happy, that they got it done on time. Unfortunately the name “on-time” is misleading. You can be exact to the schedule and be missing half of the functionality or be later than you thought but still less than the drop-dead date and have everything that the user wanted. Rarely does anyone metric what was done when and how did it measure against what you anticipated. Frequently these metrics take almost as long to calculate as the work it measures.

To truely track completion you need to know how long each step took and how was it completed in relation to what you expected. There is a difference between starting late and taking the expected amount of time and starting as scheduled and taking longer than expected. Most managers just plain do not want to know or do not want to take time to figure it out. Most project managers have had the conversation with their sponsor about when it will deliver versus when it will be completed. We have all backed into delivery dates that have nothing to do with the scheduled work required. If the culture does not really care about the substance, why try to give the detail? It is just “wasted hours” trying to figure out the past when they “know” you just guessed about how long it will take in the future, besides “what has that to do with when I want it?”.

It is complicated simply because what we know we should do has to be valuable to those getting the information.”

My reply to Michelle’s comments are in italics:

1. “Rarely does anyone metric what was done” — The “official” record of progress is often “tweaked” too much to be a good record. However, I’ve always been able to find data (meeting minutes, financial records, etc.) that gave an often better hint at how things unfolded then any official record. These can be truly great measurements of how long things took.
2. “These metrics take almost as long to calculate as the work it measures.” — Yes. I love tools and techniques but they are often overkill and/or unwieldy. I talk about simple measurement techniques that work better in many circumstances (see: Your Project Management Average Is Powerful) .
3. “do not want to know or do not want to take time to figure it out.” — Mostly I suspect because they don’t really believe it can be done that way. They may have never seen nor been apart of a successful effort. If they’ve seen a successful effort, they really don’t know why it was successful to be able to do it again with confidence (see: A Successful Manager But Never A Successful Project).
4. “culture does not really care” — The trick here is to pull off a successful effort. I’ve found these “don’t care” folks really do like to see it done well and will often jump on board if they think you can do it (and, yes, make them look good).

Each of the above comments warrant a standalone article in their own right. I just want to expand upon thoughts #3 and #4.

Many very successful managers may simply have never experienced a successful project. While this seems completely at odds with the notion of being successful, if you come from an environment that rarely delivers a project on time, keep in mind that someone still has to be promoted and someone has to be in charge.  Companies can be very good at their core discipline, and have a successful business, but not be particularly good at project oriented activities. I’ve seen many software intensive organizations that were doing a booming business, but could never deliver their software when it was promised. It just becomes normal to be “late and buggy.” Within this normal environment, many managers will manage these projects, get normal results, and still be promoted and rewarded. Their promotions and rewards will be based upon other attributes (e.g. hard worker, good communicator, highly respected) rather than the success of the project. Since nobody has ever delivered on time, not delivering your project on time is not a negative event.

There is a silver lining in the situation above. That silver lining is that if we can deliver a project on time, with quality, then these same managers will often readily become great supporters. (Maybe this seems self evident, but I’ve experienced occasions where success resulted in unhappy bosses — see “The Leap To Excellence“). I had one boss who was very resistant to many of my approaches to software development management. They were different from what he had done when he had managed software development directly. We butted heads during the entire project. He once pulled the plug, literally pulled out the computer’s electrical plug from the wall, on a demonstration I was giving to our customers on the new software. Yet, when it was all over and we had not only delivered on time, but our customer could not find any issues in our software, he admitted that he “liked the result.” He simply didn’t believe one could actually deliver on time with good software quality. He had never done it nor had he ever seen it done before.

Does anyone really care if our project is on time? Of course they do. But many folks will first have to be convinced that on time with quality is something that you can really make happen.