PUTTIN' COLOGNE ON THE RICKSHAW

“The real sin of project management is not being over cost and behind schedule−it’s not knowing it ahead of time.” I don’t know who penned this saying but in my experience no truer words were ever spoken. I’ve worked on many (too numerous to even count) projects in my career and frankly I can’t remember one that completed on schedule, under budget and met the original expectations (specification). I’ve worked on projects at both ends of the spectrum−small and large, simple and complex yet all of them had the same odds of ending badly.

I recently read Frederick P. Brooks’ book called The Mythical Man Month ©1975, an exposé on why projects typically end badly. While the central theme of the book revolves around understanding why software projects typically end up badly, it reveals some fundamental reasons why any project can end in catastrophe. The book introduces Brooks’ Law which states: “adding manpower to a late software project makes it later.”

Brooks’ observations are based on his experiences at IBM while managing the development of OS/360. His premise is that more projects have gone awry for lack of calendar time than for all other causes combined. From my own experience I’d have to agree. Thus the question is why is this cause of project disaster so common?

Brooks details five areas he believes contribute to disastrous results:

• The typical techniques used for estimating are poorly developed
• Estimating techniques fallaciously confuse effort with progress
• We are uncertain of our estimates
• Schedule progress is poorly monitored
• When schedule slippage is recognized, the natural (and traditional) response is to add manpower

More to the point he claims the real problem is that no matter what has happened in past projects we don’t learn from the past. We start every new project with the unvoiced assumption that all will go well. Einstein once said the definition of insanity is doing the same thing over and over somehow expecting a different result.

So the first false assumption that undermines a project right from the start is that we assume that “all will go well,” i.e., that each task will take only as long as it “ought” to take. The second contributor to disaster is the very unit of effort used in estimating and scheduling: the man-month.

Cost will vary as the product of the number of men and the number of months however, progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

The man-month implies that people spend most of their work hours actually working the project. Studies have shown that most people waste more time at work then doing actual productive work. Between Internet surfing, excessive meetings, co-worker interactions, office politics, and fixing their own and others’ mistakes it’s a wonder anything productive is ever done. In other words you’re lucky to get much of a workers’ time actually spent on the task at hand.

In her 2013 Forbes article, “Who Wastes The Most Time at Work?” Cheryl Conner gives us some statistics on just one of those distractions. She tells us: “Sixty four percent of employees visit non-work related websites each day. In this category, the amount of time wasted per week on non-work related websites is as follows:

Time Wasted Percent of Employees
<1 hour 39% 1-2 hours 29% 2-5 hours 21% 6-10 hours 8% 10+ hours 3% As Conner tells us, “Imagine an employee who works 2,080 hours per year (260 days). If she is in top the bracket of time wasters, she wastes 520 hours per year. That’s 25% of her total hours at work spent on unproductive activities.” And that’s just wasted time on the internet. Add to that meaningless meetings and disruptions from peers that just want to BS and you see why progress is never made and schedules are never met. Brooks tells us that men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication between them. This is true of reaping wheat or picking cotton; it is not even approximately true of complex engineering projects, or as Brooks would point out: software projects. In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer than an even trade of men for months. Another area where we get wrapped around the axel is with scheduling the project. Schedules are basically just a list of tasks, or events, with anticipated end dates, called milestones, which when completed in the allotted time, and the correct order, lead to the project completion date. Some tasks are contingent on other task and many can be done independent of other tasks. Independent tasks can be performed in parallel, but contingent tasks must be performed in sequence. These then are what take up the most calendar time. The longest of these contingent paths being what’s called the critical path. The critical path is not necessarily the path that’s the most challenging and can change as a project progresses. As other sequences of event fall behind schedule they can overtake the original critical path and thus become the new one. The biggest threat to a project completing on time is when we’re developing something that’s never been done before−you can’t schedule “creativity.” In the feeble attempt to manage our projects, we create the all-consuming monstrous Microsoft Project files that approach megabytes in proportions with every task carefully documented and connected in Gantt chart glory. These behemoth schedules consume all in their sheer detail and length. These schedules go into ad nauseam detail scheduling minute tasks down to the hours of duration, all connected in a cause and effect relationship whereby if the first task overruns it’s time constraint the project is already behind schedule. Updating and managing the schedule is a daily, if not hourly, task and thus the schedule becomes more the project than the project itself. What is management’s typical response when an essential task is behind schedule? Brooks reminds us that they add manpower, naturally. However, this is exactly what they should not be doing. Recall Brooks' Law: “Adding manpower to a late software project makes it later.” Brooks Law applies to all projects and all disciplines of work. Adding more people to the effort is like dousing a fire with gasoline, making matters worse. More fire requires more gasoline, and thus begins a repetitive cycle which always ends in disaster. Of course another problem with project scheduling is that typically the need date of the customer often governs the wished-for completion of the project. However, it cannot govern the actual completion of the project. The length of time of a project depends upon its complexity and sequential constraints. The maximum number of people working the project depends upon the number of independent subtasks. From these two quantities one can derive schedules using the least number of people and months. One cannot, however, get workable schedules using more men and fewer months. Remember, you can’t put nine women together and expect them make a baby in one month. The critical path is nine months, no matter what you do. More projects have gone awry for lack of calendar time than for all other causes combined. Remember, project schedules are lagging indicators−by the time you discover you’re in trouble the damage has already been done. This is where project managers need to be proactive in “statusing” their projects more often than the typical once a month. Another critical problem is that we often confuse having a detailed schedule with having a plan–they are in fact different. Most projects are like jumping leaping off a cliff and then trying to knit a parachute on the way down. Another common problem that threatens most projects is “underestimating.” It’s human nature to underestimate the effort we’ll need to complete a task. To make matters worse we’ll typically stand by our estimates even when we know we’re not going to meet the deadline−we can’t admit we were wrong, or that we’ve been wasting time on other, non-project diversions. Also underestimates do not change significantly during the activity until just before the proverbial stuff hits the fan at which time it’s too late to make changes that will save the project from disaster. Our estimates of the length of an activity do not significantly change as the project proceeds no matter how wrong they ultimately turn out to be. We will never admit to being behind schedule until we actually are behind schedule−despite the fact we may have known it for weeks, or months. There are a few other problems that plague any project that have to do with how humans behave. The first is summed up in what’s called “Parkinson’s Law,” which states that “work will expand to fill the time allowed.” The second is what’s called the “Student Syndrome,” which revolves around our natural propensity to procrastinate. We all do this−we have estimated how long we think a task will take and then we procrastinate until the last minute to start the work. Some of this is not our fault, as I mentioned earlier, we allow ourselves to be “interrupted” and then we have to scramble to complete our tasks. In other words, we consume all the safety slack upfront. And when we scramble, we both make mistakes that further delay the project or we conclude that we underestimated the effort it will take to complete the task. Of course don’t forget our misguided belief that we can multitask. As I’ve shown in a previous post−multitasking is a myth. In the end what you hear is the project manager claiming the project is “off the rails” and it enters the annals of history along with every other failed project. The irony being that when the next project comes along we’ll make the same mistakes over again−somehow believing “this time will be different.”