Six Sigma and the Business Analyst

Featured
47682 Views
10 Comments
56 Likes

I began my career at Cap Gemini Ernst & Young where doing business analysis and implementing large scale systems was my job. At that time, I just thought everyone intrinsically knew you had to understand the business and all the requirements before you begin designing a system (whether custom built or off the shelf). When I got out in the real world that"s when I realized corporate America had not yet fully embraced the idea of conducting business analysis internally and the profession itself was actually in its infancy. I was ever so grateful for the appearance of the International Institute of Business Analysis (IIBA) in the 2003 / 2004 timeframe to start to bring a level of legitimacy to a profession that was deeply needed in IT shops across the country.

In some ways, I feel I have grown along side the profession. Very early in my career the IIBA did not exist, then mid-way in my career it came to fruition, and now as they continue to drive new, and different conversations about the role of business analysis in the modern corporation; I find myself in the same position - attempting to provide leadership in an ever evolving and still much needed field.

I give you this background to give you context to my ah-ha moment as I sat in yellow belt training. To me, it is a rigorous and well tested process for conducting business analysis whether the solution is technology or not.

As we walked through the methodology it sounded curiously familiar to the Enterprise Analysis chapter in the Business Analysis Body of Knowledge (BA BOK). The interesting part is that regardless of what you call the activities, every organization should be doing them and have people proficient in doing them.

The six sigma continuous improvement methodology follows the DMAIC approach which involves:

  • Define
  • Measure
  • Analyze
  • Improve
  • Control

Define simply has to do with defining the problem. As business analysts" we can use problem statements to define this, we also typically scope a project from a business perspective where you may create a context level dataflow diagram. The purpose of this activity is to simply understand the problem and put some boundaries around what you are trying to solve.

The Measure activity is what really intrigued me and seems to be the area we have been missing in the business analysis world. Many times we present information based on hunches or previous experience whereas with measure, you focus on the facts. This is an extremely powerful aspect of the six sigma methodology. It says, 'you think there is a problem, but let"s find out if there really is". In other words, what may at first seem like a problem may not be the problem at all but you can only determine that through gathering metrics. The six sigma methodology recommends things like the time series plot and pareto charts. If you are not familiar with these types of artifacts, I recommend taking a class or at a minimum, googling to get more information.

Analyze again provides power and I think this is an area we are still struggling with as business analysts. In this field, there continues to be this behavior where a solution is decided before true analysis is even done. As an example, on a project I was on, the leadership team insisted the problem was the technology supporting a specific business area. Essentially, they said the technology was no good. After doing a root cause analysis, it was determined the real issues had to do with amount of time it took to make a request and receive a response from the IT team. The technology itself was not the problem, the process around it was.

Improve has to do with offering up solutions. Again, it is important to look at all possible solutions to a particular problem. From the example above, one the solutions was to improve the process and response time for the business from the IT team. Although it may not be widely supported in your organization, I still challenge you to look at a problem from all the angles and provide objective solutions (even if the solution has already been dictated to you). At the very least, you may uncover some additional requirements through your detailed analysis. There are several benefits you will reap from this approach. As you begin to provide valuable information to your leadership, you will become the go-to person. Leadership typically wants a well rounded picture before they make decisions. You can help provide a view of all the possible solutions. In addition, you will be adding to your repertoire of skills and improve your own marketability (which is important in this world of ever increasing lay offs).

Control has to do with monitoring a project all the way through its lifecycle and evaluating the results at the end. This is yet another opportunity for business analysts to take it to the next level. In the last 10 years of my career, we continually fall down in this space. We don"t do a good job of measuring whether we were successful or not. When we don"t do a good job of measuring success, every project begins to look like a failure. If you look at the statistics, there are still a high number of IT projects seen as failures. What are we doing wrong? There are several pieces to the problem (which I will save for another article) but one piece most definitely is not establishing critical success factors up front (another six sigma trick) and then measuring against those at the end of the project.

In conclusion, whether you are a business analyst, business architect, customer engagement manager, client engagement manager, enterprise business analyst, system analyst, project manager, or any other title we can come up with and whether you are a six sigma shop, a BA BOK shop, PMI BOK shop, a Lean shop, or an Agile shop - I hope you are doing these activities. We should all be doing these activities to make our projects more successful.


Author: Kimberly Terribile is a Manager of Business Analysis in the Clinical Trial Operations group within Development and Medical Informatics at Pfizer. She began her career with Cap Gemini Ernst & Young in 2000 and spent 5 years working on a wide variety of large scale software implementations across telecommunications, government, and health care insurance. In 2005, she went to ESPN where she became the Manager of the Business Analysis group. Subsequently, she accepted a position to teach business analysis with a niche training vendor. She also did curriculum development as the Director of Product Development.

Like this article:
  56 members liked this article
Featured
47682 Views
10 Comments
56 Likes

COMMENTS

Sanat posted on Tuesday, September 8, 2009 10:56 AM
Hi,

Thank you for a informative posting.

I am presently working as a 'Business Analyst' in an software company. My role involves Requirement gathering, Facilitating JAD sessions, Configuring Organizational and master data, performing UAT and insuring all functional and non- functional requirements are met.

