When projects go wrong, they generally go wrong at the beginning. As my experience is largely in the defense industry, most of the following is derived from those experiences. Poorly defined requirements lead to poorly defined statements of work and specifications which lead to unrealistic expectations both at the customer and at the supplier. This fundamental communications issue blights projects and affects them throughout their life cycle. 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 the world of government contracts. That the US Government attempts to employ good project management practice is a given; however their shortcomings are three-fold.
First, the program managers may be on promotion track, and that means reluctance to admit to problems.
Second, the program controls / Earned Value organization seems often more interested in accounting than in project management.
Third, the persons developing the statements of work and technical requirements fail to make them both clear 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 major 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” in order 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, but the later creates misunderstandings leading to unnecessary changes, do-overs, delays, and increased cost 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 ideas that firm requirements tied their hands or reduced “creativity”. This then 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 the he isn’t really doing a good job? The IT services model of defining requirements through joint analysis and jointly agreeing on requirements is a good one, as is 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 costs begin to exceed the benefits, then 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. It certainly is worth approaching when you find yourself in the vague statement of work circumstance. 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 the house in addition to building it. However, he still must provide basic requirements for us, for him, and for the project to be successful.
Establishing plain, 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, for the seller, may be a no-win situation, but it is better to have warned the customer’s project manager and to have 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 late with a disaster, and you have a judge.” I employed that thought literally when I sat 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. That the Government’s EV people come 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 measurements, 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.
Improvements:
