The Shift to Modern Requirements
I’ve been on the road quite a bit lately, and part of my travels include delivering conference presentations about modernizing requirements.
The presentations hit home with those who are feeling the stress of increasing speed, complexity, ambiguity and change. Trends and transformations related to agile, artificial intelligence, machine learning, robotics, etc., are putting immense pressure on business analysts to build better requirements, FASTER!
This pressure is compounded by the perception that project failure is due, in large part, to inaccurate requirements gathering (2017 PMI Pulse of the Profession Survey). Is this perception a reality? Do we need to adapt our requirements approach?
Shifting to modern requirements practices does not require a major overhaul. Instead, modern requirements are the same best practices shifted slightly, with a change in mindset. Consider these three questions that highlight the differences between “old-school” and modern requirements:
Do you spend more time preparing documents or preparing techniques?
I remember the early days of my business analyst career when my requirements approach was a list of document templates. The same templates needed to be completed, reviewed and approved for every project. My job was to fill in the templates. There was little or no coaching on how to get the information needed for the templates.
Fast forward 15+ years. Now techniques drive my requirements approach. I carefully consider which technique or set of techniques will help me get stakeholders talking, thinking and collaborating. I choose techniques that will create a shared understanding that gives each stakeholder a clear picture of context, user needs, and value.
Then, I only document what is needed to remember the conversation and capture the shared understandings created by the conversation. When teams break their work into small chunks of value and working closely together, then less documentation is needed. Working with small chunks of value is why agile teams tend to document less. Agile teams have a small “work in progress” and small number team members so documenting can seem like a waste to them.
Many are concerned about documenting for audit, compliance, support, etc.—and this is valid. However, I would also argue that the requirements documentation shouldn’t be a document of what was built, rather what the user needs. There should be other mechanisms in place to document what was built.
I am not advocating for no documentation—I am simply putting out there that I believe too many teams are documenting far too much at the cost of missing out on using that time for other strategic projects and work.
Modern business analysts don’t spend time on documentation unless it provides value to the team. Instead, they apply facilitation techniques to help the team learn, experiment and create shared understanding. Modern Business Analysts strategically plan how they are going to use techniques to move the team through the evolution of the requirements from a high level to a detailed level.
This technique-driven approach makes requirements cognitively easy for the team and stakeholders. They have a deep understanding of how their work fits in the big picture. A technique driven approach can more quickly elicit and obtain more accurate requirements.
What do meetings look like?
Meetings look a lot different when a Business Analyst shifts to a technique-driven requirements approach. High impact collaboration becomes the goal of every technique they use. Meetings focus on a high-quality conversation over reviewing documentation. The high-quality conversation comes from high impact collaboration.
High impact collaboration helps BAs and stakeholders get to shared understanding faster. The quality of requirements also improves, because we get beyond stated requirements to the real needs of users.
Here is a comparison of low impact and high impact communication methods:
| Low Impact Collaboration | High Impact Collaboration |
| Reviewing text-based documents and requirements in tools | Co-creating visuals, lightweight documentation |
| Audio only conference calls | Face-to-face (video), digital whiteboard collaboration, other online collaboration tools |
| Sitting at a conference room table | Drawing on whiteboards, working with sticky notes on walls, building prototypes, brainwriting, experiments, etc. |
| Email chains or instant messenger feeds or slack channels. | Small group huddles (face-to-face or video conference) |
How are requirements organized?
A value mindset dramatically improves the quality of the modern business analyst’s requirements. The value mindset calls BAs to organize requirements by value stream and value increment, not by system area. The value mindset puts user and organizational value ahead of the team’s needs.
BAs help their teams think like users (outside in) instead of thinking like techies and analysts (inside out). Great BAs go beyond requirements and inspire the team to organize backlogs, features, needs, issue lists and even conversations by value.
This mindset change is the key to preventing failure. Teams that focused on the user and organizational value avoid over or under engineering solutions. They prioritize what’s most important to the user, not what’s easiest for the team. This gets users what they want faster and keeps the users on board for future iterations.
When business analysts modernize their requirements, teams reduce waste. They minimize time and money spent on tasks, deliverables, features, solutions, and products that do not provide value.
Despite increasing change, complexity, and ambiguity, requirements can be done faster with better quality. When BAs use techniques that focus on value and create a culture of high impact collaboration, failure points surface faster and make addressing change less painful, with less impact on results, cost, and
schedule. In turn, modern requirements give project leaders confidence that their teams are focused on the RIGHT stuff—solutions that will deliver value to the users and the organization.