In This Chapter

Getting a government contract was your first goal. Now, you must move beyond getting the government contract to keeping it. One of the nice features of having the government as your customer is that, once the customer identifies a need, that need tends to be a recurring need—year after year, decade after decade. The challenge is to keep the contract you have and use the net revenues from that contract to fund the getting of more contracts. Holding on to your own contracts is called defending your territory. For example, the local exchange carriers in the telecommunications business consider any services in their own territory (as defined by the old Bell System map) to be their own home territory and strive mightily to hold on to all that business.

Similarly, once the government awards you a contract, consider that contract yours, and defend it against all challengers. Do everything you can to avoid a termination, and begin preparing, from Day One, to defend that contract when it comes up for recompetition. This chapter offers guidelines and checklists to ensure that you are doing everything possible to hold on to your hard-fought gains.

Yes, you read right. “What do the contract say” might be sloppy grammar, but there’s nothing sloppy about how your contract lays out your obligations to the customer. The contract answers precisely the question of what counts as good in the eyes of the customer.

The contract is a serious, legal document which gives the answers to “What should I be doing?” Therefore, if you’re the program manager, I strongly advise you to read the contract early and often during contract execution. Typically, the contract calls for specific deliverables (both products and services) as well as reports of your achievements and activities in many areas.

As the program manager, you will undoubtedly be faced—sooner or later—with the phenomenon known as scope creep. Sometimes slowly, sometimes quickly, the government program manager, or perhaps some other government employee, will hit you with a request to do something very reasonable but specifically not in the contract.

Here’s an example: the contract is for delivery of a particular product. Before you can deliver the product to the government and obtain an acceptable sign-off, the contract calls for a specific set of standards you must meet and pass. The acceptance and delivery triggers a chain of events that results in payment to you. But after the work has begun, the standard changes. So the customer test manager wants your testers to use the new standard. That request is perfectly reasonable and even the right thing to do in support of your customer. A new standard requires new acceptance tests.

Doesn’t sound unreasonable, right? But, wait. Suppose the new standard is far more stringent, and therefore much more difficult to achieve an “accept” on the test. Now you’re in a bind. Do you do what the customer’s test manager—a perfectly wonderful person (undoubtedly, her mother and father love her, at least)—wants, or do you refuse and conform to the contractual standard? Well, “What does the contract say?”

The bottom line is that you are not obligated to use the new standard. You will need to take a close look at the implications to the obligations you would have under the new standard and compare those obligations with those now found in the contract. If there is a significant negative impact, in that you are now required to pass more stringent tests (therefore requiring you to do more work to pass the acceptance tests), then, in all fairness, you are allowed to ask for an adjustment in the price, schedule, or both. Correspondingly, if the new standard means less work and lower costs to you, then the government is allowed to negotiate for lower costs, to get delivery sooner, or both. The contracts in this case are an agreement about how, and under what circumstances, you and the KO will adjust the contract to fit new developments. In effect, it’s an agreement to reach a new agreement, based on equity to each party.

The overarching rule here is to refrain from what may well be your natural instinct, which is to do just about anything to “please the customer.” Pleasing the customer is a very good idea, but it must be within the confines of the contract of record. Examples of such out-of-the contract activities are: re-work of already accepted deliverables (unless such re-work is called for under the contract); creating deliverables helpful to the customer, but not specifically called out in the contract; and purchasing equipment from your own budget, when the contract requires the customer to supply that equipment.

As you and your team toil away to meet the contract obligations, always track your progress through the creation of deliverables (CDRLs). These contract reports are not just busy work, but use them to report progress to the customer regarding how you’re doing in relation to their goals and objectives. Having these reports ready on time and with a high degree of accuracy is of the utmost importance for two simple reasons: the reports are required contractually, and correctly reporting in accordance with the contract is a huge step forward in pleasing the customer.

To get an idea of the type and number of reports that may be required, here is a list of selected reports required under a multi-billion dollar GSA Networx Universal Contract awarded to three large telecommunications companies in April 2007. They are available on the winning companies’ websites.

Your contract may not have nearly as many deliverables as the ones listed in this sample; but whatever requirements your contract lists, you are contractually obligated to provide the reports. Reading the contract lets you know what the customer expects. Then actually doing those things means you are meeting the customer’s expectations.

Often, one of the most serious contractual provisions is the program schedule. Typically, the contract spells out the important milestones, and the program manager has the responsibility to achieve those milestones, in accordance with the schedule.

As you go about the business of delivering on the promise, you’ll be in frequent communication with the customer. When you submitted an organization chart as part of your proposal, you clearly showed that the single point of contact for the government would be your program manager. So now that the project has kicked into action, the program manager should serve as that point of contact. The only exception to this is the “No Single Point of Failure Rule,” which allows for an immediate fail-safe backup should the prior designated program manager not be able to fulfill the commitment.

The program manager encourages and allows contact between the government’s people and the contractor’s program people. For example, the quality representative from the government should work hand-in-glove with your quality people. The government engineers and your engineers work together to solve issues as they arise.

As program manager, you want to encourage peer-to-peer contact between the government personnel and your personnel. These contacts help solve day-to-day issues and problems. This contact is not contrary to the formal “single point of contact” process shown in your organization charts. It’s necessary, though, to ensure that everyone concerned acknowledges that, in the final analysis, the formal line of communication is government program manager to you as the contractor program manager. Things can go along for weeks or months without a problem. But when problems that cannot be solved easily and quickly at the working level (for example, engineer-to-engineer) arise, the clear escalation path goes from the government program manager and you, as the program manager, upward in your organization to the next higher level of management.

Chapter 17 shows the organization charts that apply to your program. In that chapter, Figure 17.2 shows the relationship between your program manager on this program and the balance of your own organization. The solid lines show the escalation path. The government program manager, therefore, knows exactly who is next in the escalation chain. There is no ambiguity.

We’d all like to believe that the government contracts we win go off without a hitch. Well, there’s no such thing as the tooth fairy, and there’s no such thing as a program without problems. The problems could be with technical performance, schedule variances, or cost overruns. In the worst case, it could be all three. So it’s not a question of will things go wrong, because the fact is that things will go wrong. The important consideration is how you come to know that things are going wrong and then what you do to get back on track (for example, create and execute a catch-back plan).

What kinds of things can go wrong? The answer is just about anything shown in the management plan. Here’s a short list of examples:

A function of management is, among other things, the replacement of uncertainty with certainty. The way to do that and to show you’re doing that is to develop a program plan (as in your winning proposal) and then follow that program plan during program execution. The best individual to author, or at least supervise, the creation of the management section is (not surprisingly) the program manager-designate. This person is the single person most likely to be concerned about the correctness of the plan.

You’ve read it before: the number-one reason for losing competitions is the lack of top management (TM) involvement in the process. Correspondingly, an easy way (not the only way, but an easy way) to lose a customer is to give the impression that your top management is disengaged from your program execution. A TM who doesn’t care enough to be accessible to the government program manager and that person’s superiors is asking for the customer to become disenchanted. The customer quite properly says, “Hey, where is that top level of involvement that we, the government, saw throughout the competitive phase? Where is TM now, and why can’t I get a prompt response to my issues with this program?”

The lesson is this: just as it was the responsibility of the proposal team (led by the three important functions: capture manager, proposal manager, and program manager-designate) to keep TM involved, it’s now the program manager’s responsibility, assisted by others as appropriate, to do the same during program execution.

The Least You Need to Know