Rules of Thumb for Business Analysis

I’ve been thinking about what makes a good business analyst, and in general the soft knowledge is harder to pick up in many cases than explicit knowledge like accounting or marketing.  To that point, here are a few of the rules of thumb I try to follow.  None of them is particularly sophisticated, but I include them because they are the issues that people tend to neglect when rushing to finish a project or a deliverable.  These more ambiguous thought processes are often what separate good analysts (and for that matter decision-makers) from great ones.

The 80/20 rule

Most people have heard about the 80/20 rule (otherwise known as the Pareto rule), but it’s often ignored in practice.  Consultants in particular, myself included, often have a hard time not throwing every analysis and every recommendation against the wall.  Throughout your work, always ask yourself what will truly make the biggest difference and focus on that.  Do your best to ignore other issues, or at least put them in an appendix (literally and figuratively) where they won’t distract people from the top priorities.

Be skeptical

I’ve come to realize that whenever I come up with an amazing conclusion while working on a project, there’s about a 50% chance that it’s an error.  It could be due to bad data, a spreadsheet goof, or just not fully understanding the context of the situation.  So, the more astounding your conclusion is, the more you should treat it with skepticism.  Double-check your work and try to poke holes in your logic.  There’s nothing worse than showing off your idea to your boss or client as a crowning achievement only to realize that it’s just a mistake.

The same is true when talking to people.  Everyone in an organization has an agenda (shocking, I know), and many of them will try to feed you biased information to support their cause.  The more you want to believe it because it’s “interesting,” the most you should take it with a grain of salt and try to confirm it.

Correlation does not imply causation

When I show a number based on customer interviews to clients, one of the questions they like to ask is whether it’s statistically significant.  It’s not a bad question to ask, but if often misses the bigger point.  The biggest risk isn’t that you don’t have enough data points, it’s that there’s some confounding factor that’s the true cause rather than the data you’re analyzing.  Like epidemiology, business analysis is messy, and it’s very tough to be sure you know the real cause of something based on statistics.  Look at the data, but don’t forget to rely on judgment as well.

Unintended consequences

Always ask yourself how recommendations may play out in real life differently from how you have planned.  People will always try to game the system, and any change will almost certainly have unintended consequences.  If salespeople get quarterly bonuses, you can be sure that some of them will knock it out of the park for three quarters, make enough money to be happy, and then mail it in the fourth quarter.  If you offer customers a service for free, they will often use it even if they don’t really need it.  Anticipating these consequences is by definition difficult.  Rather than trying to eliminate them, try to make sure you can live with the ones that seem most likely.

The initial reaction to unintended consequences is to try to make processes more complicated to keep people from gaming the system.  Unfortunately, that often does not work, confuses people, and results in a more bureaucratic organization.  Which leads me to my next point.

Complexity cost

For every bright idea you come up with, consider the level of effort people will need to go through to comply with it, not just the financial cost.  The ultimate example of ignoring the cost of complexity is the IRS tax code, which single-handedly keeps millions of people employed dealing with its more byzantine aspects.  Don’t create industries within your company or your clients’ companies devoted to adhering to your processes unless it’s truly worth the cost.  If your recommendations do add a significant amount of complexity, perhaps you need to figure out a way to simplify other processes in order to keep things in balance.

Of course, this isn’t intended to be an exhaustive list.  What other rules of thumb do you keep in mind when thinking about business problems?


Related Posts:

  • No Related Posts
  • http://twitter.com/dwwright99 David Wright

    I am trying to figure out what your main deliverables as a BA, what are your inputs and what value do you add? Priorities? Conclusions? ideas? System recommendations? Because I am a BA consultant, and do none of these things.

  • http://www.brekiri.com/blog/ Greg4

    “Business analyst” is definitely an ambiguous term, and I should haveclarified what I meant by it. I'm looking at it primarily from theperspective of management consulting or internal analytical work, whichcould take place in a variety of functions including marketing, strategy,operations, and supply chain. The term is also used in IT work, but I don'tnecessarily have IT systems or requirements in mind.An example might be coming up with a new marketing strategy for a company. Inputs would include customer interviews, financial data, sales forceperformance metrics, and discussions with the management team. Outputswould include strategy recommendations and an implementation plan, andpotentially program management and training assistance. The work in themiddle would consist of qualitative and quantitative analysis.I hope that makes it clearer what I had in mind. What does your BA workinvolve?

  • http://twitter.com/dwwright99 David Wright

    Business Requirements, primarily for but not limited to Information Systems. I think what I do has co-opted the name “Business Analysis”, such as at http://www.iiba.com, though arguably what you do better deserves the name. As the ancient Asian saying states, “All Wisdom starts with calling things by their right names.”

  • Dua_ravi

    When thinking about Business Problems think of these four things and everything will get sorted out .1. What is the root cause of Problem ?2. What are possible solutions ?3. How do I communicate the solution ?4. What will be impact of solution ?For Example – Attrition is the problem for IT companies and a company does some data crunching and results are that people are leaving the organisation because of better prospects , here the root cause is better prospects is what a normal person will think however it is more complicated then that when you look at data it gives you direction but that direction may not always be correct one as a business analyst you need to create conclusions and not follow conclusions , in the example shared above the BA finds out real reason for attrition is better opportunities because there has been sudden demand for SAP skills and people who are SAP are moving out due to it . Now comes finding out what possible solutions are and BA can go ahead and list down all the solutions possible and gives a ranking to each of the solution after carefully interviewing people /customers and gives rankings to each of these solutions ..remember no solution is full proof and sometimes it is combination of solutions which may work so ranking solutions paves way for such situations. Next comes understanding impact of each solution , if the solution was to increase compensation the impact will be financial to company or may impact planned growth due to restrained financial resources to solve the situation at hand. Communication plays a pivotal role in how people percieve things and it should be handled with maturity and experts should be involved and if possible drafts should be prepared accordingly.

blog comments powered by Disqus