Project Rescue and Recovery
Estimates are wrong if you cannot beat them half of the time; they are also wrong if you are not late half the time. Neither condition is one that should make management upset. In fact, matching that score is a great accomplishment. So how can people get so emotional about the statement? The answer is that people do not understand estimates and how they work. Through years of estimates being treated as quotes, we have been brainwashed into thinking our best effort is to meet the date, not better it. Heaven forbid if you are late. This lack of understanding is very evident by the number of blogs on the subject and some of their bewildering comments. The comments point out wildly different views. Some people think that Monte Carlo analysis gives you an estimate that has a 95% chance of being right and others believe that using Agile relieves people from having to make estimates entirely. Both of which are plainly not true.
Why is it that tasks always seem to be late? No matter how much time we allot, there never seems to be enough to complete a task on time. There is one overreaching reason pervasive throughout the enterprise—poor time management. To accommodate the continual barrage of supposedly urgent tasks, we heavily pad estimates. Excessive padding triggers numerous negative work patterns. The extra time and over confidence in estimates allows people to accept other unrelated tasks, introduce low priority features, and strive for perfection. It is unfair, however, to saddle the individual with the entire problem; the work-place culture reinforces and rewards the behavior.
The term 'Inception Phase' is often used to signify a project's beginning. Isn’t it really the birth? There are many similarities between a project's lifecycle and this familial analogy.
Inception happens much earlier with a glass of wine, maybe two. That first thought, “Hey, wouldn’t it be neat if we had a…” Complete the sentence to fit the situation. It is at this point that the ball gets rolling, so to speak, and someone decides to invest some time to explore the possibility of making something happen. The originator courts the business manager, selling the concept of the idea, until there is approval to move forward. Voilà! It is conceived. Someone commits to carry and nurture the project, allowing it to incubate and mature into a viable form that can properly benefit the organization as a final product. After the proper gestation, the project is born and has a team assigned. This is the transition that many methodologies errantly label inception.
Many companies have some form of a portfolio management group to manage their projects and their backlog. The projects they govern range from network pulls to new software development. However, most use only one methodology to run these projects. It may be waterfall, Agile, Critical Chain or some other process. This is analogous to having only one knife in the kitchen. Anyone that has cooked more than a few meals realizes that a table knife is insufficient for all your kitchen needs. It purees tomatoes, cuts meat poorly, fails at filleting fish and suffers as a steak knife. There are hundreds of knives, each designed to do some specific job. As with many jobs, some tools are better than others are for certain tasks.
The policy reads, "Before you can proceed, the PMO needs to approve the design gate." So, you begrudgingly wind down the project so the slowest members of the design team can catch up. A week, maybe two, sometimes even more flash by. The rest of the project team starts finding work on other projects. Once the PMO finally gives the project the green light, you will need to wait for people to complete those other tasks before they can focus on your project. Precious time is lost.
There is a reason we hesitate to teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptoms and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.
Or... I Think I Can
I have a book that sits in the bookshelf behind my desk and has been there for as long as I have had a desk—The Little Engine That Could, by Watty Piper. I have read it numerous times to each of my children and soon to my granddaughter, Kennedy. Each time I open it, the smell takes me back to my Dad's lap and a time when life was much easier. A time when my vocabulary was devoid of the word project. I am not sure if there is a direct connection between that word and life's simplicity, it is probably just an coincidence.
The west coast of the United States is where I call home. Many refer to us as "left coaster" because... well... that is how it looks on a map and many of us are politically a little further to the left than others. Around here, common thought is that everyone should be open-minded. A sentiment that I proudly subscribe to as I lack most prejudices. You can imagine my shock when I found out that my unbiased presumptions are not only undesirable, but also undeniably wrong.
There I was, in a posh Montreal hotel conference room, two customers on one side of the table, and my client and me on the other. Taped to the back of my laptop lid was a conference-center supplied piece of paper with a hastily scrawled note on it. The entire message consisted of only two letters followed an exclamation mark. The letters were "N" and "O." They sent a succinct message that was hard to ignore as the customer incessantly strove to get a little more functionality brought into the failing project's scope. For every request, I would drop my chin slightly, look over the top of my glasses, tap my right index finger on the top of my laptop, and they would relent. Instead of being a pessimistic curmudgeon, I was bringing realism about the budget and timeline and doing what leaders do—making hard decisions.
The two most common project attributes that raise the red flag are cost and timeline problems. Both are easily measured and inextricable intertwined. As the timeline extends, there is a commensurate increase in cost; similarly, as cost goes up (usually from increased scope) the timeline increases. However, time is different. Benjamin Franklin said it best, "You may delay, but time will not." Work can stop work (controlling the burn rate) and extraneous features can be removed (decreasing the required work), but time marches on. We cannot control time. Although intuitively obvious, the concept seems to escape a large number of managers and executives.