Skip to main content

Author: George Pitagorsky

George Pitagorsky, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. He is a coach, teacher and consultant. George authored The Zen Approach to Project Management, Managing Conflict and Managing Expectations and IIL’s PM Fundamentals™. He taught meditation at NY Insight Meditation Center for twenty-plus years and created the Conscious Living/Conscious Working and Wisdom in Relationships courses. Until recently, he worked as a CIO at the NYC Department of Education.

Say What You Think to Promote Project Success

Written by George Pitagorsky on . Posted in Articles. 7 Comments on Say What You Think to Promote Project Success

Not speaking up about controversial issues can cause project failure.

It takes courage to speak up in the face of a perceived flaw or error. This is particularly true when the idea being critiqued has been put forward by someone in a hierarchy above you. First, you might be wrong. Then again you might be right and subject to firing or other penalties. Courage is not enough, though. Timing and diplomacy are also required. It is all about saying the right things at the right time to the right people in the right way.

The Trip to Abilene

The Trip to Abilene is a story by Jerry B. Harvey about how four intelligent and well meaning people took an unpleasant trip to somewhere that none of them wanted to go. The Abilene paradox is a phenomena that takes its name from this anecdote.

The Abilene paradox is the cause of many a misstep by organizations. People do not speak their mind when what is in their mind is opposed to the perceived general opinion of the people around them. Note that the Abilene paradox is different from group think. With group think, people are convinced that the group’s idea is sound. In the paradox, people are consciously aware that they oppose the idea and are acting contrary to their own thoughts and insights.

People don’t speak up because they may think that what they have to say is unimportant, possibly stupid, and/or bound to upset someone. They may fear retribution and censure. Sometimes this fear is quite rational. There are many examples of whistle blowers being persecuted. Many examples of the negative effects of arguing against the favored idea, design, plan, etc. Further, it takes effort to come to the table with a compelling argument. Harvey, quoted Herbert porter a Nixon campaign aid as saying that he “was not one to stand up in a meeting and say that this should be stopped”, a decision he then attributed to “the fear of the group pressure that would ensue, of not being a team player.” Porter was referring to the Watergate scandal.

Few will risk saying that the emperor is not wearing any clothes. Hans Christian Anderson’s tale of the Emperor’s New Clothes is another way of bringing out the difficulty of saying what you think. In this story, a vain emperor is tricked into believing that he was getting a suit of clothes that could only be seen by the most intelligent people. No one but a child had the courage to appear unintelligent and tell the Emperor that he wasn’t wearing any clothes. The emperor himself was too vain to admit that even he couldn’t see the new suit.

Whatever the reason, not speaking up is a problem.

Example

For example, in one project to implement cultural and technological change in a large organization, the project sponsor had in mind aggressive objectives coupled with an aggressive time line and a limited budget. When he stated his desires to his direct reports some of them thought the objectives were great while others hated them. No one argued. Some thought “nothing I could say is going to change the situation so why bother.” Others thought “the change is going to fail, all I have to do is wait.” Still others thought “I don’t want to be seen as a naysayer.”

With tacit consensus on the idea, the next step was to define the approach. How would the project achieve the change within the time frame and budget? Here experts were called in to design and estimate the various parts of the project. Some came back to their managers with the bad news that it was impossible to hit their targets and therefor the overall target could not be met. Whether Driven by the desire to meet the target date or the fear to tell the sponsor that the target date was not viable, the middle managers pushed their experts to make it work.

It is easy to make a complex project work on paper. The realm of planning is conceptual. A complex environment is simulated and, for the most part, over simplified. Planners and estimators can adjust the plan to fit any target date and budget. This may be done intentionally to sell some services or meet an imposed demand from above. Alternatively, It may happen inadvertently because the planners are too optimistic and they don’t adequately manage risk.

Based on an overly aggressive, unrealistic plan the project was approved and kicked off. Expectations were set in the minds of the sponsors and other stakeholders. Off the organization went on a trip to Abilene.
Once the work started and people began to interact, the real world of complexity, ambiguity, resistance and poor communication came into view. To compound the problem, status and progress reports were influenced by fear and the Abilene paradox continued to manifest itself in the area of project reporting and control.

