Contributed by Thomas Koehler, PMP, CA Technologies
This fall, my daughter started college. As an experienced project manager, I wanted to have a viable set of requirements to transition her from her as-is state (living at home) to her to-be state (living on campus). The various stakeholders—the college, my daughter, my wife and I—each had unique requirements. The school required a long list of purchases. My wife had other requirements (many of which my daughter disagreed with). My only requirement was that all the stuff had to fit into one of our cars so I didn’t have to rent an 18-wheeler or make multiple trips.
Then there were my daughter’s requirements. One item on her list was a coffee maker. We told her repeatedly that she should wait on that purchase because once she was in college, her priorities and needs would probably change. But she was so set on the coffee maker that she was willing to pay for it with her own money. She did extensive research—just short of sending out RFPs to potential vendors—to make sure she got the best value for her money. After she bought the coffee maker, she used it extensively in the as-is state.
A few weeks after college started, we returned to campus for parent visitation day. As we were touring her room, my attention was drawn to the coffee maker, and I asked how often she was using it. You guessed it: not at all. She had projected the as-is state into her perception of the to-be state, expecting her needs to be comparable.
In my experience, this is typical of so many projects. Our requirements focus in detail on features and capabilities in the current system and how the new solution can replicate them. Often, future-state requirements can be summarized as “exactly as it is today, plus more” instead of finding a better way to do our job using the new solution. We then write these requirements into contracts. It’s a very safe approach, but we miss opportunities for getting more value from the planned solution in the form of improving the entire process.
The bottom line is that in defining requirements for a new solution, we’re often held captive by the limitations of the current state. We don’t think outside the box, and are more concerned with overcoming the limitations of our current solution than with embracing the potential of the planned solution. In reality, we can save time and money by understanding our ultimate business need.
Here’s a typical example: reporting features are often at the top of a requirements list. It still amazes me to see specific report layouts attached to contracts in an attempt to maintain the status quo with the new solution. Let’s take a step back, though: how many times do we use a report as an intermediate step in data extraction? When the current system doesn’t provide the needed data analysis, we download the data through a report into Excel, and then massage it to meet our needs. The real end product—and therefore the actual requirement—is the data analysis, often in the form of pivot tables or charts that provide business intelligence as a foundation for better decisions. That data analysis and business intelligence—not the reports—should be our requirement. If the future solution provides the required data analysis, especially out-of-the-box, why bother with superfluous reports?
How can we overcome this tendency? Here’s a checklist that can help you avoid unnecessary requirements and get the best value from your new solution:
- Focus on use cases: Hone in on the specific actions that specific users must perform to accomplish their work—independent of the way they do it, screen appearance or similar considerations.
- Make sure your project team is experienced with defining project requirements: An experienced project team can help you explore new ways of doing your job and offer alternatives. Of course, that assumes you’re willing to listen to them.
- Avoid the “We’ve always done it this way” trap. Your project manager should encourage stakeholders to leave the as-is state behind and dream about a better way of doing things.
- Learn about the new solution. You selected a new solution because you’re tired of the old solution’s problems and limitations and you want to leave the old solution behind. You will create a better world only if you’re not dead-set on making it work exactly like your old world.
To that last point: its good practice to determine requirements independent of the solution you ultimately choose. Frankly, we care about many things beyond the functional requirements expressed by use cases. We care about “touch and feel” items like screen layouts, the wording of prompts and even color schemes. Those items, while not necessarily functional requirements, will drive acceptance of the solution and, by extension, project success. This is yet another reason that a good understanding of the planned solution is essential during the requirements process.
Good requirements can provide excellent guidance during implementation of your new solution. Bad requirements can doom your project to failure before it even gets off the ground. Make sure your project manager understands that the project succeeds or fails by the requirements, and allow him or her to guide you to success.