Modern Requirements – Reality or Virtual Reality

Have you ever found yourself in the middle of a project and thought, there HAS to be a better way? Me too! In my recent travels to conferences and training […]

Have you ever found yourself in the middle of a project and thought, there HAS to be a better way? Me too! In my recent travels to conferences and training there are deep discussions 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. As a result, the 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 or reality TV? What I mean here is to what degree is it necessary to adapt our requirements approach.

Shifting to modern requirements practices does not require a major overhaul. It reminds of that old saying we learned in school, K.I.S.S. – Keep It Simple Sister. As an alternative approach, modern requirements are the same best practices shifted slightly, with a change in mindset. Below I have presented three questions to consider that highlight the differences between “old-school” and modern requirements. I hope they quell that, “has to be a better way” sensation and send you on a path towards requirements simplification.

1 – 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. These 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. Therefore, I experienced some sincere frustration.

Now fast forward 15+ years; my techniques drive the requirements approach. As a result, I carefully consider which technique or set of techniques will help me facilitate stakeholder discussions, encourage big-picture thinking, and foster team collaboration. I choose techniques that will create a shared understanding that gives each stakeholder a clear picture of the context, user needs, and value. Sharing really is caring.

Consequently, 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 work closely together, less documentation is required. Working with small chunks of value is why agile teams tend to document less. Agile teams have small “work in progress” and small number team members so documenting can seem like a waste of time for them. Many are concerned about documenting for audit, compliance, support, etc.—and this is valid. However, I would also contend 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.

This is not advocating for no documentation, simply put, I believe too many teams are documenting far too much at the cost of missing out on time for other strategic projects and initiatives. 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 macro to micro levels of detail. This technique-driven approach makes requirements cognitively easy for the team and stakeholders. They have a deep understanding of how their work fits into the big picture. A technique driven approach can more quickly elicit and obtain more accurate requirements.

2 – What Do Meetings Look Like?

In today’s workplace, everyone bemoans having meetings for meeting’s sake. However, 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. The Harvard Business Review (link) conducted a survey and reported that Face-to-Face meetings were 34 times more effective than emails. High impact collaboration helps BAs and stakeholders get to a shared understanding faster. As a result, the quality of requirements also improves, because we get beyond stated requirements to the real needs of users. Below is a chart that compares two communication methods, feel free to share it with your colleagues or post in your meetings.

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)


3 – How Are Requirements Organized?

My last question focuses on an organization. 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. Therefore, the value mindset puts the 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). Successful 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. Consequently, this delivers users what they want faster and keeps them engaged for future iterations.

In conclusion, when business analysts modernize their requirements, teams reduce waste. They minimize the 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.

What are your thoughts on this approach? What questions do you ask? Share your efforts and results with us on our social media channels! We want to foster a community of BAs that help each other navigate career success!