RISE – Requirements Improve Solution Effectiveness

Prior to coming on-board as an application analyst at GLWA, I would spend 20+ years helping organizations define requirement strategies and requirements for applications that we built. 

Now that I have “driven” out of the automotive industry and “dove” into the wonderful world of Waste Water Recovery where solutions are predominantly purchased, I’m finding that teams report on similar problems with their procured applications. 

Requirements elicitation is, as often as not, treated as a necessary evil. Stakeholders feel forced to spend time completing this work upfront to check off a task on a project plan. The work is treated as though it was not important enough to impact the design, development, test, and launch activities and timeline. 

One can imagine the results of elicitation are often mixed at best, as unpredictable as throwing a handful of candy up in the air in front of a group of kindergarteners; you never know what you’re going to get.  Finger pointing ensues, with quite a few internal and external bruises to show for it. 

We don’t plan to do it right, but we have time and money to do it twice?
~anonymous

When a company builds an application off of the results of a poorly defined requirements process, costly issues are quickly resolved regardless of the implementation methodology used (waterfall or agile) –  blame is assigned and money is found to address the issues raised.

However, when a company buys a solution, the situation is quite different as there is a total reliance on the product vendor and their development path. In some of the worse cases, the organization has to start the vendor selection process over completely when the solution fails to address the needs.  More than the budget can be damaged in these cases. 

The risks are arguably greater when purchasing vs. building an application, but the underlying fault in both cases is frequently the same.

Too often solutions are determined prior to understanding Business Requirements

For both built and purchased applications, project initiation often happens before discovery, putting the cart before the horse.  Would an architect allow construction to begin on a building before every plan was drawn, reviewed, and approved?  No, but often companies are influenced by what they are familiar with, such as the applications employees have used in the past or by what an employee hears is the next best tool/toy.  In the world of purchased applications, companies often select the design/tool and then attempt to make their business needs fit the solution.  They want the requirement process to be quick and easy, but they are really just setting themselves up for disappointment. 

Making a conscience effort to elicit requirements prior to selecting a solution enables identification of the following:

• Problems to be solved
• True business needs
• Organizational impacts
• Goals and objectives
• CARD considerations (Constraints, Assumptions, Risks, Dependencies)
• Feasibility
• Cost

Requirements, for applications both built and purchased, should feed the business case, which in turn informs the purchase, contracts, project charter, project plan, test plan, test cases, implementation, and project closure needs.  When requirements come first, the rest of the project deliverables are executed more smoothly, with fewer errors and increased customer satisfaction.  Reduced rework and lower cost positively impact a company’s budget and resources, but more importantly improves its ability to address other business problems within the organization faster.

Quality requirements enable IT to focus more on project delivery and support, which in turn nurtures IT/Business and customer partnerships.

Guiding an organization toward a more efficient requirements process does not happen overnight.  The IT PMO, working hand-in-hand with IT and the business customers can get us there given enough support, time, and patience introducing:

• A defined project intake process (with full Business Requirements)
• Accepted elicitation techniques (process flows, use cases, etc.)
• Accountability for requirements through the procurement and project management lifecycles
• The use of tools, such as an enterprise requirements management tool to facilitate ongoing collaboration on the requirements

In short, Requirements Improve Solution Effectiveness, therefore RISE to the Occasion!