Fade to a conference room in a large, successful company. I’m talking with several business leaders about an upcoming project with critical strategic importance. The conversation turns to several past projects that failed to deliver expected results, and they outline the reasons they believe some projects fall short of expectations:

	IT just doesn’t seem able to deliver what we need when we need it.
	Our projects take too long, and they deliver less functionality than we want.
	We often settle for “phased” implementations, hoping that phase two of the project will give us what we really wanted in the first place.
	Phase-two projects rarely get done: new projects rise to the top of the priority list, pushing phase-two items down to the bottom, where they typically remain—forever.

Cut to different conference room at the same company where I’m speaking with key IT staff. Their outline of past project experiences:

	Product/business people never seem to be able to make up their minds about what they want.
	We scramble to deliver what they asked for, yet they still aren’t satisfied.
	It seems like their real business requirements only come out after we’ve designed, coded, tested, and implemented a project.

Much like the different versions of the crime in “Rashomon,” these comments reflect distinctly different perceptions about the same projects at the same company. But this is where the similarity ends. While “Rashomon” leaves us to ponder the vagaries of truth and human perspective, the reason so many projects fall short of the mark is not so ambiguous.

CIO magazine summed up the problem in its November 15, 2005 issue: "Analysts report that as many as 71 percent of software projects…fail…because of poor requirements management, making it the single biggest reason for project failure.”

Well-documented business requirements that specify what must be accomplished are as necessary to a business project as a blueprint is to building a new home. Imagine workers lining up to dig or pour fittings for your new house. Now imagine them doing this without the benefit of detailed specs defining location, depth, and so forth. Doing this to your home can lead to cracked walls. Doing this to a major project can lead to problems that are far more costly.

We all know this—it just makes sense. Nonetheless, many companies undertake large, mission-critical projects without clearly defining the business specifications for what is to be constructed and implemented. This is not to say that companies don’t work on business requirements. They work, and work, and work on them. Regrettably, the documents they produce often miss the mark.

Helping people figure out what needs to be done, helping them document it in a way that is easy to understand, and using that document as a blueprint for technical design and construction is at the heart of managing successful projects. And it’s the only way to bridge the sometimes enormous—and unnecessary—gaps that can arise between business and IT people working side by side on projects.

The Key: Start at the Beginning and Work Through to the End

Every process has a beginning, middle, and end. Taking the time to elicit and document business requirements following the entire cycle from front to back is a logical way to capture requirements. But taking a front-to-back approach alone won’t ensure complete requirements, and here’s why. Too often, the people who work on the initial steps of the process are not fully aware of the downstream impacts of their processes and decisions. If the middle and end process requirements are done later by different people, it’s highly likely that all the pieces of the puzzle won’t fit together. That’s one reason requirements seem to change far into the technical design phase: by the time new requirements are identified, significant re-work can be needed. All of which adds time and cost and often turns a project into phase-one now and phase-two later.

The solution is simple: Pair a cross-functional team of business experts with their IT counterparts. Ask the entire group to start at the beginning and work their way through to the end of the life cycle, capturing, documenting, and validating clear requirements. The requirements should be ones that everyone understands, are easy to turn into technical specifications and test plans, and so on. This once-and-done approach dramatically reduces project risk by eliminating guesswork, accelerates speed to market, and significantly improves the quality of results. It is also the only proven way to make sure that business and IT are on the same page.

But persuading an organization to commit the full complement of experts needed to define requirements up front can be a challenge. Of course, if poor project requirements result in problems and gaps in the long run, the inevitable re-work will involve far more people, time, and money. Come to think of it, Kurosawa may have had the right idea after all. It’s all in how you view the situation. Take the time to get the requirements right, or be prepared to spend more time later fixing your cracked walls.