This perrenial grows on our farm, but we have no idea what it is. A beautiful flower, it's in bloom from July through August. If we can collect seeds from it, we'll try to spread this plant around. It seems the deer aren't interested in it, so it should do well.

Farm Notes

Stool Bed Planting & Fence Construction - May,2007

Fence Repair & Watering/Weeding - June, 2007

Fence Repair & Watering/Weeding - July, 2007

Tech Writing Notes

Outline for task proposal responses:
Task Title
-Task Objective - Respond to shalls with wills, then back it up with hows and wheres
-Task Approach (to achieve the objective) - the how, defined by tools and techniques
-Our Prior Experience - the where, our past performance
-Deliverables

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)

Draft Response to RFI, influencing the direction of the RFP

Parse the RFI into subjects, organize those subjects into groups if it makes sense, adds clarity, or organization to ease implementation.

Respond to each section, point by point, painting the barn blue. Reorganize points only if necessary. Draft a picture that illustrates relationships between the points of that section.

Discuss what each point accomplishes, and why it should be done. Consider drafting "how" it should be done, but save that for the RFP, not the RFI.

Give each section an introductory header, like "Beware of false prophets", or "Managing Change" to clue the reader in to the subject of the content to follow and provide them with a unique file handle in memory to help relocate that particular topic.

Write in paragraphs, to the point, using the page limitations stated (if any).

Proposal Lessons Learned

Ya gotta be lowest price to win...

Get your team together early, and get the proposal disseminated, in its entirety as quickly as possible. If you only receive it in hard copy get someone to start scanning and OCR'ing the document into softcopy. This will be a critical time saver later.

Go through the RFP and develop an understanding, visual and written, what the RFP is asking for. These images will be important to your gold/red team reviews later.

Identify your book bosses early and work with each to develop an understanding of the RFP implications for their individual books. In particular the technical volume, the team should be sized appropriately to support it. If it's a big technical challenge then chunk it down and find staff to handle the chunks.

Begin early with your leadership team. Walk through the proposal development game plan with them and build buyin for what has to happen, and when it has to happen. Develop this game plan into a speech, schpeel, brief, or whatever, but be prepared to communicate it repeatedly to the troops as they come on board to support. The surest way to confusion, frsutration, and lots of rework is to not communicate what the overall process will look like, and what is expected of the team members.

In this latest instance we did not have a game plan that was shared with the troops. Instead we had a couple three senior staff that had the experience and new what the general game plan would look like. They were augmented with other staff that new how to handle individual parts of the problem. But at no point was the entire team brought together and given a talk on how the whole the executed and would come together in a proposal document 8 weeks into the future. As a result a lot of muttering under breath, poor moral, and half hearted effort became the norm. The team never merged into the tight unit that it could have become.

As for process, here are some of the things that happened along the way:

Get the RFP copied and diseminated early. Have extra copies on hand for late comers.
Ask the readers to answer these questions while they're reading:
Do you understand what the customer is asking for in this section?
Do you have an idea of what the solution could be in this section?
Do we have experience within SAIC to deliver such a solution?
Can you parse the section into clear requirements and deliverables?

Readers should mark up their documents to highlight requirements and deliverables, making them very obvious. Each reader who will respond to the proposal must develop a good understanding of what their section requires and be prepared to discuss technical solution options at a soltuion development strategy session.

A requirements driven outline is a very good way to structure the propsal response. But in some instances the RFP does not lend itself well to such an approach. Two other approaches for organizing the proposal revolve around mapping to the CLIN outline (or cost outline) or mapping to the RFP's own outline of the problem (lifted straight from their document outline). I recommend using the latter to structure the proposal, and the top level of the WBS. But the former (CLIN) should be integrated into the WBS to assist in developing a cost role up that the customer wants to see.

Requirements analysis is critical. Bring in a requirements analyst who can parse the document and find all requirements statements. They should also identify all deliverables and mark them as such in the requirements traceability matrix. Requirements can take at least two forms, deliverables, or capabilities. Deliverables are concrete objects that are left behind with the customer, including events such as meetings. Capabilities are attributes of deliverables, such as speeds and availability, etc.

The output of requirements analysis becomes critical to ensure that you've developed a technical solution that meets all of the requirements of the RFP. Requirements must be mapped to the WBS to ensure that somewhere in the execution of the program each individual requirement will be addressed and satisfied. A cross walk analysis betwenn RTM and WBS ensures completeness and accuracy of both. More critically it establishes reality upon with the Bill of Materials and Basis of Estimates will be built.

RFP->Questions->RTM->Solution Outline->WBS->BOM->BOE->Cost
Solution Outline->Understanding of Requirement->Approach to Meeting Requirement
Understanding of Requirement -> Past Performance Examples

Read the RFP
Develop Questions
Draft an organization of the work, graphic WBS
Draft a geolocation image of the sites involved
Draft the org chart/hieracrchy of the organization and mission components/sites
Scan the Program Management Section, Cost Section & Requirements Section for guidance on lifecycle, major system components, CLINs, and other factors that will help form the top level organization of the WBS/Project Plan
Create a Configuration Item for every major system component, assign each CI to a Cost Account Manager
Cost Account Managers must further develop their respective WBS sections to accomplish the work of their CI
Parse requirements from the WBS and map them to the WBS line items that will satisfy them
Parse all deliverables (meetings, leave behinds, not requirements) from the RFP and make sure they are all delivered in the WBS.
Identify dependancies (try working backward from the deliverable)
Lay in the overall schedule requirements from the RFP (e.g. customer's prefered lifcycle phases)
Drive down to bill of materials level with step by step tasking that accomplishes the requirements and makes the deliverable.
Put scheduling in and allocate resources (labor and materials).