6 Tips to Identify Business Analysis Red Flags-EN

I recently read an article from CIO.com “6 Tips to Identify Project Management Red Flags.” While reading, I couldn’t help but think of business analysis red flags in the same respect. So here’s my take on “6 Tips to Identify Business Analysis Red Flags” to help you see the signs that your analysis might be in jeopardy. Along with each red flag, I will propose what I feel are some good questions to ask to avoid or mitigate these risks and determine how to approach the project. Keep in mind, this list is not exhaustive as each project could produce its own particular questions but it is a good place to start!

#1 No clear understanding of why the project is being done.

Want certain failure? Avoid identifying and fully understanding the problem that we are trying to solve with this project (or the problem we are trying to avoid). I can guarantee you will go down in flames. Constantly asking ‘why?’ will help identify not only high level objectives, but will help bring out correct details.

Admittedly, walking around the office asking ‘why?’ would make us look just a bit silly. Do you know how many times the average four-year old asks why in one day? About four hundred. In order not to sound like a four-year old, let’s talk about better ways to ask why.

Some of the questions I would pose to the executive sponsor, business area management, and maybe the project manager:

• What problem(s) are we trying to solve?
• Do we understand the true root cause(s) of the problem(s)?
• What benefits or results are we trying to achieve? What is the financial benefit? Are there non-financial benefits? (such as customer satisfaction or philanthropy, which might actually convert to financial benefits).

#2 No clear understanding of the scope of the project.

How do we know where to start and when we are done if we do not understand the scope? How do we understand impacted parties? Pretty impossible tasks without scope.

There are many questions we can ask in order to understand what is in and what is out of scope:

• What business capabilities (processes) are expected to be analyzed and possibly changed?
• What objectives or benefits are targeted as a result of changing these capabilities?  How are we measuring those benefits now and how will we determine if we achieved those benefits post-project? What parties are impacted? These parties could be internal or external customers, vendors, government agencies, business partners.
• What are the risks of changing our business capabilities? Should we even do the project? What if we don’t do it?
• What should not change?
• Are there dependencies on other business initiatives or projects?
• Are there constraints on time and budget (of course there are!).  If so, are they realistic?
• Does everyone that needs to be involved in the project also have a good understanding of all of these previous points?  Do they understand their role in the project?

Get more on scope and scope creep from my co-worker Jacqueline’s post: 4 Step Process to Manage Scope Creep and Evaluate Changes.

#3 No real understanding of the business itself.

I have had many business analysts look at me as if I had two heads when I ask what their business does. If I don’t understand the business capabilities and business information, how am I going to correctly solve their problems? Pretty impossible without that understanding. My opinion is that when I have a good understanding of the business data and the decisions made based on that data, then I have a good understanding of the business itself. The decisions are determined by business rules, which are typically made up of business data, which are implemented in business processes.

There are so many questions to ask here that I could write a book!  These questions always depend on the characteristics of the business such as culture, organization, demographics, geographics, size, maturity level, etc. When in doubt, I go back to the basics:  who, what, when, where, why and how? This may entail looking at a business area at the ‘value stream’ level, which starts with a high-level understanding of overall business capabilities and what value they add to the business. Or it may start with a look at low-level problems, and trying to put pieces together so that you can get back to the value. Once again, asking good questions about data and business rules used in the processes help you fully understand the process.

If I am trying to determine business data and rules I ask questions such as:

• What decisions are made based on this information? Those decisions are fed by business rules.
• What reports use this information?
• What calculations use this information?
• What processes (or steps, tasks, procedures, etc.) are performed based on the receipt of this information?
• What other pieces of information might be changed based on the receipt of this information?
• What happens if we don’t receive this information?
• How do you define this piece of information?
• How does this information relate to other information?
• Is this information required, and if so, when?
• Is this information something we use to identify ‘things’ in our business (customers, products, assets, etc.)?
• What are the possible values of this information?

Download our Ask the Right Questions Checklist for more help on how to uncover initial project information.

#4 Too much documentation.

Don’t get me wrong; I think documentation is hugely valuable, especially in our fast-moving, job-jumping world. But spitting out pages of “the system shall do this or that” can be useless. Figuring out how to be concise, drawing pictures of requirements when we can, and determining what communicates best (not necessarily what is the “correct technique”), is crucial.

How do I know what is sufficient documentation for a project? Let’s talk about what I call the “DisneyWorld” scenario first. In a perfect world, when I start on a project, I have a good picture of the business architecture of the business area(s) I will be analyzing. This means there is existing documentation of the business capabilities (agnostic of technology) and the stakeholders, data and business rules involved in each capability.

Let’s take an example with which we are probably familiar: buying groceries. If I go back a hundred years and need to buy flour and milk, what would I do?  I might go to my local grocer and ask for flour and milk. The grocer asks me how much of each and would check to see if he has those items in that quantity. He would then tell me the order total, I would pay him, get my receipt, and give him my address to have the items delivered to me (back then, maybe via bicycle?).   What is different now? I might buy my groceries online, but all the same tasks and business rules and data apply, right? In general, these change only affect how we get the tasks accomplished physically. We might soon be getting groceries by drone or they might be “beamed” to us (beam me up, Scottie!), but the basic tasks are the same. If I am the grocer, I have to know what the customer wants, make sure I can fulfill that request, make sure I get paid, and make sure they get what they wanted. Voila! If you document this once, you will have the reusable business requirements! Now we can get to functional and technical specifications much more efficiently because we have a good understanding of the business.

Now, let’s talk about non-Disney moments. If the business documentation does not already exist, we have to figure out how to understand the business capabilities so that we can fulfill the solution needs correctly. My approach is typically to at least get a high-level understanding of the capabilities within scope of my project, then as we are working on more solution-oriented tasks on the project, I try to pull out the detailed data and business rules requirements and document them separately. We have to get them down somewhere, whether it’s in the business, functional, or technical requirements (or just in the code!). Why not document them where they can be reusable for the next time you have a change or enhancement to that business area?

#5 Lack of focus on reuse.

If I am reinventing the wheel every time I get on a project because either the lack of documentation or outdated/overwhelming documentation, then I am wasting a huge amount of time. Organizing requirements and focusing on how they will not only be used now, but in the future, can save time, money and frustration. I think my diatribe on separating out business requirements above addressed this issue.

#6 Too much emphasis on the process and not on what’s best for this project.

Each project is different: different focus, different problems, and different people. Critically analyzing these pieces and adjusting our approach based on the best projected outcome for those pieces is the key. Methodology for methodology sake is a waste of time.

What questions can I ask to avoid doing unnecessary deliverables:

• What is the purpose of each deliverable?
• From whom will the information be elicited?
• How do I best elicit it?
• To whom do the contents need to be communicated? Talk to each party and find out what type of deliverable will either help them review and approve the contents or help them get their jobs done better. Show them examples of what you have done or what you think would work best if they cannot answer you. Collaborate on all of this!

I hope this helps! When I get overwhelmed on projects, I come back to these concepts and the projects just seem to go better. Good luck to you and let me know about any other business analysis red flags you see on a regular basis!

All the best,

– Ali