13 ideas for building better RFPs

The truism that you get what you ask for is painfully evident in the world of federal procurement.

So many programs have gone wrong because contractors have done their best to deliver exactly what their customers said they wanted. In some cases, it’s because the customers' stated requirements are out of whack with what they really wanted. In other cases, the requirements turn into a moving target, which inevitably takes a toll on costs and schedules.

There are endless variations on this theme of mismanaged requirements, and none of them ever ends happily.

Consultant Ray Kane, who has been around the federal IT market for more than 40 years, has seen more unhappy stories than he cares to remember, but he said he still believes the situation is fixable.

The task, as Kane sees it, is to rethink how customers define their requirements. Indeed, they should stop thinking in terms of requirements at all.

As is often the case, one good idea leads to another. After posting Kane’s article online, we asked other procurement experts to join the conversation, either by responding directly to Kane’s idea or by offering their own suggestions for improving how agencies define requirements in their requests for proposals.

Here is our roster of experts.

• Ray Kane, IT business development consultant.
• Tom Love, CEO of ShouldersCorp, an IT consulting firm.
• Jaime Gracia, president and CEO of Seville Government Consulting.
• Dennis McDonald, an IT consultant.
• Peter Tuttle, CPCM, senior procurement policy analyst at Distributed Solutions.
• Sterling Whitehead, a contract specialist at the Navy and a blogger at www.allthingssterling.posterous.com.
• Mary Davie, assistant commissioner of the General Services Administration's Office of Assisted Acquisition Services

NEXT: Ray Kane.

Stop Talking About Requirements

By Ray Kane

Requirements are the Achilles' heel of procurement.

Ask users, managers and regulators for a program’s requirements, and you will get a vague description of products and services that are currently available. They inevitably “require” what they already know could work today. And that’s a problem because by the time the request for proposals is released, the proposed solution might be overtaken by better and more affordable options.

What a program requires is a competitive procurement that complies with regulations and delivers the desired results. The challenge is determining what a program really needs. How can we define those needs in such a way that bidders can propose solutions that take advantage of what’s available today but also retain the ability to meet changing and future needs?

One answer is to ask the “What are your requirements?” question in a few different ways. Tom Love, CEO of ShouldersCorp, offers hope in this regard. He suggests we bench the term “requirements” and use other terms that will unearth real needs. In other words, pose the question to elicit more thoughtful and thorough responses.

Love has put together a list of 18 terms or concepts that can help deepen a discussion and bring real needs to the surface. For example, one idea is develop story cards that show how the solution might be used. Love also encourages people to incorporate refreshment plans for updating technology and decommissioning plans for bringing systems to a close.

This approach can help us break our reliance on known and preferred solutions and focus instead on the actual needs of users — to transform from solution understanders to user-oriented requirements understanders, as Jim Beveridge put it in his sales and marketing seminars in the 1970s.

It might also help us finally resolve what renowned software engineer Barry Boehm calls the IKIWISI problem — “I’ll Know It When I See It,” a common problem that makes it difficult to define needs.

As the needs are identified, we might prioritize them by creating three categories: needs, wants and desires.

For example, we need a payroll system. We want to include the ability to issue W-2 statements in the required period. We desire to deliver it all on the first official release day to impress our employees with our support services. Discussing perceived needs might unearth some interesting possible solutions and bring to light the readiness to accept new or revised solutions.

A lot of this comes down to semantics, but in this case, semantics matter. The ultimate solution might very well come out better if we pose the question in a different way.

NEXT: Tom Love.

Software Requirements? Keep Your Options Open.

By Tom Love

On a recent interagency software project, I noticed that team members kept talking about requirements. Asked to be more specific, they offered 14 different meanings of the term. I realized that a complete set of requirements requires all 14 — a clear impossibility!

I also became intrigued by the verbs preceding the word “requirements.” Examples included gather, harvest, collect, elicit, capture and develop.

What an interesting set of images this evoked. I imagined a nice young lady with a basket walking through the user community “gathering requirements” or a tractor driving along “harvesting requirements” or an aging hippy with a pony tail “capturing requirements” with a butterfly net.

It doesn’t work that way. We are deluding ourselves. We need to rethink one of the most fundamental aspects of the way we work. And our rethinking has to start with the acquisition process.

Large projects routinely fail because there is no such thing as a complete set of requirements for a software product or project, nor are these requirements ever fixed. Actually, requirements only become fixed when they are expressed in code, even if it is really hard to understand and change.

The solution is to break large projects into short-duration development projects with the test cases for each two-week development sprint recorded in advance on an index card — also known as a story card. Even then, it takes five to seven development sprints for a newly formed team to accurately estimate what it can build in two weeks.

