While we’ve already talked about the importance of Preparing for Elicitation and Conducting Elicitation Activities, it’s not enough to stop there. The next two (and IMHO, critical) tasks in the Elicitation Knowledge area are Document Elicitation Results and Confirm Elicitation Results.
The purpose of Document Elicitation Results is to:
Record the information provided by stakeholders for use in analysis.
The purpose of Confirm Elicitation Results is to:
Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder needs.
Together these two tasks take up a mere 4 pages in the BABOK and they can be quite simple to execute on. Yet they are often overlooked even though they are critical to the success of any project.
Through these two tasks, we are essentially saying a big, “I heard you” (which happens to be a great way to get stakeholders to stop repeating themselves, just in case you have that issue). And, even if the project takes another direction, a stakeholder’s needs go unmet, or their problems are simply not as much worth solving as other bigger problems unearthed during elicitation, at least they know upfront that they had their say.
Most simply, documenting elicitation results takes the form of meeting notes, though it can also include recordings or other physical means of capturing what was discussed (such as a whiteboard, a picture of a whiteboard, or the renderings from a whiteboard session recreated using a modeling tool). Interestingly, in the BABOK, each elicitation technique is coupled with a suggestion as to how to document the results when using that activity. Sometimes reports are captured after the elicitation activity and sometimes, such as during brainstorming or a requirements workshop, the activity itself produces the results.
For example, many times throughout my career, I’ve captured a synopsis of the discussion on the whiteboard. In these cases, the whiteboard itself is the documentation of our conversation and, when captured via photograph, no other documentation is required.
Simultaneously, the whiteboard drawing has also served to confirm results. Confirming elicitation results involves sharing the results with those who participated in the activity to be sure you got it right. This is when the stakeholder feels, “I heard you” or, if you got something wrong, “I wasn’t heard,” Capturing the ideas discussed on a whiteboard documents confirm the elicitation results by giving everyone the chance to make corrections on-the-fly.
Regardless of the elicitation process used, if you are truly confirming elicitation results and not just publishing notes for the sake of checking off a task on your list, your stakeholders are empowered to provide feedback if you misheard what they told you and they need to provide clarification. And therein lies the power. Before we strut off analyzing, prioritizing, and coming up with solutions to requirements, it’s critical to confirm, “did I hear you right?” in the first place. Otherwise, everything else you do is built on the foundation of the wrong information.
This post is one installment in our Journey Through the BABOK with BA Stories series.
Pingback: BAs make the world a better place - Ryan Knapton » BSG (UK)
I always follow up planning workshops and meetings with a recap email of what I plan to include in my documentation as well as calling out takeaways of assigned tasks that were determined at the meeting to make sure that everyone knows what is expected of them on follow up. It is also helpful for anyone who may have been an invited attendee but missed the meeting. I always ask the question – did I miss anything or is there something that anyone understood differently or needs more clarification?
I usually write a draft of the requirement for them to review based on my undersanding of the discussion..is this wrong?
Not at all! Though I do find that for some projects this intermediary step of confirming what was discussed, before capturing it in a requirements document, can help build trust and increase buy-in. If there are a lot of decisions to be made before you decide what goes in the requirements document, you might consider taking iterative steps, gaining confirmation or approval at each stage, before drafting a requirements document for review. Otherwise you risk creating the perception that you ignored what was said.
Each requirement needs a different way to confirm elicitation results, depending on the complexity.
Screen changes/simulations can often be confirmed and documented immediately, depending on the tool you’re using and the feedback your getting.
Complex back-end business business automation may take more time, especially in an integrated systems environment.
@michelle, I agree with you that the requirements pot sometimes needs time to stew, but some reqs can be flash fried for that sweet crunchy flavor of satisfaction!
@Laura, I have seen many times that a simple rule change can have tons of reprocess ions on other areas, so to confirm even the smallest of changes may require insight.
Perhaps another step is needed in approving reqs, where reqs can be documented in the meeting, and the Stakeholers should choose a reasonable time for how long to incubate the requirement. Approval is conditional, up until the incubation period has passed. The requirement should not Be implemented until then. Should the stakeholder find something wrong with the req, they can bring it up for discussion.
This may add more time in the schedule, and there is also a risk of never closing on a requirement, but it may give more favorable results. What do you think?
Nick,
Yes definitely. There is a big difference though between confirming elicitation results and approving requirements for implementation. Confirming elicitation results does not necessarily include requirements analysis, which is where I often find all those additional requirements are discovered.
The BABOK is a bit tricky in this respect as it separates out tasks that a lot of us naturally group together in our work and our thinking.
Laura, the most interesting story I want to share is gathering requirements for a web store. We were given 1 day with the stakeholders and gathered some great requirements in the workshop.
We used our SMART board to document. I always give the stakeholders time to think about their input as invariably a few days later they will come back and clarify or change a requirement. We validated the requirements in another session and there were more changes. People really need time to process the direction they want to take to get to the end point.
Couldn’t agree more, Michelle. I find that I need that time too…as often as I reflect on what I learned from my stakeholders I come up with more elicitation questions. Typing up notes really supports that process for me, which is why I am hanging onto it!