Missed requirements: how to avoid this BA nightmare

Author: Adriana Beal

Some time ago, I received a call from an IT manager from a large NY-based company.

This manager (let’s call him John) wanted my help in Phase 2 of a project whose first phase had experienced serious cost overruns.  The purpose of the project was to customize an off-the-shelf content management system for use by various business departments. “I want to warn you,” he said, “that the stakeholders you’ll be dealing with are very difficult. They worked with the BA initially assigned to the project, signed off on the requirements document, and only on the day we offered a demo, right before the go-live date, decided to complain about things that never came up during the requirements phase. We ended up missing an important deadline because the project sponsor refused to approve the release until a long list of change requests was implemented.”

I asked John a few questions about the requirements that had been missed, and quickly concluded that they could have been easily anticipated and dealt with in a timely manner, had the business analyst asked the right questions to the right people during the discovery phase.

One of the main objections from stakeholders was that the solution didn’t allow members of the Marketing team to easily reshuffle a series of events after they had been published to the website’s calendar. The software requirements clearly described how users would be able to create individual events, preview them in the calendar, make adjustments, and publish to the website. However, the requirements failed to account for changes in dates of connected events after they had been published.

Imagine that in early August, the Marketing team published a full calendar of events for September, pertaining to the release of a new product.  Then, mid-August, the product team announced that the release would be delayed three weeks. In this common scenario, there would be a high risk that the calendar ended up with incorrect dates due to the time-consuming process of reshuffling each associated event manually.

The BA’s mistake was to rely on the stakeholders to tell her which capabilities they needed to perform their job. A good first step here would have been to focus on how the stakeholders are behaving today. Stakeholders don’t necessarily realize that they have a problem to solve (“move around a series of linked events without having to manually change individual dates, to reduce the effort and mitigate the risk of human error”). But they are very good at describing how they perform their tasks today, and this knowledge is an invaluable source of information about what needs to be built.

Here are the some of the questions that would have helped the BA in John’s project identify the deal-breaker requirements that were initially overlooked: 

  • Can you walk me through the process you follow, from the time you learn of a new event or series of events that need to go into the calendar, to the time the events are live in the website’s calendar?
  • How often do you have to publish events to the website calendar?
  • How often do you have to update events after they’ve been published?
  • What do you normally do when you have to update an event after it’s been published?
  • What is the most frustrating thing that you have to do when you are creating or updating an event?

Note how all those questions focus on how the interviewee is behaving today, as opposed to asking about what he or she would like the solution to do for them. By asking questions about the present, rather than the future, the BA would have learned that it was common for the marketing team to have a series of events with dates that are relative to each other (e.g., Conference Day 1, Conference Day 2, etc.) and that might have to be moved after the schedule had been published.

Stakeholders would have explained how they currently built the monthly calendar using an internal project management tool that allowed them to multi-select the events you need to move and shift them all together to a future date, preserving their sequence in the series. This piece of information would have allowed the BA to identify the ability to move a whole series of events in bulk as a necessary capability in the new solution, to avoid an inefficient and error-prone process of rescheduling events one by one.

You may be thinking, “but each situation is different—what if the missing requirement is not about something that the users currently do, but rather about what they’ll have to start doing in the new application?”.  As any business analyst knows, understanding and translating what our stakeholders truly need into software specifications that deliver the right solution is easier said than done. Different circumstances call for different interview techniques to uncover what the stakeholders’ real needs are.

>>Learn More

If you could use help in this area, check out Adriana Beal’s e-book: Tested Stakeholder Interviewing Methods for Business Analysts. This e-book offers proven techniques and actionable steps to ensure you uncover any deal-breaker requirements early on and avoid last minute surprises in all your projects.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.