If the agile team can’t consistently deliver on its two-week sprints, its contracts should be canceled. It’s actually a low-risk way to do projects and has been shown to scale to projects involving 175 team members and millions of lines of code.

One such project replaced 11 million lines of existing code with 500,000 lines of maintainable, extensible code — all developed in two-week development sprints with continuous user involvement. That agile re-engineering project was delivered on time with excellent quality.

NEXT: Jaime Gracia.

Don’t Handcuff Yourself With Specifications

By Jaime Gracia

There's no question that the requirements process is an Achilles’ heel of government procurement. But what is truly astonishing is that little attention is being paid to this fundamental problem.

The Office of Management and Budget’s guidance in the past 16 months has focused on various areas of contract management reform and featured a renewed stress on contracting openness and transparency — certainly important issues that need improvement to boost acquisition performance. However, poorly defined requirements often derail an acquisition and set up a program for failure from the beginning.

It is a simple fact that government can't keep up with the rapid change and advancements of modern technologies. Therefore, a paradigm shift is desperately needed to enable the government to focus on best-value procurement and buy what is truly in its best interest. The key is innovation.

Innovation, along with competition, is what drives industry to find ways to offer the best solutions at the best prices. So why does the government not allow itself the opportunity to capitalize on its buying power and take advantage of innovation?

The fear of change, combined with a risk-averse culture, has created a procurement process for technology that is outdated and obsolete. Instead of focusing on needs, the government focuses on buying specificity by the dreaded “shall” statement. Specifications are larded into a statement of work to the point that best value is not possible. Instead, contracts go to the lowest bidder and are accompanied by ubiquitous modifications to create failing programs that are over budget and behind schedule.

The performance-based approach to technology is the path to improvement when buying technology. Instead of concentrating on specifications, the government must focus on needs and outcomes. Programs should have business cases that prioritize needs that are aligned with the agency’s mission and identify the program’s objectives and ultimate outcomes. It's those outcomes that the government is after. Therefore, continuing to tell industry “how” is continuing a cycle of failure.

Focusing on outcomes and allowing industry to propose innovative solutions to solve the government’s problems is the path to success. Government simply does not have the technological acumen to know what is in its best interest. Instead, it must focus on what it needs to perform its mission, allow industry to present the best value and then manage for results.

NEXT: Dennis McDonald.

Don’t Underestimate the Importance of Process

By Dennis D. McDonald

I know it's attractive to focus on outcome and performance rather than on tool or product requirements. The theory is that if you make vendors focus on ways to accomplish a goal rather than how to accomplish that goal, you will get a better and more effective solution. The problem is that solutions are rarely developed independent of existing practices.

A good example is the Interior Department’s solicitation for cloud computing services. It specified Microsoft software, triggering a lawsuit by Google. At one level, the requirement makes sense if it fits with Interior’s operating environment. However, that requirement clearly prevents the proposal of a competing solution.

We'll always have those types of problems because of the need to balance innovation with efficiency. Arriving at such a balance clearly goes beyond how requirements are defined to include not only RFP outcome requirements but also RFP process requirements.

Of course, outcome requirements refer to the target of the procurement action: acquisition of products or services that generate some benefit for a user community.

Process requirements, on the other hand, refer to the way the RFP process is supposed to be conducted, as governed by rules such as the Federal Acquisition Regulation and the Defense Federal Acquisition Regulation Supplement.

Experienced managers in government and industry know how to keep track of the two. Those who are less experienced can get confused by process requirements that seem to have little to do with what the government is trying to procure.

It's natural for any bureaucracy to formalize and standardize how processes are performed. Why reinvent the wheel every time something has to be purchased? The problem is that nothing stays static for long. Even the process for buying standardized or generic products or services is likely to change.

Think about how people communicate during the course of a procurement. Many of the rules and regulations surrounding government practices were first developed and codified when communications relied more heavily on the movement of paper from Point A to Point B.

But these days, people communicate formally and informally in ways that stretch traditional definitions of competition, openness and secrecy. For example, procurement-related information can be published online instantly — or perhaps not published at all but instead communicated via real-time conferencing systems. Those issues must be taken into account when developing process requirements for RFPs.

People often mistakenly assume that RFP outcome requirements are static as well. But as a project manager, I know that there is always a difference between what you plan for and what actually happens. Requirements and goals can change dramatically between the start of a procurement and the final award. The RFP must include a process for accommodating such changes or there will be problems down the road.

NEXT: Peter Tuttle.

Got the Content? Now Work on the Clarity.

By Peter G. Tuttle

I think most of us can agree that it is difficult to describe requirements in writing, whether they are high level and brief, detailed and granular, or outcome-based.

