The why of business analysis

What is the role of business analysis? One might say that the goal is to help provide better solutions to meet business problems or capitalize on opportunities. Someone else may say that the goal of business analysis is to allow an organization to improve and develop. I think that the answer is more basic than that. To me, the objective is simply to communicate ideas.


Eureka! The objective is to communicate
This sounds like a very easy thing to do but it really is not. First off, a business analyst must understand what business clients need. Gathering this information can be a very tedious process. Sometimes business clients are merely listing out symptoms of a problem but not the actual root cause. In other cases, clients just do not feel that they need to provide much information, "It's obvious to me, why isn't it obvious to you?"

Business clients speak in their native tongue; full of company jargon, industry jargon and obscure references. Even worse, sometimes a lack of objectivity is apparent and rose-colored glasses are used. However, through diligence and perseverance a body of requirements will take shape.

Now it is time to relay the business clients' needs to the IT groups. These groups have their own subtle nuances. IT groups also make use of their own set of terminology. Sometimes the same terminology and expressions that worked so wonderfully with the business clients leave IT groups completely dumbfounded. Have you ever seen the, "That's got to be the dumbest thing I've ever heard," facial expression? Or perhaps the, "In English please," expression?

Eureka! The job is to translate!
It is almost like a business analyst has to act as a translator; deciphering ancient Greek and translating it into modern English so it can be enjoyed by a specific audience. Perhaps that is the objective of business analysis; to translate (ensure the clear communication of ideas.)

In closing
Have you ever attended a meeting where two people saw the exact same thing, got into a heated argument about who has the correct interpretation, and you sat there stunned because they sounded like they were both arguing for the same thing?

A zebra is a white horse with black stripes. No, a zebra is a black horse with white stripes. At the end of the day, they both represent the same thing.

The two parties simply could not understand each other. They needed someone to bridge the gap. To translate and facilitate the communication of ideas.

They need a business analyst!

The business analyst & the business systems analyst

In the past, I have asserted that when gathering high-level business requirements, one must aspire to be design agnostic. This is because the consequences may be severe if an inappropriate solution influences a requirement set.

Eventually, there will come a time when a solution must be defined. As a project progresses through the design stage of a system development lifecycle, the methodology, tools, 3rd party applications and approach have already been agreed upon. At this time, requirement documentation becomes much more detailed.

The BA vs. the BSA
So what is the difference between a business analyst (BA) and a business systems analyst (BSA) anyway? I've worked at a few different companies and seen the two terms used synonymously. But from company to company, there is a vast disparity in meaning.

For me, the distinction lies with whether the analyst is more closely aligned with the business side of things or with the IT side. Business analysts interact with the business to understand what is needed. The BA then liases with the design team (or through a BSA) to transfer knowledge of the business' objectives and needs.

Contrast this with business systems analysts who create specifications (to fulfill the business requirements) and interact more closely with the development & design staff. A BSA will generally tend to have more technical expertise than a typical BA.

Determine the skill set needed
Because of the varying composition of project teams and skills, individuals in BA or BSA roles may be asked to perform many different types of duties (as well as aspects of a BA and BSA role.) Rather than debate whether someone is a BA or a BSA, focus on how he or she has been involved in past projects.

During the different stages of a system design lifecycle, what was the role that was played?

Does the role require someone to be involved at the inception stage of a project or is the majority of the role to provide IT teams with specifications?

Does the role require a significant amount of client interfacing or does the role require significant technical knowledge?

What gaps in the team is one trying to fill?

Spend time understanding what is needed rather than what to call the role.

The good, the bad & the ugly... And the road ahead

I could not think on a better title than a play on an old Clint Eastwood spaghetti western for this post. So without further ado, let's start!

During the last 6 weeks, I have provided some tips and guidelines on how to prepare (high-level) requirements documentation. I have also talked about some of the common pitfalls to avoid. Regardless of what tools or applications one uses to manage a body of requirements, these guidelines will be relevant. The focus of this post will be to dove-tail all of that material in an eloquent fashion. In essence, this post will summarize and serve as an index of my previous posts.

