Article Menu

Tuesday, 13 October 2009 09:24

The Three Most Important BA Factors

Written by 
Rate this item
(0 votes)

"Location, Location, Location" is a phrase used by Real Estate experts regarding the three most important factors in determining the desirability of a property. I have a phrase for the three most important factors in determining desirable business analysis, "Iteration, Iteration, Iteration." This thought hit me yesterday when I was facilitating a meeting. There I am up in front of 20 people in a conference room and I see someone sleeping. Eyes shut, head bobbing...out! It happened to be my PM...yikes. Side note - I don't worry if one person falls asleep in my meetings. When two or more start crashing I know I need to switch things up!

"Sleeping Beauty" reminded me of my requirements reviews earlier in my career. Participants did not fall asleep, but they told me those meetings were a bear to get through and mentally checked out 20 minutes into them. In the past I would wait until I had everything documented before having a review. The old throw it over the fence mentality. Knowing the importance of having key stakeholders review the requirements, I adapted my approach and started reviewing small chunks of requirements at a time. Then when all the requirements are complete a final review is painless.

Here is an illustration of a basic flow to explain the process.

3mostimportant_sml
Click for larger image

There are two huge benefits with this approach in addition to avoiding people falling asleep in your meetings.

  1. You validate that you are headed down the right path. By reviewing a draft you ensure you are headed down the right path. If you wait until the end to review what you captured a lot of time will be wasted if you missed the mark.
  2. Stakeholders can absorb small chunks. It is very hard in one sitting to absorb and consume an entire project's requirements. By reviewing in iterations, it allows the stakeholder to focus on one area and really review the document.

When I speak to BAs about this approach a common reaction is, "I don't like showing a customer something that is not perfect." My response: "Get over it!" Requirements do not need to be perfect. They need to be accurate and enough for the team to build the right solution. It is better to find any issues early and make corrections.

I have also run into QA analysts and developers who don't want to be bothered reviewing requirements before they are "complete". You know what I tell them? Right, "Get over it!" Requirements definition is a team activity. All team members and business stakeholders need to work together to elicit, clarify and communicate requirements.

If you want to be a desirable business analyst ...iterate, iterate, iterate! You'll stay on track, and you'll have a higher rate of success, making sure the entire team understands and agrees on the requirements, which will lead to successful projects.

All the best,

Kupe

Don't forget to leave your comments below

Jonathan "Kupe" Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at This email address is being protected from spambots. You need JavaScript enabled to view it. .

Read 3686 times Last modified on Tuesday, 27 March 2012 13:46
Published in Kupe Kupersmith
Tagged under
Kupe Kupersmith

Kupe Kupersmith, President, B2T Training, possesses over 14 years of experience in the business analysis profession. He has served as the lead Business Analyst and Project Manager on projects in the utility, television and sports management and marketing industries. Kupe is a Certified Business Analysis Professional (CBAP) through the IIBA. Kupe is a trained improvisational actor and performed for years in clubs around Atlanta.  He is a big believer that we can work and learn while having fun. Kupe is a connector and has a goal in life to meet everyone!

Latest from Kupe Kupersmith

Related items

More in this category: « Mr. Business Analyst, You're Not a Good Fit! Business Analysts are Set-up to Fail »

Comments  

 
0 # Liz Dunn 2009-10-13 06:12
Kupe, I'm with you 100% on this one. The ABSOLUTE LAST time I want to hear about misunderstood requirements is the formal requirements review (ok, maybe it's in QA, but I digress :-). It is critical to iteratively review sections "in draft form" as you go. Multiple exposures to the structure/organ ization/rules of the document throughout the process should significantly lower risk in the long run. Also, quite selfishly, I hate rework so I want to be sure I'm on the right track before I spend too much time dotting the "i"s and crossing "t"s for a final document.
Reply | Reply with quote | Quote
 
 
0 # Cathy Brunsting 2009-10-13 09:27
Kupe, I agree too. Along with that principal, I like to break the requirements in a series of smaller documents (that can be reviewed and potentially implemented in pieces) to keep focus. Even if you review in pieces, if you just keep adding to one large document, business users, developers and QA tend miss details. Or, you end up creating the infamous "addendum" to highlight changes later in the process and dev & QA don't know where to go to find the actually information to implement and test.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2009-10-13 13:40
@lizdunn and @cathycmb, Tha nks for the comments and it sounds you fall into the desirable BA ctegory!
Reply | Reply with quote | Quote
 
 
0 # Todd Anderson 2009-10-14 05:22
Great blog - I think you are right on with this one. I'll add another angle to this. We are using an agile development methodology now (Scrum). We like to get a higher level draft written that helps clarify scope and get review on that. We then right more detailed functional requirements before each development iteration and review those with stakeholders. This helps avoid writing requirements that won't get developed and spreads the reviews out over the life of the project.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2009-10-14 13:01
@tplusfive - Good stuff. This concept can be used with any development methodology.
Reply | Reply with quote | Quote
 
 
0 # Nathan Caswell 2009-10-15 11:57
It is generally possible to break the sessions into modules that make sense interacting with each other. For example intermediate goals/checkpoin ts along a process. That way you can elicit and validate smaller chunks with better focused teams then validate the composition with everyone. Less work, better quality, fewer sleeping beauties. Rather like good unit test, good integration test, easy system test. :)
Reply | Reply with quote | Quote
 
 
0 # Alagammai Subramanian 2009-10-15 20:24
Great blog Kupe, I totally agree with the iteration concept. It is beneficial to all the stakeholders if the mistakes are found at the initial stages. Though, this approach might be time consuming, it proves worthy in the long run. If the subject to be reviewed is too lengthy, chances are high that the reviewer skips certain key items in the document for want of time and patience.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2009-10-15 22:17
@ncaswell - the unit test, integration test, system test note is right on! Thanks for the continued comments. @Ala gammai - Right on. The more to review the more that will be missed. Thanks for joining the discussion.
Reply | Reply with quote | Quote
 

Add comment

back to top