Open Discussion At the Right Time

If one of the many people who knew that there were good reasons to not go on the trip had spoken up and put forward his/her reasoning the others may have listened, thought about the ideas, had a discussion about differences of opinion, risks, rewards, etc. and then made up their minds. The outcome can be far better when there is open discussion.

Doing this at the right time in the life of a project is important. Open discussion requires that people speak their mind in a constructive attempt to reach mutual understanding and agreement. When initiating, and planning a project it is best practice to establish a formal process to cut through the causes of people holding back. Open discussion generally means not only being open to conflicting ideas but to actually promoting conflicts by requiring that alternative ideas are raised even when it seems as if everyone is behind the idea that is on the table. Risk assessment is an example of how a team can create the space and give people permission to “be negative”. It motivates people to bring up issues that in the absence of the risk assessment context would make them seem like they not are being team players. By making risk assessment part of planning as well as part of any major decision there is a greater likelihood that open discussion will take place at the right time.

Sometimes we find that people speak out after what they have to say can no longer be acted upon. Instead of arguing about the details of requirements when the product is delivered, discuss or even argue about them when the requirements are being defined. A statement like “I could have told you so” is a sign of dysfunction. If you think something is wrong, say so.

Diplomacy

Diplomacy is artfully dealing with people with sensitivity while being effective. It is knowing the right way to say the right thing in a situation. Diplomacy is necessary as a balance for the assertiveness that is required to be candid. It can be taken too far and then be used as a way to avoid saying anything that might be disturbing to anyone. But in the right measure it is an important skill. It enables a person to say something that is controversial in a way that is least likely to arouse hostility while promoting healthy conflict.

Conclusion

The bottom line is that unless people say what they think at the right time and in the right way about key issues, projects and processes in general are more likely to fail. Commit to being candid and to taking the risk to say something you think will make you unpopular. If you can, make it as easy as possible for others to say what they think.

Don’t forget to leave your comments below.

The Power and Pain of Setting Deadlines, Targets and Time Boxes

Written by George Pitagorsky on . Posted in Articles. 3 Comments on The Power and Pain of Setting Deadlines, Targets and Time Boxes

Whether we call it time boxing, setting deadlines or setting target dates, the practice of picking and announcing a date upon which some event will take place is common, useful and dangerous.

While we can call them all targets, there are subtle differences. Deadlines connote musts. The term is said to have originated during the U.S. Civil war at a prison camp. Anyone who crossed the deadline would be shot. In the newspaper business, the deadline is the point in time that copy must be delivered to get the paper printed and delivered on time. Missing a deadline has a serious impact.

Target dates are softer. The target is set, but, as in archery and target shooting, there is a reasonable expectation of hitting the target. Missing the target therefor does not result in “death”. Coming close to the target is often considered a success.

In project planning, time boxing is a method for establishing a target date for delivering a clearly defined set of functions. In time boxing the scheduled target date drives the scope. In most other types of planning the scope drives the schedule.

Setting targets and time boxing have a softer, more flexible connotation than deadlines. Targets can be missed by a mile or an inch. Time boxes are set with a solid understanding of scope, resource availability and effort. If a time box target date is missed, remedies like de-scoping are readily available and the impact is not usually that great.

All scheduling results in target dates, that have been set with a focus on what has to be done, how much time and effort it takes to do it and who is available to do it. Scheduling is a complex synthesis of these factors totarget dates

The pros and cons of Expected Completion Dates

Like most practices, setting dates has its pros and cons.

In favor of setting deadlines is the fact that they are often necessary. Government regulations and start of school are examples. Even when not necessary they are useful because they motivate timely completion and make it possible to plan more effectively.

Unfortunately target dates are often mistaken for deadlines. They tend to be set in stone, often without regard to the relationships between schedule, scope, cost and risk. Many deadlines are arbitrary. There is no external force creating the deadline. it is simply someone’s decision, often motivated by fear, greed or ignorance.

Expectations

Anytime anyone publishes or even mentions a date at which some event will take place there are expectations. Expectations may be rational or irrational. The irrational ones do not consider the probability of the expectation being successfully fulfilled. They are overly simplistic.