Can you please inform from where i can get the knowledge on six sigma and how it can help in my career.

Thanks

Sanat
sanat235
zarfman posted on Tuesday, September 8, 2009 9:55 PM
Ms. Terribile:

I tend not to view business analysis as a profession. In my mind a profession has a statutory basis for its existence. Some examples are; MD; CPA; PE (Professional Engineer); etc. In most states, if you hold yourself out as a MD, CPA or PE and are not, you end up in court and face a fine and/or jail time.

I’m not sure of the order of Measure vs. Analyze. Every Statistician that I’ve worked with always said design the experiment before you start collecting data. This assumes metrics are a form of data.

What may at first seem like a problem may not be the problem at all. I agree, unfortunately, after the actual problem is defined evil still lurks. It’s called the three part lag. First the problem must be discovered, then a fix must be proposed and implemented, and then did the fix work. Each step involves the passage of time. If the fix doesn’t work, what steps have to be taken? Considerable misery can be visited on a company during this time including paying a large fine or filing for bankruptcy protection. Few things help more during this time than very smart competent employees.

The time series plot and Pareto charts. I strongly suspect that the analysis of a time series plot is beyond the capabilities of most business analysts. Actually decomposing a time series requires a good understanding of statistics and mathematics. For example, time versus frequency domain analysis, linear versus nonlinear etc.

Root cause analysis, as far as I can remember there are several different analytical techniques available. Two that I remember are Bayesian inference and Kepner-tragoe. This begs the question, how does one select the proper technique from among several available alternatives?

Provide a view of all the possible solutions. Perhaps providing all possible solutions may overwhelm and/or confuse rather than enlighten management. Maybe Pareto aka the 80 – 20 rule could be of use.

Regards,

Irritable old CFO.
zarfman
Steve Jones posted on Wednesday, September 9, 2009 5:04 PM
One of the things I miss about Six Sigma since moving to other companies... the ability to be involved early in a project for Define and Measure (think Enterprise Analysis). For some of us, this was the only meaningful experience with Enterprise Analysis. 6 Sigma takes the time to not only document current state, it also finds out the important factors to the business customers so you aren't just trying to elicite future state requirements in a void - there's something there and measurable! It provides the perspective that Kimberly mentions into the range of solutions, not just the one chosen that many of us have to try to implement as we are brought in after the decision for the solution is complete (and typically no insight into the alternative ideas presented).

I also like the fact that 6 Sigma asks you to not only define the success criteria for Control, it also includes the measurement during Control as part of the overall project and doesn't let the project team just "turn it over to maintenance" after the warranty period is complete. Its a process that goes from cradle to maturity - you did the project for it to grow up, not die off .

Unless your company already embraces 6 Sigma and has training available, the best place to go (state-side) for information is probably the American Society for Quality (www.asq.org). The tools for 6 Sigma can be a lot of fun to use but unless you have the opportunity to apply them on real projects, you will lose much of the value of the training.

Have fun with it whenever you can,

A Hartford BA
Steve.Jones
cvestal posted on Friday, September 11, 2009 11:34 AM
Zarfman, your comments are interesting but one of the assertions made in the article is how to advance Business Analysis as a profession - including standardization and certification processes for business analysts. There was a time when there was no bar exam or medical board exam to pass those wishing to practice law, medicine, accounting, etc... As asserted, Business Analysis is a new profession, just as CTO and CIO are relatively new appendages to the executive levels of corporations.

Business Analysts serve a vital role as a layer between business and technology departments within organizations. Increasing value by learning how to interpret Pareto charts may have some validity - especially when it may be necessary to correct irritable CFO's who may not have the complete story. Of course, we will continue to correct and instruct following all appropriate protocols and professional courtesy. :-)

CV
cvestal
Jeff Carlson posted on Friday, September 11, 2009 11:50 AM
The one thing I noticed about this article was the almost complete lack of the concept of user or customer in the discussion. The idea that the BA "thinks" up the requirements is really quite silly.

To quote the article, " Many times we present information based on hunches or previous experience whereas with measure, you focus on the facts. This is an extremely powerful aspect of the six sigma methodology. It says, 'you think there is a problem, but let"s find out if there really is". In other words, what may at first seem like a problem may not be the problem at all but you can only determine that through gathering metrics. The six sigma methodology recommends things like the time series plot and pareto charts."

Wow ... How about you do the real work of the BA and work with the END USERS to determine their requirements. Time Series Plots ??? That is the sick sigma solution ?

Business Analysis is an art and thinking you can learn how to do it well thru some sort of cookie cutter training like 6 sigma is laughable.


lackawaxen
zarfman posted on Saturday, September 12, 2009 12:04 AM

CV et al:

I would be thrilled to see the business analysts acquire the same level of certification and or licensure as MD’s, etc.

I freely admit that over the years I’ve become cynical and irritable. The following are but two of the examples that have influenced my views on business analysis and IT in general.

