Here are Six 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:
There are many questions we can ask in order to understand what is in and what is out of scope:
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:
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 effect 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:
Are you interested in learning more about becoming a good, or even better Business Analyst?
Then I highly suggest you enroll for our BA Career Coaching.
Contact us at Jadetan Enterprises Ltd via
Tel: 0872 113 1105