Rational expectations know that no estimate is 100% guaranteed. As the scope and complexity of work increases the ability to estimate with certainty decreases. When there are other variables, like the availability and capability of resources, changed priorities, the delivery of required supplies and inputs, and the weather, the ability to estimate with certainty decreases further.

Expectations lead others to make promises, plan purchases, schedule events and more. When expectations are held by powerful people who are your superiors, sponsors or clients, the impact of not meeting them is greatly magnified. Target dates become deadlines. Fear drives performance and that leads to poor decisions which result in low quality products. Think about how fear of missing a deadline leads to corner cutting and how corner cutting effects outcomes. For example, if to meet a deadline a project team cuts testing or hides flaws, the results can be disastrous.

So what to do?

There are options. You can

  1. Refuse to set any targets until you have finished the work itself. This removes any risk of setting unrealistic expectations.
  2. Set rational targets, estimating as accurately as possible considering all the variables and the probability of success
  3. Accept a mandated deadline

No targets – Just do the Work

Option one works but only under special circumstances. You would need a fairly unlimited budget, a patient sponsor, a high priority, and a difficult to estimate project, perhaps one that has not been done before. The problem is that we need to plan future work and people in powerful place do not like the uncertainty that comes when there is no schedule. Thisreminds my of the scene from ???? In which the Pope calls out to Michaelangelo, who he has commissioned to paint the ceiling of the Sisteen Chapel, “when will you make an end?” and Michaelangelo answers “when I am finished.”

Set Rational Targets

Setting rational targets not only implies taking scope, resource availability, cost, and risk into consideration, it implies that expectations are managed. Remember, even the most rationally set target date can become an irrational deadline. All it takes is a sponsor, client or manager who forgets about all the variables and qualifiers and focuses on the date, saying, “You said you be finished by …”.

Managing expectations means giving estimates in ranges, continuously assessing the estimates in light of accomplishments and current conditions, and regularly reminding stakeholders of the probability of hitting the target. Change the target date, scope or other factors when hitting the original target is no longer possible.

Accept the Deadline

Deadlines are often necessary. Even when they are not driven by a compelling reason and are set arbitrarily, you may have no choice but to accept them or lose your job. Note that sometimes losing your job is the best choice, particularly when each project you work on is a forced march to failure and retribution.

Short of quitting, there are two approaches to accepting a deadline. The first is to just dive in and do the work. This is not a particularly skillful approach. Even when the deadline is set, it is necessary to plan and manage expectations.

The skillful approach is to estimate, consider risk and risk remediations. The goal is to determine up front whether the deadline can be met and under what conditions. Estimating and scheduling is about making trade offs among scope, time, cost and resources. It implies risk mangement.

When there is a deadline, time, or duration to be More exact, is valued more than the other factors that drive schedule. To plan to meet the deadline you can reduce scope or increase resources. Sometimes you might choose riskier approaches, always including risk remediation in your planning.

Whether you plan backwards from your deadline or forward from the start time, you want to be realistic. If your planning and estimating shows that you will miss the target, you must do something to change the scenario. If you get to the point at which the scope is cut back so far as you won’t be delivering anything of value, or where the cost of adding resources becomes unacceptable, then you do best to let the powers that be of the probability of failure.

