Planning your IT Adventure: Agile or Waterfall?

First, let’s start out with a slightly different question: how do you plan your vacations?

Many of us use the traditional approach. We set specific “requirements” (beach vs. mountains, rest and relaxation vs. new adventures, and so on). Then we spend hours on the Internet researching and fantasizing about our options. We compare locations, features, advantages and disadvantages. We check social media, search for the best deal, and lock it in. After evaluating our options and making the final choice, we congratulate ourselves for getting a bargain and sticking to our budget. There’s a huge advantage in knowing from the beginning exactly what we’ll get, and at what cost. The vacation countdown begins in earnest.

Then something happens to plant questions in our minds. Friends are full of suggestions, such as better hotels and activities we hadn’t considered. We can change our arrangements, but that will cost extra. Of course, no matter what the destination, there are risks—lost luggage or having to evacuate Vacation Paradise due to a hurricane. But then we remind ourselves that even with the risks, we more often than not have a great time.

Another approach requires less up-front planning. We can rent a recreation vehicle (one with a GPS, of course) and set out on the road trip of a lifetime. Once on the road, we regularly adjust our itinerary of landmarks, historic sites and other places of interest. To make the most of each day, we map out our destinations for that particular day. If a fellow vacationer or in-the-know local leads us to a special place not on our apps and maps—a unique antique store, an amazing waterfall or another traveler’s treasure—we add it to our list of objectives. If the weather doesn’t cooperate one day, we skip outdoor escapades and explore a fabulous new museum instead. When we run out of time and/or money, we head home. Even if we don’t achieve all our objectives, everything has been new and fun—and worth the trip.

These two approaches are analogous to two major solution implementation methodologies. The traditional approach is frequently called the waterfall methodology. We spend a large amount of time determining requirements and laying out the plan. We document the expected end state in detail and use it to justify the budget request. We know exactly what we hope to get for our money.

The issue with the waterfall methodology is that it’s not very flexible. Sure, we can manage change to adjust to new requirements, but we frequently incur additional cost. Risk management also becomes an essential skill. We may spend time and money implementing requirements that turn out to be unnecessary. With a long-term implementation, the business environment often changes so much that the final outcome we originally planned for ends up being suboptimal.

Approach #2, often called the agile methodology, is gaining popularity. We have a general roadmap with specific major objectives, a budget and a timeline. We may not achieve every objective, but we’ll very likely pick up capabilities along the way that we didn’t even consider at the outset. With this methodology, we can deal with unforeseen risks more easily and adjust more quickly to changes in the business environment. The issue with this approach: we don’t know where we’ll end up until we reach the journey’s end.

I’m not here to advocate one methodology over the other; each has advantages and disadvantages. What I’d like to suggest is that we weigh both methodologies when approaching an IT project.  When considering the deployment of a new solution, one aspect of planning should be deciding which methodology presents the least risk and the best value.

While an IT project can’t ever be called a vacation—or even a walk in the park—the right approach can make all the difference. Let’s find out how our community approaches projects—and why. How do you determine your project methodology? I’m very interested to hear your thoughts, and encourage you to share them in the comments section below. I’ll report back on the findings.

Article source: CA PPM Blog

Tags: , ,

Leave a Reply

Skip to toolbar