The Problem with the Waterfall Deployment Methodology

When looking at your software deployment methodology, it’s important to consider who developed it, and why.

It’s really interesting to contemplate why the methodologies being used by major organizations to deploy major applications, be it SharePoint, ERP, CRM, Business Intelligence or other solutions, are all based on methodology designed by the software vendors.

That fact alone makes current standard software methodologies somewhat suspect. The standard methodology is designed to have you, the client, buy the software first and THEN go into functional requirements and detailed design. It’s designed to have you make a purchase before you have all the necessary information. It’s what I call the waterfall deployment type – starting at the top and free falling to the bottom with little to no control on the way down. This is asking you to start with the largest, most significant decision, and then work out the details later.
Let’s think about that for a moment.

You’re going to buy software somewhat blindly, and once you have paid for it, you’re going to look at your functional requirements and see how well they match that software. With any luck, the software you bought will help you solve the issues in your business you later uncover.

The methodology is designed this way for a reason. This allows the vendors to sell software more easily, and with less risk. It’s significantly easier to convince you to buy software by regaling you with tales of all it can do, when you’re considering features and functions in absence of your actual requirements. Once you’ve been dazzled by the demo and bought the software, you have absolutely no choice but to make it work for you, whatever that takes.

Sounds like a winning situation for the vendor, not the customer.

Starting with software selection then moving into functional requirements doesn’t even seem logical, yet that’s how a majority of software implementations are sold. We believe this methodology contributes significantly to the staggering number of implementation failures and over-budget projects.

At Rand Group, we look at software selection from the perspective of a professional services firm, and give you advice on how to buy before we advise you on what to buy.

To start, you need to identify your business strategy, determine what business models you are addressing, and define your business architecture. Thoroughly consider what business problems you’re trying to solve, and make a high level list of the features and functions your solution has to have. Also consider the data architecture design, integration architecture design, and other elements of how your business currently works, and how you’d like it to operate moving forward.

You really need to look at the business today, and decide what you’re willing to change, what you want to change, and what you’re not willing to compromise on. Only once you’ve really examined your current state and future interests, should you move onto software selection.

No software solution is going to fit your needs exactly. Most will only solve 85% of your problems, so it’s up to you to identify the most critical business issues, and ensure you’re solving the right 85%.

This is why the Rand Group approach is different from any other software methodology used by major vendors today.

Our solution has been to move the functional requirements phase UpFront in our methodology, starting there before we recommend or select software. This allows for 2 things to happen:

  1. It improves project success rates: Outlining needs and wants, and performing a thorough information gathering in advance allows you to make the right choice in software before you spend any money or cycle too much time. Making a properly informed decision seriously diminishes risk, as well as budget and scope creep.
  2. Full Disclosure: Through the functional requirement process, we may help you determine that there is not a high enough ROI to warrant the project. By detailing a plan in advance of purchasing the software, it may become clear that there is a better approach to resolving the issues. Conversely, you may discover that there is more significant or valuable work to be done in advance of a major software purchase, that would impact the software you should select.

You certainly don’t want to spend hundreds of thousands of dollars to find that out, and be stuck with a software solution you don’t need, or worse, that doesn’t work for you.

It’s up to you to make your own decisions about software, but Rand Group is here to help. We believe that solving your business issues is the most important thing we can do, and only sometimes does that include a major software purchase. If you’re contemplating an ERP, CRM, SharePoint or other major software solution, I suggest thinking about the logic in buying software in advance of requirements planning. From where I’m sitting, buying software before performing your due diligence work doesn’t make any sense. Does it seem logical to you?

– Software Delivered as Promised. No Surprises.

Latest Posts