Stakeholders would rather know early on that the deadline is probably not going to be met than become aware of it as the deadline approaches and is passed. There are times when this seems not to be the case. You might think that making the stakeholders aware at the last minute will save you the trouble of presenting the bad news earlier and seeking a change to the deadline. But, don’t do it. Give them all the time you can to assess the trade offs and make rational decisions. If they choose to tell you to “just get it done by the deadline any way you can, or suffer the consequences” just dive in and do the work (according to your plan as best you can. You may or may not be late, but it’s the best you can do.

The Good News

The good news is that few project managers are fired for missing a deadline. Even the most seemingly irrational stakeholder finds it hard to ignore the realities of all of the things that get in the way of on time completion, particularly when the project manager has diligently and persistently presented progress reports that lay out the facts and their implications.

In the end, you can only do what you can do. By definition, the impossible remains impossible regardless of who wants it to be otherwise. Your job as a project manager is to insure that what you think is impossible really is.

Don’t forget to leave your comments below.

Requirements without Users

Written by George Pitagorsky on . Posted in Articles. 2 Comments on Requirements without Users

Conventional wisdom and best practices tell us that end users and other stakeholders must be involved in IT application and other product requirements definition. In traditional mode, the involvement is before design and development. With an Agile approach the users must be an integral part of the project team.

What Do You Do When Users are Not Available?

But, what do you do if users are not available because they are fully engaged in their operational duties and can’t spare the time, are resistant to change, or just not interested enough?

You can wait for them to get on board the development train. That might take a long while and delay a project that can provide significant benefits to the organization.

You can force them to get on. That might get you started, but, as soon as they can or must they’ll jump off and your project will be delayed. Sometimes they will even derail the train.

What if you just start without them? Radical and risky you might say, though it might be the best way to get moving and deliver a useful product in the shortest amount of time. Think of a requirements-without-users approach that is like prototyping. A prototype can be developed based on minimal requirements and then refined until the product is ready for production use.

This approach requires that the following conditions are met, 1) you have a window of opportunity to make use of development staff that might not be available later, 2) your users and sponsors are open to getting engaged later in the process (ultimately they must get involved) 3) your sponsors and senior user management are realistic enough to accept that there will be a lengthy acceptance testing and refinement process that requires involvement by users and stakeholders. once the initial version of the product is delivered and 4) you have alternate means for determining the requirements.

Condition 1: Resource availability

Condition one means that there are programmers and analysts who are waiting for something to do and who have the capacity and knowledge to do the job. In another month, some other project will be ready to start and the resources will be grabbed up. If you don’t get started now, you may never get started.

Condition 2: Buy in

Condition two says that you must ultimately get buy in from users and their management. Buy in to the process of letting the development team has to be earned. It requires that the sponsors trust the development group to work in a way that best supports the needs of the business and that the sponsors are eager to get the project moving. It requires that the user group or groups agree to letting others “read their mind” and postpone their involvement until a prototype is delivered. Buy in to the product will come because business requirements, including efficient and effective operational procedures, are met. In other words, the product must deliver expected benefits and do so in a way that makes good business sense.

Condition 3: Realism

Condition three is realism – a management team that is able to accept a lengthy post delivery change process and who will make make the users and other relevant stakeholders available for the acceptance process. This condition implies that whatever the result of the initial round of development there will be a process to make the result acceptable to its users. It is more than likely, perhaps inevitable, that no matter how product requirements are defined and no matter who defines them, there will be changes that are discovered once the product is delivered. This is the underlying reason for acceptance testing and ongoing enhancement process planning. Taking a requirements-without-users approach generally means that there will probably be more changes than if the users were integrally involved in the requirements definition and in the development itself (as in an agile team). Consider the initial deliverable as a prototype. The acceptance process refines the prototype. The duration of this process depends on the number and type of the changes required and the availability of resources, including the users who will test the product and make requests for change.

In effect, the Requirements-without-Users approach is really a change in the placement of user involvement in requirements definition in the development cycle. in addition to change where in the cycle users are involved, it also changes the nature of the elicitation process. Users must still accept the product and that means they have to make their requirements known. Elicitation is usually done by asking the stakeholders what they want. In this approach stakeholders are asked to verify that their requirements are met by the delivered product.

Condition 4: Alternate Source of Requirements

Condition four is also about realism. In keeping with the reality that nothing spontaneously arises without causes and conditions, requirements have to come from someplace. Where do they come from when the users don’t provide them? There are a number of sources: research into products such as commercial packages for a similar application, the existing application and/or business process and its strengths and weaknesses, change requests and complaints about the existing application and process, research into the needs of the recipients of the output and services provided by the current system, the knowledge of technical staff and business analysts who have been working with the user community for years, and from expert consultants with deep knowledge in the application area.

In most application development projects an existing system is to be replaced. The system, whether automated or entirely manual, has in it many of the requirements for the new system. In effect the new system’s requirements can be inferred from the combination of the existing system’s features and functions and any complaints, change requests and/or project justifications that may be available. Manual procedures can be assessed by shadowing the users or researching standard operating procedures, if they exist.

