1. Requirements are not features. You simply must know what your users must have to do their jobs. Distinguish thoughtfully and carefully between what is needed and what the vendor is offering. At the same time, you must be able to factor into the requirements documentation other considerations, such as budget limitations and regulatory constraints. You will need to train your users how to specify their requirements, which takes tact, training, and patience. A request usually starts with: "All I really need is " and then wanders away. A vague or ambiguous statement -- regardless of its intent -- will consume user time, IT time and cause some other loss, such as the opportunity to do another project. This issue is methodology neutral: Agile methods will have the same problem if user time is not focused and users are not trained. You cannot fulfill the requirements until they're precise and complete and you understand why they're important to the business.
2. Features are not requirements. Eliminate decisions made by squeaky wheels --- sometimes referred to as "design by whine" -- where the loudest department gets the most resources. Your goal is to make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you're expecting. Start by working backward, to match the problems solved with existing software to identify the problems that must be and can be solved only with new software. Don't lose anything you have now that is essential to the business; it's easy to forget "hidden" requirements that oftentimes are taken for granted or ignored.
3. Work with your resources and manage with discipline. Developing an effective requirements document costs money and managing resources requires discipline. A politically expedient decision, even if it's cost effective in the short run but is not the right decision in the long run, will cost time and money -- eventually. From a strategic point of view, ask if the requirements process itself is going to cost more than it's worth. You will find that using the enterprise requirements documentation process will help you avoid useless meetings, which saves time and money, but more about that later. When the appropriate constituents are communicating with each other, they accept the value of their participation because they can track the project's payback to the entire organization.
4. On-going documentation is essential. It's necessary that you continue to manage your requirements, because sometimes internal departments continue to push for a project, application or feature that was denied in the last upgrade or purchase. Perhaps it wasn't worth the cost, or its payback wasn't acceptable to the enterprise as a whole. By maintaining continuity in your requirements documentation, you can see why a prior request was denied. If the reason hasn't changed, it's likely there is no need to investigate it again -- and you can avoid bringing in a "new" solution to solve an equally "new" problem. Referencing prior documentation also can help you eliminate ongoing costs for applications and hardware that are no longer used.
5. Identify and understand the workarounds and desk drawer systems. You need to understand what in your current application made a workaround or desk drawer system an attractive solution. Then, make certain the upgrade eliminates these systems and their causes, with this caveat: You might learn, in the course of such an investigation, that a certain desk drawer system has a unique function or user, and that it's best left alone.
6. Focus your users' attention. You want to learn from them what can be done better, faster or more efficiently, but realize that users don't always know their current business needs. In fact, users at different levels of an organization have different perceptions of business needs, priority and urgency. They tend to segregate by department or management level " dismissing problems because "it's not an IT issue" -- but an effective requirements document requires integration and impact analysis for all departments. Know, too, that the needs of other stakeholders (senior management, operations personnel and human resources, for example) must be considered. User frustration comes from asking for one thing and receiving another; help them articulate their needs carefully and fully. When what a user asks for is not possible, feasible or within budget, say so, because unmet expectations foster dissatisfaction. Always ask what's the relative value of a new "requirement" to avoid spending $10 to save a dime. And don't forget: users take what they have for granted, so make sure it's carried forward in the new request.
7. Benefit from "outside" expertise. An objective outsider, can, will and should ask the questions an insider cannot. What works? What doesn't? What frequent requests create problems because they're difficult to meet with the existing application? That's the outsider's function -- to have no vested interest in how the problem is solved. It's a common pitfall in requirements documentation to describe a problem in terms of its supposed solution -- which might not be the best, or most cost effective, approach. An outsider also can provide useful guidance on how to handle regulatory requirements that affect information systems, but that most business people are not aware of, such as the prohibition against retail businesses retaining credit card numbers after a transaction.
8. Consider your upgrade as an investment and apply metrics to it. A comprehensive requirements document will help you decide if the benefits of the new application or upgrade justify the cost. How much more productive can the organization be with the upgrade, compared to the current application? Track paybacks for projects and information assets to determine when to re-invest or stop further investment. It's possible that an application was a good investment -- at the time. When it was installed, perhaps it saved every one of your 5,000 clerks 30 minutes a day -- but today, you have 5 clerks and it saves them three minutes a day. That feature probably isn't worth the cost. And some stand alone features -- such as desktop publishing -- aren't needed now, thanks to the tools available in word processing applications.
9. Save time. Reduce rework by spending time in the requirements gathering and analysis process, where it's much cheaper to eliminate a "need" than realizing it costs too much (or isn't cost effective) downstream in the design, development or application stage. Time invested in the initial steps of the process provides more time for decision making at the right time. More control of the process will help keep it moving; participants will know what to expect as you move from blue sky thinking to brainstorming to understanding to decision making. Tracking the results of your meetings will document what you've agreed to do and what you've agreed not to do and who made the decision.
10. Save money. To start, you will eliminate ongoing costs for applications and hardware that your requirements information gathering tells you are used no longer. With the right subject matter experts and decision makers involved at the right time, you will not be able to move forward on ideas that sound promising but contain potentially expensive problems that would have to be solved later in the process -- and at a greater cost. You will open many avenues to managing costs, whether it's eliminating unnecessary systems, consolidating a value-added system or evaluating long-term versus short-term value. You might learn, for example, that in the year required to acquire and install a new system the opportunity to use it will disappear. One of the most promising benefits of developing enterprise requirements is the strong possibility you will establish standard solutions to many of your seemingly "unique" problems, obviating the need for custom solutions -- and that can be a real time and money saver.
