by Don Jones

I’ve long been a proponent of solidly-written, detailed requirements for any IT project, and especially for application development. I hate being given a vague set of requirements, writing an application or designing an infrastructure to meet those requirements, then spending forever in revisions “fixing” things that weren’t ever communicated to me in the first place. Measure twice-or thrice, even, and cut once-meaning “spend some time coming up with requirements, then just write to them.”

But I get a lot of pushback from people when I talk about that, because many folks in IT have been through the “infinite requirements gathering” cycle, where people spend an incredible amount of time trying to come up with an absolutely complete, absolutely correct, absolutely definitive set of requirements. So much time, in fact, that the requirements actually change while they’re still gathering them, and the project never formally gets off the ground. Everyone gets frustrated and vows to never do it again. Until next time, of course.

So how do you manage a requirements-gathering phase so that you’re not trying to come up with some kind of Ultimate Unified Business Theorem? Simple: Change your development approach.

The oldest and most easily-understood development methodology is commonly referred to as Waterfall. It’s a straight-line, simple process that usually starts with requirements gathering, moves on to writing detailed functional specifications, moves into development, then moves into testing and deployment. Major, huge software companies-like Microsoft-have worked that way for decades, and in most cases, continue to do so. In fact, to offer a non-technology example, that’s exactly what the US Congress attempted to do in late 2009 with their groundbreaking healthcare legislation. With 2000 pages of rules and requirements later, the House and Senate still couldn’t agree on the Ultimate Perfect Health Reform Plan.

And that’s the problem: When you’re dealing with huge tasks, trying to wrap your head around all of it at once can be frustrating and even futile, whether it’s healthcare reform or a corporate line-of-business application. Even Microsoft-stinging from the market perceptions of Windows Vista after a long, 5-year development process-is taking a hard look at the traditional Waterfall approach.

So what are the alternatives? Smaller chunks. Don’t set out to solve every problem your company has in a single application. Instead, address one small piece of the problem. Even if that piece will never be fully used in production, that’s fine-solve it, get it working, then move on. Acknowledge that there will always be subsequent versions and revisions, and embrace that as part of the process. From a health-reform perspective, acknowledge that whatever is in the first bill will be inadequate and problematic; get something smaller and solid out the door, then immediately start working on the next round of revisions and expansions. In the software world, this concept is called Agile Development. Numerous software development methodologies, such as Extreme Programming, derive from Agile, and their premise is simple: short development cycles, small feature sets, short list of requirements. Get it out the door, and start working on the next round immediately.

Let’s put this into a real-world business context. Say your company wants a brand-new application to handle incoming orders, customer records, marketing campaigns, and so on. Don’t tackle all of it at once: You’ll either get a quick-and-dirty, incomplete set of requirements, or you’ll spend the rest of your life gathering requirements from all the stakeholders in the Ultimate Corporate Application. Instead, focus on one small bit. Work out a new order-entry application. Maybe it will talk to an older back-end database, or maybe you’ll have to do some side work to integrate old and new databases, but focus on just a piece of the puzzle so that the realm of requirements is smaller. Gather those requirements, and write a first version of the application. Get a few people to pilot it-even if it’s not “for real” production. Most people can do a better job of providing requirements if they have something to touch and beat up on; give them that, then gather the next round of requirements for improving the application. The next version can go into wider use, where you’ll gather yet more requirements for the next revision. Keep those revision cycles as short as possible, time-wise.

You’ll never stop doing this. The company’s requirements will change, and by being Agile, you’ll be able to work new and unforeseen requirements into the application in a much more timely fashion-without having to wait for the next 5-year cycle. The application will always continue to evolve-in slow, deliberate increments, driven entirely by business needs.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.