ARTICLES

IT Spotlight: Works as Designed, But Not as Needed
By David DeWitt, NueVista ERM Practice Leader

The IT project was delivered on time and within budget. The discussed solution was designed, built, tested and implemented. Sign offs were received at each point in the project and the business approves installation. At this point, IT concludes that the project is a success, but the business team doesn't agree for very long and here’s why: As they use the system, critical business needs still aren't met. IT responds with, “The system works as designed; any additional work will require a scope change or new project.” The business then asks questions such as, "Why wasn't this caught in testing?" and "Didn't you check with field operations?"

Does this sound familiar?

Unfortunately, this scenario occurs more frequently than it should. Whether it’s a system implementation, upgrade or integration project, business stakeholders are frustrated when technology doesn’t perform as expected. From the solution provider’s perspective, the system works exactly as requested. Neither party wants to accept responsibility for a costly solution that doesn’t meet stakeholder needs or generate the anticipated return.

How can you avoid this all-too-common fate?

Instead of playing the blame game, savvy organizations have realized the fault is often in the process, not the people, and they are addressing the problem at its root cause the requirements definition process. According to CIO Magazine’s article “Fixing the Software Requirements Mess”, poor requirements management is the cause of more than 70% of IT project failures—greater than bad technology, missed deadlines or change management errors.

An effective requirements definition process is collaborative, interactive and analytical. It requires participation of all key stakeholders, including appropriate functional, technical and/or business personnel. (If the people doing the planning are not the system users, or don’t understand the context of its use, it’s highly unlikely the solution will meet its intended use.) In addition, the solution provider (IT or external vendor) must use effective questioning techniques and strong problem solving skills to uncover root causes of the requestor’s challenge and investigate viable solutions. The result will be a mutually agreed upon solution approach, one that results in a system that works both as designed and as expected and generates anticipated ROI.

Top tips for ensuring IT solutions meet the business need – and customer expectations

Below are seven proven ways to strengthen the requirements process:

1. Invest time up front in the requirements gathering and analysis process, where it’s much cheaper to eliminate a “need” than realizing it isn’t cost effective downstream in the design, development or application stage.
2. Train your users to be specific when presenting a requirement. You cannot evaluate requirements until they’re precise and complete and you understand why they’re important to the business.
3. Make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you’re expecting. Will the benefits of the proposed solution justify the cost?
4. Involve the appropriate constituents in the process and facilitate ongoing communications among them.
5. Carefully manage expectations. When a user asks for something that is not possible, feasible or within budget, say so. Unmet expectations foster dissatisfaction.
6. Consider bringing an objective outsider into the process. Too often, requirements documents describe the proposed solution, which might not be the best, or most cost effective, approach. An external expert will ask the tough questions needed to ensure the validity and viability of a requirement.
7. To save time and re-work in the event the request resurfaces, maintain ongoing documentation to track why projects are denied