Making systems—3: Development
VIII   Specifications
Chapter 35   Proposals

35.1 Introduction

Some projects will involve writing and submitting a proposal before being able to move on to build a system. A project typically builds a proposal when they need to obtain resources or permission to proceed with development. This might be a customer deciding to buy an instance of the system, or it might be for getting resources from a funder.

A good proposal is one that both meets the customer or funder’s needs and that makes the case that this proposal is the best choice for them to make. These imply that the team must come to understand the needs, develop a concept that meets those needs, and show how it is better than the competition.

Assembling a proposal is like a system-building project in miniature. It has the same early phases—purpose and concept development—to gather stakeholder needs and develop and idea for what the system might be. Other work proceeds in parallel, such as understanding what the competition for this proposal might be. These are followed by writing the proposal itself. Section 35.3 presents a reference work flow for building the proposal.

Work flows for crafting a good proposal have been refined over several decades. There are standard practices for reviewing a proposal and for making go-no go decisions about it. There are also standard practices for how to interact with stakeholders after a proposal has been submitted but before the proposal has been accepted (or rejected).

Once a proposal has been accepted, the ordinary system-building work flow can proceed. Section 35.3.8 discusses how the proposal work flow can be inserted into the standard work flow.

35.2 What is a proposal?

A proposal is a document (or set of documents) that make the case to a stakeholder that they should choose this team and this project to build a system.

There are two general situations that call for building a proposal. The two situations lead to similar outcomes.

In the first situation, a potential customer wants to get a system. They may put together a formal solicitation, or they may express their needs informally. The team assembles an answer to them, explaining the system they could deliver along with the time and cost involved. The customer may ask multiple teams to provide such proposals. The customer will then decide, based on the proposal, whether to accept the proposal or not.

The second situation is where a proposal goes to a funder, not to someone who will acquire the system. The team has to make the case that the proposed project is a good use of those resources, and possibly that the project is better than alternatives. Each funder will have their own criteria for deciding whether to provide resources or not.

Proposals typically address four topics.

  1. What the system would be;
  2. How that system meets the customer’s or funder’s needs;
  3. How much resource is required; and
  4. Evidence that the team is capable of building the system, including within requested resources.

When a proposal is a legal document, providing a formal offer for the customer or funder to accept, it must include statements about who is making the offer, the duration for which it is valid, and certifications about the organization making the offer. Proposals to government organizations often require acceptance of acquisition regulations.

Finally, some proposals must follow a prescribed format. In the US, proposals in response to government solicitations must follow a provided outline, putting the information into defined volumes, chapters, and sections. Each part often has a maximum page count, paper size, font, and font size. The solicitation defines the media that must be used for the proposal—often multiple paper copies plus an electronic copy. Failure to adhere to these requirements can mean that the proposal is rejected.

35.3 Work flow for a project with a proposal

Developing a proposal is a project in itself, and proposal development should have a work flow. That work flow is similar to the work flow for system development, and if the proposal is successful the proposal work flow becomes part of the system development work flow.

undisplayed image

As with system development, a proposal development work flow begins with a purpose phase; in this case, the purpose includes both the purpose for the system to be built and the purpose the stakeholder has for asking for a proposal. Developing a concept of a solution comes next. The proposal development includes a competition phase for working out who might produce competing proposals and how to position this proposal against those competitors’ offerings. The team may choose to adjust its system concept in order to counter competitors‘ strengths. Depending on the nature of the system, concept development may involve some prototyping and partial specification development in order to have confidence that the system being proposed is correct and feasible, and to estimate how much time, funding, or other resources will be needed.

Finally there is proposal development phase itself. This includes decision points for deciding whether the team should go ahead and invest effort in completing and submitting the proposal, a number of internal reviews, and a final review for approval to submit the proposal. If so, the last step is to submit the proposal to the stakeholder.

undisplayed image

The stakeholder will evaluate the proposals they receive. They may ask for clarifications, which result in modified versions of the proposal. If the stakeholder decides to accept the proposal, then they will negotiate various terms and conditions in order to complete a contract. In some cases the “contract” will be an informal agreement, such as when a team is making a proposal within their own organization. In other cases the contract will be a complex legal document that requires significant legal review before both sides can agree to it. Once the contract is approved, then the team can prepare for regular system development, revise the work they have already done, and proceed on to a normal system development workflow.

35.3.1 Proposal development preparation

Proposal development is typically shorter and more intense than regular system development. Where a system might take months to years to build, proposals often must be finished in a few weeks (or less).

