The Default Fault

      On the foggy back side of the Comfort Zone, the population of defaulted projects grows by the day. Defaulted projects are the ghosts of those formerly promising intentions that slid backwards from their Project Plans into mediocrity or worse. Execution did ‘em in.

     So implementation is what matters? We should forget planning and just launch straight into action, right?

     Wrong.

     This whole issue of how to manage planning-execution is an essential matter in Project Management, and handling it successfully is a secret of project success.

     There is an apparent contradiction involved: As General Eisenhower said, “Plans are nothing; planning is everything.” He endorsed the process, but was deeply suspicious of its product.

     Here’s what I think he meant: Plan as if every detail must be permanently nailed down in advance – then execute as if every element of the plan is wide open to amendment or reversal on the fly.  

     The key to the conundrum is understanding how the planning process affects human expectations, and therefore underlies managers’ behavior during the unfolding of a truly meaningful project.

     If you planned well, you are solidly planted when change becomes necessary. You know why you’re where you are, and how you got there. Your responsive action in the new situation then is  confident rather than wobbly and rootless.

     In fact, every good plan makes its parts sufficiently specific that the manager is enabled to choose wisely among the elements for the right ones to change and how to do so.

     Otherwise, faced with strange and challenging situations, we default to what is familiar and nonthreatening. We wrap ourselves up in the famed comfort zone.

     The results are familiar: Cost overruns, blown schedules and disappointing outcomes. Basically, multiple defaults from what we intended. If we’re more than 10 percent off on any one of them, I consider it a management failure.

     This is the Default Fault. 

     It frequently results from fuzzy management, which itself often starts with imprecise definitions.

     For example, what’s a “project”? If a group activity isn’t strange and challenging, I don’t favor calling it a “project.” It’s a “process,” a distinctly different animal.

     A process is a series of sequentially-dependent steps which, done properly, assure a predetermined outcome. Such an activity rewards repetition, with close attention to reducing variance in any of the steps. Most of what we do is like that.

     A project, instead, is unusual. It is characterized by uncertainty, unfamiliarity, complexity, risk and dependency upon factors you don’t control. It requires innovation and careful advance into the unknown.  

     One of its more devilish characteristics is that the typical project includes a number of known processes as well as true project elements. That reality can lure the unwary project manager into inattention, unprepared for the inevitable slide into unfamiliar territory. Default Fault again.

     I’m probably in a minority on this, judging from the literature of the project profession and from the talk of most working professionals. They don’t seem concerned about complexity, uncertainty and risk. I see too much simple reliance on the standard tools. There is a lack of awareness that the frequent project shortfalls are not inevitable – but result from careless development and unthinking execution of plans.

     Clear concepts and complete definitions would produce better planning, crisper direction, less waste and stronger results.

     A big weakness of the popular viewpoint is its failure to account for the fact that RISK is the central fact of projects, and therefore the major factor in Project Management.

     Risk is the possibility that something will go wrong or not work, Risk management is the organized process of identifying and accounting for anything that could open up that possibility.

    

     Risk management should dictate the actions of the project manager at the very inception of project planning and organization.

     Where and when is that?

     While the organization's management may have developed specific intentions earlier, project management starts when the project manager is appointed. At that point, the manager's first questions must be raised and the answers researched. The results should then be built into the fundamentals of the project.

     Some of those questions are:

     Why does the organization want this project? How – specifically – do the organization’s decision makers define the goal? What – again specifically – do they plan to invest in the effort? What do they expect as a return on that investment? How do they define the role of the project manager? And so on.

     The first default fault is planted in a project when this kind of thorough exchange is skipped or glossed over, and when something like it doesn’t produce a full mutual understanding between the sponsoring organization and the project manager.

     I can’t count the number of projects I have witnessed – indeed, worked on early in my career – that suffered from this default.

     The anti-default approach must be applied throughout the planning, preparation and conduct of the project. Everything is thoroughly researched, specified, tracked and guided.

     The project manager and the designated sponsoring executives negotiate it all and record it all, including assumptions, performance metrics, variances and plans for in-process correction.

     There are no defaults to low-quality substitute project results. There are backup actions built into the plan, legitimately residing in the comfort zone.