Business consultants are often accused of being hired to tell you what you just told them. In a certain sense, this is true. A good analyst will learn your business model and come to know it as well as or better than you do. Your aims and priorities will be documented and shared with your whole leadership team, developing a common vision for the future. But more than that, you will be given a plan to make your vision come true. That is what you should expect from your business analyst.
Performance. Your business analyst concludes the study by setting the stage for performing a business transformation based on requirements gathered. The study results are presented formally, and the reports and supporting work documents are handed over to you. These materials should include, at least, a problem definition document, a description and assessment of the current business state, a description of the desired future state, and a pro forma execution plan allowing you to move from the current to the future state. Additionally, the analysis materials may include a list of alternative solutions, a list of circumstances considered in choosing the recommended solution, a list of risk factors and mitigating actions associated with moving to the future state, and a high level cost estimate for implementing the execution plan.
Process. The collection of business requirements is an art unto itself that requires experienced practitioners and facilitators. Your business analyst should have a general familiarity with the problem domain, as well as good interpersonal skills. The analyst should come prepared with a “tool kit” of templates for methodology, process and deliverable work products. The process of eliciting requirements may take the form of written questionnaires, individual interviews, holistic brainstorming seminars, focused workshops or any and all of these techniques. Depending on the scope of work, you may have a single analyst or a whole analyst team sited on your premises. The results of the requirements elicitation process should be documented in work product templates, and classified according to the work methodology.
Preparation. First, it helps if you are prepared. You already understand the general need or issue that your business must address. Establish your time constraints and budgetary limits; and be ready to discuss those with your business analyst. If you are unsure of the size of the project, commission a smaller feasibility study or situation analysis to examine the general scope and solution parameters. Draw up a contract that defines the work to be delivered, as well as the project parameters and constraints. Also, compose a mutual nondisclosure agreement and sign it with your analyst. Additionally, give your business analyst access to your staff members and their explicit cooperation.
But what, in general, should you expect from a business analyst whom you hire? You yourself set the overall expectations, of course. You already know the outcomes you desire, even though you may not understand all the implementation details. You might also need an objective validation of your business strategy. Knowing your expectations, the business analyst can then begin activities to meet your expectations. For convenience, these activities are divided into three areas: preparation, process and performance.
The business analyst job description is very broad. It covers any number of tasks ranging from collecting smartphone customer preferences to designing major IT data centers. An analyst might seek the causes of poor business unit performance, or map the integration of major new operations software. Generally speaking, business analysis focuses on gathering business requirements and then proposing solutions to meet those requirements.
Transformation is not complete until each task has been executed AND verified. Verify each task independently based on your same requirement statements. Verification planning and execution can easily eat up 60% of your transformation budget, so be careful. Verifying task outcomes is not necessarily about massive regression testing programs, but more about selectively performing the correct tests.
When you engage a business analyst to advise you on a transformation, what should you expect? What work will be performed and what tangible work products will you receive as the result of that work? That’s the next topic.
Hang with me now, there are two more important steps: execution and verification. For the uninitiated that means doing the real work, and then proving you did it. This is why we say that business requirement statements must be both actionable and testable. Track these processes with a scorecard or dashboard that summarizes incremental completions for all your business requirements.
In summary, you should see that defining your business requirements leads to design, execution and verification of the work that will lead to transforming your business. Because the work is carefully specified, it can be finished and tested to the satisfaction of all your stakeholders.
In my next blog post, I’ll go into more detail about planning the execution and verification phases, as well as some pitfalls and pratfalls to avoid.
Next, you use your business requirement statement to design the business transformation. This is not usually easy, because you need to backtrack some. That is because your business requirement states only what needs to be, but not what is the case now. So, you must prepare a realistic and descriptive report of the current state of your business practice or process. Once you have described your current situation, and also what you want it to be instead, then you can design the transformation. That is, you can now map the steps you need to change from the current state to the future state of your business practice.
Business requirements transform business. They provide the roadmap to fulfilling client and customer satisfaction. By doing so, they give you your competitive edge.
How do you make that happen though? To some, it seems mystical and magical. To others, it seems obvious, so get out of the way and let them get started. But what really happens is that you must work the business requirements, in order to get work out of them.
To start with, as mentioned in a previous blog post, a good statement of a business requirement is both actionable and testable. It is simply, but completely stated so that it may be implemented without misunderstanding. There is truth in saying that identifying a problem is half way to solving it. Half the work of implementing a change to your organization is in defining its business requirement clearly.