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.
No comments:
Post a Comment