Everything was running along smoothly.  We had looked at past project performance and had measured the typical progress trend seen in these new product projects.  In this particular case, we were at a milestone where the software was done and it was working on the hardware prototypes, and we were debugging and tuning the marriage of the software with the hardware.

I noticed that once we passed this major milestone, with one of the best passing quality assurance grades ever, the whole speed of the development effort seemed to slow down.  Since we had measured past performance and had scaled the project based upon this past trajectory, this slowdown — as seen in the defect arrival and removal trends — was a big concern.  So after doing a few calculations, I blasted out a message to the development managers showing them the “before” and “after” rates of defect removal, and the projected trends and said that if we don’t get back to where it once was, we would start to miss our upcoming milestones.

For more on this see Defect Reports Are Your Best Friend

This got everyone excited and moving.  However, the lead development project manager tried to explain to me that there was not a true slowdown only that the easy defects had been fixed and now we were facing the harder ones.  So it was logical, he claimed, for the fix rate to slow down.

This is a typical use of speculation I’ve seen in many projects.  It was a great theory he had. Now he needed to go and test this theory by looking at real defect data.  Instead, this “fact” just seemed right to the project manager and he told it to me and all his bosses, and they in turn began to say the same thing to their and my bosses.  Luckily, before this theory spread too far and impacted what folks were doing, my trumpeting the alarm had caused a clear jump in the defect removal rate.  Also luckily (or maybe because of proactive and objective management), the rate stayed up and we hit all our milestones and went on to deliver the project only ten days from the original finish date after an 18-month effort.

As project managers, we need to distinguish between what we know as fact and what we suspect — our theory — on what might be going on.  It might sound like a great idea, but first, do some checking and test our notion before announcing it as a fact.  We may find our original notion does not hold up to scrutiny but we’ll inevitably benefit by often discovering a more insightful reason that goes to the true heart of the issue and keeps us on track to a successful project.

Do you recall any management actions that were based upon an unsubstantiated theory that was accepted as fact?