The Problem with the Project Charter

When you consider the PMBOK, creating the Project Charter is one of the first things you do on a project. But look at the work to develop a Project Charter, Table 3-1 of the PMBOK 3rd Edition, the inputs are the contract, the Statement of Work, the enterprise environment and organizational processes. Then, I am not expected to create my Work Breakdown Structure WBS until even later in the process. I really like "Rita's Process Chart" (Rita Mulcahey) to put these activities in order. If you don't have her book sitting right next to your PMBOK, you should.

Do you see the problem? I have a contract before I know what the work is supposed to be performed AND I have a contract before I know how much it should cost. Maybe in the commercial sector this level of squishy-ness in Statements of Work can be tolerated, but in the government, this cannot occur.

Statements of Work (SOWs). All Statements of Work shall include the work to be performed; location of work; period of performance; deliverable schedule; applicable performance standards; and any special requirements (e.g., security clearances, travel, special knowledge). To the maximum extent practicable, agency requirements shall be performance-based statements.
FAR 8.405-2(b)

Additionally, government contracts more than $100,000 must have an Independent Government Gost Estimate (IGCE). This Powerpoint gives a great overview for that process.

Do you see the problem now? If I was to follow the Project Management processes as identified by the PMBOK, I would be violating regulations and policy. But I challenge anyone to find a Contracting Officer who will award a contract without both a good understanding of the work to be performed and a reasonable baseline from which to review proposals. Thus we are left with a problem. How do we get the information we need to award a contract AND complete a Project Charter? The simple answer is to abondon or amend one or the other process. But I would caution against that. Let's see if we can be pragmatic and meet both objectives.

Steve McConnell, the Microsoft developer talks about the "fuzzy front end" as

the time before the project starts, the time normally spent in the approval and budgeting process. It's easier, cheaper, and less risky to shave a few weeks or months off the fuzzy front end than it is to compress a development schedule by the same amount. But it's not uncommon for a project to spend months or years in the fuzzy front end and then to burst out of the starting gates with an aggressive, often unattainable schedule.

But we can't short change this part of the process. You must have a good understanding of the work to be performed in order to create a Statement of Work that meets the requirements of the Federal Acquisition Regulations. I believe that the best way to do this is to actually decompose the work to be performed and develop the WBS. The hard part is that there is a cost to doing this. Thus you are essentially incurring project costs really before you have a project. That is a risk that you must consider and deal with as an organization. This type of work is basically seed money, or start-up money. But you have to be careful as well or you'll spend all your time working on this part of the process and not managing the development portion.

However, once you break down the project into its constituent parts you will find that it is only one more step to generate your IGCE. You have the WBS, either in MS Project or in Excel, create a column for level of effort (I usually use hours) and then add a column for Rate (cost per hour). The final column multiplies the two to find a cost for that item in the WBS. Once you total your costs you should have a reasonable bottom-up estimate based on the work to be performed.

I would very strongly suggest that you get as many eyeballs on your WBS and estimates before calling it "Final" and sending it to the Contracting Officer. You should have Project Managers review it to identify areas in which you didn't identify work, especially in the areas of Planning, Quality Assurance and Quality Control. You need to review all of it with the subject matter experts to do two things, first, that they agree you have identified ALL of the work they expect to be performed (didn't leave something out) and they will be able to draw upon resources needed to pay for this work. This is the painful process of getting everyone's expectations in alignment. (But don't allow the elements necessary for PM visibility to be removed, you NEED that in order to keep the project on track.) Finally, make sure you get the infrastructure people to consider the WBS and estimates as well. The platform, hardware and networking costs are often overlooked and can be expensive.

Keep refining the WBS and costs until everyone is in agreement and able to support the final numbers. This means that you are indeed performing some of the work out of order with the PMBOK, but you will be ahead of the game, not behind.

I'm sure I'll be writing more about these topics over time.