The LCSP and the RFP

LCSP-RFP

LCSP
Information the Government Could Convey
Potential Proposal Information

The LCSP can be an effective communications tool in the source selection process.  As with all effective communications; it must be a two-way dialogue.  In this case the Request for Proposal (RFP) and the offeror's corresponding proposal form the basis for that dialogue.   While the dialogue will vary based on the life-cycle phase, there are key aspects that will be common to each phase.  The difference is in the level of detail and the options available for consideration.

A word of caution.  While there are many ways the LCSP can be used to formulate an RFP, the LCSP must not be included in the RFP as a blank template for the offeror to merely complete and propose back to the government along with its cost proposal.  The LCSP is the Program Manager's (PM) plan, not the offeror's plan.  The offeror can provide valuable input to sections of the LCSP but at the end of the day, the LCSP is the PM's responsibility to frame and execute the program's Product Support Strategy. 

The converse is also true.  While it would not be prudent to provide the offerors a complete finalized LCSP in the RFP.  The offeror's proposal is an excellent opportunity to gain insight into innovative ways to implement the requirements based on unique feature of their design or unique business processes. 

Providing the government’s cost estimate or budget in the RFP would not be appropriate, unless it is important to relay to industry what budgetary constraints or affordability targets a program may have for key elements.  Such a disclosure can help streamline the source selection process by serving as a decision point for an offeror to determine whether or not it is in a company’s interest to submit a proposal.  

Information the Government Could Convey:

Using the LCSP to inform the RFP can be a very effective strategy in controlling costs and reducing risks.  Providing critical information to the bidders early in a program's life cycle will help focus the offeror's efforts and prevent them from having to guess the government's intent.  (This is a critical affordability issue because contractors traditionally address uncertainty, with its associated risks, by increasing their costs.)  On the other hand by specifying too much the government can unintentionally limit a offeror's ability to provide innovative approaches.  A balance is required between not providing enough information to get a sound proposal and providing too much information which limits contractor creativity in addressing the warfighter needs.

The following are examples of the types of LCSP related information that could prove to be useful in an RFP to help frame the offeror's proposals and reduce the amount of uncertainty:

• Baseline Product Support Strategy.  Early in a program care must be taken to frame the strategy at the right level (e.g. weapon system, critical subsystem impacted by the operational or sustainment environment, etc.) to provide the baseline for subsequent trades/alternatives including those that might be offered in the contractor's proposal.  In addition, using the strategy of establishing a baseline and tracking the subsequent trades across the life cycle should be an integral part of a program's "Should Cost" efforts.
• Sustainment Performance Requirements.  Again care must be taken framing the high level/overarching values, and their definitions, to allow innovative approaches without pre-determining the technical solutions.  The focus here should be on well defined requirements that are driven by the Key Performance Parameter/Key System Attribute (KPP/KSAs) and the projected operational and sustainment environments.
• Envisioned Government Organization.  While this may be generally known, conveying the Program Office's actual structure in detail can help convey to an offeror the areas in which the government will focus its attention with emphasis on the upcoming phase.
• Regulatory/Statutory Requirements Including Core.  The sooner this is known by all parties the fewer "should have known" surprises the team will have.  This in turn should help to reduce non-value added efforts.
• Broad Notional Schedule.  The schedule is a cost driver and working out the expectations early can avoid surprises down the road.

This is not an all inclusive list.  Each program needs to determine the right balance of information conveyed in the RFP to ensure we are reducing risks while not constraining an affordable solution that will meet the warfighter needs.  Consequently there is LCSP information that should not be included in the RFP; specifically the program's funding levels.

Potential Proposal Information:

The offeror's proposal must respond to the RFP requirements.  There are too many ways on how this can be done to provide an all inclusive discussion here since it is program and phase specific. However, below are some examples of types of information that could be asked for in a proposal.

•  "Design to" Requirements Including Verification Methods.  This typically includes the "decomposed" requirements based on a proposed design to achieve the KPP/KSA's and other sustainment metrics spelled out in the RFP.  In addition, it can be expanded to have the offeror identify the inherent design features within the proposed technical solution which will allow or drive an affordable product support strategy.
• Product Support Strategy.  Generally speaking this would expand on the level of detail contained in the RFP.  The benefit here is that the expansion would help provide confidence that the offeror understands the sustainment strategy and what in the proposed approach will drive and/or support the eventual Product Support Strategy with its associated requirements.
• Supportability Analytical Approach.  This can provide confidence that the offeror understands and has the capability to define an affordable Product Support Strategy and implement the Product Support Package. The tools information combined with the schedule and cost proposal can provide the PSM with a good indication of the offeror's ability to effectively integrate the Product Support Elements.
• Management Approach.  In addition to the specific management approach and IPT structure with the "checks" and "balances", the offeror's proposal should include the staffing levels corresponding to the cost proposal.
• Schedules.  Expanding on the schedule provided in the RFP based on the knowledge gained from the aspects above will help to provide the PSM confidence that the schedule and costs can be met using the offerors proposed approach.
• Contractor Costs in the Cost Proposal.  Having an offeror include the costs to accomplish the RFP requirements/Statement-of-Work in its cost proposal using a government specified cost breakdown structure can be very helpful in developing realistic program cost estimates.

In assessing the offeror's ability the above discriminators cannot be looked at as stove pipes.  The relationship among them is critical in assessing the proposal.  Finally, anytime the proposal includes modifications to the specifics contained in the RFP, the offeror must include the specifics required in the RFP.  If any proposed alternatives are included in the response, a cost benefit analysis supporting the alternative approach should also be provided.