Page 531 - Using MIS

Case Study 12 499

CaSe Study 12

When Will We Learn?

When David Kroenke, textbook author, was teaching at thought-stuff. If two governmental agencies were to construct
Colorado State in 1974, he participated in a study that investi- a building and if they fought over, say, how many stories that
gated the primary causes of information systems development building was to have, then their disagreement would be visible
failures. The findings? The number one reason for failure was for all to see. People would notice one group of contractors
a lack of user involvement in creating and managing system adding a floor while another group is tearing it down.
requirements. So part of the problem is that the requirements are require-
Technology has made enormous strides since that study. ments for pure thought-stuff. But what else?
In 1974, computers consumed large rooms, and neither the How do you know if the requirements are complete? If the
minicomputer nor the personal computer had been invented. blueprints for a building don’t include any provisions for elec-
Alas, the development of information systems has not kept up; trical systems, that omission is obvious. Less so with software
in fact, one can argue that nothing has changed. and systems. For example, what if no one considers the need to
Consider Case Study 7 (pages 290–292). The state of Oregon do something when a client forgets his username or password
wasted more than $248 million attempting to develop an in- and has no record of policy numbers? Software or procedures
formation system to support its healthcare exchange. And very need to be developed for this situation, but if no one thinks to
early in the project, Maximus Company, an independent con- specify that requirement, then nothing will be done. The sys-
sulting firm that had been hired to provide quality assurance, tem will fail when such a client need appears.
warned that requirements were vague, changing, and incon- And how do you know the quality of the requirements
sistent. Those warnings made no difference. Why? statements? A requirement like “Select a qualifying insurance
policy for this client” is written at such a high level that it is
Why Are Requirements Not Managed? useless. One of the reasons for building a prototype is to flush
In 1974, it might have been that managers were computer il- out missing and incomplete requirements.
literate and thus couldn’t know how to manage requirements.
However, everyone involved in Cover Oregon has a cell phone Assess Feasibility and Make Trade-offs
and probably an iPad or Kindle, so they are hardly computer il- But there’s more we can learn from this example. All of the
literate. So today, at least, computer literacy isn’t the problem. state and federal healthcare exchanges needed to be operating
Does the problem of managing requirements lie with man- by October 1, 2013. So, the schedule was fixed with no chance
agement? Or with requirements? In Case Study 7, you learned for an adjustment. Considering cost, while funds were not
that Access CT, the Connecticut healthcare project, succeeded. fixed, they were not easily changed. The states initially pro-
Was it because the project was closely managed by the lieu- vided some funding, as did the U.S. government. Once those
tenant governor? A woman with future political ambitions? financial allocations were made, it was difficult to obtain more
Oregon has no lieutenant governor, but surely there was money. Not impossible, but difficult.
someone to manage the project. One indication of manage- Examine Figure 12-19 again. If schedule is fixed and if fund-
ment problems in Oregon is that the information system was ing is nearly fixed, what is the one factor that can be traded
to be used by one healthcare agency (Cover Oregon) but off to reduce project difficulty and risk? The requirements.
developed by a different healthcare agency (Oregon Health Reduce them to the bare minimum and get the system run-
Administration). The two agencies fought battles over require- ning. Then, after some success, add to the project. That seems
ments. Due to lack of senior-level management, not only were to be the strategy that Access CT followed.
requirements unmanaged, they were fought over by two com- But this principle exposes another of the problems in
peting governmental agencies. Oregon. It wanted everything. It embarked on a policy called
9
That might be the prime cause for Cover Oregon’s failure. “No Wrong Door,” a policy that would leave no person nor
But is there something else? Even in well-managed organi- problem behind. Cover Oregon should provide a solution for
zations, is there something about requirements that makes all. Such statements make wonderful political messaging, but
them hard to manage? Fred Brooks provided one insight if the schedule is fixed and the funding is nearly so, how are
when he said that software is logical poetry. It’s made of pure those goals to be accomplished? Tell your roommate that you

9 Maria L. La Ganga, “Oregon Dumps Its Broken Healthcare Exchange for Federal Website,” Los Angeles Times, April 15, 2014, accessed June 14, 2014,
www.latimes.com/nation/politics/politicsnow/la-pn-oregon-drops-broken-healthcare-exchange-20140425-story.html.