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.
