FEDERAL SECTOR REPORT

WRITING STATEMENTS OF WORK

For the past month, I have switched roles. Instead of writing proposals to the government, I am writing technical Statements of Work that the government will issue to contractors for competitive bids. The work is onsite in Washington, DC at one of the most highly visible organizations in the Executive Branch. The project, which will continue for several more months, provides a perspective that may be useful to my newsletter readers who are working hard to submit winning proposals to the government.

Requests For Proposals (RFPs) are seldom perfect, and there are good reasons why. First, the time available for the government's drafting and reviewing of the document may be quite limited; the contract must be awarded on schedule for a variety of reasons, including the Y2K deadline with which I'm working. Second, most of the government's technical managers have ongoing duties; and preparing the specification for a contract is just one more extra duty. Third, the RFP must be approved by a wide range of government reviewers--ranging from attorneys and competition advocates to technical experts and the people who need the contract's services and/or products.

What do constraints mean to prospective proposal developers? Begin by assuming that the RFP was not etched by the finger of God on Mount Sinai. You will need to do some background research, know the potential customer, and make inferences. The RFP is often like a "connect-the-dots" picture--where you take the RFP information, make knowledge-based inferences, and connect the pieces into a workable vision of a solution. This ability is what separates the stars from bidders who merely agree to comply with the RFP.

Are you a specification kisser or a solution provider?

Sometimes the government Statement of Work will intentionally identify a problem or technical requirement without defining a solution. This may mean that there are alternative solutions; and the government wants the prospective contractor to weigh the tradeoffs and recommend the best solution. In this case, the proposal will need to identify the alternatives, present the evidence, and justify the recommended technical solution.

A related issue is that agencies are holding contractors accountable for the effectiveness of the solution: If the government defines the solution, then a contractor could contend that the Statement of Work (SOW) was defective and caused the lack of success. If the SOW requires the contractor to propose and implement the solution, then the contractor is fully accountable for achieving the performance goals stated in the contract.

Given the complexities of today's technologies and performance requirements, Government agencies are likely to acknowledge that they do not have all the answers ... and need outside expertise. Your proposal will need to demonstrate, concretely, that you have access to the authoritative expertise to solve problems and achieve results. This is more than merely stating that your engineers (or others) have 10 years of experience. More to the point:

• What credentials and certifications do they have?
• How have customers recognized their achievements?
• How productive and effective are they?
• What contributions have they made to their profession and industry?
• Can they function within an ISO 9000-type environment?
• What training or education have they had to keep them up-to-date with cutting-edge knowledge?

Unless you are simply running a temporary personnel contract--supplying warm bodies that meet the requirements of position descriptions, your proposal needs to demonstrate technical and professional leadership. This should extend to "past performance" histories, personnel qualifications, company capabilities, and access to leading-edge knowledge.

Can a small company play this game? Yes! Recently, I have reviewed the credentials of several outstanding 8(a) companies. Senior technical managers were active in presenting papers at professional meetings and participating in committees of standards-developing bodies (such as IEEE). They also had networks of formal relationships with manufacturers of hardware and software, large contractors who were mentors, and university faculty.

Of course this approach can be applied to almost any business area--not just information technology.

Ten or 20 years ago, an information technology contract would primarily need to satisfy the needs of the Information Systems organization or of a department within the agency. Today, however, technology resources have become so critical to the agency's mission that a Statement of Work must conform to enterprise policies. That is, your imaging contract for the agency library, your software for decision support, or your engineering workstation project must conform to agency-wide (enterprise) policies and procedures.

In my current role of drafting SOWs, I spend a serious portion of my time making sure that the documents conform to the agency's System Development Life Cycle (SDLC) Manual, the strategic plans, and the management strategies of the government executives who direct my work.

Most government policy and procedures documents are publicly available. Proposal developers need to take time to familiarize themselves with these documents ... so that their proposed solutions and operational procedures are compatible with the agency's enterprise policies.

A Statement of Work--and the overall Request for Proposal--has many stakeholders within the government. This became painfully evident when I developed an elegant set of specifications which provided enormous flexibility during the design, development, and testing phases for a computer system. The technical managers loved it; but the contracting officer shot me down: It was too complicated for pricing the options of outlying tasks, and the contracting officer thought that the SOW might lead to defective pricing by bidders ... or an incomplete cost evaluation by the government. So now I'm taking two days to restructure the SOW into three parts: a basic design and development phase with two options--with the government deciding whether to award Option A or Option B after completion of the basic phase.

In the setting where I'm preparing SOWs, there are multiple stakeholders: the people who will use the system, the people who rely on reports or data from the system, the computer system managers, the contracting officer, the lawyer who reviews the draft SOW, the IT policy makers, and other systems that interface with the SOW's system.

The Statement of Work is a consensus document that must satisfy many stakeholders. Your proposal must also satisfy many, if not all, of these stakeholders.

The printer finally delivered! During 1998, I was the principal writer of a book, Children of 2010, which explores the challenges confronting children and democracy at a time of profound demographic change within our society. The program was funded by the W.K. Kellogg Foundation, and the book was published by the National Association for the Education of Young Children.

CONSULTING SERVICES

We provide enterprise-level management consulting services for federal agencies and the contractors who support them. Our areas of specialization are Capital Planning and Investment Control, Enterprise Architecture, strategic planning, performance evaluation, and acquisition support including work statements. Our consulting specialty includes experience in many related areas such as CIO program support, earned value management, risk management, the C&A process for security, and customer satisfaction surveys.

NEWSLETTER ARCHIVE