A few months ago, I wrote about perfection with respect to a "perfect" methodology.  This month, I'd like to address behavior I've seen with respect to producing "perfect" deliverables.

I'm a big believer in the quote by William Fowble:

If you chase perfection, you often catch excellence.

The important thing is not to get so caught up in the chase that you lose sight of the value you are delivering.  Unfortunately, I've seen that happen to otherwise excellent business analysts.

The nature of business analysts is to be detail-oriented.  Most BAs I know also want to deliver their best work.  But sometimes these two traits become a hindrance rather than a help.

Fundamentally, the role of a business analyst is to take an amorphous mass of information and "factor" it into component pieces — terms, processes, business rules, business decisions, etc. — and then synthesize the pieces together to produce a business solution in the form of a business model.  It is an iterative approach, continually reassessing (and sometimes radically changing) your initial findings as you learn more.

It's somewhat like an archaeologist who delicately brushes around a set of bones until a full skeleton is revealed.  However, some BAs insist on digging up the entire skeleton before sharing any results.

At any point during the analysis, you could potentially be 'wrong'.  And this, I think, is what trips up some business analysts.  Nobody likes to be wrong; so to avoid this, I see a common pattern of:

1. a set of activity with the business stakeholders (facilitated sessions, interviews, etc.),
   
   
2. a long gap while the BA documents the business model in great detail up until the very last minute,
   
   
3. a period of validation with the business.

It is the long gap that can cause problems:

• The stakeholders are drawn back into their day-to-day activities thereby losing their momentum and context.
  
  
• By the time the validation sessions start, the stakeholders have forgotten their initial thoughts and need to essentially start from the beginning.
  
  
• The stakeholders lose their sense of ownership if they haven't shaped the business model all the way through the analysis process.
  
  
• The stakeholders don't get comfortable with the representation of the business model.  It becomes something the business analyst needs to do for their own purposes rather than something of value to the business.
  
  
• There is no time to course correct if the business model is incorrect.

Given the iterative nature of the analysis approach, it's important to review your results with the stakeholders as you go.  I always preface my reviews with caveats that the results are a work-in-progress and are subject to change.  In addition, all my outputs have the word "Draft" clearly visible on every page, usually as a status against each business rule, task, term, etc.

Another tip is to document your uncertainty in the form of comments/notes.  For example, I always have two sets of comment fields when I document business rules — one with questions/issues/comments for the stakeholders, and a "BA Comment" field that is for BA eyes only.  I use the latter to document the state of the rule.  (My most frequent BA Comment is "needs more analysis"!)

Conclusion

Let me conclude with another favorite quote, this one by Harriet Braiker:

Striving for excellence motivates you; striving for perfection is demoralizing.

Although it may seem risky to share work in progress, your results will be better if you get input from the stakeholders all through the analysis process.

All quotations are from BioQuotes, a quotationary.  At www.bioquotes.com  

Building Business Solutions:  Business Analysis with Business Rules by Ronald G. Ross with Gladys S.W. Lam (2011, An IIBA® Sponsored Handbook).  

Business Rule Concepts:  Getting to the Point of Knowledge (4th edition, 2013) by Ronald G. Ross  

# # #