Special Focus on Firm Fixed Price Bids and Contracts

We add here to the previous discussion of fixed-price contracts our ''top dozen'' list of actions to consider in order to reduce the risk associated with bidding and accepting such contracts; the possible actions include walking away from a particularly high risk project. This list is provided below as Exhibit 4.2. Further explanation of the items follows the list.

Exhibit 4.2: ''Top Dozen'' List for Firm Fixed-Price Bids/Contracts

1. Assure high performance team (HPT) with proven track record.

2. Construct a contingency plan.

3. Set aside reserves.

4. Perform no out-of-scope work.

5. Assure ''chunking'' of work with associated payments.

6. Establish clear, measurable acceptance criteria.

7. Limit software warranties.

8. Have limits on penalty clauses.

9. Incorporate the proposal by reference.

10. Establish special rewards for the project team.

11. Set up a cost information system.

12. Know when to walk away.

High Performance Team (HPT). Since you are dealing with a firm fixed-price (FFP) effort, it is critical to use the very best team that you have. This normally means that the core team has worked together for the past three to five years and has proven that it consistently achieves high-level results. Adding new senior people to a proven HPT should be done carefully to make sure the new folks are team players. If not, act quickly to remove them before they're able to cause damage to the team's spirit and productivity. Never micromanage an HPT. Doing so invariably leads to negative consequences. If the team has a proven track record, as you should insist be the case, give them the job to do and manage largely by facilitating.

Contingency Plan. Even with an HPT starting the project, you still need a contingency plan if the work is being done on a FFP basis. A contingency plan flows from the project risk analysis (see elements of a project plan in Chapter 3) in that it is focused upon the actions that might be taken if various risks actually occur. Although risks to a project can be quite numerous, one of the most serious is the loss of key personnel, for whatever reason. We used to ask the generic question—''What if your lead engineer gets hit by a truck?'' That worst case scenario required the PM to think through how the project would be completed without experiencing a serious setback.

A contingency plan does not have to be a long document. It can be a one-pager listing the risks on one side and the plans to mitigate those risks on the other.

Reserves. As referred to under Section 4.3.3, reserves are especially important in FFP contracts, with recommended amounts in the 8-12% range. The lower end of reserve is used when the project is one of many similar ones that have been carried out in the past. The 12% may be expanded to 15% when there are a few new challenges presented on the project. Such challenges should not be, for example, pushing the state-of-the-art. They should be well within what the project team believes is workable. Project reserves for FFP contracts should be under the control of the PM and signed off by the PM's boss. Other ''pots of money'' might be made available as reserves above the project level, for example, by the cognizant vice president. Knowing how to deal with reserves in a corporate enterprise context is an important element of overall risk management.

Out-of-Scope Work. Out-of-Scope (OOS) work is all activity that is carried out in support of project goals and/or objectives that are not in the terms of reference of the contract. It is also any ''gold-plating'' that was not part of the original bid that was signed off by the customer. The bottom line with respect to OOS work is simply that it should not be permitted since it normally increases risk and spends potential profit dollars. Whether suggested by the internal team or by the customer, OOS work can be kept on a list for consideration in a future contractual effort (not the current one). If there is a question as to whether or not a piece of work is in- or out-of-scope, then a most serious meeting needs to take place with the most senior people of the project in attendance. If you and your customer disagree on this type of issue, an extensive and immediate meeting is necessary to resolve this conflict. Failing to do so usually leads to great difficulties down the road.

"Chunking" of Work. Work on a project is normally defined in ''chunks,'' whether they are elements of a work breakdown structure (WBS) or task statements that are part of a statement of work (SOW). The added ingredient here, however, is to connect the completion of these work elements to contractual requirements to get partial payments on an ''as-you-go'' basis. So, for example, if there are ten major and approximately equal effort tasks to be accomplished, it is highly desirable that you get paid one-tenth of the contract value as you complete each of these tasks. Under these circumstances, if there is a controversy at the end of the contract, you will have received 90% of the payments due under the total contract. This, of course, reduces the overall financial risk. It may be compared to the case in which there are no payments made until all ten tasks are completed. In this case, a controversy at the end has quite different dynamics as well as psychology. This overall strategy might well have the subtitle ''progress or partial payments.''

