Are you results-oriented?

Featured
39155 Views
9 Comments
18 Likes

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.

Laura BrandenburgAuthor: 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.

Like this article:
  18 members liked this article
Featured
39155 Views
9 Comments
18 Likes

COMMENTS

CharuR posted on Tuesday, June 1, 2010 12:03 AM
Hi Laura,

Very practical, great article.
I totally agree that a BA has to be fully results oriented.

The very old TQM theory also says to get on with what can be achieved rather than sit with huge tasks and dreams .....that are waiting for reviews, responses.......sometimes, with minimum info, we have to even make assumptions (with calculated risk, of course that the area of design or the solution or the process could change - until it settles down and gets to BAU - which is what being agile also means!)

And, I also agree with you - it is not the name of the methodology or the rules book that matters - getting things done (sometimes or mostly with work arounds) is totally important. We may never get the oportunity to gather the right group and sort out the ideal process before the first emergency strikes....while, yes, that is important to do that gathering and streamlining it for BAU.

I am with you totally!
Cheers
Charu
deepakmahar posted on Tuesday, June 1, 2010 7:05 AM
Hi Laura,
Great article. Will try to look for your book now :-)

-Deepak
LauraBrandau posted on Tuesday, June 1, 2010 6:18 PM
Charu, Great point about the interplay between making assumptions and getting things moving. Though I've also had the reverse happen, where I made too many assumptions to keep things moving and ended up off target. There is definitely a time to pause and escalate the assumptions you are making if you are roadblocked by specific issues. I do whole-heartedly believe in work-arounds and side steps as well. I recently read somewhere to focus on taking the easiest path toward your goal ... the positive forward steps you take will create momentum and make the more challenging steps that much easier.

Deepak, Thanks! The Promotable Business Analyst is due out this summer. You can link to How to Start a BA Career above--it's available now as an eBook.

Best,
Laura
CharuR posted on Tuesday, June 1, 2010 9:23 PM
Thanks Laura.

Yes - it is quite dangerous making assumptions - I fully understand that.
But sometimes, some business owners / users cannot understand the importance of a process decision or a requirement decision until they see the next step or the effect of the next step.
So, there is no choice but to make an assumption and move forward, carefully tracking all the assumptions made and revisiting them as we move forward.

Of course, if the BA makes these assumptions, completes the project and gets away from the contract, this will lead to the failure of the entire system.

Agree with you regarding the momentum - that is exactly it ..........
ejazbutt posted on Thursday, June 3, 2010 8:39 PM
Hi Laura,

Really a nice and inspiring post.

Ejaz
CameronF posted on Friday, June 4, 2010 2:36 PM
Enjoyed the story about Bob to drive home your point -- makes the lessons easy to remember.
LauraBrandau posted on Saturday, June 5, 2010 1:19 PM
@Charu Definitely agree. Using assumptions to elevate risk or ideas to the stakeholders can quickly get a dead project moving! And this puts you in a position to continue to discover requirements, which is a good thing.

@Ejaz @CameronF Thanks for the positive feedback. I appreciate you leaving your notes!

Laura
pVuollet posted on Thursday, June 6, 2013 8:55 AM
As a developer, I thank you for putting that important step into Bob's successful process.

I found this article as I was researching results-oriented in general. Very relevant.
Only registered users may post comments.


Upcoming Live Webinars



Latest Articles

What’s Wrong with the Term ‘Knowledge Worker’
Oct 30, 2014
0 Comments
This column examines the three basic kinds of knowledge workers involved in business processes, and discusses how the distinctions among them are impo...

Featured Digital Library Resources 

brought to you by enabling practitioners & organizations to achieve their goals using:

Copyright 2006-2014 by Modern Analyst Media LLC