Men at some times are masters of their fates: The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings.
—Julius Caesar, Act 1: Scene 2

While sometimes we're loath to admit it, as consultants we control our destiny. Despite applying the latest technologies, working long hours and starting initiatives with the best of intentions, software projects fail. These breakdowns take many forms. Some projects run over budget. Many initiatives fail to meet time-sensitive deadlines; others may fall prey to unexpected technical glitches or a genuine lack of development expertise. Developers criticize their clients for changing specifications. Clients criticize developers for missing deadlines. High-level executives are often left in the unenviable position of playing referee. Most often, however, projects are doomed from the start due to a failure by everyone involved to understand the true scope and nature of "the big picture."

Alright brain, you don't like me and I don't like you but let's just do this and I can get back to killing you with beer.
—Homer Simpson

Understanding requirements takes patience, commitment and an acknowledgment by all parties involved that the problem that needs solving is often completely different from the one that initially presents itself.

Frequently we encounter customers who initially chafe at the notion of paying for a detailed requirements analysis. They feel like they've thought through the problem and can't understand why we can't translate a 10-point bulleted list of requirements into a flat-fee price quote. To help them understand the challenges, I compare the software development effort to building a bridge. The client has identified the need for crossing a body of water. Their functional spec contains the requirements for using steel (choosing CF as a platform): it must carry a certain number of cars per hour (scalability) and it should not under any circumstances fall down (failover, robustness). All other details are subject to interpretation.

As application architects, it's our fiduciary duty to translate these broad requirements into finely detailed blueprints that can be handed off to the construction team. We must perform an environmental impact study to determine how the custom software will fit into a customer's business landscape. How will the site affect different business units? Will supplemental staff be required to maintain content or administer the application? Can we leverage other resources on the Web? Should we interface with databases both internal and external to the organization? Where will the company recoup their investment? What level of end-user or administrator training will be required? How will we measure success? Unfortunately, too many software initiatives charge ahead with arbitrary deadlines, inadequate resources and unclear goals because questions like these were neither asked nor answered. For our part, as developers, we're not immune to this criticism either. Frequently we're too willing to start coding before the appropriate level of specifications has been developed. Many of us lack the patience to sit through a facilitated requirements gathering process, and feel uncomfortable about voicing our reservations concerning designs we feel don't make sense. The involvement of requirements facilitators such as project managers, business process modelers and management consultants proves invaluable.

There's never time to do things right...but there's always time to do things over.
—Unknown

When specification phases are ignored, the inevitable result is that our development process degenerates into a multiple prototype approach. I've seen entire applications rewritten two, three, even four times before the final result is deployed. While not every contingency may be accounted for in the design phase, investing in a rigorous discovery and design phase certainly yields significant efficiencies over the brute force approach from every perspective. We can develop better products in less time for less expense. The process, however, may neither be shortchanged nor underappreciated.

I have fought the fight, and now it's up to others to take the responsibility of leadership.
—Richard M. Nixon

This month we'll witness the introduction of new and exciting technologies at the Allaire Developer Conference. Don't let the challenges of mastering new techniques blind you to the real issue at hand - understanding your client's true requirements. Keep the big picture in focus and you'll never be led far astray.