Acceptance Criteria. Many FFP contracts give to the customer the exclusive right to determine whether or not a contractual deliverable is acceptable. In this situation, the customer may look at a deliverable and say ''This isn't acceptable; go back and work on it until it is.'' Of course, this would normally lead to a request for specifics as to why it isn't acceptable. All of this hinges upon the existence of written acceptance criteria that form the basis for judging acceptability. If such criteria do not exist, then a fuzzy set of conditions is likely to prevail, and you may be asked to continue to work the problem indefinitiely. This argues for establishing firm acceptance criteria for all deliverables, one at a time, or as a group. Limits on review times as well as number of deliverable iterations can often serve adequately when it is difficult to be definitive about acceptance criteria.

Software Warranties. Some customers will request software warranties. One form of such warranty is that the software be free from latent and patent defects. This should be viewed as a red flag since it may lead to (a) downstream rejection of the software product, even after it has initially been accepted, and (b) the invocation of penalty clauses as a result of defective software. A more useful construction is simply to agree to fix software (at no additional cost) found to be defective during the six month period after it has been accepted and paid for. This normally limits the liability in ways that should be acceptable. The potential cost of this type of warranty should be built into the price of the software in the initial bid, usually on an expected value basis. If a ''worst case'' cost scenario is built into the bid, it may be that the probability of winning such bids will sink to unacceptably low levels.

Penalty Clauses. Penalty clauses require the developer to step up to various types of penalties if the delivered product is not satisfactory. These types of clauses vary in their difficulty, and at times can be viewed as a double red flag. Penalties can be sought when the product is simply not delivered on time. Typically, there would be a charge for each day of delay in the delivery schedule. This can be quite onerous and should be avoided in most situations. A second type of penalty is associated with the discovery of product defects (eg., bugs in the software). Here again, great care should be exercised in accepting this type of penalty clause. If the product is proven and mature, one can be less nervous about these clauses. Another alternative is to request extra (bonus) payments for early delivery, for example. This can provide offsets and incentives that work for both developer and customer.

Incorporation of Proposal by Reference. Some customers like to incorporate the proposal into the contract between the two parties. This means that the developer must live up to any and all promises made in the proposal. When these are overstated so as to increase the chances of winning, major problems can result when the proposal becomes part of the contract. The two most obvious countermeasures are (a) to not accept incorporation of the proposal into the contract, and (b) to try to go back and ''scrub'' the proposal so that all questionable promises are deleted. Here's where the company lawyers need to earn their keep by focusing on these promises and working as part of the team, together with the PM, CSE, and PC for the project.

Special Rewards. Since FFP contracts represent special potential risks for the company, it should be worth real dollars to mitigate such risks. One way to do this is to offer bonuses to key project personnel if the project is executed within schedule, budget, and performance specifications. Further, such bonuses should be commensurate with the effort required as well as the benefit to the company. In other words, they should be real motivators for the team to do an outstanding job. At times, possible promotions are connected to high levels of achievement on a particularly important project. Business as usual rewards typically result in business as usual performance. Companies should not be worried about treating some people in a special way when the circumstances call for special treatment.

Cost Information System. The project cost information system needs to be finely tuned in at least three dimensions for FFP contracts. The first dimension is the cycle time for cost reporting. Monthly cost reporting should be changed to every two weeks for FFP efforts, for example. If the standard cost reporting system cannot respond quickly enough, investing in a special system is likely to be worth it. Second, cost to complete estimates need to be provided on the same two-week cycle time, requesting such estimates from more than one person if necessary. Third, the PM and CSE should ask the PC to take personal responsibility for presenting a project status overview at a meeting every two weeks. This includes looking very carefully at potential schedule slippages that, in turn, might lead to cost increases. The PC should also be in a position to look for biased cost and time to complete inputs that might present an overly optimistic view of project status. In FFP contracts, one needs to search for the truth, and as early as possible.

Walking Away. If you are unable to successfully negotiate an appropriate number of the above items, especially on a FFP software product delivery that needs to be developed from scratch, it may be time to simply walk away. One form of doing so is to add large reserves to account for all risk areas such that you drive your price into a noncompetitive range. This strategy may backfire if your intent was to truly walk away in that your competitors may have done the same thing, leaving you the winner. Walking away from what many people in your company believe is a real opportunity may be quite difficult. But signing up to a losing contract can be a disaster in that one not only loses money, but also experiences significant opportunity costs. Having your best people working ten to twelve hours a day leaves them unavailable to tackle other ongoing contracts as well as new bid opportunities. Here's a case in which discretion may truly be the better part of valor.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment