Your Requirements Sherpa: A Business Analysis Case Study

It’s an all too common tale: your project is over budget and late to launch because of misunderstandings of what was intended to be built in the first place. There can be many causes of this, including the following: 

  • Project requirements weren’t amply documented
  • Project requirements were only partially thought through
  • The project’s stakeholders haven’t reached consensus on some requirements
  • Project requirements were misunderstood

Certainly there are more potential causes beyond this, but the principle behind them remains the same: a successful project must have a set of requirements that are both clear and complete. A Business Analyst (BA) can provide the clarity and completeness of requirements needed for any project. Although there are many descriptions of what a business analyst does, the one I like to use is that of a translator of the informal to the formal. The business analyst gathers the informally-expressed needs of a project’s stakeholders, and translates them into a formal, complete description that a technical team can design and implement off of. 

There are many deliverables a business analyst can provide. As an illustration, I'll walk you through several of the business analysis deliverables we we created for a recent project with a government-related project. They provide a good cross section of the ways we can formalize stakeholder requirements, and will provide you a good sampling of the business analysis deliverables you can create on your own project. 

What level of knowledge should attendees have before walking into your session?
This is a beginner level, nontechnical session.

What will your session accomplish and what will attendees walk away having learned?
This session will demonstrate the value of business analysis has on projects. Attendees will walk away with the high level knowledge of how to create business analysis deliverables of their own.