Every system has people or other systems that provide and receive data or services from the target system. It is possible to infer the requirements of the target system from the needs of related systems. For example, if an application is supporting a service to customers, the definition of the service itself, chronic complaints and problems and knowledge of the existing system’s features and functions, new features and functions may be used to identify the requirements that will enable improved customer service.

Often IT staff and business analysts have significant knowledge of the business areas they serve. Sometimes they are more knowledgeable than the users themselves. In addition, they are structured in their thinking. They can be excellent sources of requirements, though their perspective may be too computer centric to be relied on as a sole source of requirements.

Conclusion

While it is necessary to engage the users of an application in the acceptance of their system, it may not be necessary to engage them in an intensive up front requirements analysis process. The need to take a Requirements-without-users approach to application development arises when users are not available or when they are resistant to change. When the right conditions are met, requirements can be derived from existing systems, the needs of the ultimate recipients of data and services, from knowledgeable IT and BA staff and/or from expert consultants. Based on these requirements a prototype can be created and used to validate that the product meets the users’ needs.

Don’t forget to leave your comments below.

Take a Break to Improve Your Effectiveness

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Take a Break to Improve Your Effectiveness

You are working in a high profile project. Your team has been working long hours for several months, including a good number of weekends, and doing a great job. Vacations have been put off until the project is done (another six months, if things go well). The project is on schedule and budget. Remaining activities are to finish the development work, perform quality assurance and roll out the product to its users.

The phone rings and it’s your project sponsor. There has been a change at the highest levels; some political issues coupled with a new project that is in the wings and needs to be expedited makes it necessary for you to get done in three months instead of six.

What do you say?

  1. Yes sir
  2. Are you nuts? No way.
  3. Let me take a look at the options and I’ll get back to you
  4. Nothing. You hang up on her and cry.

Clearly, your best choice is 3. You are smart and experienced. You know that a change like this needs some clear thinking and some quality time to do it.

What do you do next?

  1. Polish your resume and call your favorite recruiter
  2. Take some time to relax, meditate and/or work out
  3. Assemble your team and give them the news
  4. Immediately review and begin changing the plan

The Best Answer – Take a Break

Here, the best answer is 2. Take a break. This is counter intuitive to most people but it is the right thing to do because you need a clear and relaxed mind to address the situation in the most effective way. Stressing about it and trying to figure it out in the shortest amount of time is counterproductive.

The Effect of Rest and Recovery on Productivity

“Paradoxically, the best way to get more done may be to spend more time doing less. A new and growing body of multidisciplinary research shows that strategic renewal — including daytime workouts, short afternoon naps, longer sleep hours, more time away from the office and longer, more frequent vacations — boosts productivity, job performance and, of course, health.” Tony Schwartz, February 9, 2013 in the NY Times

Relax! You’ll Be More Productive. Let go of the attempt to figure out complex problems (after a reasonable amount of effort) and solutions will emerge.

It is widely accepted, though less widely practiced, that rest and recovery is necessary to allow the body and mind to integrate the effects of exercise and to rejuvenate after an exercise or wor work session. Pushing through fatigue, whether using aids like caffein and sugar or just raw will power may work in the short term, but the results are an increase in fatigue and a reduction in productivity and performance.

For project managers, and knowledge workers of any kind, mental acuity and the productivity it brings to creativity and decision making are critical to success. Rest and recovery increase mental acuity.

In addition, problem solving, planning, designing and other creative tasks are best done while relaxed and open, as opposed to exclusively focused on intellectual and analytical effort. Breakthroughs often occur in the shower or on a walk in the country while not thinking about the problem in a left brain, linear and analytical way. Letting go and letting the often untapped right brain, intuitive and holistic mental functions operate leads to AHA moments. AHA moments lead to creative solutions and effective decisions.

Productive Breaks

we can divide breaks into long, intermediate and mini categories. The long term break is a day or more off. The intermediate break is an hour or more. The mini break can be as short as five or ten minutes.

All three are important and all three have similar benefits – rest, relaxation and recovery from intensive work and mental clarity.

