Kelman: It's all in the requirements

What makes successful IT projects? For many, it's obvious.

In one of my recent blog entries, I asked readers for their ideas about the one change government and industry could make that would most improve the success rate of large information technology projects. I got many interesting answers — readers might want to check out all the comments — but one idea won a solid first place for the highest number of votes. Readers
said, “It’s the requirements, stupid.”

One reader wrote, “Guys, the name of the game is requirements management. You need to draw a line in the sand. Design a solution for the requirements that are validated by the customer. Save all new requirements for the next release.” Another wrote:  “A successful leader I know said, ‘Start with the end in mind.’ It certainly has worked for me. You need a clear, documented, well-understood vision that is properly subdivided and clarified over the life of the project.” A third commenter said that the Office of Management and Budget “could do the government and the American taxpayers an immense favor if it required any project over some amount — say, $10 million — and some time period — say, three years — to have a requirements definition that passed peer review by a group assembled from a pool of experienced government project managers.”
And finally, there was a three-word plea:  “Control requirements creep.”

It has always struck me as penny-wise and pound-foolish for people to be so anxious to quicken the procurement process that they give too little upfront attention to establishing requirements for what they plan to buy. People typically offer poor reasons for not giving requirements the attention they deserve.

One such reason is the argument that requirements will always evolve as users get a better feel for what they want after they begin using a new application.

That’s a good argument for successive releases. It’s also a great argument for getting Release 1.0 up and running quickly.

A second reason offered for shortchanging the requirements phase is that developing requirements is hard, and people prefer to put off the pain. But if the government doesn’t bite the bullet, the pain gets worse later.

The bottom line is a variant of the old saw that if you don’t know where you’re going, any way will get you there. However, for IT projects, if you don’t know where you’re going, you’ll never get there.

Requirements definition is closely related to performance-based contracting. Whenever possible, and to the fullest extent possible, requirements should be presented in performance terms.

Our community needs to develop a sense of urgency about improving the success rate of government IT projects. We can’t promise the moon.

Large IT projects often are inherently difficult, even with good requirements. Ambitious IT projects often fail in the private sector. The government is not unique in this respect. But we should be doing better than we are. In a world in which people intensely scrutinize the dollars that the government spends on IT contracting, we must do better.

Kelman is professor of public management at Harvard University’s Kennedy School of Government and former administrator of the Office of Federal Procurement Policy. He can be reached at steve_kelman@harvard.edu.

Featured

  • Congress
    Rep. Jim Langevin (D-R.I.) at the Hack the Capitol conference Sept. 20, 2018

    Jim Langevin's view from the Hill

    As chairman of of the Intelligence and Emerging Threats and Capabilities subcommittee of the House Armed Services Committe and a member of the House Homeland Security Committee, Rhode Island Democrat Jim Langevin is one of the most influential voices on cybersecurity in Congress.

  • Comment
    Pilot Class. The author and Barbie Flowers are first row third and second from right, respectively.

    How VA is disrupting tech delivery

    A former Digital Service specialist at the Department of Veterans Affairs explains efforts to transition government from a legacy "project" approach to a more user-centered "product" method.

  • Cloud
    cloud migration

    DHS cloud push comes with complications

    A pressing data center closure schedule and an ensuing scramble to move applications means that some Homeland Security components might need more than one hop to get to the cloud.

Stay Connected

FCW INSIDER

Sign up for our newsletter.

I agree to this site's Privacy Policy.