Project Governance and Definition
Risk is a risk in itself. It is risk for you if you dare bring it up. Have you ever identified the risk, in writing, that your boss' inherent inability to make decisions is going to sink the project? How about the company loss of market share will require laying off half the project team? Or, that the project manager has never had a successful project? These are CLMs (career limiting moves). Even mentioning such common risks as a company's inexperience in the project's domain is too risky to put in the risk register. It is as if management enjoys blissful ignorance and relishes the firefight that ensues. Cowboy mentality. Identifying risk, modeling mitigation plans, and compiling contingency are too boring compared to the thrill of disaster 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.
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.
Project failure is rampant in nearly every industry. In the US alone, the cost are huge with estimates running as high as a trillion dollars a year. In most cases, the project manager and his or her team are blamed. The project, however, is only the symptom with the source of the failure imbedded in the organization. Project pressure stresses the weak links in the organization causing them to snap.
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.