Skip to main content

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part III

Written by Cynthia Low on . Posted in Articles.

Getting to the Right Amount of Requirements Management

Choosing appropriate requirements management processes is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. On some projects, following a great deal of rigor is required; on others little is. Scott Ambler, a proponent of the Agile approach, stresses the importance of “just-in-time JIT requirements elicitation.” Alan Davis supports “Just Enough” approach.

Some of us remember the pre-process and pre-methodology chaos of the 1970s. It was not uncommon for developers to sit down by themselves or at best with a single “user” to hammer out features of a new piece of software. Those of us who lived through that time remember some of the issues of the “users” who articulated their own needs, but who didn’t represent all the stakeholders. Or management who pitted one developer against another to try to get the software developed sooner, or the developers who dictated to the business what was in and what was out of scope.

Nevertheless, too much rigor can become overly-burdensome. Here are some pitfalls to avoid:

  • Misaligning the amount of rigor required with the size of the project with. One example of misalignment is having inappropriate levels of approval, such as requiring a formal Change Control Board for a small, well-understood, low-impact, and well-accepted change. 
  • Developing a requirements management plan that takes more time to create than developing the product • Requiring the creation of a requirements management plan “because that’s the process we follow here.” 
  • Handling all projects with the same degree of requirements management.

The “right” amount of requirements management occurs when there is enough rigor to: 

  • Reduce business and product risks 
  • Communicate effectively with all stakeholders. Communications becomes more complex with more stakeholders, so formalizing the communications on larger, more complex projects is usually appropriate. 
  • Help ensure that a quality product is delivered at the end of the project. 
  • Ensure the production environment is not jeopardized during deployment.

To this end, some applications of requirements management may need more emphasis than others. For example, one of the authors of this article was the project manager on a new retail application where the risk included the possibility of having incorrect prices on all the items in all the retail store locations. The project team spent several months planning traceability, testing, implementation, risks, communications, and other aspects of requirements management, and we implemented a three-year project within days of the projected date, only to have performance so poor, that holiday sales were in jeopardy. She also managed a project that she thought was “small,” ignoring requirements management completely. The team spent several months in “stabilization,” which was a nice term for cleaning up the mess that had been created.

Negotiating the dates

In all likelihood there will be stakeholders who want to complete the business analysis planning more quickly than seems reasonable. Because business analysis is not always perceived as value-added, some stakeholders will attempt to shorten the process. Here’s an approach to follow: negotiate not the deadline, but the deliverables. Trying to change the projected date is fruitless without negotiating the scope, which is comprised of the deliverables that will be produced. If the sponsor wants to bargain to reduce the business analysis time, here are some tips to try: 

  1. Make sure your sponsor is aware of the requirements process and/or methodology and why it was chosen. This implies that thought has been given to that requirements approach and that it was chosen with care. For example, a sponsor may have heard of “agile” projects and may want to dictate that your project be done “agilely.” Emphasize the benefits of the chosen approach. 
  2. Show the sponsor the deliverable Work Breakdown Structure, which serves as a “picture” of the scope of business analysis work. Explain why each deliverable is important to the project outcome. Give the sponsor a choice of removing deliverable(s), but for each one the sponsor wants removed, explain the risks and impacts of discarding it. You can also recommend which deliverables to remove. The sponsor will appreciate your understanding of the impacts and ability to present alternatives and the associated benefits and risks. 
  3. Be prepared to quickly re-estimate the effort with the removal of deliverables. You will lose credibility if the planning process drags on with iterations of estimating, reviewing, and changing, without solid agreement. 
  4. Be sure to be prepared when meeting with the sponsor. Talk to key stakeholders before the sponsor meeting to understand which deliverables really are negotiable, and which are essential to the end product being delivered. Work with the key stakeholders to obtain as close to a consensus as possible, so that you can present your recommendation neutrally thus truly representing the client perspective. 
  5. Be sure that you absolutely understand the business problem that the sponsor is trying to solve. Any deliverables that do not help in solving the problem should be removed from the WBS. In addition, explain how managing requirements can actually save time. Explain how using requirements management tools, such as the traceability matrix, can save time because it ensures there is a clear linkage between a requirement and the business problem being solved. By tracing requirements we not only help ensure that every requirement adds value, and that every approved requirements will actually be produced, but also that scope creep is less likely to occur.

If during requirements planning new deliverables are uncovered, or changes to deliverables are desired, it will be necessary to modify the WBS, create new tasks, re-estimate the amount of time it will take to produce the new or changed deliverable, and discuss what changes in the schedule are required. Negotiating with the sponsor, as described above, is important whenever there is a change. Sponsors typically want to know what every new requirement will cost, so be prepared with estimates when discussing them.

References: Ambler, S. Agile Modeling, http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm 
Davis, A. Just enough Requirements Management Part 1 http://conferences.codegear.com/article/32301

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com.

Views: 3