Proposal Land

Some notes on management content: what drives the requirement, what it looks like, and where your focus should be. RFP responses can seem complex and intimidating, especially to the uninitiated. Simplify the task by dividing and conquering.

Where Does the Requirement for Management Content Come From?

I’m thinking you’re able to guess this one: “The RFP.”  But what are the underlying drivers?  I think two things:

• Client due diligence, especially around labour and the environment
• Client risk avoidance

What Kind of Management Content is Required?

“What kinds aren’t required” might be a shorter list.  Here are relatively standard things:

• A description of the bidder’s experience in similar work, both corporately and for the personnel being proposed
• Narrative, tables, and schedules that describe how the bidder will design and staff the organization to deliver the product or services on schedule and budget, including a transition plan if someone else is now doing this Work
• Narrative that describes how the bidder will manage the effort:
  • To deliver on schedule, scope, and budget
  • To meet quality and performance standards
  • To manage subcontractors
  • To handle client interactions
• How the bidder plans to meet safety, environmental protection, and any other regulatory requirements
• In Canadian defence and security procurements, an explanation of how the bidder will meet federally mandated regional development requirements (similar requirements to support small, minority-owned and/or disadvantaged businesses exist in the USA)

Is It a Good Idea to Submit Additional Management Content?

As with technical content, this is an imponderable.  You pays your money, you takes your chances.  Evaluators might reward or penalize additional content.

Where Should the Focus be for Management Content?

Like technical content, management content should be:

• Clear
• Compliant with any management requirements in the RFP
• Complete against the response requirement
• Consistent (tough, tough, tough to achieve, since management topics – think safety and quality –  slop across technical topic boundaries)

But, in addition, management content should focus on real-world credibility and plain-language examples of where the approach has been used, and to what effect.  Credibility is harder to achieve in management than in technical content, because the former has fewer hard, objective criteria.

Some notes on technical content: what drives the requirement, what it looks like, and where your focus should be. RFP responses can seem complex and intimidating, especially to the uninitiated. Simplify the task by dividing and conquering.

Where Does the Requirement for Technical Content Come From?

As with contractual content, the short answer is: “The RFP.”  But in this case, the underlying driver is the Work.  Clients don’t make up response requirements for the fun of it. Instead, they determine what they need to know about the goods or services (or both) that they want:

• To validate that a bidder’s offer is what they want, or to assess how close it is to what they want
• To make bidders commit in writing to delivering the goods and/or services
• To distinguish bidders’ offerings
• To identify and quantify any risks that they might be accepting in going with a bidder’s technical solution

What Kind of Technical Content is Required?

Whatever it says in the RFP: Designs, drawings, specifications, plans, procedures, schedules, miscellaneous narrative . . .

Is it a Good Idea to Submit Additional Technical Content?

Ah, the $64,000 question.  Here’s the dilemma:

• In bidder debriefs, clients sometimes note that they wanted more detail, or even that another (unnamed) bidder submitted not just a plan as requested, but also an operating manual.  That suggests that more is better.
• In bidder debriefs, clients sometimes note that they took issue with the bidder’s approach, as detailed in extra content.  That suggests that while more may be better, sometimes less is more.

There is no single right answer: What is good will depend not only on the client but on the preferences of the  individual evaluators.

Where Should the Focus be on Technical Content?

Technical content should be clear.

Technical content should be compliant with the technical requirement (that is, the solution described by the technical content should be compliant).

Technical content should be complete against the response requirement.

Technical content should be consistent.

Boy, I’d say that was enough work for any proposal effort.