It all starts with a plan

Proposal lessons learned here... Need better game plans. All to often I've seen the same mistrake repeatedly. Leadership assumes that those brought in to work a task have a very good understanding of what is expected of them, when in fact they may have never done any proposal work what so ever, nor have any training. Thus it is imperative for the leadership to gauge the skill/experience level of everyone on the team (not directly, but through his book bosses and other delegates) and assess who could benefit most from some coaching and oversight.

I've noticed that in fact the people we pull in to these teams are very bright, and competent at their day to day job, but thrown into a foreign task, like proposal writing, they often flounder. That's not their failure, it's the proposal team leaderships failure if they don't prepare for and address the issue. Everyone needs to understand the game plan.

Game plan is a pretty simple concept. It lays out an end to end series of activities, events, and goals that must be accomplished. Later, AFTER the game plan is laid out, it is appropriate to after schedule or date constraints. In this last proposal I noted that the schedule was delivered and everyone was expected to comply. Unfortunately no game plan was ever briefed so many folks did not know how to achieve the goals that loomed in their future.

Game plan is hierarchical in nature, i.e. there should be game plans for sub activities that run within the larger game plan. For instance, in this most recent proposal I was the book boss assigned to develop the WBS, BOEs, manage inputs to the Cost Volume and all develop all Red Team and FPRB review materials. Fortunately the review materials could be handled by a couple of old seasoned professionals that we had recruited, and they knew a lot more about the process than I did. But the WBS and BOE development was not a well understood activity (but lots of people think they understand the activity). I knew I would have to lean heavily upon the technical leaders who were busily writing Story Boards and Tech Volume inputs for their input to WBS activities and subsequent estimates of resources required to complete the job. I also knew that none of these guys had done a hardcore WBS or BOE in the past, so I put together a game plan on the white board and briefed everyone on what we would be doing over the next few weeks. Thanks God I did, because it was a long and indepth process that would have taken weeks more if I hadn't organized everyone up front.

Just for posterity, the game plan looked something like this:

1 - Parse the RFP into task areas and subtasks, ALWAYS maintain compliance with the customer's organization and naming of the tasks (doing otherwise makes it hard to evaluate your propsal and jeopardizes your ability to ensure you're compliant with the RFP).

2 - Organize those task areas into a WBS, no deeper than three levels if possible.

3 - Then work with the technical leads to fill in the subtasks at level 4 and 5, these are the tasks that you can develop real resource estimates for.

I recommend not building your WBS in MS Project. It's a real bear to use when you get into large programs with many lines of detail, and the tendency to use the menu options will invariably cause you heart ache in the end. I can use MS Project because I've struggled through years of experience and learned how build them "by hand", or largely without the use of wizards and menus. But for the unitiated there are propbably better tools to work with. I will be trying PS8 for my next WBS/BOE development effort.

4 - As the resources are loaded (including labor, travel, other ODC's) you will need to iterate repeatedly to ensure your BOE rationales are sound (and recorded for the record). These rationale statements are critical to explaining to the Red Team and FPRB how you built your estimate. The strongest type of estimate is based upon metrics that you've collected while doing exactly the same type of job in the past. Next best are estimates based upon doing the exact same type of job in the past but without any metrics to lean upon. Then there's metrics for similar types of jobs in the past, then experience from similar types of jobs, and finally, the weakest type of estimate, the engineer's estimate.

It is also critical to speak to your capture manager during this part of the process. They may have some intel developed months before the RFP release that will help guide your estimates. For instance, it's not uncommon for the capture manager to be aware of the "bogey" or limit of what a customer might be able to accept. Therefore you might be able to establish an upper bound for your estimate and know what kind of constraints to apply to your estimate. But this should always come last. You should always build an accurate estimate first (with minimal gold plating) and then work backward from there if you've exceeded the bogey.

As the estimate matures you should be able to roll labor hours up into the positions/skills that you'll need to accomplish the work. DO NOT let someone's preconceived notion of an org chart drive your estimate. It works the other way around. The RFP sets initial guidance for the organization's members. The BOE validates that guidance (or refutes with justification) and completes the organization with the correct type of skills and associated labor hours needed to complete the work (this is critical in a Firm Fixed Price bid). Thus your org chart will be driven and validated by your BOE (which is driven by the WBS, which id driven by the RFP).

5 - labor hours and staff positions, once established, become inputs to the costing exercise, or pricing exercise. Working with your project controller you can provide the BOEs in terms of labor hours per staff position. They'll work with the prospective PM (who should have selected resumes of the staff he wants to place on the program) and establish labor categories (after profitability analysis) for each of the position. From there they can work up the price and tell you if you still fit within the capture manager's notion of what the bogey should be (assuming he knows). Be prepared for many iterations of this exercise as the BOEs may be tweaked over time while the proposal matures. Standardize your BOE template to the pricer and make his life easier. A standard template can be easily imported to his pricing template. A new format will cause major heartburn and rework on the pricer's part.

To be written ... The Proposal Game Plan (an outline)