JB Weekly Digest (07-45)

I’ve been traveling this week, so I haven’t had a lot of time for commentary, but I have had time to read some good stuff. Here are not notables and quotables from the past week’s reading.

Building Relationships

I recently had an opportunity to spend some time working on a project with one of my company’s vice presidents. We talked a bit about systems, about processes, about solutions, but often about people. He emphasized that we do business with people. To be successful we have to have successful relationships. I agree with the importance of establishing relationships of trust. You may have heard the old cliché that people “don’t care how much you know, until they know how much you care.” I think there is wisdom there.

I get the impression that Jim from Project X Discussions feels the same way. In his article, Challenges of the Business Analyst, he states:

I have found that the first step in any meeting between people is the development of rapport. The people need to feel comfortable with each other as people. How many times have you been meeting with somebody and things go very poorly and you had the premonition in the first twenty seconds. Likely no rapport has been established between the people.

He then goes on to give some examples of how rapport may be built, and how to proceed once it has, or once it is lost. One of the points Jim makes that I’ve seen made elsewhere, but that I’d like to note is the danger of using IT jargon when dealing with non-technical stakeholders. If our goal is to establish a meaningful relationship based on the common ground we share, we can cause that ground to crumble quickly if we use terminology with which others are not familiar and uncomfortable. Per Jim:

Listen to the words the person uses to describe something and use the same words. If they have a name for a function, use that name. If they have a name for a process, use that name. Stay away from the technical jargon we all slip into in the IT world. “The ETL process of EDW is critical to Micro-strategy software. We need to understand how to normalize your data so we can drill down and across.” If you thought I was from the moon before, I just moved to Mars.

Writing Good Requirements

Structure in requirements writing, MJMurphy

I’ve come to the conclusion that the logical structure of the writing is as important as the content. Although it may seem that content is more important than structure, in fact it is the structure that makes a document readable and understandable. If your readers cannot easily comprehend your work the content really doesn’t matter.

Murphy then elaborates and provides a bit of useful advice on ordering grouping requirements. Go have a look at the rest.

I wanted to refer to this article in this week’s digest because I agree that the way a document is structured has a great effect on how readable and ultimately how effective the document is as a tool of knowledge transfer. This whole structure bit is actually one of the knocks on natural language requirements. As it is, natural language – even with the most clear and concise wording – can often have more than one interpretation. Couple that with an unclear or illogical arrangement of requirements, and you’ve got yourself a recipe for a disastrous document from the reader’s perspective.

I like to break requirements into subsections with nice, large headings and to to keep the progression of requirements as logical as possible, and seek early feedback on the document through informal reviews and one-on-one discussions with document consumers. Anyway, it’s a great topic and one that I may try to explore in more detail on this blog in the coming weeks.

Methodology

You Don’t Know What You Don’t Know Until You Take the Next Step, Bob Koss

Koss points out that one main reason for failure in a waterfall environment “or at least the problem with the way most companies implement it, is that there either isn’t a feedback mechanism or the feedback loop is way too long.”

I’d agree that a successful waterfall-type methodology is one that resembles agile if in no other way than that requirements gathering is a highly interactive and iterative process, and feedback begins early and happens often. Also, we have to understand that just because a document has been signed-off, we ought not to assume we’ve identified all the requirements. In Koss’s words:

Before there is UML specifying a design, there must have been requirements stating a problem that the design addresses. Have we captured all of the requirements? Are they complete? Are they accurate? Are they unambiguous? How do you know? I believe that you don’t know, and worse, you don’t even know what you don’t know. You don’t know until you take that next step and try to design a solution. It’s only during design that phrases like, “What’s supposed to happen here,” or, “That doesn’t seem to have been addressed in the spec,” are heard. You don’t know what you don’t know until you take that next step. It is very easy for everybody on a project to believe that they are doing good work and that the project is going according to plan. If we don’t know what we don’t know, it’s hard to know if we’re on the right track.

Back to the phased, waterfall type approach. If it’s hard to know if we’re on the right track, it’s hard to know that we can finish the requirements “phase”. When we’re unsure, we tend to prolong phases and begin to churn and overanalyze; we get stuck in analysis paralysis. For a waterfall-type methodology to work, I think it has to acknowledge – much as does the agile approach – that requirements gathering is iterative. Once we’ve gathered requirements sufficient to let us proceed with design with an acceptable level of risk, it’s time to dive in to design. As design moves forward, of course we’ll come across things that need to be included as requirements.

Use Case Disgruntlement

(Ab)using Use Cases from Stephan’s Process Blog explains that many companies try and then abandon use cases because they were too hard or complicated to use.

The usual cause I see is that organisations try to make [use cases] the vehicle for all requirements. This leads to long, hard to read, use cases causing disenchantment and ultimately abandonment of this technique. This is a pity because there are few approaches so powerful in eliciting and structuring requirements.

Stephan’s post provides 8 items that might be used to avoid discouragement with use cases and to help in using them effectively.

Short Cuts:

• BABOK 2.0: Kevin Brennan provides a sneak peak at the BABOK 2.0 framework.
• Roles & Responsibilities: Read up on the RASCI framework and even download a sample matrix from Kent Blumberg in his post, Clarifying Responsibilities.

Related posts:

1. Weekly Digest – 8-17
2. JB Weekly Digest (07-44)
3. JB Weekly Digest (07-42)
4. Weekly Digest 08-43
5. Weekly Digest 08-44