Chapter 7—Persuade your customer away from mistakes
Always a difficult thing to deal with in a pursuit is a customer whom you believe is making a mistake. When you think this to be the case, it’s necessary to do some rigorous self-examination to be reasonably sure it’s the customer making the mistake, not you. There is always the temptation to think that you know better than the customer does what the customer needs. Sometimes it’s just your self interest speaking.
Here are three of the most egregious mistakes a customer is likely to make in the pursuit environment. We will discuss them in the order shown:
Customer mistakes require fixes that are specific to the nature of the mistake, but there are also some universal considerations. We suggest the following:
Wanting more than is affordable
In many circumstances this is the most serious mistake a customer can make. If not corrected, it can make the pursuit a guessing game and can destabilize the project after a contract is awarded. It seems to arise in two different ways:
We are not sure which is worse, a customer who doesn’t have enough money and knows it, or a customer who doesn’t have enough money and doesn’t know it. In the former case, the customer will be tempted to award the work to the low bidder regardless of whether that bidder understands the work. This can lead to project failure. It also wastes the time and money of serious bidders who could do a good job if there was enough money. In the latter case, the customer’s notion of the appropriate competitive bidding range will be poor. Serious bids will be unaffordable, and this could trigger cancellation of the project. But a poorly informed low bid could win, and again the result could be failure.
If the customer is willing to listen, project teams can help correct this error by providing informal cost feedback to the customer. This has to be done with full awareness that your competitors may be cynically “pumping sunshine” to the customer to lead the customer to believe that the stated needs are affordable given the available resources. There is always the risk that as a bearer or bad news you will be rejected.
An effective way to provide informal feedback is to provide a credible “cost study.” This could take the form of a study of cost outcomes on other projects of similar nature. It could also include appropriate information collected by various public agencies. And it could include results from parametric cost models of good repute.
Another good approach is to suggest that the customer order an independent cost analysis. Your recommendation should be that this be done by consultants who have no direct or even indirect interest in the project, and who have no fear of telling the truth. Although this could be costly, it might be much preferable to a project overrun.
Whenever dealing with a customer that you think is moving out of the arena of affordability, always keep in mind that the customer may have access to resources of which you are unaware. For example, your customer may be seeking additional allocations from other budgets you don’t know about, or cancellation of some existing project may be imminent, freeing up funds. So always proceed carefully.
Poorly structured project goals
We have over the years encountered six serious problems with project goals. Existence of any of these can predispose a project to failure, and as a minimum will increase project risks. Here are the six, and a few suggestions for dealing with them:
Stability. One of the most difficult risks a project team can face is instability of the project goals. Conscientious as a project team may be, it is hard (and expensive) to satisfy a customer who keeps revising the goals. Of course, in the fixed price contract project environment where the work content is tightly defined, the project team can handle this rather neatly by recording all of the changes and presenting the customer with the bill. This may or may not result in an unhappy customer.
In other situations, goal instability can be a difficult problem for the project team in controlling the customer’s risk. Failure to control the customer’s risk can result in a customer who is dissatisfied. Even though the customer is a major contributing cause of the problem, the customer may blame the project team.
We believe instability of the goals has two main causes, 1) a poorly organized customer, and/or 2) technological immaturity. Often the project team can help relieve the instability problem if the customer is cooperative. The key is trying to identify why instability may exist. If it is due to technological immaturity, it might be well to delay the project (or create a less ambitious pilot project) until the technology is more mature. If it is due to conflicts or uncoordinated decision-making in the customer’s organization, it may be possible to resolve the problem at a higher level of management.
A common source of instability is multiple customers who keep disagreeing about what to do. If it is necessary to have multiple customers, the distribution of power among them and the protocols for exercising it should be carefully considered.
Sometimes it is helpful to do more “prototyping.” This means communicating better with the customer what the product will be like without actually building it. There are many forms of prototypes. Examples are “brass boards” (for electronic products), static and working models, mockups, pilot plants and computer simulations. Software projects often create so-called rapid prototypes that are little more than inactive or semi-active screens the customer can look at to better understand what the final product will look like. If the customer dislikes what is presented, changes to a prototype are relatively inexpensive. Prototyping helps satisfy the customer who says, “I’m not sure what I want, but I’ll know it when I see it.”
Anticipatory documentation is another form of relatively inexpensive prototype that has been used successfully to assure customer satisfaction before proceeding with expensive detailed development of a product. It involves creation of draft user guides or training materials based on what the product will be like. By simply reading the documentation, the customer is able to obtain an excellent mental picture of the final product configuration.
There is a form of volatility of the goals that can be benign, but is not necessarily so. It is called goals creep. Sometimes when a project is in progress, it becomes clear that for a relatively small amount of additional time, money, or both, the project can be made to produce benefits that outweigh the added costs. Or sometimes, for example in military projects, a new or modified threat or problem is discovered that must be countered, causing goals to increase in scope. But all too frequently, goals creep represents nothing more than a hidden agenda that is gradually revealed. When this is the case, it is just a form of bait and switch. Hidden agendas and bait and switch are discussed later in this section.
Basis in reality. Aside from goal instability, little can make a project more risky than to have goals not based in reality. We have all likely had the experience of working on a project where the goals were poorly grounded. Even though the plan may have been thorough and the project team may have performed as well as could be expected, the problem didn’t get solved because its true nature was never recognized.
Goals can be at variance with reality in several ways. Some of the most common are:
The latter way of being disconnected from reality is sometimes recognized after the fact by unintended consequences. A classic example is the introduction into agricultural practice of the insecticide DDT. It was hailed as a boon to mankind, especially in third world countries, where it significantly raised crop yields. Yet only a few years after it was introduced, it was condemned as an environmental disaster.
A post-project excuse commonly heard when goals are not based in reality is “We didn’t know then what we know now.” While that may be true, it may also be true that someone could have, but did not, take the trouble to work the problem through before starting the project. There used to be a common saying in project teams: “There is never time and money to do it right, but there is always time and money to do it over.” In today’s competitive, resource limited environment, there is seldom time and money to do it over. It needs to be done right the first time.
Another aspect of poor basis in reality is when cash flow or elapsed time constraints are overly tight. This often happens because the constraints are rigidly set before there is a good understanding of the desired product. This problem cannot always be avoided when the project deals with very sophisticated “state of the art” systems. But it should be avoidable for most “low-tech” public construction projects, infrastructure projects, and other projects where there is a huge database of consistent cost and schedule experience that can easily be used to verify estimates. Yet amazingly, these projects often experience serious cost and schedule overruns. The difficulty is often traceable to a lack of realism in the goals, often introduced by micromanagement and political meddling. It can also be introduced by the opposite of micromanagement—a failure of proper oversight. Trust but verify, as a famous presidential saying goes.
Clarity. A clear goal is one that has definite criteria that can be used to decide whether or not it has been met. A counterexample is: “The software shall be user friendly.” This goal is vague and unclear. The customer and the project team may have radically different ideas about what “user friendly” means. The difference in these ideas could span a cost range of millions of dollars. If these extra millions are not in the plan, failure is likely.
An unclear goal is often in reality a complex of linked sub-goals, which are not well articulated. In failing to articulate them, risk is introduced into the project. Faced with unclear goals, the project team will tend to work on what is most familiar, or what is most convenient. The result is likely to be completely unsatisfactory.
It is seldom necessary to define every goal in a project with mathematical precision. But certainly all of the important ones should be clearly expressed. Not all problems with goals are preventable, but lack of clarity almost always is.
Generality. General goals have one or a few criteria. Specific goals have many. A general goal in a project might be to create a system that will move all baggage from an arriving aircraft into the baggage claim area within ten minutes of aircraft arrival. There are many possible means for achieving this, and each of them can be defined by a set of specific design requirements.
A great source of risk in projects is the premature transition of goals from general to design-specific requirements. It is very risky for project goals to prescribe specific design solutions before the nature of the problem is clearly understood. What is generally best is an orderly and careful transition from the general goals to design-specific derivative requirements, as the situation unfolds.
Particularly in complex cost-plus contract work, the customer must avoid the temptation to over-specify the end product in the concept phase. This may force the project team down a path that leads to a poor, costly design solution.
Linkages. We have already noted that vague goals can be a cover for a set of multiple, linked sub-goals. When a set of linked goals is examined in depth, there can be several types of linkages. Most notably, there can be positive and negative linkages between goals. The result can be stresses and risks in the project.
If two goals are positively linked, satisfying one tends to satisfy the other. But if they are negatively linked, satisfying one tends to dissatisfy the other.
Product performance goals and cost and schedule constraints have strong negative linkages. Negative linkages are explicitly revealed in expressions such as “cost /benefit,” “cost efficiency,” and “cost effectiveness.” Real projects must deal successfully with negatively linked goals. They are unavoidable. The first step in dealing with them is to recognize that they exist and to identify them.
One way to proceed is to give priority to one goal and let all negatively linked goals find their own level. This minimizes risk. The more usual situation is to set limits on all goals. But be aware that the tighter the limits, the higher the risk.
Visibility. A perilous situation arises when negatively linked goals comprise a hidden threat that only becomes visible when trouble arises. It is important that goals be visible when the project begins.
Unfortunately, hidden threats are not always easy to find, especially when they take the form of a secret agenda that someone wants to keep under wraps as long as possible. The best defense is generally a thorough review of all of the goals for consistency and coherency. Hidden threats may reveal themselves simply because they distort the pattern established by the goals that are clearly visible. It’s a bit like having a snake sleeping under a sheet. You can’t see the snake, but you can tell there’s something under the sheet that doesn’t belong there.
Ambiguous, obfuscating language often betrays a hidden threat. This is especially true when it occurs in specifications that govern the performance of the project’s product. Whenever a specification is written in a confusing way, you should strongly suspect that whoever wrote it doesn’t know what he or she wants. Later, when he or she has finally decided, you may be blamed for not understanding what was (according to him or her) always as clear as spring water. This sounds like a rare condition, but actually it is not all that uncommon.
An especially pernicious form of hidden agenda is the bait and switch. The expression bait and switch comes from the retail world. It happens when a merchant advertises a product at a very low price to entice customers into the store. But when they arrive there, they find that the advertised low cost product is mysteriously sold out, and will never be stocked again. So the merchant attempts to sell them a much higher priced and more profitable product. Something similar often happens in the world of projects, especially government sponsored projects. Someone, often a project team or interest group, successfully sells a project to a sponsor (such as Congress or a city government) on the basis of a phony, low cost estimate. Once the project has begun, the true extent of the cost is gradually revealed. It is typically much higher than the phony estimate. The sponsor, to avoid losing face or for other reasons, goes along and continues the project.
The bait and switch phenomenon in projects is not necessarily due to overt dishonesty. It can also be due to pride, greed, and simple hubris. Truly independent cost reviews by expert analysts are usually an effective remedy for the bait and switch.
In the visibility category, there is a subtle form of risk that might be likened to not being able to see because you have a hundred bright lights shining in your face. Sponsors of projects who have some uncertainties as to what they really want and are willing to accept sometimes load up project contracts with extensive boilerplate language and lists of related specifications to the point that even they don’t fully understand what they are asking for. This is especially common in government procurements, where 50 or 100 or more specifications may be listed. This gives the customer comfort that nothing important has been left out. But it leaves the pursuit team in an uncomfortable condition.
Often in a long list of boilerplate specifications one will find ambiguities and even conflicts. Boilerplate specs are often neglected and get out of date. The pursuit team either must try to sort it all out, and insist on exceptions when troublesome items are found, or go ahead and accept the work as is and hope for the best. Chances are, the “fine print” will never become an issue, but if it does, the problems could be huge.
A sponsor who wants a successful project will not load it up with unnecessary boilerplate requirements that require a team of lawyers and engineers a month to sort out. This practice is unprofessional. The dubious protections it provides are likely to be more than offset by a higher price for the work.
Poorly prepared project team
The customer who does not understand the project well or who is in a rush to get it started is likely to field a poorly prepared team to manage it. Poor preparation can be at two levels and sometimes it occurs at both levels.
At one level is the team that has been pulled together from various customer organizations and other sources. It typically includes people who weren’t busy enough where they were and may include new hires. Such a team probably has a poor understanding of the nature of the project and may be weak in the technologies involved.
At another level is a team that is inherently competent but has not had enough time to work important project issues. There is a rush to get someone under contract and get the project rolling. Unless the team is lucky, this situation will lead to costly mistakes.
If your pursuit team is competent you will be able to quickly sense that the customer team has not reached that level. A common manifestation of weakness on the customer side is likely to be poor understanding of likely costs and poorly structured goals, both previously discussed.
Dealing with a poorly prepared customer team can be costly. If you expect the customer team to be poorly prepared it is wise to plan to spend more interface time explaining what you are doing and why. It also may be that they will tend to make mistakes that you may be able to help them avoid.
Chapter 7 Review Questions
1. Have you ever encountered and had to deal with a serious customer mistake in the pursuit phase? How was it approached? What was the eventual outcome?
2. Explain in your own words how the customer wanting more than he or she can afford can result in project instability.
3. This chapter discusses six major problems with project goals. Can you name at least one other?