Preparation for proposal work needs to be done quickly. This includes finding people, facility space, information tools, and reviewers.

There are several kinds of people who are needed for proposal development who are not typically part of regular system development. Preparing for the proposal involves filling these roles on the team. The roles include writers, editors, costing experts, graphics designers, competition experts, and proposal development managers.

During proposal development, a small team works closely together. They need the facility and tools that let them collaborate smoothly. Many proposal teams work in physical proximity; if so, in my experience a dedicated room for the work is helpful. Most proposals also use online tools to share the artifacts that the team develops.

The work often involves information that must be kept confidential. This includes information from the customer on what they want, and also information about the organization that is putting the proposal together and information from potential subcontractors. When multiple organizations are competing for the project, each organization will want to keep its concept private to avoid possible competitors taking advantage of the information. For some systems, there may be legal requirements to protect the information used to develop the proposal as well as the proposal itself.

Confidentiality means that the physical space and information systems used must be able to protect the information. All the large proposal development efforts I have worked on have set up protected rooms with dedicated computer systems for managing the information.

Proposals benefit from several rigorous reviews. People who can review parts of the proposal, and who are independent of the team developing the proposal, need to be identified at the start of the proposal development process.

35.3.2 Purpose phase

As with any project, the first step is to define what the purpose of the system is, and thus what needs the proposal must satisfy.

For a proposal, it is worth separating the purpose into two parts: the purpose or needs that the system being proposed will fill, and what the stakeholder needs in the proposal.

Investigating the system purpose for a proposal is essentially the same as for any other system-building project. The investigation reveals who has a stake in the system, identifying what each one of them needs, and organizing this information in a way that later work can reference.

In most cases, a proposal is in response to a request for proposals (RFP), as I discussed in Chapter 33. An RFP should provide much of the purpose information, but does not always—sometimes inadvertently, sometimes deliberately. In those cases the proposal team tries to fill in the missing information by talking to the stakeholder or to proxies for them.

The stakeholder also has needs for what they need in the proposal, in addition to system needs. The stakeholder may have rules about how they interact with potential proposers; they may require specific information in the proposal, or for it to have a specific format; they may have rules about how they will evaluate competing proposals.

Stakeholders often have expectations of the time and cost that would be required to deliver the proposed system. They likely have a budget for how much they can afford and how long they can wait for delivery. They may not make this information available in order to incentivize teams to make the best offer they can, in which case the team will have to use estimates.

When deciding to respond to an RFP, the team must learn what acquisition rules the (potential) stakeholder is using in order to determine what restrictions to follow when communicating with the client. The team must also learn how the stakeholder makes decisions, including who makes the decisions, who influences the decisions, and how the decision will be made. When responding to a commercial RFP, this can be easy: there is a contact who sends out the RFP and who can answer questions as needed, there is someone they work for who reviews and decides whether to accept a proposal or not, and the decision is based on what the decision-maker thinks meets their needs at the best price. For a US Government agency RFP, on the other hand, the decision process is defined by the Federal Acquisition Regulation and by the agency’s supplemental rules. There are formal processes for submitting questions; there is typically a defined scoring and weighting system that a formal review team must use to rate each proposal.

The proposal team uses information about how the stakeholder makes decisions to decide what kinds of information to focus on in the proposal.

35.3.3 Competition phase

Many proposals will be in competition with proposals from other teams. The effort spent on a proposal only pays off if the team wins the competition. The team increases its chances of a successful proposal if they understand their competition, and use that to emphasize how their proposed system will be better.

The first step in understanding competition is to find out who the other competitors are likely to be. There are multiple sources of such information: discussions around the industry or knowledge of what organizations are in related lines of work. In some industries, there are consultants who track such information. Some formal procurements will hold meetings for potential proposers; attending those meetings can give hints about who might propose.

For complex systems, groups of organizations may make joint proposals, so knowing who might partner with whom is helpful. Sometimes an organization will proactively team with other organizations to eliminate the chance that a competitor would also try to team with that other organization.

The next step is to estimate what each potential competitor might offer. This involves understanding what kind of systems each competitor has built before and where they have capabilities they could draw on. Paying attention to rumors of what kinds of work the competitors want to do can also reveal intentions.

Information about competitors is used two ways. First, it is used to guide the team’s system concept and their proposal. If the team knows strengths that a competitor has, they can find ways to neutralize that advantage or come up with an offsetting strength. If the team knows about a competitor’s weaknesses, they can design the system concept to make the competitor’s weaknesses obvious. Second, the team uses competition information to determine whether they have a reasonable chance of winning the competition. If there are competitors with overwhelming advantages, then the team can rationally choose not to pursue investing in a proposal.

