Preparing a technical proposal

NOTE: This information is tailored for the establishment of proposals for R&D Contracts. It does not take into account specific requirements and constraints applicable to flight hardware proposals.

What is the purpose of the technical proposal and which elements should it typically contain?

The technical part of the proposal (the “technical proposal”) is essential to support the technical evaluation and addresses in particular the two following ITT criteria:

• Understanding of the requirements and objectives and discussion of problem areas
• Quality and suitability of proposed programme of work and adequacy of engineering approach

Bidders might sometimes be unclear between what should already be available with the proposal and what is to be done as part of the activity itself. The proposal should basically reflect the preliminary technical work and the first iteration performed by the Bidder on the basis of the SOW. It should not simply be a mere repetition of what is stated in the SOW but should reflect this technical elaboration. Preparing the technical proposal requires a thorough analysis of the objectives, requirements, possible solutions, foreseen problem areas and this leads to a proposed “best” baseline concept and to the detailed proposed programme of work to meet all objectives listed in the SOW.

The typical technical elements to be provided in the proposal are:

1. Regarding the understanding of the requirements and objectives and discussion of problem areas

• Understanding of the objectives (what is the product/methodology to be developed, to which maturity level should it be developed and tested, what are the final deliverables etc.)
• Current state of the art (what is the technical context, what are the existing solutions that could be used as a starting point, are there any similar developments / products in other fields etc.)
• Discussion of possible concepts and trade-off (what could be the possible solutions  - at least 2 to 3 - that could be elaborated during the activity on the basis of the Company/Consortium experience and the technical state of the art, what are the criteria that can be used to compare these solutions and how do they actually compare when performing a first trade-off)
• Critical assessment of requirements and possible limitations with corresponding justifications (analysing each requirement and confirming compliance, proposing limitations and even new requirements whenever appropriate, justifying in detail all non compliances or partial non compliances)
• Discussion of problem areas (what are the technical challenges that  are expected to be addressed during the development and what are the mitigation approaches established to address them)
   

2. Regarding the quality and suitability of proposed programme of work and adequacy of engineering approach

• Identification of the selected baseline (what is the “best” proposed solution from the ones explored)
• Detailed description of the selected baseline (what are in the detail the specification, work logic, work breakdown structure and work packages to develop this baseline)
• Compliance matrix with comments (what is for each requirement the declared status of compliance to be able to judge in a synthetic way how the proposed baseline address each of the SOW requirements)
• Elements to allow the assessment of the credibility of the proposed programme of work (is there for instance a back-up plan proposed in case the selected baseline is not retained during the activity, are risks and problem areas well tackled, are all constraints built-in in the overall programme of work e.g. a constraint for availability of a specific facility)

It should also be noted that the special conditions of tender or the cover letter might indicate some specific technical elements that need to be provided with the proposal. For instance, there could be a statement in the special conditions to tender on the need to provide in the proposal a detailed list of the facilities intended for testing. The bidder can derive this as “ESA requires this information because doing this type of testing is obviously not straightforward / standard work and they want this information with the proposal because of the impact on the activity”. The Bidder should always pay particular attention to such special conditions of tender, they are there for a reason.

Hints and things to avoid

A good technical part of a proposal:

• is consistent and balanced in all chapters
• addresses the technical discussion and the review of requirements and does not jump directly to a proposed baseline concept without explaining the “why this concept”
• is well structured and shows a logical development
• is easy to read and complete
• defines very clearly what ESA gets out of the activity
• is consistent with the Work Breakdown Structure (WBS) and Work Package (WP) descriptions
• has all WP’s well identified in the planning and costing
• reflects the technical knowledge of the proposed team and key personnel
• is catching the eye, within limited number of pages

It is preferable to avoid:

• pure repetition of the SOW
• lengthy philosophical considerations
• inconsistent subcontractor involvement
• narrow single solution approach
• inconsistency between WBS / WP and technical description
• inconsistency between compliance matrix and technical description
• inconsistency between technical proposal and management & financial aspects (e.g. work proposed does not fit man-hours)