With requirements, discussions matter most

elicitation

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.

6 Comments

  1. Great article. I am about to kick off the requirements for a business capability that has a pretty narrow scope and an “agile feel” in a waterfall world. I’ll definitely do the quick-iteration approach you outline for cycling between implementation teams and principal / end-user stakeholders.

  2. I believe much of this behavior is a consequence of the project management office and the sharp division of concerns that the industry has morphed into. Everyone becomes narrowly concerned about their own focused function, but for a team to work well there needs to be tremendous overlap of concern. That’s the foundation of teamwork.

    For most of my career I worked on projects where all the cross functional team members were direct reports to the development manager. We never experienced these problems. There was always a lot of collaboration on these teams more than i’ve ever seen in PMO organized projects.

  3. This is a fantastic article. Waterfall is becoming old-school, and the requirements development profession is evolving to meet the needs of an iterative/AGILE approach.

  4. Welcome to the blog, and thanks for the comment, Mike.

    A card system veteran, eh? That's great. We have several guys around the office that tell stories of the coding sheets and punch cards.. Typically the stories involve dropping a stack of ordered cards or some other nightmare, and are always accompanied by the 5 mile walk to work – in waist deep snow – uphill both ways….. 🙂

    The "old-school waterfall" as you describe it may well be in danger, but I think that there will always be a place for the heavier, more document-centric methodologies. Regulated industries, distributed teams, large (or multiple) development organizations, and business stakeholders that are difficult to get time with, for example, are all factors that seem to push an organization toward a more traditional methodology as opposed to the "Agile" methodologies that are all the rage right now.

    And if you want to head up the "Waterfall Preservation Society" I'll pitch in a buck. Almost sounds like an environmental concern, doesn't it?

  5. An interesting article, recently I have come to think that the Waterfall method has become an endangered methodology and has been for some time. I don't agree with Bill's comment about project management office, mainly because I've worked in them, and it was always collaborative; although I do sometimes wonder if outsourcing can cause Waterfall.

    I've been in the IT development business for far to long and most of my projects have been 'staged' where you do a bit, review a bit, deliver a bit and work in teams. The only real old-school Waterfall was back in the days when the analyst wrote a spec, I coded (using a pencil) onto coding sheets, which were then punched to card etc. Batch processes lend themselves to waterfall development, although it's not compulsory!

    Anyway if Waterfall is endangered, we should establish the environment that it thrives in so that we may preserve this cultural icon and oddity.

Post a Reply to Scott Sehlhorst Cancel Comment

Your email address will not be published. Required fields are marked *