Vacations and retreats are periods when you get out of the work mindset and let the mind refocus and the body rejuvenate.

Lunch hours and breaks are as important as longer breaks. Get away from your desk and take a walk or run, meditate, do some yoga or other exercise, take care of personal errands, take a nap or sit under a shady tree. The distance these breaks provide from focused thinking and working changes your perspective. Physical exercise, a nap and some healthy food renew your energy.

The mini break is a quick stepping back from intensive work. Every hour to hour and a half make it a point to stop, get up, move around and relax. Just a few minutes will give you the moment you need to refocus, relax and go back to work refreshed and with a more effective perspective on what you are doing and how you are doing it.

Meditation

If you meditation into your breaks, they will be even more powerful. Meditation is a mental exercise that cultivates a calm mind, results in physical health benefits, enhances concentration and cultivates the ability to objectively observe what is occurring in and around the meditator’s mind. Focusing on the breath or another mental object while letting go of any thoughts that might arise is a technique that is a powerful addition to anyone’s personal productivity tool box.

Stepping Back and Being in Flow

Breaks provide rest and recovery which enhances energy. Of at least equal importance is the stepping back to change your perspective.

There is great power in getting totally focused on a task, getting lost in it, being in flow or in the zone and experiencing what Mihaly Csikszentmihalyi described as “being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you’re using your skills to the utmost.”1

As long as you are in flow and your flow is taking you in the right direction, there is no need to step back. But flow is not sustainable for very much longer than an hour or two. After a while, fatigue sets in and the concentration required to sustain the flow experience is lost. When this happens, the time is right for a break. Instead, many people push on and end up working less efficiently, often finding that they have to rework what ever they have accomplished during that forced march period.

Consciously step back. Review what you have accomplished. See it in the context of the bigger picture of the project as a whole. Clear your mind. Refresh your body and then, when you are ready take on the next task or continue the one you took a break from.

Don’t forget to leave your comments below.

1 Geirland, John (1996). “Go With The Flow“. Wired magazine, September, Issue 4.09

Managing Expectations Situationally – Single vs. Multi-Point Estimates

Written by George Pitagorsky on . Posted in Articles. 4 Comments on Managing Expectations Situationally – Single vs. Multi-Point Estimates

A recent conflict in a project highlighted the need to take a hard look at how to communicate estimates.

The issue was kicked-off when a functional group presented an estimate for a key critical path activity for a high profile business project.  Upon hearing the estimate and assessing both its impact on the project end date and their opinion on how long the activity should take, some members of the core project team became frustrated and started to escalate the issue to put pressure on the functional group to get things done faster.

Before things got too crazy, a brief intervention discovered that the estimate was meant as a worst-case scenario that considered a number of risk factors with varying degrees of likelihood and impact on the activity.  Relatively quickly, the functional group presented its assumptions and its most likely scenario, which satisfied the project’s need to meet a pre-established deadline and helped to create an attitude of greater trust and respect between the groups.

Estimating + Communication = Expectations Management

The lessons learned from this situation apply to two dimensions of project management, estimating and communications.  These two dimensions meet at expectations management, a most critical project success factors.  Estimates set expectations.

When communicating, it is important to make sure that the message sent is crafted in a way that is most likely to achieve its underlying objective.  The objective of an estimate is to set an expectation that can be fulfilled. As with all communication, the recipient will interpret the message through his or her filters – knowledge, personality, past history, etc.  Know your recipient and tailor the communication accordingly.

When you receive an estimate that ruffles your feathers, ask the sender questions, such as “What are your assumptions?” or “Is there any other possibility?” to avoid unnecessary conflict and escalation and begin a negotiation process.

Estimates and Situational Management

Estimates represent a continuum of values with worst case (pessimistic or highly conservative), most likely and best case (optimistic) points.  For professional project managers, conventional wisdom is to present all three points along with their underlying assumptions.  Unfortunately, conventional wisdom is not always so wise.  

