The Proposal Triad of Crap, or TOC

It’s the three most common mistakes in proposal writing, and it makes evaluators crazy: 

TOC item 1 – Restating the SOW or PWS requirements.  The RFP says “offeror shall build X”, and the proposal says “we will build X”. 

TOC item 2 – Writing a past performance citation, oddly enough this usually happens in concert with restating the requirements “we will build X.  We have built X on 15 other programs; we have the demonstrated experience to build X fast, better and cheaper” (or some other proposal fluff)

TOC item 3 – Writing a tutorial.  This one really insults the evaluators.  The RFP states: describe your approach to implement the ITIL framework.”  The proposal says: “The Information Technology Information Library (ITIL) is a framework consisting of five core services;  Service Strategy,  Service Design,  Service Transition, Service Operation, and  Continual Service Improvement. Blah blah blah…”

Although the TOC happens most commonly with inexperienced proposal writers, I’ve seen the TOC come from seasoned proposal authors as well.  I usually know the proposal is headed down the TOC path when the section starts with:  “We understand your environment….”.  When you see that, or if you write that, watch out.  You are headed into the grasp of the TOC.

So how do you avoid the proposal TOC? 

First off, start early and institute a proposal culture of “How”.  Always ask “How” the approach satisfies the requirement.   The response has to have the “How”.

Secondly, if you are struggling with the “How”, use the Demming Cycle approach to lay out the “How” by using Plan, Do, Check, Act.   Here’s an example for a generic project:

Plan:  We will develop a project implementation plan and coordinate its approval with the Government during phase-in.  The plan will include project charter, roles and responsibilities, deliverables, milestones, resource loaded schedule, critical success factors, KPIs and key metrics, gate reviews, budget and cost control approached, etc., etc., etc….

Do:   At project approval, we will conduct a kick-off meeting with all stakeholders.  We will obtain the resources per the project plan and allocate them to their specific work activities. Daily status meetings will be held….We will conduct Systems Requirements Reviews…Critical Design Reviews….Acceptance Testing, etc., etc, etc….

Check:  The project manager will track planned work activities against actual work completed.  This will include % work complete, schedule completion, budget tracking, etc….    Our Quality Assurance Manager will evaluate actual work products against the Critical Success Factors and metrics.  Variances will be analyzed using our Lean Six Sigma process and handled in accordance with our ISO-9000 QMS (….oops, here we go – proposal fluff). 

Act:   We will apply lessons learned and root cause analysis techniques to develop enhancements to our processes and rectify any deficiencies….blah blah…and some stuff on continuous improvement…

I frequently augment the PDCA with the 5 W’s and How: 

Who will do the Work?

What will be produced?

When will it be produced?

Where will it be produced?

Why is the product produced?

How will the product be produced? – rolling right into PDCA.

I have a handy dandy MindManager template to use for all this located right here>>>>

Thirdly, do lots of in-process reviews – at least weekly.  Have the authors present their approach to satisfying RFP requirements to a group of their peers as well as external observers.  This doesn’t have to be a long presentation, just have them get up and explain: “How”.  You’ll quickly see gaps and get them corrected before you are in a real time crunch. 

As always, the key is to start early on most proposals, and always ask “How”.  Don’t wait for a pink or red team to find out you are overwhelmed with the Proposal Triad of Crap.