In one situation I was a regional controller or comptroller if you prefer. The company decided to install a corporate wide accounting system. Because each region had a different system some computer based, some manual. We regional controllers specified very precisely what we required. We never got anything close to what we could use. Accordingly, project and overhead costs got out of control. The company had financial difficulties and ended up being bought out by large well run company. The shareholders were nearly wiped out and hundreds of employees lost their jobs (including yours truly).

In the year 2000 I was financially involved in a start-up. The company provided internet based spread sheet, word processing and other services. It turned out the self proclaimed genius systems architect, most of the programmers and the DBA’s were idiots. Much sound and fury, very little actual usable product. That screw up cost me $3,000,000.00. All told investors lost $225,000,000.00. The only ones making money now are the lawyers.

I hope this gives you some insight in why I tend to be cynical, irritable, highly suspicious and critical of IT. However, I still need the financial and accounting software

Anyhow, I’m done with this thread. I eagerly await next months Modern Analyst.

Regards,

The old irritable CFO
zarfman
rayc posted on Sunday, September 13, 2009 12:37 AM
Interesting article, provoking discussion.

The techniques referred to are all good stuff, and to people who have been BAs/SAs for a long tine, as I have, they have been around in various guises for a long time, not just Six sigma (which does not seem to be very widely used in IT projects here in the UK), at least not in my industry sector (Insurance)

Following on from some of the points raised above, I think the main learning is that a BA should have available to them all/any technique(s) that can help them to do the analysis tasks, but the techniques should not drive the analysis tasks, only help in achieving them.

For example I recall from many years ago, when 'methodologies' such as SSADM were popular, having a meeting with peer BAs and expert users where we walked through (walkthroughs being perhaps the best 'quality technique!') a set of DFDs (Data Flow Diagrams) and the BAs spent half the meeting arguing about whether the DFD followed the 'method' correctly etc, and thus completely alienated the users who the refused to discuss further DFDs.

One of the techniques that I often use now is the 'State Diagram'; a simplified version of the technical version (State Machine, or 'State Transition Diagram') that users can understand. When discussing requirements with users, business entities often go through several 'state' changes (e.g. a life assurance policy might go from 'proposal' to 'in force' to 'cancelled' or to 'lapsed' then maybe back to 'in force' again) so a simple diagram helps to extract from users the business states and explain what should cause a change from one state to another.

Basically, when there is a need to use a particular technique, do so, and modify the technique so that users are not alienated by it but see the benefit, but do not drive the analysis by any particular techniques.

I appreciate that this takes experience and if the site standard is to use a particular set of methods, it might be difficult for a more junior BA to resist, but in the end common sense must prevail.

Sorry to have veered away from the Six Sigma specific points

Regards

RayC
rayc
Steve Jones posted on Monday, September 14, 2009 10:01 AM
To follow up on this series of comments:

"Wow ... How about you do the real work of the BA and work with the END USERS to determine their requirements. Time Series Plots ??? That is the sick sigma solution ?

Business Analysis is an art and thinking you can learn how to do it well thru some sort of cookie cutter training like 6 sigma is laughable."

With these comments, it shows that you know nothing about the 6 Sigma process or methodology and are making assumptions based solely on the article that you doin't fully understand.

I'm sure you've found in your experience at some point that users don't always know 1.) what they want and 2.) what they even have.
6 Sigma helps them understand what they have by finding out what their key performance indicators (kpi's) are and sets out to measure them initially (as well as documenting current state in the process). From this baseline, the customer can make informed decisions on whether their original KPI's were still valid and what their requirements are going forward in a future state.

The only thing cookie-cutter about 6 Sigma (when applied correctly) is the process of evaluating the impact of a problem and potential solutions prior to investing boku money for a project. With 6 Sigma, when/if a project is cancelled, the number of people impacted is much smaller because there has been more work done by a few prior to full project launch/kick-off.

As analysts, we are supposed to understand current state as part of the process before eliciting requirements for the future. Try practicing a little of your own work instead of bashing what you don't really understand (because you were too lazy to bother).

Hartford BA
Steve.Jones
Tony Markos posted on Wednesday, September 30, 2009 12:57 PM
Great article! A couple of comments of the Define portion of DMAIC.

1.) Proceeding in a purely top-down fashion on larger scale projects is often next to impossible - no one has that level of knowledge at the start. So typically the team must create some lower level data flow diagrams and then summarize them upwards into a context diagram.

2.) As I have experienced and read, the biggest boggie in the "Define" phase is identification of process INPUTS. Typically, identification of process outputs is realatively straight forward; but, most often, even the process experts can not rigorously identify process inputs.
ajmarkos
Nidhi posted on Sunday, February 24, 2013 11:47 AM
Hello Kimberly

Awesome article!!

Your comments about undervaluation of the Business Analyst's role really resonated with me. I have been contemplating creating a business case on how Business Analysts can add value to the organization. But I do feel its going to take baby steps to bring about change.

My company follows a strict waterfall method and I work as a BA on the IT side. I would love to get your opinion on at what stage can we initiate this change.

When a project is submitted by the business should we introduce Lean Six Sigma process at the Initial Gap analysis phase? Where in the process of development does it fit best?

Thank you so much for sharing your knowledge and expertise!!
Nkulkarni
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC