When projects go wrong, they generally go wrong at the beginning. My experience is mainly in the defense industry, so most of the following are derived from those experiences. Poorly defined requirements lead to poorly defined statements of work and specifications, which lead to unrealistic expectations for the customer and the supplier. This fundamental communications issue blights projects and affects them throughout their life cycle. So why do project teams make these same mistakes over and over and over? After scores of interviews and post-mortems in the last twenty years, it unsurprisingly comes down to poor practices and lack of discipline. Is this the project team’s fault? Only partly. Often it is the customer’s fault, particularly in government contracts. That the US Government attempts to employ good project management practices is a given; however, their shortcomings are three-fold.

First, the program managers may be on the promotion track, which means a reluctance to admit to problems.

Second, the program controls / Earned Value organization often seems more interested in accounting than project management.

Third, the persons developing the statements of work and technical requirements fail to make them both explicit and realistic.

Let’s start with the last first, as that is where a project can be at risk from inception. The problem with statements of work for significant development procurements is that the persons writing them often either do not know how to define the requirements when the aim is inventing technology, or they may have a jaundiced view of requirements definition, i.e., they want to leave certain things “obscure” to maintain a degree of “flexibility” in the future or they want to “challenge” the supplier to create a “better” solution. The former circumstance is merely a fact of life. Still, the latter makes misunderstandings leading to unnecessary changes, do-overs, delays, and increased costs without advancing the project toward the ultimate goal of providing what the end-user needs. Over the last twenty years, I worked with several engineering managers who avoided stating firm requirements because of the mistaken idea that firm requirements tied their hands or reduced “creativity.” This is a warning sign for the risk identification process…ill-defined requirements mean greater exposure to both buyer and seller.

So how does the “seller” correct this when it means telling the customer that he isn’t doing a good job? The IT services model of defining requirements through joint analysis and jointly agreeing on requirements is a good one, employing the intent of the spiral project life cycle model, which allows the risky bits to be identified and resolved at the lowest possible cost. If the risks cannot be reduced, then the project requirements and objectives can be modified, or if the prices exceed the benefits, the project may be abandoned entirely. This, again, will require a close relationship with the customer and may be a difficult sell on the supplier’s part. However, it certainly is worth approaching when you find yourself in a vague statement of work circumstances. One successful technique is to put that reluctant technical manager in the seller’s situation by asking him if he would sign a firm, fixed-price contract as a home builder based only on an artist’s sketch of the house. You can infer what to do with the analogy from there. Ideally, we would want that technical manager to hire us to design and build the environment. However, he still must provide basic requirements for us, for him, and for the project to be successful.

Establishing direct, straightforward, and honest communications is the only method for dealing with the first circumstance, that of a customer project or program manager who, for whatever reason, doesn’t want to hear about problems, issues, and risks. This may be a no-win situation for the seller, but it is better to have warned the customer’s project manager and told him the truth rather than being complicit in a disaster. A manager friend of mine had a sign on his desk “Come to me early with a problem, and you have a partner in finding a solution. Come to me lately with a disaster, and you have a judge.” I employed that thought when I sat as the customer project manager chair. That was one of the first discussions I would have with the seller on a newly contracted development project. It may be painful, but it works, and the pain is short-term rather than a reputation destroyer.

Using earned value as a project management technique is essential. However, the Government’s EV people from a financial background may present a challenge when attempting to design, organize, and build a project that results in meaningful measurements and statistics. I found three things crucial in earned value management: objective measures, a deliverable/product breakdown structure as opposed to a “product-oriented” WBS (this often required deviation from the government’s contract WBS or MIL-HDBK-881A), and using labor hours for EV measurements on labor efforts. I’ll discuss each of these in a subsequent blog.