The effective communication of requirements or needs has always been somewhat of a challenge despite technological advances. Humans must think through needs and then communicate them in a manner that can be understood by as many people as possible — no matter how easy technology makes it to transmit and receive the information.

Ray’s suggestion of asking questions about requirements in different ways is a good approach when those questions are specific enough to elicit useful responses or generate an additional dialogue that improves understanding. Tom Love’s list of suggested terms is another method that can help flesh out areas that have some impact on the requirements or must otherwise be considered because of regulations, for example.

Naturally, all that is easier said than done because the process for generating requirements can be extremely time-consuming, complex and frustrating and involve a multitude of stakeholders. Because the process today is generally bureaucratic and burdensome — for at least the past 30 years — agency leaders should focus on ways to improve communications, elicit meaningful dialogue, and create the potential for greater understanding and collaboration throughout the requirements process instead of being tempted to dissect and neuter the process.

The wiki is a promising tool for enhancing communications and, perhaps, collectively thinking through the building and refining of a requirement. Although its use should be subject to the usual security and legal constraints, a wiki can serve as an excellent platform for collaboration in the requirements-generation process. At a minimum, a wiki can be used to gather expertise and input from multiple stakeholders and facilitate the process of defining and writing the requirements so they can then be released as part of the formal acquisition process.

NEXT: Sterling Whitehead.

Do Your Homework (But Let RSS Help)

By Sterling Whitehead

A few years ago, I was an intern for Sen. John Warner (R-Va.), now retired. One thing I remember about him is that he was very well informed. He would spend three or so hours every morning reading the Washington Post and other newspapers. He was well regarded as a senator, and I believe much of that had to do with his awareness of the world, in addition to his legendary chivalry.

Unfortunately, most of us don’t have three hours to read the paper on a given day. The key, then, is to make better use of our time, and one way to do that is to use Web-based Really Simple Syndication feeds.

Essentially, RSS feeds let you subscribe to multiple sites’ updates, whether they are news, trade magazines, press releases, comments, video or audio. Those updates feed into a single page, and you can scan them or analyze them at your leisure. The only requirement is that a site must allow RSS feeds, and many do. It’s simple to use — you just search the Web feed for keywords as you would a regular search engine.

Strategic market research — which is essential to requirements definition — is ongoing, and it is about keeping an eye on the market. Web feeds are perfectly suited for that purpose. You can find feeds that let you keep tabs on specific companies, such as Lockheed Martin or Northrop Grumman, or different technology areas. You do not have to visit multiple sites. You do not have to search. The information comes to you.

I use Google Reader. It’s popular, pleasing to the eye and intuitive. I started using it three years ago, and it has changed my life. I know more about the markets for defense, mobile phones, social media, and finance and innovative happenings in the contracting world, which helps me in may job as a contract specialist at the Navy. I get 100 to 200 stories a day. I scan most and read others, but I am hyper aware of what’s going on in the IT world.

The best thing is that the Web feed is now a habit. If I check my e-mail messages, I also check my feed. It’s part of my morning routine, and I wouldn’t miss it for the world.

So take my advice: Set up a Web feed and make a habit of using it. I promise you will be happy you did.

NEXT: Mary Davie.

7 More Ideas for Better Buys

GSA’s Mary Davie has been actively involved in identifying ways to improve the federal procurement process through the Better Buy Project, a joint effort by GSA, the National Academy of Public Administration and the American Council for Technology/Industry Advisory Council.

She passed along the following ideas that have surfaced during those discussions.

• Build repositories to share market research across government — and, for that matter, to share statements of works, statements of objectives and performance-based statements of work. An example is the Defense Department’s DODTechipedia, which was designed to increase communication and collaboration among DOD scientists, engineers, program managers and warfighters. DOD also created a public crowdsourcing system named DefenseSolutions.gov. Market research should be a shared responsibility both governmentwide and in collaboration with industry.
• Collaboratively build requirements in the open on a wiki and ask for input from any interested parties. GSA tested that approach and had success through the Better Buy wiki.
• Use integrated product teams to define requirements and frame solicitations.
• Create agency advisory boards composed of the eventual users of the procured items or services.
• Segment acquisitions into smaller pieces for faster procurement and increased competition. Keep the pieces small enough that vendors can effectively compete for them, thereby reducing costs for the government through competition and creating small-business jobs.
• Require open standards, open-development environments and open-source code so individual pieces of the project can be tracked as they are developed. That will also ensure that they will fit together.
• Consider crowdsourcing ways to break projects into smaller pieces that you can start immediately. But keep in mind that using social media to gather requirements can make a project’s scope become impossibly large.