Article Menu

Tuesday, 18 October 2011 13:38

Why Business Analysis Processes are a Waste of Time

Written by 
Rate this item
(0 votes)

Kupe_Feature_Oct18_CroppedI recently read a sales blog post, Why Sales Scripts are a Waste of Time, where the author talked about the need for sales professionals to adapt their approach based on the customer they are selling to and not follow a standard script or process they learned through sales training.  Rather than follow a process step by step a sales professional should use the steps as a framework.

The same applies to the business analysis community and a business analysis process. There are techniques, skills, tasks and approaches you have at your disposal.  It is the collection of those that will help you adapt your approach for each project.   The projects our community works on are not to build widgets.  The Ford Motor Company requires a consistent manufacturing process. Ford wants to make sure every Ford Fusion that is built looks and acts the same.  They fine tune their manufacturing process and make sure it is as repeatable as possible. There are steps that are followed A to Z with no deviation to ensure consistency.  Yes, different lines of a model include different steps, but you get the picture. 

In manufacturing following a process step by step is a good thing. In our world this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project. With that said there are two must steps.  One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible.

At the beginning of a project or iteration you and the team need to plan the approach.  The team needs to determine what steps you’ll take during the project.  You as the expert need to provide your thoughts and advice for the analysis steps, but you should not determine your approach in a vacuum.  Your team needs to buy-in to the approach and ensure their needs will be met to ensure a successful project. 

Things never go perfectly, so you should be inspecting your approach as you go and make adjustments.  At the end of a project or iteration you should inspect and learn to improve for your next initiative.

Let me end by stating I don’t think you should have to make everything up in between your plan and retrospective for every project.  You should have a base approach that you use as a framework.  Just use that as a starting point to add and/or remove steps to customize your approach for the specific project. 

All the best,

Kupe

Don't forget to leave your comments below.

Read 10727 times Last modified on Monday, 02 April 2012 16:19
Published in Kupe Kupersmith
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

More in this category: « Why Bother with a Business Analysis Center of Excellence The Business Analyst’s Citizen’s Arrest »

Comments  

 
0 # Jon 2011-10-18 07:19
Kupe, you are a master of rhetorical Blog titles. Once again the BATimes email caught my eye. I agree mechanical or algorithmic work differs vastly from heuristic work. As you point out, project work that a BA does not typically fit an algorithm. There are far too many variables in each individual project, this is without even counting the single biggest variable of all…the human element. BAs need a framework to follow, best practice knowledge areas, and most of all the ability to adapt these to the ever changing project conditions.
Reply | Reply with quote | Quote
 
 
0 # Cathy Brunsting 2011-10-18 07:27
Very nicely put Kupe (as always!). Proc ess is one of those funny things. Too much or too little can both be detrimental to a project. When you have a total absence of process, you often get chaos and no repeatabliity. I have worked in such environments. I once worked for a company that had a website in production that they could not make changes to. The person who worked on the project did everything in a vacuum - no requirements, no source repository (other than their own machine), no back up! When the original developer left the company, the source code disappeared!! But, having too much process can be just as bad. Teams end up spending more time on adhereing to an out-of-date or inappropriate process rather than focusing on delivering business value. I worked for a company once where the businesses main complaint was that they could not get new functionality fast enough. The IT group's answer was to develop a process that had something like 20 gates that every project had to go thru (only the first 5 gates were requirments process gates) - to ensure that we were delivering proper quality! Needless to say, the projects did not get delivered any faster :-) Nor did the quality of the projects improve!! Really high priority projects often went rogue to work around the process - the business users generally considered these the more successful projects. Like you, I prefer to see process as guidelines - a starting point to begin looking at the problem. But, you always need to be able to adapt to the needs of the project.
Reply | Reply with quote | Quote
 
 
0 # Slava 2011-10-18 07:30
It's a bad idea to consider analysis process as step-by-step instrucstions. Define processes which allows some freedom, which would not restict analysts practices, however will remind that this or that should not be skipped or that these activities must be done before those. This point if view on processes makes them very efficient.
Reply | Reply with quote | Quote
 
 
0 # Greg Busby 2011-10-18 07:53
Kupe, Nice article, and so true. When we were developing our BA practice a few years ago, we got a lot of pressure from management to create and publish a Methodology; after all, the PMs have one. We resisted to a certain degree and came up with a Framework instead, with a simple mantra: "If it doesn't add value, don't use it". We have checklists, templates with explanatory text, example diagrams, and all the rest, but none of it is prescriptive. Your article gives a concise explanation of why we did that. Well done.
Reply | Reply with quote | Quote
 
 
0 # Greg Busby 2011-10-18 08:05
Kupe, well written as always. When we were starting our BA practice a few years ago, we got some pressure from management to create and publish a Methodology. We resisted, and instead developed a Framework with templates, checklists, examples and guides. Our mantra is: "If it doesn't add value, don't use it!". By taking this approach, we've managed to avoid nearly all the complaints about too much overhead that a heavy-duty methodology often engenders. Your article neatly and concisely explains why we did what we did; I wish I'd had it then. Thanks!
Reply | Reply with quote | Quote
 
 
0 # Jon 2011-10-18 08:24
@Greg - Had a similar experience at my current employer. I like your desciption of "Frameworks...a nd guides." as the way you defined your practice. As you mentioned, I have also found examples to be very helpful. I definitely think many BA communities of practice should adopt the mantra that you mention "If it doesn't add value, don't use it!" ...and if you do create it, be sure to tailor your artifact to meet the needs of the intended user (audience). Often we create artifacts that are thought to be useful, that have no audience.
Reply | Reply with quote | Quote
 
 
0 # Kyla 2011-10-18 08:42
I'm pleased to see syour article. It is a way back to common sense, but it may be too late. You need to be louder.
Reply | Reply with quote | Quote
 
 
0 # Ian Gomez 2011-10-18 09:52
I think we're confusing 'process' with 'detailed work instructions' or 'flow diagram' - the terms are not synonomous. Whilst process documentation may contain a flow-chart or work instruction, I would suggest that the base approach which you use as a framework really does meet the criteria of process documentation - i.e. it documents actions which bring about a result. The issue is with the level of prescriptive detail in the process - the further down you go the less judgement is involved. With processes with variable inputs and outputs as well as uncertainty caused by under-definitio n and external impact (such as the process of scoping a project), the level of prescriptive detail you can expect to get to is reduced. Hence why I believe the classification of 'judgement worker' is probably more appropriate for BAs than 'knowledge worker' (one to think about - good judgement requires knowledge, but the reverse is not true).
Reply | Reply with quote | Quote
 
 
0 # Marcos Ferrerand 2011-10-18 13:18
Hi, Kupe, great article! I like to think that the root cause of "variable BA process" is the fact that every project is a "learning" for the BA and the organization. If we knew how to do it for this circumstance, we would have done it already, which we haven't. Learn ing curves are hard to predict or plan. When asked "What to do?", my first response is "What is actually happening?". When asked "What RA modeling technique to use?" my first response is "What is still confusing, causing debate, disagreement or misunderstandin g?". Track the "state of the learning" to help adjust the process - a BA Plan can be a good "curriculum" guide, but remember that the point of the project is not to "pass or fail" the participants based on whether they can keep up with the material. The point is to get the participants up to speed, in order to succeed, team and stakeholders all. Have fun!
Reply | Reply with quote | Quote
 
 
0 # Od 2011-10-18 18:05
Kupe, The title of the article is a nice lesson in marketing. To me its a bit of the devil's alternative. No process - bad. Rigid process - bad. I guess the efficacy of process application on each project is dependent on the experience and artistry of the BA.
Reply | Reply with quote | Quote
 
 
0 # Gagan 2011-10-18 19:00
I guess business processes are not a bad thing. All organisation need processes. The bad thing is 1) making heavy weight processes which are difficult to make and follow, so making lightweight process is a good way. 2) believing existing process is the only way, but in principle existing process are just a framework or representation of old world. In today's world, the old processes need to be changed to reflect current situation, current project, new way of thinking.
Reply | Reply with quote | Quote
 
 
0 # Craig Willis 2011-10-18 22:35
Great post, I agree strongly on this, if the process is defined to too much detail, in order for analysis to be performed, the chances are people are not doing it in the prescribed way. I wrote this week (http://wp.me/p1KGaW-1U) about how workers should be given enough information for them to be able to construct their own understanding of processes. Providing the right information at the right time and giving workers the freedom to rely on their own expertise to achieve their goals.
Reply | Reply with quote | Quote
 
 
0 # Ian Guenard 2011-10-18 23:08
When you use cookie cutter processes, you end up with cookie cutter solutions. =)
Reply | Reply with quote | Quote
 
 
0 # Dave Schrenk 2011-10-18 23:29
Spot on Kupe!
Reply | Reply with quote | Quote
 
 
0 # Tom Ryder 2011-10-18 23:49
Kupe, when I first read title of your blog I said, "What?" However, I have to agree with Jon who said you are the "master of rhetorical Blog titles". I think a standard process is necessary to provide but agree that business analysis is not performed step by step or paint by numbers the same way every time. Every project is different and this this requires BAs to think, analyze and solve problems.
Reply | Reply with quote | Quote
 
 
0 # Mary Gerush 2011-10-19 00:10
I couldn't agree more. I advocate that BAs take a toolkit-driven approach. Fill your toolkit with techniques, templates, samples, and a selection of tools, and use your business and technical knowledge and analytical abilities to use it in the most appropriate way. I really appreciate that you emphasized the planning process. In my research and experience, I've found that BAs often don't plan at all (likely because they are either added to the project team late in the game or because they have been told to follow a prescriptive process, so they don't consider how the project context should influence their requirements approach). One additional note: To define and follow the right adaptive approach, BAs need to have a strong understanding of the business and technology context, stakeholders, risks, and constraints. They also must have powerful soft skills to analyze the situation, plan their approach, and lead the stakeholders down the path to good requirements. I include business/techni cal knowledge and soft skills as critical components of a BA's toolkit. Reall y nice article. Thanks!
Reply | Reply with quote | Quote
 
 
0 # Claudio Br (Kerber) 2011-10-19 00:54
Kupe, this is really going to help me in my discussions with pratictioners in Brazil. People here are obsessed with planning the perfect process and to stick to it forgeting that, like you said "Every project is different. Different people, different risks, different priorities, etc." and forgeting something even more importante: LEARNING. Lear ning leads to change, so, it is hard to think about an unchanging defined default process. Thank s!
Reply | Reply with quote | Quote
 
 
0 # Suzandeise ("Susan Daisy") 2011-10-19 02:22
Right on, Kupe! I also liked Mary Gerush's comment about the "toolkit-driven approach". That's what good BAs do. And it's a lot easier said than done...
Reply | Reply with quote | Quote
 
 
0 # Cecilie Hoffman 2011-10-19 03:30
Kupe, your article titles make the hairs on my head stand up straight.
Reply | Reply with quote | Quote
 
 
0 # Ken Livingston 2011-10-19 10:08
Good stuff, Kupe, but it presupposes that the BA has a broad enough knowledge of various methodologies to be able to pick and choose the most appropriate for the project or environment. Mary Gerush quite right points out that we need to fill our toolboxes with a collection of tools, and a lot of that comes from education, training courses, peer exchanges, past successes and failures, and current and past work environments - in other words a heap of experience. Thinking on that a bit more - I guess it's a distinguishing feature of a senior or principal BA - one who can look at the task at hand, recognise how it fits the pattern of previous (and maybe theoretical) work, and map out the most appropriate approach.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-10-19 22:24
@Ken - Yes it does. And this is why many BAs struggle. If a less experienced BA is left alone on a project they are set-up to fail. This is a reason, I consistently push for organizations to rethink their org structure so the senior BAs with the right level of knowledge and experience can mentor and guide the junior BAs. With that said. Our community now offers many opportunities to learn and find "mentors" with online communities like BA Times, LinkedIn Groups, Twitter, etc. Even if a junior BA does not have a go to person in their company, they have us!
Reply | Reply with quote | Quote
 
 
0 # Lorie Karpyn 2011-10-20 00:16
Thanks for backing up the standard answer of "it depends"!
Reply | Reply with quote | Quote
 
 
0 # KHo 2011-10-20 02:07
Wow. Wish I could say general comments with a thin grasp of the English language, and get so many accolades! Keep up the mediocrity, Kupe!
Reply | Reply with quote | Quote
 
 
0 # Dennis Nelson 2011-10-20 08:02
There has to be enough "process" so the effort that has been expended can be repeated and the iterative results tested against each other; and not just by the original individual but by others as personnel turnover occurs. Also, there has to be enough "process" so the BA data, information, knowledge and discernment can meet the input requirements of the other teams and the other teams' output can meet the BAs' input needs. The members of every team (project, football, basketball, volleyball, etc.) with multiple members must have a common context and "plays", and the rules, roles, responsibilitie s, relationships and results clearly defined. There must be constant and consistent commitment, individual and team practice, and transparent and genuine communication. All of that requires "process".
Reply | Reply with quote | Quote
 
 
0 # rduboistx 2011-10-21 05:58
Great attention grabber. You are the master at what the heck is he thinking. Great conversation by all the contributors. From my perspective what we do as BAs is half art and half science. Throw in a little process, a little framework, a little this and a little that. We have our toolboxes and we have our experiences. In almost everything we do we are trying to capture the human experience, thought and actions. You can't cookie cutter your way or assembly line that activity. In reading through this I thought of the Clint Eastwood movie Heartbreak Ridge - we are paid to adapt, improvise and overcome.
Reply | Reply with quote | Quote
 
 
0 # alien 2011-10-21 06:49
good article.
Reply | Reply with quote | Quote
 
 
0 # ted 2011-10-21 09:51
too bad corporate governance makes this impeccable advice impossible to adhere to.
Reply | Reply with quote | Quote
 
 
0 # Kimberly 2011-10-21 22:31
Every project has it's own personality!
Reply | Reply with quote | Quote
 
 
0 # Ann Bergquist 2011-10-21 23:38
Good title - I had to read this article. On target as usual. P.S. Great job at NJ IIBA this week - useful advice for UAT testing, again with your wonderful sense of humor.
Reply | Reply with quote | Quote
 
 
0 # Lisa R King 2011-10-22 06:20
As a former Ford IT employee, I must say that the Solutions Delivery Methodology or formerly the Systems Life Cycle (SLC) in the early 90s was quite a bit for many of the systems folks to wrap their minds and daily project tasks around. However, as project costs continued to rise and defects were found in later project stages such as late Design and even in some cases post-testing, the need for refined, clear and concise business requirements upfront became amazingly clear. In particular if defects or requirements missed altogether resulted in rework or re-engineering efforts meaning additional costs and time incurred to complete a project effort. Ford developed its of internal Community of Practice and a streamlined, fine-tuned BA training program to ensure requirements elicitation and documentation was done correctly in the earlier project stages. This resulted in more robust projects and delivery of quality systems with minimal defects in many cases. Doing the true BA work of investigation and study, building business acumen, rapport with business partners, and thoroughly documenting the business processes seemed time consuming in the beginning but paid off in ROI in later project results positively impacting the bottom line. Business Analysis in my opinion as a certified business analyst for a decade, is not a waste of time, but a cost and time saver when done appropriately. All experienced BAs know that you must often tweak the methodology during a given project to document as required in the cost/timing constraints given to get the best quality delivered to the end-customer. The customer is never as concerned about the methodology, as they are the functionality the process describes, which should work like the great pictures we draw in the end that we took up their time to develop doing this wonderful thing called business analysis and requirements gathering. When the results are delivered and the product works as it’s supposed to, the BA value is realized and rewarded. When this happens the customers are more willing to free up time to work in concert with the BA staff one projects to get those results repeatedly and consistently on future efforts.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-10-23 20:28
@ Lisa - Thanks for sharing your story. These are the stories need repeating. Your last paragraph starts with "Business Analysis in my opinion as a certified business analyst for a decade, is not a waste of time, but a cost and time saver when done appropriately." I hope you don't think I am saying business analysis is a wast of time. I am saying a prescribed process for every project increases the chances for wasting time. In my unscientific research, enough people do not "know that you must often tweak the methodology during a given project to document as required in the cost/timing constraints given to get the best quality delivered to the end-customer." That's why I wrote the blog.
Reply | Reply with quote | Quote
 
 
0 # Martin Schedlbauer 2011-10-24 01:36
@Kupe hit is right. Processes are guidelines. They guide you along a path and make sure what things you might need to think of as you do your work. Good processes are not prescriptive. I think that any time you have a prescriptive process with prescriptive templates you end up wasting a whole lot of time and effort. Provide template so that analysts know what they should think about, but if it does not make sense for this project or if the value of some artifact does not exceed the cost of developing the artifact, then DON"T DO IT -- too many of my clients do much of their BA work because "it's required" or "we have always done it that way" or "the PMO uses this mandatory template:.
Reply | Reply with quote | Quote
 
 
0 # Bennett Mendes 2011-10-24 03:28
Kudos to Kupe for having the courage to come clean and call a clunker a clunker. I recall a project some time ago where the PM required all team members to attend a Data Modeling exercise led by a Consultant from a well-known (and expensive) company. Where there may have been some value to it, it was miniscule and not worth the time, effort or expense. Considering that the solution was a COTS one, there was even less justification for the exercise and was held against the PM by various stakeholders. The lesson was learned - before you embark on a pathway, be aware of the value it will bring to the process/project . I can almost envision many BA processes being worked on right now as I write that are, as Kupe kalls it ' a waste of time '
Reply | Reply with quote | Quote
 
 
0 # steve blais 2011-10-26 09:48
Figures, Kupe. I get a business analysis book published that describes a business analysis process and you come out with an article that says we don't need no stinkin' processes. Fortunately the book suggests strongly that there really is no hard and fast, right and absolute process any more than there is a silver bullet. The key is that the business analyst must constantly think, appraise, evaluate and select focusing on what is necessary to solve the business problem. As for processes, to paraphrase Groucho, I wouldn't want to be part of a process that would allow me to follow it.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-10-26 20:21
@Steve - Great job with your book. I would not expect us to have opposing views here. What's the title of the book...how do we get a copy?
Reply | Reply with quote | Quote
 
 
0 # steve blais 2011-10-27 03:23
The book is Business Analysis: Best Practices for Success from John Wiley. It's available now from some sources and generally on November 8. You can pre-order it from Amazon or B&N or Wiley. You are right in that there are no opposing views. In fact, you are included in the book
Reply | Reply with quote | Quote
 
 
0 # June Bosland 2011-11-01 08:42
Ever so true and it is reality - it is great to see this reinforced! Thank you.
Reply | Reply with quote | Quote
 
 
0 # Blair Loveday 2011-11-02 12:04
Why am I not surprised. Nice posting Kupe…a practical BA.
Reply | Reply with quote | Quote
 
 
0 # Ron Ross 2011-11-28 01:01
Kupe, I think you are saying that a 'business analysis process' is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a 'social process' or 'dynamic process' or 'case-based process'. Such a process is: * 'Social' in that interactions at various times with various people with various kinds of know-how must be orchestrated for acceptable results. * 'Dynamic' in that the 'flow' is more situationally-b ased than straightthrough (static). * 'Case-based' in that 'flow' of events is dictated by the case (project) at hand, rather forced conformance with an ideal. Let me make a couple of observations (which are not points of disagreement): * There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/ case-based rather than traditional/sta tic/straight-li ne. Customization and personalization of products and services demand it. * Achieving *manageable* customization and personalization *at scale* requires an appropriate infrastructure that is business-based. * The need for infrastructure leads you inevitably to business vocabulary and business rules. (What's the alternative??) So business rules are probably even more essential for social/dynamic/ case-based processes than traditional/sta tic/straight-li ne ones. What does that have to do with the 'business analysis process'? I'll let you draw your own conclusions on that one. Ron
Reply | Reply with quote | Quote
 
 
0 # Gerwin 2011-11-28 07:08
I was shocked at first when I read the title, especially coming from an esteemed practitioner like yourself. But then it dawned on me, you are right on this one, most of the time anyway. A little high level process doesn't hurt just to get us started right. Great article as always.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-11-28 19:22
@Gerwin - Yes some high level process or framework is necessary to give some starting point. Thanks everyone for comments and additions to the discussion.
Reply | Reply with quote | Quote
 
 
0 # Julian Sammy 2011-11-29 04:24
Kupe, are you describing business analysis as a system (in the systems thinking sense, not the 'technology' sense)? That's how I think about BA tasks and even BA processes. They're not a prescriptive set of steps, but a dynamic, non-linear system of inter-related components. In a system, the outputs can be inputs _to the same system_ - it's called feedback. A car engine with turbo is one example: the exhaust is fed back into the engine to amplify the performance of the engine. Is the exhaust an input or output? Yes! The BABOK® Guide Version 3 Core Team is working on a Change Framework with six Core Concepts, that attempts to describe business analysis as a system. We're almost ready to release it for public review, and will welcome (lots of) feedback!
Reply | Reply with quote | Quote
 
 
0 # Martin 2011-11-30 06:01
The bolg title is blatantly misleading. It's not about business processes but about the steps involved in the project approach. How about giving realistic titles such as Adapt the project approach for each project, or is that just not sensational and misleading enough?
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-11-30 06:12
@Martin - you are entitled to your opinion regarding the title choice. What I am excited about is people are getting engaged and adding to the conversation.
Reply | Reply with quote | Quote
 
 
0 # LAL 2011-12-01 00:50
I'm confused about the title also. I'm having difficulty with the concept that BA's do not know that they can adapt the steps of their process depending on the project. I think you are making a huge mistake here by stating that BA Processes are a wast of time. BA processes are not a waste of time, in fact, they are critical to the success of any project.
Reply | Reply with quote | Quote
 
 
0 # Countman 2011-12-07 05:26
As usual, a provocative Kupe title! If you don't know better, having structured processes are a blessing, as they give you something to follow. If you are competent, you know which parts to emphasize and which ones to "deprecate". If you are expert, you will do more stuff that is off the chart, use the chart to make sure you haven't missed anything by accident, and curse at each piece of mandatory documentation you must submit that does not add value in the specific case you are dealing with.
Reply | Reply with quote | Quote
 
 
0 # Steve Hogan 2011-12-13 06:20
There is a comment above that suggests the title of the article is misleading. I think that person shouldn't be working as a BA. I, and most of the other contributors, took the article to mean that if you apply rigid analysis processes to what we do than the 1 size fits all approach simply does not work. Where I am we have an overall organisation wide analysis approach to BA activities/proc esses but the various projects are given some latitude in deciding whether to follow it religiously or to modify it a bit. The suggested approach works well for really big projects but breaks down for smaller less structured projects because its simply an overhead you dont need. Yes we need structure but we also need to be flexible. No 2 projects are ever the same so why impose processes that wont work or wont be used properly.
Reply | Reply with quote | Quote
 

Add comment

back to top