Your Job Is Not to Elicit and Document Requirements
In my last article, 5 Things I Wish I’d Known When I started As A Business Analyst I said I wish I knew is that my job was not to elicit and document requirements when I first started out.
Why did I say that? It comes down to the difference between outcome and output.
What is the Difference between Outcome and Output?
Before I go much further, I should probably explain what I mean when I use the words outcome and output in a context relevant to business analysts:
Outcome is the change in the organization and changes in the behavior of stakeholders as a result of a project.
Output is anything that your team delivers as part of your project. This could include requirements, documentation, processes, software, tests and other things that tend to be measured in order to gauge how the project is going.
The goal of every well-defined project is not to produce output; it’s to reach a specific outcome. A successful project seeks to maximize outcome with minimal output. Why do you want to do that? Well, you want to get as close to desired change in your organization and your stakeholders’ behavior with the least amount of initial and ongoing work as possible.
Requirements are (not the final) Output
To look at it another way, satisfying the needs of your stakeholders is the outcome you seek, and the solution you deliver to satisfy those needs is the output you use to reach your desired outcome. Requirements are outputs in that process, but they aren’t the final output that drives the desired outcome. They tend to be an interim output on the way to getting to the solution.
When you view the purpose of analysis as eliciting and documenting requirements you most likely have a couple of assumptions: 1) the best way to reduce uncertainty about the solution is to write everything down at the beginning of the project and 2) it’s possible to know what those things are. Those two assumptions generally end up false, so I’d rather work according to this assumption: we’re better off creating a shared understanding of the problem we’re trying to solve first, and let the specifics of the solution emerge as we get things underway and learn more about the problem space.
Changing those assumptions means looking at analysis as problem-solving and building shared understanding. Along with that comes a substantial change in how your team views requirements and designs. They are no longer deliverables that get tossed over the wall to the people performing the next step in the process. Now both requirements and designs are tools that teams can use to build a shared understanding of the solution they seek to deliver in order to reach the desired outcome.
How do you focus more on Outcome than Output?
Here’s a recent experience that shows how to maximize outcome while minimizing output.
For a little over a year, I’ve been the product owner for the initiative to revise the Agile Alliance website, membership and conference registration systems. When it came time to do a deep dive into the membership aspects of the system, I took it upon myself to write up all the specifics about membership – what information we wanted to track about members, what rules were relevant, and what types of memberships we had. It was a fairly short, yet comprehensive set of requirements. I was admittedly quite happy with them.
I was happy with them until the delivery team started developing functionality and they didn’t seem to pay much attention to the requirements. At first, I was perplexed, did I not clearly tell the team where the requirements were? Then I was irritated. Why weren’t they paying any attention to them?
Then it occurred to me that what I had done wrong was that I had focused on the requirements as an output, without considering how it contributed to our desired outcome, to increase membership. I didn’t talk with the delivery team to find out what was the best way to share information with them along the way as they built the various aspects of the membership functionality. We didn’t have conversations as we went along to specifically point out the relevant rules and pieces of information for the specific backlog item that they were working on at the time.
Once I came to that realization, we changed how we communicated. We still used the rules and data element information, but we used them more as reference points in the frequent conversations we had. We also started using examples on a more regular basis to talk through the specifics of a given backlog item. We found that me simply writing those examples down was not sufficient. In many cases the real advantage was through talking through them as the delivery team was getting started on a backlog item.
I should have known better to start the way we did. I realized it is easy to forget good practices when you’re in the midst of a project and the pressure is on. Here are some of those good practices I hope you don’t forget when you run into the same situation:
- Take time to talk with your team about how you want to work, and the best way to communicate information in order to build and maintain a shared understanding. When you have those discussions, don’t be afraid to suggest approaches that your team is not familiar with if they are applicable for your project.
- Document requirements collaboratively during your discussions with the team to build and maintain a shared understanding.
- Stop thinking of analysis in terms of gathering and capturing requirements and instead think of it as solving problems and building a shared understanding.
I hope this story gives you some ideas on to focus on outcome over output. I’d love to hear some of your stories on how you’ve focused more on the outcome while minimizing your output.