When will We Learn?

When David Kroenke, textbook author, was teaching at Colorado State in 1974, he participated in a study that investigated the primary causes of information systems development failures. The findings? The number one reason for failure was a lack of user involvement in creating and managing system requirements.

Technology has made enormous strides since that study. In 1974, computers consumed large rooms, and neither the minicomputer nor the personal computer had been invented. Alas, the development of information systems has not kept up; in tact, one can argue that nothing has changed.

Consider Case Study 7 (pages 199-202). The state of Oregon wasted more than $248 million attempting to develop an information system to support its healthcare exchange. And very early in the project, Maximus Company, an independent consulting firm that had been hired to provide quality assurance, warned that requirements were vague, changing, and inconsistent. Those warnings made no difference. Why‘?

Why Are Requirements Not Managed?

In 1974, it might have been that managers were computer illiterate and thus couldn't know how to manage requirements. However, everyone involved in Cover Oregon has a cell phone and probably an iPad or Kindle, so they are hardly computer illiterate. So today, at least, computer literacy isn't the problem.

Does the problem of managing requirements lie with management’? Or with requirements? In Case Study 7, you learned that Access CT, the Connecticut healthcare project, succeeded. Was it because the project was closely managed by the lieutenant governor‘? A woman with future political ambitions? Oregon has no

lieutenant governor, but surely there was someone to manage the project. One indication of management problems in Oregon is that the information system was to be used by one healthcare agency (Cover Oregon) but developed by a different healthcare agency (Oregon Health Administration). The two agencies fought battles over requirements. Due to lack of senior-level management, not only were requirements unmanaged, they were fought over by two competing governmental agencies.

That might be the prime cause for Cover Oregon's failure. But is there something else? Even in well- managed organizations, is there something about requirements that makes them hard to manage? Fred Brooks provided one insight when he said that software is logical poetry. lt’s made of pure thought stuff. If two governmental agencies were to construct a building and if they fought over, say, how many stories that building was to have, then their disagreement would be visible for all to see. People would notice one group of contractors adding a floor while another group is tearing it down.

So part of the problem is that the requirements are requirements for pure thought-stuff. But what else?

How do you know if the requirements are complete? If the blueprints for a building don't include any provisions for electrical systems, that omission is obvious. Less so with software and systems. For example, what if no one considers the need to do something when a client forgets his username or password and has no record of policy numbers? Software or procedures need to be developed for this situation, but if no one thinks to specify that requirement, then nothing will be done. The system will fail when such a client need appears.

And how do you know the quality of the requirements statements? A requirement like ‘Select a qualifying insurance policy for this client” is written at such a high level that it is useless. One of the reasons for building a prototype is to flush out missing and incomplete requirements.

Assess Feasibility and Make Trade-offs

But there's more we can learn from this example. All of the state and federal healthcare exchanges needed to be operating by October 1, 2013. So, the schedule was fixed with no chance for an adjustment. Considering cost, while funds were not fixed, they were not easily changed. The states initially provided some funding, as did the U.S. government. Once those financial allocations were made, it was difficult to obtain more money. Not impossible, but difficult.

Examine Figure 12-19 again. If schedule is fixed and if funding is nearly fixed, what is the one factor that can be traded off to reduce project difficulty and risk? The requirements. Reduce them to the bare minimum and get the system running. Then, after some success, add to the project. That seems to be the strategy that Access CT followed.

But this principle exposes another of the problems in Oregon. It wanted everything. It embarked on a policy called “No Wrong Door,"3 a policy that would leave no person nor problem behind. Cover Oregon should provide a solution for all. Such statements make wonderful political messaging, but if the schedule is fixed

and the funding is nearly so, how are those goals to be accomplished? Tell your roommate that you have 1 week between semesters and nearly no money and you plan to take a first-class, 2-month jungle excursion in Africa. Hello? Anyone home?

Software and systems are made of pure thought-stuff. Easy to imagine a glorious future of amazing capability. But they are contacted by costly human labor, and nine women can't make a baby in 1 month. Remember that sentence when you are asked to help determine requirements for your new information system.

Describe three reasons why cases like this will remain relevant 40 years from now. Describe three developments that could make these cases obsolete. Which will pertain? Will such cases be relevant 40 years from now? Justify your opinions.

2.) Read the Executive Summary of the First Data report located at

www.oregon.gov/DAS/docs/co_assessment.pdf

Applying your knowledge about the SDLC, describe what you think are the three major reasons that Cover Oregon failed.

Answer rating: 100% (QA)

For years lefty health policy wonks have instisted against all the evidence that expanding Medicaid would save hundreds of thousands of lives and that therefore opponents of the Medicaid expansion are ... View the full answer