Bring Your Requirements Practices out of the ‘80s

What are you hanging on to? What do you need to purge from you project closet? Still fond of the requirements equivalent of MC Hammer parachute pants, jackets with shoulder pads, stirrups, acid wash jeans or jelly shoes?

If you’ve been using the same requirements approach since banana clips, and popped collars were all the rage, then you might not realize your processes are outdated. So, just like my old Teen Beat magazine, here’s a little quiz:

  1. Do you find yourself trying to document everything perfectly before reviewing with stakeholders?
  2. Do you find yourself defining the current state in the finest of detail before working on the future state?
  3. When you need some ideas for requirements models, do you pull out the big three-ring binder from your BA training or methodology training from 1989?
  4. Does your team still call it “Requirements Gathering”?
  5. Is scope creep and changing requirements the evil sins on the project? Do you do everything in your power to avoid them?
  6. Does your team have a strict/elaborate/red-tape-filled change control process?
  7. Do you need to write specification level details that developers can code from—telling them exactly what and how to code it?
  8. Do you need completion/approval of text-based templates before projects can move forward?
  9. Does your requirements approval process include multi-hour review sessions where stakeholders review lists and paragraphs of requirements line-by-line?
  10. Are requirements are prioritized by first-in, first out (for those working on enhancement lists)?
  11. Are ALL requirements the HIGHEST priority (for those working on projects)?
  12. Does the QA team need user interface detailed design to start with test planning?

If you answered yes to any of these questions, it’s time for a little spring cleaning. Let go of the old practices that slow your progress. Make room for a few new things. Modernize your requirements process!


{module ad 300×100 Large mobile}


But why? If your current process seems to be working just fine, why would you change?

Skepticism and cynicism are understandable. You’ve seen dozens of methodologies, approaches, tools and techniques come and go and come back again, just like neon, leg warmers, and fringe. Your process is like the classic black suit or basic black boots—timeless—right?

Yes, there are obviously foundational pieces of requirements management that will stand the test of time, but some mindsets, techniques, and processes require a modern twist. Here are a few items you should consider removing from your project closet:

Outdated Mindset: Scope Creep and Change are Bad

Change has transformed from preventable/bad to expected/good/healthy. The pace of change seems to be increasing rapidly. Changing requirements can mean many different things:

  1. We missed the requirement earlier. (This is probably still bad and preventable.)
  2. Stakeholder thoughts about the future have evolved through the process. This is expected and good! It means stakeholders are engaged in meaningful dialog, and they are thinking critically. They want to maximize value for the end-users and the organization. So, when your stakeholders seem to “change” their mind, try to reframe the change as an evolution or discovery of thought that is making the solution better than previously thought of; ultimately making the organization better off.
  3. External or uncontrollable factors create change. Obviously, these changes can be blessings or curses, but they are expected in most industries. The increasing pace of change trickles down to our projects. We need to accept and embrace these external forces to be better than our competitors and serve our customers.

We can’t prevent change, and we must be adaptable. If we keep thinking change is bad, we will waste the organization’s resources and create uninspiring solutions.

Outdated Approach: Finish Requirements Before Experimenting or Prototyping

Experimenting and prototyping should not wait until a “build phase” after requirements. Instead, use experiments and prototypes to elicit and refine requirements.

As the complexity of our organizations increase over time, prototyping and experimenting become more important. Unknowns, ambiguity, and risk drive project teams to “try stuff out” before building and/or buying. As BAs, we need to identify the high-risk features that are most likely to change and use experiments and prototypes to get to clearer requirements. It is okay that our stakeholders do not have all the answers, many times an experiment or prototype will show them what they need to clarify their requirements.

Outdated Practice: Detailed Technical Specs

Do you find yourself writing detailed technical design specs that developers use for coding? If so, ask yourself if they help or hinder your process. Here are my concerns:

  1. Developers and their team (Tech Lead, architects, etc.) should be able to take relatively technically agnostic requirements and provide options and alternatives that meet stakeholder requirements.
  2. If you write technical specs without getting a shared understanding of the business requirements (sans technical details), will you really meet the needs of your end-user/customer? Your stakeholders are not experts in technology. They think they know what they want, but their narrow viewpoint may limit the solution. This approach might introduce risks and constraints that diminish potential value. It’s normal for stakeholders to express requirements this way, but it’s our job to reframe the requirement so that the technical team can use their expertise to bring options and alternatives to the table.

Outdated Process: Shared Understanding Through Text-Based Templates

Say goodbye to the days of multi-hour meetings to review and approve giant requirements text templates, line…..by……line. Was this ever a good practice? I would say no, but many organizations take this long, slow and painful path to shared understanding because they don’t see an alternative.

But there is an alternative and it’s faster, with a better end result. Develop shared understanding iteratively through engaging conversations, structured workshops, and collaborative games that focus on:

  • Who (actor/user role group)
  • What (action the user group performs with the solution)
  • When (in what flow of other tasks, and under what conditions)
  • Why (why must this user perform the task)
  • Visuals for context
  • Matrices for detailed rules and logic
  • Non-Functional Requirements (System and feature level)

Then, after you reach shared understanding, you can complete your templates if needed. (I find that most organizations have trouble letting go of their templates, just like I can’t seem to part with my old Walkman and my rainbow colored hair scrunchie collection.)

Have you recently eliminated an outdated requirements practice? If so, let me know what and why in the comments below.