The team records information about competition in a structured document artifact. The artifact should list who each of the competitors are, how the team learned about them, the expected system concepts they might offer, and its strengths and weaknesses.

35.3.4 Concept phase

The concept development phase for a proposal is much like a normal system concept development activity (Chapter 34), with a few differences.

The system concept is shaped not just by the stakeholder’s needs, but also by understanding what competitors may offer, as discussed in the previous section. As the team considers alternative approaches for the system, they include how well an approach will play against a competitor’s strengths and weaknesses.

35.3.5 Cost and time estimation

In most cases, a proposal must include the cost, time, and personnel required to build and deliver the system. In ordinary system building projects, these estimates are expected to be quite rough if they exist at all because precise estimates require developing a lot more detail than the concept has. A team often must develop specifications (Chapter 36) and designs (Chapter 40) through the first few levels of the breakdown structure (Chapter 41) in order to have enough information to cost their proposal accurately enough.

Sometimes the estimates are easy—for example, when a system uses mostly off-the-shelf components and the team has built similar systems before so that the effort required to integrate and verify them.

Estimation is hard when there is significant uncertainty in the system. In a construction project, if the nature of soils or rock underneath a proposed structure is not well known, then surprises may be discovered during excavation. When a system requires innovation rather than using only well-understood components, some component might turn out to be more difficult than expected. (See Chapter 65 for more discussion about uncertainty.)

Many proposals must provide evidence that the estimates are accurate. This typically requires showing not just the final cost and time estimates, but a cost breakdown by component and phase of work along with a high-level schedule. A basis of estimate shows how each cost or time element was determined. The basis usually consists of a combination of a “size” for the element and cost or time based on the size. Both the size and the cost are guesses; the more historical information available to generate either one is helpful. See McConnell on estimating [McConnell09] for much more information about how to derive these estimates. The estimate presented in a proposal often must include documentation of the processes and techniques that the team used to arrive at the estimate, not just the numbers.

Building and maintaining the estimates is a tedious process. It includes a lot of details. Almost every proposal estimation work I have done has ended up with questions about whether some specific task is accounted for in one line item or another. Keeping the information well organized is vital to building an estimate that does not double-count something or miss something else.

The estimates are best maintained as an artifact separate from other things. A simple estimate can be developed using a spreadsheet, but dedicated tools are necessary to keep the information organized for systems of even moderate complexity. Some stakeholders require cost estimates to be presented in specific formats, and dedicated tools help ensure that the output reports are compliant.

The estimates are used in three different ways. First, they are likely to be incorporated into the proposal that goes to the stakeholder, and they will base their selection in part on this information. Second, the proposal team will use these estimates to check whether the team is likely able to do the project. If the project will require more people than the team can get, then the project is infeasible for this team and they should decide not to pursue a proposal. Finally, the cost and time estimates in the proposal will evolve into the plan that team will use while developing the system (Part XIV).

35.3.6 Proposal development

Finally we arrive at the proposal itself.

There are three key objectives for the proposal:

Achieving these objectives requires careful management and coordination. The team will usually work in parallel across multiple parts; without proper coordination, they parts will not end up consistent.

The general approach for the proposal is similar to specifying and designing a system: first work out the proposal’s structure, outline what each part might say, then iteratively turn those into a full draft.

The proposal benefits from regular reviews by independent reviewers who check the work. There is a common framework for these reviews, the so-called “color reviews”, that people have developed over time. While these reviews are somewhat controversial, my experience is that the basic idea is sound and I have incorporated the ideas into the work flow below without following the color review model dogmatically.

The proposal development flow is as follows.

undisplayed image

Define strategy and general concept. What is the general idea of the system that the team will propose? What strategy has gone into making this concept attractive to the stakeholder?

Review concept and make a go/no go decision. The reviewers check whether the concept is consistent and that it meets stakeholder needs. The team, or its management, makes a decision whether to proceed or not. Does the team have a viable concept? Does the team have the ability and resources needed both to complete the proposal and to build the system?

This is sometimes called a blue team review.

Outline proposal structure. The next step is to define the overall structure that the proposal must follow. If the stakeholder requires a particular format, they will have made that clear in their solicitation.

