Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

This post is based on a quote I read and liked from the article, “When Requirements Go Bad: Part II” by Kurt Bittner. The article is available from Dr. Dobb’s Requirements Development e-zine (free subscription required). According to Bittner:

We need to banish the practice of writing requirements that we can “throw over the wall” to developers or testers and instead pursue a more open, communicative approach. What is important to realize is that requirements are what motivate discussions, but it is the discussion that matters most.

Well said. While I’ve taken an occasionally rocky path to get there, my experience as a BA has led me to the same conclusion.

Tough Lessons Learned

I’ve worked projects in the past in which we would spend 3-4 weeks of requirements analysis with various users and stakeholders and then bring what we considered to be, for all intents and purposes, a “finished product” to be signed off by the design, development and QA teams.

Needless to say, those sessions were often not the most enjoyable. The dialog that the teams needed to ensure that they understood what they were expected to deliver had not taken place, and they just didn’t have enough familiarity with the project to be comfortable signing what was, by all appearances, a blank check for their labor. Of course, we worked to resolve concerns and improve the specification, but this meant adding days, and sometimes weeks to the requirements phase of the project.

Here’s one solution..

One thing my team has done that has been working much better it to pull together a quick, unrefined, “skeleton” requirements document as quickly as possible, and then invite the project team for a requirements “working session.” Note, I am careful to not give the impression that it is a formal review session or that there is any expectation of the participants other than that they express their thoughts, questions and concerns. This helps to establish them as true stakeholders in the project and to assume a collaborative role and not just a reactionary one.

One thing that I think we, as business analysts, occasionally forget is that the downstream delivery teams are our customers, too - and in a very real way. We need to make sure that they have an opportunity to develop a true sense of ownership for the project early on and that they understand what the requirements are all about.

Now, regarding these working sessions - By default, I plan for 3 iterations of these before bringing a document before the team for approval. Obviously, we’ll hold more or fewer sessions as necessary.

Mitigating the “waterfall effect”

Another benefit of these iterative working sessions up front and earlier in the requirements analysis phase is that you mitigate the “waterfall effect”, or the notion that one phase be entirely complete before work begins on the following phase of the lifecycle. I think this is what Kurt Bittner was referring to with the “throwing requirements over the wall” comment.

What I’ve found is that, be it in theory or in fact, design doesn’t wait until the final review is over and documents are signed. After the first iteration, designers, developers and QA folks are able to start mulling ideas. Sometimes they’ll hold a whiteboard session right after the meeting. If not to design, to start thinking in terms of impacts to systems, and brainstorming design options. With each iteration the they have a clearer idea of what the project will require, the constraints they’ll be working under, and the technical challenges they’ll need to work through. By the time we’ve been through a few iterations, they have a pretty good idea of what the design will look like, even if it hasn’t been fully formalized and documented.

Another thing that has become easier with the notion of this more team-oriented approach to functional requirements is that the approval process is much, much easier. Document signatories don’t feel like they’re signing their lives away without understanding the fine print. They feel like they have ownership in the document, and they understand that their approval simply means that requirements are “complete” to the extent that design and development can proceed with a comfortable level of risk. If further changes or iterations are required, we’ll get back to the table and work it out through the change management process.

Anyway, this is something that has worked for my team. In our shop, we refer to our methodology as sort of a “modified waterfall”. We do identify and track to different phases, but we’ve also adopted some more agile practices in that our requirements and design processes are purposely both collaborative and iterative. You might say that if we have a “wall”, at least it has a nice, large, open door in the middle!

What types of things have worked for you to improve the lines of communication and collaboration in your requirements process? Please feel welcome to comment on this post, or contact me.