Are you results-oriented?

There are many qualities that contribute to great business analysis. You have to be a good communicator and be able to analyze problems. It generally helps to have some solid background in the common techniques of business analysis. For some jobs you need domain knowledge, for others technical expertise. All of these are debated and discussed often in BA circles across the web.

One of the attributes I don’t hear people talk about quite as much is being results-oriented. Results-oriented individuals are focused on making things happen. You find them in the middle of successful projects digging up the road blocks and greasing the wheels. As a results-oriented business analyst you figure out how to get the right requirements, no matter the challenges faced, and stay resolutely focused on the core principles of gaining alignment and achieving clarity. You also ensure that your project and efforts are consistently focused on delivering value for the organization.

Do you think you are results-oriented? Consider the following questions:

• How do you get started on a project? Do you wait for someone else for direction or do you jump in and figure it out?

• If your stakeholders aren’t answering your emails or attending your meetings, how do you respond? Do you figure out what you can do to help?

• If your organization has a formal process, do you focus on dotting the I’s and crossing the T’s or do you stay relentlessly focused on ensuring the deliverable you create are clear and consistent and fulfill your objectives on the project?

You know your activities are results-oriented if you can answer the question of “why” for each activity you do day-to-day. This is a tough standard, but one worth considering applying to your work.

In IIBA’s May newsletter, Kathleen Barrett wrote a magnificent article about taking charge of our profession. One attribute she called out was “finding your inner project manager.” I think this is a great way to frame a results-orientation because it speaks to the fact that even though we are not project managers, we should be self-managing. This means we’re responsible for planning our requirements activities and breaking down the roadblocks that surface as we proceed along our plan. It means we’re accountable to the success of our requirements-related activities. This means we need to be results-oriented in our work.

Another aspect of results-orientation is about staying focused on the project ROI. We hear a lot about the value of specific projects and I’ve never heard anyone accuse a business analyst of not finding and delivering a high-value, quality solution. But value is delivered only if the solution can be implemented. I have heard many cases (and witnessed a few myself) where a business analyst focused only on potential value and not realistically achievable value. Like it or not, project constraints such as time and budget are a part of our world.

Some questions to consider:

• Do you feel solutions need to be perfect to be acceptable?

• Do you find yourself in debates with the technical team when the requirements are unrealistic?

• Do you help the business prioritize? And I mean really prioritize in such a way that not every idea or thought is a number 1 priority but only the best possible ideas make it through the initial analysis phase?

We all know that anything is possible, given infinite resources and infinite time. I doubt any of you have the luxury of working in an environment that meets either of those criteria, let alone both. Being results-oriented means we can focus our best business analysis efforts on what can actually be achieved. It doesn’t mean we have to forego the dream or set aside big ideas and visions, but it does mean that we do gut-checks against what can be realistically accomplished and help guide the requirements process inside a certain set of achievable boundaries. Results-oriented business analysts inject a healthy dose of pragmatism into their requirements process.

I can almost see you nodding your head and thinking you’ve got this nailed. So let me tell you a story. Let’s talk about Bob, a fictitious business analyst who is a lot like many of us. Bob is given a new project that’s the top priority project for the company. There is a bit of urgency because a competitor is launching a similar feature in a few months. Bob’s boss tells Bob to drop everything else and focus on this project. The team needs enough detail to start developing something in two weeks.

Bob calls a meeting with the business sponsor. The business sponsor isn’t 100% clear about what the competitor feature is and can’t answer a lot of Bob’s questions. Bob waits for a couple days and then tells his boss the deadline is impossible. The business doesn’t have a clear set of objectives.

Sound like a familiar situation? Let’s consider an alternate ending for this story, one that sets Bob up to be a superstar, results-oriented business analyst.

Let’s pick up this story after the first meeting with the business sponsor. Bob realizes that there is more ambiguity than expected about the project. He talks to a colleague of his in the sponsor’s department, we’ll call her Sue. Bob knows Sue well because they meet for coffee every couple weeks. Sue gives Bob a couple of documents, including a competitive report and some screen shots they were able to capture from a demo they attended. She briefs him on what she knows and they set up some time to meet the next day. All afternoon, Bob sifts through the documentation. He creates a snapshot of the requirements of the competitive feature and thinks of 3 ways his company could launch something with similar value. Next morning he reviews his 3 ideas with Sue. Sue thinks two of them are great, but one is off the mark. Sue has a different idea. Bob updates his working “idea document” and sets up another meeting with the sponsor.

In the meeting with the sponsor, Bob starts out by saying what a challenge it is to come up with a feature like this. He tells the sponsor he came up with a few ideas just to help get the conversation started. Would he like to see them? Of course! Then they launch into a 2 hour discussion of the different options, select one, and Bob nearly skips out of the sponsor’s office. He spends the remaining 7 business days working with Sue and a few other stakeholders to detail out the idea. At the end of the two weeks, Bob has the big idea laid out with details on the first few parts for the development team to start on. He meets with the development team, proud of what he managed to achieve in such a short time. The development team tells Bob that his solution is impossible. The requirements he has for the first two weeks are useless. Development will start late. Bob is defeated. He was so excited to meet the deadline that he forgot to vet his ideas with the development team.

The story doesn’t have to end this way. Let’s step back to Bob’s meeting with the sponsor and write a new ending. Instead of coming up with one solution, Bob and the sponsor select two possible solutions and create a list of prioritized objectives for matching the competitive threat. One solution has more value to the customer, but the second is probably good enough to meet the competitive challenge. They put some benefits statements around each solution possible solution.

Bob schedules a meeting with the development team to review the two possible solutions and hear their ideas. By the end of the meeting, the development team comes up with an idea that is slightly better than the second option and achievable in the time frame. Bob validates the new idea with the sponsor. Bob meets with the implementation team the next day to identify the implementation phases. Bob then sets out to fill in the details for the initial phase. He now has 5 business days, so the piece he delivers is a bit smaller, but the development team has already started working on some core architectural pieces and planned to iterate, so no real time is lost.

Bob is awarded employee-of-the-month for getting the requirements done in record time and promoted to senior business analyst.

You can call the process Bob used agile, lean, RUP, or enterprise analysis. You can call it whatever you want. There are no limit to the practices and techniques you can use to achieve results. But at the core, focusing on driving results is what will get you results. This is just one story. Bob could have been handed any number of challenges. There is no one path and you won’t ever be dealt the same hand twice. So focusing on results is the clearest path to success that I’ve ever come to know.

Author: Laura Brandenburg hosts Bridging the Gap, is the author How to Start a Business Analyst Career and of the forthcoming eBook The Promotable Business Analyst, a guide book for crafting a fulfilling and successful career as a business analyst.

To receive a special offer when The Promotable Business Analyst is available, sign-up for our early bird list.

NOTE: Top photo © gunnar3000 - Fotolia.com.