I’m trying, against my usual nature, to be predictable and consistent with my blog. I could be doing better this summer. If you are familiar with a Pacific Northwest summer, you know that you take it when you can get it. Last week and this one we’ve been blessed with both summer weather and granddaughter visits. First the eight year old, and now the five year old. The blog has had some tough competition. But, it has some new inspiration, too.

Reading kids stories, the fantasy world mingled in my mind with the realities of my clients. Sitting in a client meeting to define requirements for new software, my mind wandered to Harry Potter and the Room of Requirement at Hogwarts. Hogwarts’ Room of Requirement, as defined by www.hp-lexicon.org, “is a magical room which can only be discovered by someone who is in need.” “The Room is located on the seventh floor, opposite a tapestry showing Barnabas the Barmy trying to teach trolls to dance the ballet. To make the Room appear, a person has to walk past the section of blank wall three times concentrating hard on what is needed.”

This makes finding the room of requirement seem relatively easy, but, as Dobby tells us: “Sometimes it is there, and sometimes it is not…”

Harry Potter’s Room of Requirement magically supplied solutions to his needs. On our projects, it would be useful if a Bridge of Requirements would magically appear. If there’s one thing we should imagine going perfectly on a project, it’s building a bridge between the people seeking a solution and the people delivering the solution.

The bridge of requirements links two groups of people – the users and the builders – in a common understanding of what is needed. I use the bridge metaphor because it links two groups, every crossing poses a unique problem to solve, and a job well done can be beautiful to behold. The beauty of the bridge of requirements is the common understanding of a new solution – a meeting of minds – defined in enough clarity and detail so that the product built meets the users’ needs.

Dobby’s quote seems to also apply to building a bridge of requirements. It can be an elusive and difficult task. For the business analyst assigned to this task on a software project, it can seem like a wizard trying to teach trolls to dance the ballet. How can we find what can go right about defining requirements? I think we can learn from the wizards at Hogwarts.

A theme in the Harry Potter stories is that a wizard’s power comes from the ability to clearly visualize what he or she is trying to achieve. The more powerful and clear the vision – the more rooted it is in a positive emotion – the more powerful the spell. Harry’s most powerful spell came from a deep remembrance of his parents’ love. For his spell to work, he had to harness that vision. He had to balance emotions with control to make magic. He had to have a deep visualization of what could go right about his spell – what he wanted to achieve. And, then put it into action.

That’s what we need to achieve with our users and builders in creating a bridge of requirements. We have lots of analysis tools and techniques to get there, but sometimes these get in our way. Sometimes we think the tools, techniques, and those who apply them are the whole answer. We say “Find me a business analyst who knows how to define and document requirements!” We definitely need this, but is it all we need?

I’ve had the opportunity to work with several business analysts in the last couple of years and observe the contributions of their efforts to project success. All used similar tools like JAD sessions, user stories, use cases, requirements traceability matrices, business rules, and mockups to elicit and define requirements for a product to be built. All worked hard and had good intentions. But the results varied greatly. Sometimes, the hard work led to a bridge with gaps or that didn’t seem to meet in the middle. The finished requirements document didn’t seem to reflect the users’ vision for how their work lives would be better with the new product. This came out once building of the solution started. Too often the design (or finished product) for a new web page or process, derived from the requirements, was met with “No, that isn’t what I really need…”

Other times, the work on requirements seems filled with active conversation, “Ah Ha” moments, and documentation of detailed needs that create a bridge from users to builders that allows for productive development and well received products. How do the two scenarios differ? What went right about one that didn’t in the other?

My impression is that requirements go right when the users and builders are freed and inspired by the business analysis process to imagine a perfect outcome. They envision how a future product or process change will help them do their job much more effectively. The documentation of requirements derived from their vision complements its expression; it doesn’t get it the way. What makes this happen? It happens when the business analyst finds a balance between the need to tap the imaginations of the users and builders, and the need to provide structure, definition, and documentation of requirements expressed thoroughly and unambiguously.

Sometimes this doesn’t go well because the business analysis process becomes about the business analyst and his or her deliverables. Emphasis is on completing the task instead of delivering on its purpose. This pushes things out of balance. The process becomes about creating artifacts. Users feel constrained to expressing their needs in unfamiliar ways in order to create the artifacts. Engaging the users to imagine perfect outcomes seems, in this case, to be a distraction from efficient business analysis. Instead, the process often focuses on describing requirements in terms of the product, rather than describing what it would be like if we had a product that helped. Users are willing to say “yes” to the requirements just to get them over with because they don’t own the result.

I’ve also seen the opposite out of balance condition. The team imagines a solution, but doesn’t have the business analysis tools and skills needed to organize and document their ideas in a way that channels them into effective action. Most often, though, I think we err on the side of pushing imagination of a perfect outcome out of the balance in favor of completing the analysis tasks and deliverables. Balance is required to make the magic that creates a bridge of requirements.

An effective business analyst balances tapping users’ emotions and imaginations with structure and detailed documentation. A magical balance includes recognizing that:

• The bridge of requirements is owned by the users and builders.
• The business analyst brings methods, tools, and techniques that facilitate and support the process, but doesn’t own the bridge of requirements.
• Imagining a perfect outcome is the place to start. Ask users how their work could dramatically improve if supported by the right product? Builders are part of this – they are half of the bridge of requirements.
• Visualizing the perfect outcome is complemented by visualizing the products to bring it about. Requirements can be more completely expressed if the builders can offer examples of solutions during the process.
• The business analyst succeeds by keeping things moving, documenting vision and details in a way that doesn’t get in the way of user and builder ownership, and pointing out missing links in the bridge.

Harry Potter learned to dig deep within himself to balance vision and control to make magic. In our projects, we get the most useful requirements by doing the same thing. We balance the users’ imagination of a perfect outcome with the control and focus needed to produce buildable requirements. A business analyst that understands and can execute this balance effectively is a powerful and mature wizard whose magic makes a big contribution to project success.

Thanks for reading.

This post is dedicated to Cyndi Lough – a powerful and mature wizard whose magic helped us succeed and made us smile along the way.

Copyright Glenn Briskin and “The Other Side of Risk” 2012