In my job, I get to hang out with a lot of very senior people and talk with them about requirements and business analysts. The one complaint I hear over and over: “Our BAs are not proactive”. Maybe some in the organization are being a bit passive, but the executives I talk with are most concerned that the BAs are order takers, rather than being seen by the business as really driving the process. You need to ATTACK requirements. Be proactive! And, know the right questions to ask to motivate stakeholders to get you the right kinds of information. Here’s the problem – many analysts get in the way of their own success.
Remove the Barriers
It’s easy to fall into the role of order taker and think the customer can drive the requirements process; particularly in the face of an assertive executive with a fairly clear vision of what they want. I humbly submit, if you roll-over and become an order taker, you’re dead. The requirements on the project will likely be incomplete with significant functional areas missing, and there is likely to be no consensus between executives in the areas of interdependency. Think value-add! The analyst is the one that needs to fill the gap between what the business can articulate for itself, and what the technology department needs as input for successful development. Get people on board with the idea that there is a gap in content that needs to be filled, and removeboth the barriers to participation and the barrier to being proactive. If you show you can add value to articulating business needs, you are taking the bull by the horns and being proactive.
Have a ‘Go To’ Process that Always Works
Analysts get caught up in self-flagellation because they have no personal expertise in the business process they are reviewing. Get over it! You cannot possibly be expert in every process and system in the company. Candidly, it’s a fool’s game to try! Even the SVP operating the division must rely on their experts running the subcomponents of the business, as these in turn rely on their subordinates. How can an analyst portray themselves as more expert in every area of operation of the company than these executives without annoying their stakeholders with their arrogance? The analyst is not there to define optimal business practices for the business. The analyst is there to optimize the process used by business leaders to achieve consensus in their practices. The analyst also knows how to take concepts from high level understanding, to clear, accurate and complete documentation.
Before everyone gets angry at me…you absolutely can be expert at doing requirements and getting executives to consensus without being a business area subject expert. Analysts can absolutely be successful where they have a ‘go-to’ process for eliciting business requirements that is easy for participants, and adds value to their thinking process.
First and foremost you cannot get hung up on problem definition. You can do all the problem definition, analysis of issues and look-back reviews in the world and still have massive problems articulating a solution, especially when dealing with something complex. Watch out for the trap people fall into all the time! You cannot consistently jump from problem to solution so spending too much time on getting better resolution on the problem will not get the business closer to solution.
Situation or problem definition can be insightful, but only in so far as it helps bring clarity to the correct needs, objectives and goals. With a solid understanding of objectives and goals, it is not a large step forward to ask: “To achieve these objectives and goals, how must the business process change?” Discovering, eliciting, and describing the processes that change in response to meeting an objective business is the goal of an analyst. The ability to be a great analyst is to have the right kit bag of techniques to draw on to help the business articulate these changes in a systematic, clear, accurate and complete way.
ATTACK the Detail
There are lots of ways to break down projects into reasonable chunks using scenarios, user stories, use cases, or any number of techniques. These only get the surface information. To be a proactive analyst, you need to attack the detail and ask the questions that proactively pulls this information out of stakeholders. To attack the detail, think SIPOC (SIPOC stands for suppliers, inputs, process, outputs, customers). It’s a concept the six sigma folks hijacked, but it’s a great tool for business analysts when you use it to describe how information moves in the business process:
For the scenario “price an order” (starts with confirm item details, and ends with provide quote to customer) ask SIPOC in this order:
- Input: What information do you need to know to be able to price an order so you can provide a quote to a customer?
- Process: What do you do with that information?
- Output: What typically happens once you’ve priced the order?
- Customer: Does anyone else need to know about the priced order?
- Supplier: Is all of this information coming from you, or do you need input from someone else?
Uncovering how information needs to move to support the business process and ultimate business objectives motivating change is the detail an analyst needs in order to get clear, accurate and complete business requirements. We’re in information technology remember!
Here are some closing thoughts to consider – or maybe comment on – as you get back to the daily grind:
- As the analyst, YOU are accountable for the process of getting the requirements. If you are accountable for anything, it is to be proactive.
- Being proactive doesn’t require you to be an expert at all things business. It does mean knowing techniques that add value and can take you from problem to solution.
- There are a lot of blind alleys out there! Be sure to that you select and adopt techniques that accelerate you along the path from problem to solution in incremental steps, rather than requiring you to take giant leaps from problem to solution.