Friday, April 6, 2007

Five Facets of Successful Business Analysis

Being a part of My Profession, I am putting down for what I think "Business Analysis" is all about. Have fun reading it :)

Gathering and managing client requirements is one of the most difficult and critical aspects for any project। For a project to be successful, the needs and goals for the product being built must be understood and translated into complete specifications from which the product can be built.

You can build anything with quality and sophistication – whether it is software, a house, or a car, etc। – but if the needs of the client aren’t met, the product will either be reworked or scrapped, and the project called a failure.

According to a report I read recently:-

  • Two thirds of all projects studied were either failures or what they call “challenged”
  • Only half of the desired features made it into the finished product
  • Cost overruns happened on nearly half of all projects

Clearly, what is most needed on projects today are ways to increase functionality of products produced in less time.

Effective business analysis can supply the missing ingredients to reduce or eliminate challenged projects, capture vital functionality, and produce happier clients। Here are the five essential “Ts” for quickly nailing business requirements.


Whether we want to acknowledge it or not, it takes time for business experts to discover their requirements, particularly the details of those requirements। For example, homeowners can discuss certain aspects of the house they want to build, but rarely can they articulate all of their detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized.


Relying on one familiar tool or technique for gathering and managing requirements usually causes gaps, and can result in missed requirements। By using a small number of complementary tools and techniques, analysts can leverage them to maximize the strengths of each. The result is a more complete set of requirements, captured and analyzed more quickly than relying on a single technique.

The four tools we recommend are:

1) Process Maps to capture business processes

2) Use Cases to document interactions with a system

3) Data Models to capture data requirements

4) Prototypes to get early feedback and gather interface requirements.


Effective analysis requires more than effective use of tools and techniques. It is essential for business analysts to learn how to navigate the organizational landscape effectively. And as important as communication, listening, probing, and presentation skills are, more important are those that build relationships, such as negotiation, or that allows the analyst to walk seamlessly between business and technical areas.


Projects take longer to finish when either approved requirements are not delivered, or when scope creep occurs। All requirements need to be traced forward to the finished product to verify they have been addressed. If approved goals and needs are overlooked, then rework will occur, meaning time will be needed to complete them. In addition, when requirements that are not part of the project vision sneak into the project, the scope expands, as does the associated time. One way to reduce scope creep is to make all initial requirements and changed features traceable back to business objectives and the project vision.


We may initially trust or not trust those involved in our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgments। Business analysts and project managers don’t always have time to let relationships develop, and need techniques to help build trust more quickly. To capture requirements quickly and completely, trust needs to be present.

In the end I would like to summarize with this:-

Requirements are not easy things to understand and capture. They take time to discover and understand, especially when only one or two techniques are used. Multiple, proven methods that complement each other can help accelerate the discovery process and contribute to more complete requirements at the same time.



agile said...

Great content and organisation. Remarkably explained.

The author is generous in keeping the english simple for readers like me ;-)

Looking forward to some more articles.


agile said...

Great content and organisation. Remarkably explained.

The author is generous in keeping the english simple for readers like me ;-)

Looking forward to some more articles.


Adi Crazy said...

Hey Don!
This is a helpful info. explained in the most layman-friendly language. This reminded me of the importance of knowing what you are doing. :D
Great blog. Keep 'em comming.