Keep your contracting staff in the loop

Whenever I speak with experienced contracting people about the joys and frustrations of their jobs, high on the list of frustrations is program officers who come to the contracting office with a procurement package that was developed without input from contracting staff. Contracting officers who raise issues or ask for changes are seen as delaying the procurement and/or being bureaucratic.

Some people believe that program managers who are eager to move fast on contracts must have some version of attention deficit disorder. I most definitely do not agree. The procurement system works much faster than it did before the reforms of the 1990s, and that’s a good thing. We want program managers to care about getting their missions accomplished with urgency, and it doesn’t make sense to expect them to tolerate a molasses-like procurement system.

But it does make sense to spend some extra time getting requirements in decent shape. Sure, it is unrealistic and undesirable to expect that initial contract requirements will be written in stone for an entire project. Needs and available technologies change. But performance requirements for the first module of a new information technology system should be well defined in the initial request for proposals.

A solid RFP has manifold benefits: It improves competition, gets the government a better deal, increases the chances for quicker and more successful completion of a project, and reduces the chances for devastating misunderstandings between the government and a vendor after the contract has been awarded. Rushing through the definition of contract requirements is not a good way to show urgency about a program.

When contracting folks raise objections about a procurement package that was developed without their cooperation, sometimes they are merely being bureaucratic, wallowing in Federal Acquisition Regulation provisions or making a power play. But more often than not, they are raising objections because the requirements are too minimalist, confusing or restrictive. Although few contracting officers have the technical knowledge needed to write requirements, many are good at asking questions and having a feel for when a requirements document is well done.

In many cases, the program office throws a procurement document over the fence to the contracting team, which then makes comments and sends it back to the program office for rework. This is a lose-lose proposition, both wasting time and lowering quality.

It wastes time because work gets done more quickly when people work on a document in a group, rather than one party working on the document in isolation and then launching it on a back-and-forth journey with the other party. Sequential processing wastes huge amounts of time with documents just sitting in — real or virtual — inboxes. Studies show that when you have a document that needs several sequential referrals, 90 percent of the time it takes to process the document is inbox time.

The back-and-forth process reduces quality because program staff members tend to get psychologically committed to a document they have developed on their own, which makes them less open to input. Meanwhile, a group effort can take advantage of the ideas and expertise of the contracting folks, which makes for a better document.

So program folks: involve your contracting folks early, in a team effort. Don’t do it just because it will make them feel better and more part of the mission — which it will, and those are good things — but also because it will produce a better procurement and thus better program outcomes.