I have found that most proposals contain similar information, though sometimes ordered differently:

  1. Cover material, indicating who is submitting the proposal, who can be contacted about it, and certifying that the offering is valid.
  2. Technical content, defining the system being proposed.
  3. Management content, defining how the development project will be managed and who the key people are who will work on the project.
  4. Cost content, defining how much time and funding will be required.
  5. Past performance content, providing evidence that the team will be able to do the work.

Each of these parts is likely to have a defined structure, with page count restrictions for some parts. There may be instructions on the size of pages, margins, typeface, and how the information is to be organized into files or volumes.

The output of this step is an outline identifying the order of the content and the amount of space available for each part.

Define contents for each part. This step defines the content to be placed in each part. This is sometimes called a storyboard for the parts. Appendix C has a template for these storyboards.

The purpose of this step is to prompt the ideas that will make up the proposal content without trying to create the real text or graphics. It should not generate a polished outline; rather, it should only go as far as notes about each part.

In some proposal projects, I have created a form that people fill in for each part. The proposal includes items like:

  • Requirements that the part must meet;
  • Space allocated for this part;
  • The approach to meeting those requirements;
  • General content for that part;
  • Any major explanatory diagrams that will help;
  • Features to highlight in this part;
  • Competitor strengths and weaknesses that this part addresses (and how); and
  • Risks associated with this part.

Not all this information is relevant for each part of the proposal, but a form like this prompts people to consider aspects that they might forget.

This step often includes a brainstorming exercise. On two occasions I have printed blank forms for each document part, then hung them on walls and the core proposal team has gone around and written ideas on each one. Then the forms get divided amongst the team members who fill in missing information.

The output of this step is the storyboard content for each proposal part. By the end of the step, each part should be assigned to one person who is responsible for its content.

Storyboard review. Having generated storyboards for each part on its own, the next step is to check how the storyboards against:

  • The stakeholder’s requirements for format and content;
  • The requirements for each part; and
  • How the part addresses the competition.

This is also the time to review how the parts fit together. When one looks at the storyboards in order, is there an understandable story? Do all the parts together meet the stakeholder’s needs and address competition? Are there any stakeholder needs that haven’t been addressed?

This is not usually a formal review by an independent set of reviewers. Instead, the proposal team does a longitudinal review of the storyboards.

This is sometimes called a pink team review.

Outline content for each part. Once the overall content of the proposal has been laid out, the next step is to generate outlines for each part, including rough text and sketches of key illustrations. This step builds on the storyboards, adding details.

The amount of space actually required for each part often becomes apparent during this step. It is more common for parts to go longer than the amount of space allocated. Sometimes one can trade space in one part for space in another, as long as the result does not exceed limits that the stakeholder has placed.

Different parts of this step occur at different rates. Some parts can be outlined quickly, when there are templates to fill in or the material is simple. Some of these parts can even be drafted before the system concept is worked out; for example, material about past performance does not depend on the details about the concept.

In many proposal efforts, the team will begin working with graphics designers on illustrations. A trained designer can help people with technical experience but not graphics experience find ways to communicate key information even before the real illustrations are drawn.

Review for overall flow and consistency. As enough parts get outlined, some team members can look again at the overall flow of the proposal content and check for inconsistencies. This step often reveals ways that some parts can be tweaked to improve a message or support each other. For example, material about one part of the project’s management plan can reinforce a part of the system concept by showing how the team will have special skills available that make them a good choice for building the system.

Review costing. At some point, usually in parallel with outlining content, the team will assemble its estimates for cost and time.

Before this material is added to the proposal, it must be reviewed. The most important review is for realism: can the system be delivered with reasonable certainty within the proposed costs? For any project dealing with a complex system the costs are necessarily estimates, potentially reflecting significant uncertainty. Nonetheless the stakeholder and the team’s organization will require that the project be financially feasible, and so an honest evaluation of the project’s estimated cost is vital.

The estimates also should be reviewed against any information about the stakeholder’s expectations or intelligence about the available budget. However, it is vital that evaluation against these numbers take a lower priority to ensuring realism. Low-bidding, that is, proposing an unrealistically low cost in order to win a competition, is sometimes illegal and virtually always unethical.

It is common during cost reviews to find that the initial estimates are higher than some party will be likely to accept. The appropriate response to this is to either determine that this team does not have a competitive offering, or to modify the system concept in ways that will reduce cost. (Reducing the estimate by reducing uncertainty margins is, quite simply, lying with numbers.)

Sometimes a team will press ahead to propose a system concept that will be higher than desired if they believe that they can make the case that a higher cost will be worth it for the stakeholder. In some cases they can make that case directly to the stakeholder; in others they must weave that justification into the proposal itself—for example, by showing a high cost-benefit ratio.