The truly wise PM knows that situational management is the most effective approach and that means doing what is most likely to be right for the situation at hand.  Sometimes it is best to present a single estimate, sometimes three points, and other times it is best to present a range from pessimistic to optimistic.  In all cases, it is necessary to have the assumptions, risks and/or conditions that support the estimate well thought out and, if not communicated, then ready to be communicated as needed.  It is the sophistication and past behavior of the estimate’s recipient, that determines which approach to use.

Let’s take the situation above for example.  In that situation a technology professional was presenting the estimate to a project manager who also happened to have years of experience in the type of activity being estimated.  The PM immediately assumed he was being taken advantage of, or, worse, that the estimators didn’t know what they were talking about.  Instead of responding with questions about the reasons behind what he considered an extremely conservative estimate, he got angry and escalated the issue.

Had the estimator taken into consideration the sophistication and knowledge of the PM, he would have presented the full range of estimates and assumptions.  There could have been a good collegial discussion with a mutually acceptable estimate as an outcome.

Instead, the estimator assumed that he had to protect his group from the typical response they got from less knowledgeable recipients who did not have the patience for dealing with multi-point estimates and their underlying assumptions and conditions and who latched onto a single number and forgot that estimates are subject to changing conditions.

The Problem with and Value of Pessimistic Estimates

Pessimistic estimates represent worst-case scenarios.  They are valuable.  They set expectations that are highly likely to be met and, when done well, they provide a realistic view of the risks associated with the activity being estimated.  

If, however, the pessimistic estimate is the only estimate, it sets the bar too low.  Pessimistic estimates can become self-fulfilling prophesies.  If people work to meet the estimate, as many do, it is unlikely that they will finish any earlier or cheaper than the estimated duration and amount.  If the actuals for each successful project are used as a basis for future estimates, the low bar will be perpetuated.  Often stakeholders believe that pessimistic estimates reflect an attempt by the performers to slack off and not work as hard as they could and should. 

Pessimistic estimates may lead to poor decisions.  They may lead stakeholders to seek alternative product and service providers who say they can do the job cheaper and faster.  Pessimistic estimates may make the prospects of a project look so bad that the decision makers will not authorize it.

The Problem with and Value of Optimistic Estimates

Optimistic estimates represent best-case scenarios.  They are also valuable.  They say what could be done if everything aligns as perfectly as possible.  They enable performers to do the best they can do to make for the desired outcome by better understanding the required conditions.

When optimistic estimates are the only estimates and when they are presented without underlying assumptions or conditions, they may be used as a lever to put pressure on performers.   In some cases, optimistic estimates (often called low-ball estimates) are a means for making a sale or for getting decision makers to OK a project that, had the real expected cost been known, might be rejected.

Optimistic estimates are a problem because they set unrealistic expectations.  The manager who relies on an optimistic estimate will be setting unrealistic expectations for those above him or her (e.g., program managers, more senior executives or clients).  When the estimates are not met, the result is embarrassment, a cascade of blame and retribution and, in some cases, financial damages.

Qualified Estimates

Qualified estimates give their recipients a sense of the reliability, risk and conditions associated with the estimate.  Referring to an estimate as High-level or a budget estimate or a definitive estimate gives a sense of the degree to which the work being estimated has been examined in detail and a relative sense of the range of variance to expect.  Three point estimates are qualified as are any estimates that come with explicitly stated variance ranges and assumptions.  A qualified estimate whether three points or not, is one that states the conditions that have to be met to deliver the expected outcome in expected time and cost.  Assumptions regarding these conditions underlie every scenario.  Assumptions may be about the outcome of a risk event, the duration of activities like approvals.

Some powerful stakeholders, whether executives, clients or managers, are known to consider a three point estimate to be a multiple choice question in which they get to choose the answer they like best; usually the most optimistic one. They mistake most liked for the most likely.  Some do not bother to read the assumptions or understand the difference between terms like high-level and definitive.

As an estimator, take a situational approach and make sure you create and communicate your estimates in a way that gets the message across and then continuously remind stakeholders of the reality that estimates are not actuals and are therefore subject to change as conditions change.

As a manger, insist that the people reporting to you make and deliver estimates that are properly qualified, consider risk, and are supported by reasonable assumptions that relate to the conditions that will prevail when the work is being done.

Don’t forget to leave your comments below.