Connect the Dots Please ....

I'm a practical guy and I don't like is doing the same work twice. However, every time I work on a proposal it seems the same predictible things happen. I could be one of the factors ... but more likely its not me so much as it is my tools.

The projects I'm associated with have a predictable pattern. There is a Request for Information from the customer's acquisition team followed by a written response. Then there is a solicitation requesting a technical and cost proposal followed by several weeks or even months of effort resulting in a proposal. Sometimes we win, sometimes not. But when we win we go into execution mode - and it is here the double work begins.

Common Data Requires a Common Workflow

The root cause seems to hide in the lack of a common lifecycle and workflow for (in my case) the GovCon workspace. Much could be standardized on the data side of the equation if we could agree on the lifecycle/workflow requirements. For example, if we take the "Acquire New Business" process how many companies use a Customer Relationship Management (CRM) system or similar tool? How many conduct Gate Reviews? What about Bid/No-Bid Decisions?

The workflow drives the data requirements. Even a "Best Practices" model produced by a recognized industry leader like the Association of Proposal Management Professionals (APMP) leaves space for improvement - especially in the "handover" phase and the Program Transition Plan where the data collected or generated during the proposal is turned over to the operations team.

But alas - much the work done during the proposal effort including draft schedules and cost estimates and risk analyses tends to be left on a shelf and fresh efforts started to build a project plan essentially from the ground up. WHY? Do project managers fail to understand that much of the groundwork has already been done and passed by the customer for their review and acceptance? Or is it the tools we are using the fail to provide a way of leveraging the work that was done during the proposal? It's a little of both - but perhaps we can fix that.

The Proposal as a Project Planning Exercise

Many of the books you will read concerning proposals dwell on writing, marketing, and graphics techniques as applied to proposals or with managing the production of the actual proposal. Few, if any dwell on the underlying activities of planning what one would actually do during project execution. As one business development manager once told me ".. there are bear trappers and bear skinners". In other words "I win the business - you figure out how to actually deliver on my promises". Oops!

Proposals - at least the ones of the size and complexity I typically am associated with - require a lot of detailed planning in terms of cost and schedule. Often these projects require submittal of certified cost or pricing data which is then subject to a pre-award audit. To accurately develop such estimates we rely on integrated schedule and cost data. We use elaborate procedures and sophisticated tools to develop or capture such data frequently through detailed bottom-up estimates. After all, we have to be spot on (at least according to the government accounting rules) under the penalty of some pretty serious repercussions for defective cost or pricing data.

Consequently, we typically create a work breakdown structure aligned with the statement of work, develop a resource loaded project schedule, and then apply specific rates and burdens to the estimated resources to develop our estimate. Each deliverable or activity in the project is estimated separately and supported by a written narrative called a Basis of Estimate to justify the material or labor resources used and the hours required to accomplish the work.

I encourage this level of planning during the proposal - even when not strictly required - because it tends to bring out problems and risks that need to be considered or solved as part of crafting the proposed solution to the customer. I also recommend sharing details of that planning with the customer through the previously created work breakdown schedule, project schedule, risk analysis, and draft project planning documents. By doing this I achieve two goals that support a better proposal evaluation: 1.) A high degree of understanding of the customer's requirements and a definite plan to achieve those requirements and 2.) Reduced performance risk to the customer.

Reinventing The Wheel

Its disheartening then when all the detailed analysis and thought that went into developing a bottom-up estimate of labor hours and costs, project schedule, and risk analysis are simply shelved or ignored as the project - now in the form of an awarded contract - are handed over to the operations team for execution and they begin the analysis and planning all over again -often from a clean sheet. Why is it that they fail to leverage this information?

One reason - and an easy one to correct - is that there are frequently different teams creating the proposal and managing the project. Often the "real" project manager is not a key participant in the the proposal effort. This is a management failing that I contend should be addressed. PM's need to have input into the proposal for projects they will inherit - otherwise they have no "skin in the game" or ownership of the proposed solution and are apt to simply blame future issues on the proposal team who gave them an impossible situation to execute.

The second is incompatibilities in the tools we use during proposals vs. the tools we use during execution. This is another area where we can reduce the pain and ease the transition from proposal to execution.

Tools and Data Portability

The tools used for project planning during the proposal process usually include a scheduling program such as Microsoft Project or Primavera and a costing program or spreadsheet. These tools are fed data from other sources such as CAD programs (bills of material) or various Enterprise Resource Management tools. The result is a well documented set of data describing the who, what, when and how much of the project.

Now the fun begins. When the contract is awarded the estimates become budgets - as they ought to do. But how does one seamlessly export the estimates from the pricing tool to the accounting system? The typical answer is "not very well" ... While a costing system is capable of producing reports showing costs (or labor hours) by WBS activity spread over an assumed period of performance - the accounting system may or may not follow the WBS. Accounting systems often are focused on departments rather than projects. In the end the data tends to be exported to a spreadsheet, manipulated by some queries or cross-tabs, and the resulting summary data either imported as ASCII or XML into the accounting system. Often times there's not even this low level of interface and the proposal data is hand-keyed into the accounting system or new estimates are created from scratch.

Schedules tend to fare a bit better as the same tools are commonly used for performance as for planning. Where they differ is in the degree of detail in the schedules as the proposal schedule tends to stop at what would be called summary level activities or planning packages and the execution schedule is developed in far greater detail.

If we only had to do the data conversion one time to import the data it would be bad enough; but it seems we have to do the same kind of translation in the other direction for reporting purposes. What's up with that? This is especially true if we elect (or are required) to use an Earned Value Management approach for managing schedule and cost performance. As a project controller at Boeing I vividly remember exporting queries from the accounting system to home brewed database and spreadsheet tools to manipulate data into the formats needed to populate EVM reports.

While there are vendors who attempt to integrate (with various degrees of success) the propose/execute/report process the solutions offered typically attack the problem of data portability from the standpoint of proprietary software that may or may not play well unless you commit to their entire solution. Therein lies the rub .. businesses have significant investments in legacy systems and data that would all either be rendered obsolete or require expensive conversion to switch over to the "integrated" system. As has been the case for decades, users may not LIKE a system - especially one that is perceived as being "clunky" but they adapt to its quirks over time and become expert in how to use it in their application. If they are going to champion moving to a different system then the payoff - in terms of usability, productivity, and functionality - had better make that process worthwhile!

So, What Do I Want?

I would like a solution to the underlying problem of data interchangeability. That lack of data portability that is a key underlying issue - and arguably one that needs to be considered by the project/proposal/business management communities and addressed. While there are some tools available such as XML schema or spreadsheets that allow some data to be exported - albeit with some difficulty and mixed results - what is truly needed is total data portability.

Towards that end, data portability requires common workflows, agreement on what planning data will be produced and used for program management and reporting, and how that data will be stored e.g., a publicly accessible data schema. That means there must be a consensus when it comes to naming conventions and data types. What one vendor calls a "Task" may be another vendor's "Activity" and whereas one vendor may use one or more values stored with the task to denote its place in the WBS hierarchy another vendor may create a separate table with parent-child relationships for each task.

Personally I don't care what software vendors do PROVIDED there is a lingua franca promoting the exchange of data between/among various tools. The Microsoft .mpp format seems to have emerged as one standard on the scheduling side - now it's time for accounting programs to follow suit. At least that's my 2 cents. Because if we really want to eliminate double work and the potential for error between the planning, execution, and reporting activities we all need to be working from a common point of reference.