Requirements Hall of Horrors

The Talkative Project Manager

As part of a proposal bid, the proposed team gave a presentation to the client. The project manager had previously successfully worked for the client in another area, so he had some advantages being a known quantity, but also some disadvantages. The client stated they were looking for a new approach and were concerned about the requirements allowing this. Eager to win the proposal, the manager talked on and on about how the team's requirements would reflect new thinking, but after each new question, he dug the hole deeper because he didn't actually understand requirements. Had he allowed his requirements lead to speak, the lead would have informed the client that the requirements would be implementation independent, thus allowing multiple alternatives to be considered. The manager failed to convince the client and no contract was awarded.

The Gold Plated Scheme

The government hired a contractor to redesign its processes. Dreaming of piles of implementation money down the road, the contractor enticed users to require all the wondrous things technology could provide. Objections that a simpler approach would be better supported by taxpayers were met with derision by contractor and starry-eyed clients--after all, this was what private industry had; our operation should be up with current times! That may be true, but the organization had a poor system development track record, and the gap between current and planned operations was large, thus costly to overcome. So costly, in fact, that parts of the organization, along with the development, are now being contracted out to minimize financial risk in accordance with government requirements. With a simpler, less expensive set of requirements, the contractor could have helped with enhancements after the project was over, and users' jobs would not be on the block.

Lost Opportunity

The firm bought a startup company that had developed a tool to automate a business function, but it needed upgrading to more current technology. A project was begun to do the upgrade, but no one documented the requirements. Seven years later, the project was cancelled, the company lost its investment, and all the staff were laid off.

Gold Plating

The professor gave the class a set of requirements to meet.  One student failed the assignment. He argued to the professor that not only did he do all those requirements but that he did extra work and added some really neat functions. "Exactly," replied the professor, "you didn't meet the requirements."

The System Engineer's Lament

As the government attempts to convert legacy systems to enhanced systems deployed on modern architectures, a common syndrome reoccurs: requests to take the legacy software and "just tweak it" with these few new requirements. How does one accomplish this task? Is porting a client server application to a 3-tier web-based architecture so straight forward that it doesn't require requirements? If the same DBMS is used, perhaps. But how does one test the rehosted application? How are test cases developed? How is sign-off achieved? It was no surprise that the developer sought permission to redesign and reimplement the application. What software engineer wants to use someone else's code? So the government agreed, and the developer attempted to infer the requirements from the various artifacts that existed, including discussions with subject matter experts. Result: the software is delivered late, it doesn't work as expected, and deployment is postponed. Now what? A Get Well Plan. Will requirements now be fully captured, approved, and form the basis of the contract deliverables? Probably not, after all, they're "almost there," and they just need a couple more weeks to straighten things out with the developer. In reality, a three-month effort with a couple of requirements capture experts and some subject matter experts would solve most of these problematic scenarios, but this approach is rarely chosen. Short cuts are always so tempting.

Injecting The Solution

During the 1980's, one organization's upper management viewed the relatively new PC-based systems as lacking security. To avoid receiving proposals with a PC-based solution, they inserted a requirement in the statement of work restricting the system to mainframe-based solutions using dumb terminals. Because of this one sentence, over the years the system was being developed the project was prevented from updating to more current technology. The system was rejected by the users, and the organization lost tens of millions of dollars and many years of opportunity. It also cost management credibility, making it difficult for them to acquire the resources to start over and build this mission critical system.

Increasing Profits

On this scientific software project, contractor management believed that loose requirements would allow scope creep, which they could use to get more profit. They assigned analysts who had no requirements experience. The analysts developed one context-level diagram and maintained it could not be decomposed for the GUI. They were given specifications by the customer, but ignored them as being too detailed. The project was a major financial loss for the company, running 100% over budget and schedule.

Winning The Bid

On this $500 million project proposal, the project manager of the favored, incumbent contractor insisted requirements were not needed in the proposed tasks because this was an integration project. When it was realized requirements are needed on an integration project, it was too late in the proposal process and the favored incumbant lost the bid.

The Methodology

The company was tasked to create a simulator for the client. The analysts had no background in requirements analysis. They interpreted the company's methodology to mean that requirements should be decomposed only to the major subsystem level - not even to the functional primitive. The customer, who had requirements experience, was expecting decomposition to the specification level. Despite a last ditch effort by the analysts to supply the information, the project was cancelled.

Good Requirements; Bad Client

We negotiated a very clear statement of work, detailing what would be done. The first part of the deliverable was an outline of the document with a description of the contents for each section. This was approved. As we drafted each section, we gave copies to the client (and subject matter experts) for review and feedback, and we incorporated the comments. The client knew exactly what was going to be delivered, approving it each step of the way. There were absolutely no surprises--except for us. The client rejected the deliverable when it was delivered because it wasn't what he wanted. On top of that, he was loud, rude, and nasty when he rejected it. The requirements were fine: the client can go to hell.

Page updated 10/25/2005
Ludwig Consulting Services, LLC