The Good
The purpose of these habits is to promote understanding on a few different levels:

Each requirement statement is understood by all affected parties. To accomplish this requirements must be clear, feasible, correct & complete.

Each requirement fits in and does not conflict with any other requirement. Consistency within the body of work must be maintained.

Each requirement can be traced backwards and forwards easily. This improves the ease of verifying them as well as encouraging modularity.

High-level (business) requirements answer the question, "What should the system do?" not, "How should the system do it?" In other words, they must be design independent.

The acid test is, "Are my requirements readily understood? Can someone who is not familiar with my project, read my requirements and understand what I am trying to accomplish?"

The Bad
To appreciate each pitfall, it is important to have an understanding of its impact.

Requirements are less clear when:

• They are ambiguous.
• There is excessive rambling.
• They contain vague or speculative references.
• They contain many possibilities.

Requirements are more difficult to test when:

• Multiple requirements are squished into one big one.
• They are ambiguous (surprise, surprise!)

Requirements can lose consistency when:

• They contain escape clauses.
• Different types of requirements are mixed together in one document.

Requirements are unattainable when:

• They are composed of wishful thinking and dreams.

It becomes very clear that these requirement pitfalls contribute to a lack of understanding. Which in turn will be detrimental to success.

The Ugly
Now I want to focus on why requirements are important. Requirements are the foundation for the other phases of a system development lifecycle.

Requirements are also viewed as the primary reason for project failure with estimates ranging from 50% to as high as 70-80%!

Requirement gathering occurs at one of the earliest stages of a project lifecycle but the impacts of problems are felt downstream during the design, build, implement and post-implementation periods. The later a requirement error is discovered, the more costly it is to fix.

This is simply because the later an error is uncovered, the more backtracking will be needed (an obvious need for solid traceability if ever there was one) to correct it. When a requirement is incorrect, the functional specifications will suffer from the same deficiency, likewise the design documentation will perpetuate it once again and finally, even the actual code itself will have the same problem.

If an error is discovered late in the development cycle, the costs may have risen anywhere from 10% to 100% (or worse) to find and fix versus if the error was discovered earlier.

The road ahead
The guidelines I have proposed are just that... guidelines. There is considerable interdependency between them. Each guideline should not be viewed as a singular item, but rather as a factor that will contribute to the success of the requirements gathering and articulation process.

Using all of these tips will, in itself, not guarantee success. Success is never guaranteed. Projects are often subjected to things beyond their control, however, requirement management practices are controllable.

These guidelines will help one bridge communication and understanding gaps. Then, the rest will be left to your wits, skills and resolve as a business analyst. Enjoy the ride!

Bad Practices - Part V - Possibilities & Dreams

Suggestions or possibilities
In my last post, requirements were defined as needs. Note that there is a significant difference between a need and a possibility. One must be wary of the language used to define requirements. Avoid using terminology such as: may, might, should, ought, could, perhaps or probably. Either a client wants something or they do not want it.

In the past, I have seen language used to indicate the importance of a requirement. For example, "must", indicated that without this requirement being fulfilled the project would not deliver maximum benefit while, "could," indicated that this feature would be nice to have but is not necessary. This method works however, I suggest using something like mandatory, need-to-have and nice-to-have to show how important a requirement is to a project.

Avoid wishful thinking
Business users want everything to be perfect. A system will always be available, never fail, never slow down and be future proof. Unfortunately the last time I checked, I did not live in a utopian society. Murphy's law is something one must be vigilant against. What does this have to do with requirements?

The implication is that one must never interpret wishful thinking or impossible terms as requirements. A customer may want 100% reliability, but as a business analyst, one must recognize that this is not achievable.

Bad Practices - Part IV - Speculative & Vague Terms

On speculation
Avoid using generalizations and speculative words such as often, normally and typically. A requirement must not include any speculation at all.

