Business Analyst Articles: Business Analysis & Systems Analysis



BA ARTICLE ARCHIVE
» April 2014 (4)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Monday, May 31, 2010
35943 Views 8 Comments 18 members voted Article Rating

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.

Rate this:

COMMENTS

Posted on Tuesday, June 01, 2010 12:03 AM by
CharuR
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
CharuR
Posted on Tuesday, June 01, 2010 7:05 AM by
deepakmahar
Hi Laura,
Great article. Will try to look for your book now :-)

-Deepak
deepakmahar
Posted on Tuesday, June 01, 2010 6:18 PM by
LauraBrandau
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
LauraBrandau
Posted on Tuesday, June 01, 2010 9:23 PM by
CharuR
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 ..........
CharuR
Posted on Thursday, June 03, 2010 8:39 PM by
ejazbutt
Hi Laura,

Really a nice and inspiring post.

Ejaz
ejazbutt
Posted on Friday, June 04, 2010 2:36 PM by
CameronF
Enjoyed the story about Bob to drive home your point -- makes the lessons easy to remember.
CameronF
Posted on Saturday, June 05, 2010 1:19 PM by
LauraBrandau
@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
LauraBrandau
Posted on Thursday, June 06, 2013 8:55 AM by
pVuollet
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.
pVuollet
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Big Data Analytics for Dummies
Finally, a Big Data book written for business analysts, BI professionals, and data scientists!  Big Data Analytics for Dummies is a valuable resource that addresses the practical dilemmas surrounding Big Data...

A Buyer’s Guide to Customer Analytics
Discover the five crucial criteria of a customer analytics platform in A Buyer’s Guide to Customer Analytics now.

Free Analytics software: Alteryx Project Edition
Alteryx Project Edition provides you with a single solution that delivers the data blending, analytics, and sharing capabilities of Alteryx with just enough allowed runs of your workflow to solve one business problem or to complete one project.

The Business Analyst's Guide to Hadoop
Get started with Hadoop using this whitepaper, "The Business Analyst's Guide to Hadoop".

Copyright 2006-2013 by Modern Analyst Media LLC