The First Milestone of a Business Analyst – The Business Case
Effective Business Analysts realize that to avoid failure, they should build the business case for their projects by getting intimately knowledgeable about the reasons why sponsors approved their projects.
Too many projects are shelved because of the lack of justification of the business case. When project sponsors begin to see projects only in terms of costs instead of potential rewards, there are higher chances that the projects would be shelved.
It is the job of a Business Analyst and not that of the Project Manager to build the business case, though the Project Manager often plays an active support role in establishing it. Ideally, project stakeholders and sponsors evaluate the possible ROI from a project. If the project is seen in terms of generating income or reducing cost, the project will get the go ahead. Surprisingly this is a simple concept, but most often the necessary importance to this is not given, and often ignored.
Effective Business Analysts and Project Managers realize that to avoid failure, they should build the business case for their projects by getting intimately knowledgeable about the reasons why sponsors approved their projects. A project manager should work closely with clients, sponsors and other stakeholders, and build consensus over the following key points:
The specifics of the problem that is attempted to be solved (or the opportunity that is attempted to be addressed)
By interviewing project sponsors, the Business Analyst can determine their vision / goals and discuss the issues that the project would solve. In addition to project sponsors, it would be useful to interact with the ones who are dealing with the issues at the workplace, are a good source of ideas about the extent and the many facets of the problem. They may also be able to specifically provide the necessary input to assess the impact, which would go a long way in establishing the justification. Looking at the operational challenges from end-users’ point of view enables the Business Analyst to get a better understanding of the requirements of the project in terms of design and technical upgrades, as well as in terms of how it will solve end-user problems.
Clarity of the Solution Vision (Goal)
What exactly is the goal of the project; Would it make the operations simpler? Would it enhance productivity? Is it targeted to requirements generated from the market? Whatever be the goal, it is mandatory that it is supported by the end-users. Eventually it would be the Customer Satisfaction scores that count when it comes to measuring success of the project. Make sure that the goals are clear and the project’s objectives must trace back to these goals.
Clearly separate “needs” from “wish-lists” – avoid gold plating right at this stage
Most projects are overly focused on the “voice of the user” whereas the focus really ought to be towards achieving business goals. If the solution vision and scope is established before eliciting requirements, users are more prone to focus on the business goals. It would be a lot easier to set expectations and establish consensus. The project may have a lot of feature that do not have business justifications, resulting in features that took too long to build. Separating needs from fluff allows the Business Analyst to formulate requirements aligned to the business goals that are important in creating a justifiable working version of the project. The quicker the iteration, the better the chances are of project survival and acceptance from the sponsor.
Providing the Return-On-Investment (ROI) information
Even at this early stage of the project, it is possible to envision ballpark ROI figures. Because all projects incur costs, a Business Analyst should have a fair idea of when investments will be recovered and generate positive cash flow.