On dictionary.com, a requirement is defined as, "Something that is required; a necessity." On Wikipedia, the definition is, "a singular documented need of what a particular product should be or do." The common theme is that requirements define needs. When defining a solution to a problem, speculation has no place. It is either do or do not, there is no maybe (or try, as Yoda in The Empire Strikes Back would say.)

On being vague
One common mistake that people make when taking down requirements is to use informal and unverifiable terms. What do the terms: user-friendly, flexible, easy-to-use, fast, and intuitive mean to you? Do you think these terms mean the same thing to someone else? Generally, no! So when different people see these types of terms, people will generate their own interpretations on what they mean. The net result is that the requirement is not clearly understood.

Look at the picture below. What do you see? Do you think other people may see something different than you? If two people can see the exact same picture but come up with different interpretations of it, what would make anyone think that people can read the same requirement and (because of subtle vageries) come up with the same understanding?

No jargon please

Another suggestion I have is to avoid using the jargon of the company one is working with. While understanding the jargon and nuances of a specific company shows some level of understanding, one must realize that jargon does not mean anything to people who are not familar with the company. If a company employs a lot of contractors to help with projects, using excessive jargon increases the learning curve.

Bad Practices - Part III - Escapes, Rambling & Mixing

I would like to write a little bit about other requirement pitfalls. By avoiding these bad practices one should be able to keep from making a faux pas.

Avoid escape clauses
When one uses statements that contain words such as: if, when, but, except, unless or although, one is introducing many potentially complex conditions. These conditions allow out clauses that can keep one from meeting the underlying needs. A picture found in an earlier posting really illustrates the massive confusion this causes. Instead of adding clarity to life why do many street signs just add to complexity?

Do not ramble
Employ the KISS (keep-it-simple-stupid) protocol. Avoid using long rambling sentences that utilize arcane language and unreachable references. No good can come of this. Remember the 3 keys to effective business writing. No one ever said that requirements need to be stated as complete sentences!

Do not mix different types of requirements
As a project moves from its early stages and into the development phases, high-level requirement documentation is used to develop more low-level functional specifications and low-level business requirements. Avoid writing documentation where high-level requirements are intermingled with low-level requirements. In other words, do not mix user, system, business & design requirements. This makes things very confusing and difficult to manage.

Bad Practices - Part II - Multiple Requirements

One of the things I have frequently mentioned in my previous posts is that requirements must be stated as simple atomic statements. I have shown how this simple practice enables one to readily verify that requirements have been met. Another positive consequence of atomic requirements is that overall modularity and traceability is enhanced.

Sometimes when trying to state a requirement, one actually states 2 or more within the same sentence. This happens because when people talk and write people tend to use conjunctions such as and, or, with, and also. Conjunctions indicate areas where multiple requirements exist. What one needs to do is ascertain whether eliciting the items separately allows someone to understand better.

For example, one can state the following,

• Articulation 1 - "The screw must be 4.5 centimeters long and must be able to withstand a temperature of 500 degrees Celsius."

Consider another articulation of the same information,

• Articulation 2a - "The screw must be 4.5 centimeters long."
• Articulation 2b - "The screw must be able to withstand a temperature of 500 degrees Celsius."

Let's look at how the articulation of requirements impacts the ease of verifying, tracing and overall modularity of the body of work. Consider two common situations:

• One aspect is met but the other aspect cannot be met. - The screw is 4.5 centimeters long but cannot withstand 500 degrees Celsius.
• One of the requirements has been changed. - The temperature the screw needs to withstand has been reduced to 400 degrees Celsius but the 4.5 centimeters length is still required.

For articulation 1:

• Part of the requirement is met and part is not. So is it 50% met or does it fail completely? How does one measure this?
• All requirements linked to this one must be examined to ascertain the impact of the change. If there are 5 children requirements, all five must be checked.

For articulation 2:

• The first requirement is met and the second fails.
• Only the requirements that are children of the second one must be examined to determine if changes are needed.

In both cases, articulation 2 yields better results. Now, the problems with having non-atomic requirements are clear.