Wednesday, September 21, 2011

When Projects Become Unmanageable: Part 2

Share this ARTICLE with your colleagues on LinkedIn .

Projects can, and frequently do, become unmanageable. There are a number of reasons for this, as discussed previously. The key is to understand these reasons, to anticipate their possibilities (or probabilities) of occurrence, and to take appropriate measures, during the earliest stages of the defining of the project scope and the construction of a plan to achieve the project's target objectives to both: 1) implement measures [right at the outset] to prevent them from happening, and 2) allow for adverse contingencies (such as delays, budget issues and any departure (i.e., variance) from the "trajectory" of the plan in the initial client expectation management process. Both of these are crucial to avoiding unmanageable projects and dissatisfied clients. Each plays a role.

In quick retrospect, some of the central reasons projects become unmanageable (as discussed in Part 1) included:
  • Individual Scope Creep;
  • Poor communications, monitoring and feedback among team members, and/or between the team leader and his or her members - situation reports and progress reports serve a strategic purpose in keeping the Project and team members all within the scope...but just as importantly, they serve to inform the participants of where their performance may be in terms of what was expected of them, and in terms of the project as a whole, as well as to provide an opportunity for constructive input, or a reallocation of resources or a reordering of priorities in the interest (based upon the experiences of the team members to that point) of getting to the objective more efficiently;
  • Poor initial estimates of timeframes and of required resources;
  • Problems with team member interdependencies, i.e., when one member (in assembly line fashion) requires another's work in order to proceed with his or her tasks. Ironically, if there are too many interdependencies (team embers working in serial fashion, like a water bucket brigade putting out a fire instead of in parallel fashion in order to minimize nonproductive time) the slowest team member produces the greatest bottleneck -- he or she, is [groan] a 'serial killer';
  • Unforeseen changes in situations and circumstances, forcing the team to re-group and make new decisions in terms of either reducing the MVP ('minimum viable product') and narrowing the Project Scope (as well as making settling for a less grandiose but more attainable objective) , or of reallocating resources, and reassigning tasks. This happens when program budgets are suddenly cut, or during periods of shortages of various resources necessary to the completion of the project.
This article (the much-anticipated Part 2) deals with the second preventive measure which can be taken against the entropy of a project disaster. It simply involves Client Expectation Management. The conventional wisdom [although I've seen very little wisdom demonstrated at most of the conventions I've attended], in explaining to your client what to expect is to "err on the side of conservatism, " and to use your best efforts to "under-promise and to over-deliver." Conventional wisdom notwithstanding, these are the cornerstones of giving your project team a pre-programmed margin for error.

Philosophically and psychologically, an error does not appear to be an error if it has been factored in at the outset of the project. Here are three vital considerations in preparing your client, and your team, for what they will experience, or what they can expect on the journey to project completion. And while they will seem ridiculously obvious, you would be appalled at how many project managers, attempting to land an engagement by making themselves appear superhuman by overselling, completely forget these basics:

1)  Always significantly overestimate costs anticipated to be incurred -- it is far better to come in below budget than to apologize for exceeding budgeted amounts;

2)  Always significantly overestimate the length of time that will be expended in reaching every benchmark or measurement point during the process, and overestimate the total time to completion -- it is far better to be further along in the process than to be lagging behind schedule; and lastly,

3)  Always significantly underestimate the quality and capabilities of the finished project  -- it is far better to to have an outcome which exceeds expectations than to produce an inferior result or outcome.

The most difficult discipline involved in this exercise in diminished expectations is to remain certain, by and among yourself and your team, that the parameters as set forth in the preceding three items are not ever seen as the real targets. In fact, in planning the project with your team, their standards for performance must, of necessity, be far stricter than those set forth for the purpose of managing the client's expectations. As a leader or manager, your challenge is to avoid any slippage into a default setting, on the part of yourself or your team which even remotely resembles the highly conservative parameters that you have utilized in positioning the client's expectations. Perhaps the appropriate Lingovation for this typical propensity to default would be "Parametric Creep."

This (i.e., minimization of Parametric Creep requires constantly maintaining and enforcing an internal performance standard that is far superior to the external, or public, performance expectation.

In Part 3 of this series, we will address some of the best methods of early-stage action in order to prevent any project from becoming unmanageable.

*Incidentally, if you have not already done so, you would be well-served to visit The Project Management Hut at and either bookmark it or make it a favorite. It is an excellent source of information regarding the art and science of Project Management. 

No comments:

Post a Comment

View DOUGLAS E. CASTLE's profile on LinkedIn
Douglas E. Castle
Bookmark and Share