Internet Explorer 11 is not supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Failure and the Big IT Project

"Continuous upgrades are no longer an option." On this, the governor, the leadership of the West Dakota General Assembly, the Zenith City Tribune and your staff all agree.

"Continuous upgrades are no longer an option." On this, the governor, the leadership of the West Dakota General Assembly, the Zenith City Tribune and your staff all agree. The West Dakota Department of Social Services needs to replace its computer system for child-support enforcement.

But how? How do you, as secretary of social services, create this new system? Everyone has different ideas. You've talked with the CSE people to get their ideas about how the new system might work. And you've talked with the information technology people in the Department of Administrative Services to get their ideas about its potential capabilities.

And from these conversations, you quickly recognized something: The thinking of the program people doesn't mesh with the thinking of the IT people. The language doesn't mesh. Indeed, nothing seems to mesh. How could these people ever work together?

From your conversations, you have emerged despondent and worried. After all, if you learned anything about big IT projects, you learned that you need to involve both the program people and the IT people. You can't do the project without either the technical expertise from IT or the substantive expertise from CSE. The two have to work together.

You know this because Social Services has been burned before. Just a few years ago, it had to eat the IT contract for its welfare-to-work program. The team of policy experts on welfare, job training and employment had been unable to clearly articulate what they needed the system to do, and as the project evolved, the program team's tendency to expand the scope of the requirements and expectations frustrated the IT people. Conversely, the IT team had been unable to explain the operational advantages and disadvantages of the different overall strategies for the system. And the IT team's tendency to talk in its own unique language of "architectural modularity" and "interfacing applications" frustrated the program people.

Finally, the department's in-house counsel thwarted everybody by insisting that the contract go to the lowest bidder. This contractor failed to deliver, and many of West Dakota's welfare recipients lost their benefits prematurely, while others seemed to receive checks in perpetuity.

You are determined to prevent that kind of disaster from befalling the new child-support-enforcement system. But how will you prevent such a disaster? How can you get the touchy-feely social-service types to work collaboratively with the glow-in-the-dark techies?

This project is not only big financially and programmatically. It is also big politically. Everyone in the state knows that Social Services has to fix its CSE system. Everyone is watching to see how you will handle it--to see IF you can handle it.

If you can't pull off the new CSE system, Social Services will feel the effects for years: Morale will plummet, and so will recruitment. The budget will suffer, and so will other programs. When you retire and they hang your picture in the department's conference room, it will be on a dart board.

You learned some other lessons from the failed welfare-to-work project. Indeed, creating a new IT system for child-support enforcement presents many of the challenges that frustrated that effort. Both are intergovernmental programs to which the U.S. Congress and the West Dakota General Assembly make periodic (and unpredictable) policy revisions. Thus, the CSE system has to be sufficiently flexible to accommodate these inevitable legislative changes.

At the same time, you are determined to resist mission creep. You recognize that the pressures are inevitable--particularly as the program people learn what the IT people can do and the IT people learn what the program people need. You know that mission creep can morph into deadline runaway, which can be the death of the project.

Indeed, you learned that for any big project--not just big IT projects--you have to establish not only a final deadline but also interim milestones. Then, you need to tie your periodic vendor payments to the achievement of these specified milestones.

Finally, you learned with projects this big, you need a second contract. Neither your agency nor the Department of Administrative Services has the capacity to adequately monitor the proj-ect. Thus, you need to contract with another firm to independently monitor developments, evaluate progress, identify problems and recommend remedies.

Such steps, however, come later. Right now, your challenge is to launch the project by getting the program people from child support and the IT people from Administrative Services to work together to create an overall framework.

From Our Partners