You cannot automate a process that does not exist. This is the bedrock principle of any solution definition. Developers (myself included) love to build stuff, whether it solves a problem or just does something really cool. To have any value, your solution needs to do the former. To go to a customer or prospect with a virtual carrying case of solutions you need to be able to prove that you can solve a business problem of theirs – even if they don’t know it exists yet. This is where the value of an experience Business Analyst can prove their worth. This post will focus on how problem definition, either by the customer or the vendor needs to be the absolute very first step in embracing a new project.
Almost all software implementations are aimed at solving a problem that the business faces. These problems need to have clear definition. Perhaps it’s an issue concerning inflated costs in a particular business area that can be solved with automation. Maybe it’s an issue with quality of data being provided to those making key organizational decisions. There are an infinite number of types of problems that can be identified but how they are identified is the key to taking the next successful step forward.
To properly identify a problem, we need to determine what the detriment to the business is. This becomes the problem ‘mission statement’ is it were. Is it increasing the risk exposure of the organization? Is it directly leading to customer or financial losses? Is it an internal process issue where the impacts are spread over many business units? Once the problem has a material impact defined, it becomes real and recognized.
The next step in proper problem identification is determining the root cause. While there are many root-cause-analysis tools and methodologies out there (I won’t dive into any here), it’s important that thoughtful, pragmatic thought go into proper root-cause identification in order to properly identify what the solution may be (this should be software implementation-agnostic).
The third and most fun part of problem identification is determining potential solutions. I say “solutions” with plurality because for anyone who’s ever diagnosed a problem knows that there can be many solutions for the same problem. Solutions, like problems, can be infinite albeit the practical ones generally are not.
The primary focus of almost all software implementations is to solve problems. Without a proper definition of problems, the organization will likely find itself fumbling over solution after solution until they either get lucky or run out of money. When problems are properly identified they can be shared with experts who specialize in providing solutions.
Want to learn how our Digital Experience service can help you and your team? Let's talk!