When the review shows that the offering is not cost-competitive, the team can decide not to continue to pursue the proposal. Making this decision may not be easy, but if the proposal will not be competitive, stopping the proposal frees up the team to pursue something else that will provide a return on the investment of their time and energy.

This is sometimes called a green team review.

Review for compliance. After most of the proposal parts have been outlined, an independent team reviews it for compliance with the stakeholder’s requirements. The result of this review is a list of the deficiencies that the reviewers find, and the points they find unclear in the proposal outline. The team responds by improving the proposal outline, and they may ask reviewers if they believe that the changes address their concerns.

This is part of what is sometimes called a red team review.

Write draft. The next step is to turn the outlines into a draft of the proposal. The outlines become prose, and diagram sketches become real figures.

During this step, it is important for the people responsible for different proposal parts track whether their material is fitting within the parts’ space allocations.

Draft-writing is often a collaboration among the more technical people who developed the outline content, graphics designers, and writers. The tools used to manage the draft artifacts should help them collaborate. I have found that having a shared library of illustrations and shared writing tools are a significant help.

Some summary material is not written until near the end of this step. For example, many proposals include a compliance matrix. The matrix lists each of the stakeholder’s major objectives or requirements and points to where in the proposal this requirement is addressed, so that the stakeholder has an easy way to check that the proposal meets their needs.

Polish material. Finally, the team takes the draft and polishes it into a near-final form. This includes:

  • Editing the material so that it is proper text;
  • Ensuring that language and illustration styles are consistent throughout the entire proposal; and
  • Checking that the format and space allocations match the stakeholder’s requirements.

Final content review. The final draft proposal gets another independent review. This review looks for three things:

  • Is the proposal consistent and correct?
  • Does the proposal meet the stakeholder’s requirements and expectations?
  • Does the proposal meet the team’s organization’s criteria for submission?

Meeting the organization’s criteria usually involves a review by legal personnel.

This final review usually results in some feedback that the proposal team addresses and incorporates into the draft. Once the reviewers agree that their concerns have been met, the work proceeds to the next step.

This is sometimes called a gold team review.

Approval. A proposal typically represents a legally-binding offering, and so it requires approval (and signature) from someone in the team’s organization with the legal authority to bind the organization.

The approval usually takes the form of a signed letter, or even just a signature on a stakeholder-specified form.

Production. At this point, the team assembles the packet to be submitted to the stakeholder. If the proposal is being submitted in hard copy, this means printing and binding the proposal. If the proposal is being submitted electronically, this means assembling a set of files to be sent to the stakeholder.

As the submission materials are produced, part of the team performs a “white glove check”, verifying that each page is printed correctly, each volume is bound correctly, or that each file has the correct name and contents. (The name comes from wearing white cotton gloves while handling paper copies in order to avoid staining any pages.)

Submission. The last step is to submit the proposal to the stakeholder.

Hard copies are often delivered either by the proposal team themselves or by a trusted courier. It is standard to obtain a receipt from the stakeholder to show that the proposal was delivered.

35.3.7 Clarification and negotiation

After the stakeholder has received the proposal, they evaluate it and compare it with others (when the solicitation is competitive).

The stakeholder may have questions about the proposal, in which case they will ask for clarifications. In some cases these questions can be answered directly, but in most cases the response to the clarification must result in an amended proposal.

The stakeholder may like the proposal but want some changes. They will communicate with the team, who can evaluate the requests and update the proposal.

In either of these cases, the result is an offering that is different from what was originally submitted. The team follows an abbreviated version of the steps in the previous section to create the new proposal. The updated proposal must get new approval and signature in order for the update to be legally binding.

In some situations, there may be legal limitations on how the stakeholder can communicate with the team to request clarifications or changes. This most common in government contracting.

After the stakeholder makes their decision to accept the proposal, there may be negotiation with the team to write the contract for developing the system. Stakeholders often have template contracts that include standard terms and conditions they expect. This is the opportunity for the team to ensure that they can accept those terms and negotiate changes.

This leads to finalizing and signing the contract. After that, both sides begin arranging funding and oversight.

35.3.8 Transitioning from proposal to development

The proposal development effort does the first phases of system development. The proposal requires working through the system purpose and concept, for example.

Once the project is approved and a contract is in place, the team:

undisplayed image

35.4 Artifacts summary

Proposal development involves the following artifacts: