During project review meetings, I sit in the back of the conference room. I have difficulty maintaining my “stoic face.” The vantage also affords me an opportunity to study the other players’ body language when strange shit happens. Like, when El Jefe was presenting one of his spreadsheet and made this gem of a statement:

“I don’t believe these numbers.”

I pondered asking an obvious question or two, but I was more interested in seeing if anything would happen. Finally, someone other than me suggested that, perhaps, he was spending too much time immersed in his Rube Goldberg spreadsheets and not enough time actually looking around. El Jefe got ultra-defensive, claiming he spent several hours preparing these.

Why?

1. Estimates are made without consulting his team. Suppose marketing wants to erect a Colossus in the foyer of our building. After considering the request, a sculptor estimates that it will take 90 days for him to do the work. A large, bronze statue needs a team to pull this off. Instead of asking his team, El Jefe applies fudge factors:

30 days to architect the Colossus
30 days to record this in the Great Book
60 days testing the Colossus
60 days fixing problems found by testing

This is the Scotty “multiply estimates by three” maxim, and is presented as gospel. At no time has he consulted the stakeholders on his teams. There is also the linearity of the tasks. For example, it may really take only one day to record it in the Great Book, but 90 calendar days of badgering the architect to get off his lazy ass and finish architecting.
2: Statistics are abused. El Jefe concocts zero, one and two-sigma forecasts for various components of product production. Statistically speaking, the sigma represents the confidence in the estimate. “Zero sigma” is a coin-toss, that is, you’d expect that, on average, projects would finish on-time only half the time. An one-sigma estimate represents a 68.26894921371% chance of finishing on time. Two-sigma is a 95.44997361036% chance. Remember the Colossus? That 270 days is the “zero sigma” estimate.

This is actually a reasonable way of projecting delivery dates… except he has never made an accurate estimate. Furthermore, in presentations, he will toss out different sigmas to bolster some claim. Need more resources? Quote two-sigma. Want to let the documentation team know they’re second-class citizens? Quote them at a sigma less than the rest of the group. Have to make your division look bad so you can “save” them from themselves? Quote zero-sigma. And so on.

Sales has glommed onto the concept, suggesting we set their quotas to two sigma. Riiiiiight. While I have no qualms about them being highly-compensated for closing deals, we’d have to fire half the company to plan for the commensurate “two sigma revenue.”

He should never, ever quote “sigmas” beyond the confines of his division.

3: Doesn’t track resources across projects. El Jefe confuses precision with accuracy. 95.44997361036% is a precise number. It is also an inaccurate one when some people are scheduled to 110%. Or, when he does “what if” scenarios in meetings, assigning arbitrary weightings to which projects people would work on, “as if” tweaking a number would magically heal the scheduling problems without creating others. Or, when time for “fixing problems” and “architecting” is alloted to one giant pool where it decays, unchecked, until it hits zero. During a wacky two-sigma slip a few months ago, he cited we had run out of “planning” time. Oh, the irony! There were other issues.

4: Makes calculations so complex, he misses flaws in logic. He’s using a home-grown project tracking tool plus spreadsheets plus whatever accounting gives him to verify people are reporting their time in the correct categories. He’s been so focused on getting this to function, he misses the bigger picture.

For example, suppose Groucho, Harpo and Chico are slated to build a Trojan Horse. Their commitment, and the project, are set to deliver on December 31, 2007. Now, suppose El Jefe assigns Karl to the project. Karl’s availability from January 1, 2008 through September 30th, 2010 doesn’t materially affect the delivery date, yet El Jefe’s spreadsheet claims the project will be complete on December 3, 2007. Karl is able to time-travel and work on the project in the past. Workers of the world, unite!

Looks like the Marx brothers will barely finish! But wait….

Through sheer reputation, Karl helps our schedule

5: Confuses metrics, doesn’t realize it. His resource allocation assumes a full-time employee is available for 16.5 days of productivity a month — more if they’re allocated 110%. The remaining time is attributed to sick time, vacation, training, overhead, tax, title and rust-proofing. When reconciling projects with time sheets, he’s failed to realize that the number of work days per month, the figure reported by time sheets, varies. [For example, in August, there were 24. In September, there are only 19 (plus one holiday). In October, we're back to 23 days. Thus, if he budgets 192 full time equivalents in August, he ought to expect that to be 152 FTEs in September.] Instead of trying to understand this, calling it for what it is, he’s conjured innumerable unrelated excuses.