Tag Archives: us census

What Failed Projects Have In Common

I’ve written about a number of failed projects (see the Project Failure link at the top of this blog). There is a common thread across all of them. Lack of clear requirements. It is the lack of clarity that is the key point.

The US Census devices had “thousands” of “unreconciled” requirements, the Sydney Opera House had an attractive picture, but no hard factual underpinnings for how the design could ever work, the FBI’s virtual case file project were “ill defined and evolved as the project progressed” and during the H1N1 vaccine project the scope of work changed materially. All of the projects I’ve just described failed.

Now this is a short post, so I won’t detail strategies for project success, but it does seem that a sure fire way to fail is to have vague, changing or conflicting requirements. Interestingly, bad estimates don’t lead to massive delays, vague requirements do. Equally, poor budgeting may not cause massive cost overruns, vague requirements do.

Of course, to run a successful project you need to succeed in a host of areas. It’s not just about the triple constraint of cost, schedules and resources. You need to get the people and communications aspects right too, but to fail you only need to keep the requirements vague.

2010 US Census and Project Management

We know that many projects fail, perhaps the more interesting follow-up question is why this happens. Following on from investigations of project failure at the Sydney Opera House and the H1N1 Vaccination Program this post examines the 2010 US Census which has experienced several project management problems in recent years. The US Census occurs every ten years to count the number of people in America so as to inform policy discussions, allocate budget and apportion seats to the House of Representatives.

Whilst it’s true that the US Census will happen (a delay to the program would be illegal) elements of the project are a failure. One of the goals of this census was to use automation to “improve coverage accuracy and efficiency”, in part by providing 500,000 handheld computing device to eliminate the need for those walking the streets collecting census data to print out questionnaires and maps. This process was “relying as never before on contractor provided technology”. $3 billion of the $11.5 billion census budget was to be spent on automation including the devices, which cost approximately $600 million. However in early testing in certain locations these devices experienced 27% downtime as well as other issues.

Reports from the US Government Accountability Office showed “an increased probability that the system would not be delivered on time and within budget or perform as expected.”

This situation occurred for the following reasons:

Lack of clear requirements

“The contractor is overwhelmed by a substantial increase in requirements having thousands of unreconciled (that is, not validated) requirements.”

Poor risk management

Some risks have been identified some risks, but there is no formal process or resource allocation to mitigate them should they occur. “Because they did not develop complete mitigation plans, the project team could not ensure that for a given risk, techniques and methods would be invoked to avoid, reduce and control the probability of the occurrence.”

Partial cost management plan

The program had initiated Earned Value, but not selected detailed performance measures to implement full cost management.

Executive reporting and communication gaps

The review calls for reporting on a “periodic and event driven basis”, but there was no evidence to document that risks were discussed with executives.

Of these issues the primary one appears to have been requirements management, because of the reliance on a vendor to provide the technology, this was a critical part of the process. It is not enough to give the vendor requirements, this was happening. Indeed the vendor received thousands of requirements, the need is for consolidation and validation of requirements.

It is likely that imprecise requirements is what caused cost overruns. Precise requirements could also have supported risk management because the timing of requirements and the mitigation strategies if they were not met could have been part of the process.

Whilst project management is a complex and interconnected discipline, it appears that similar to the example of the Sydney Opera House, imprecise requirements and scope management were a significant part of the problem.