Thursday, 01 September 2016 06:14

5 Things I Wish I’d Known When I Started as A Business Analyst

Written by
Rate this item
(15 votes)

I found myself in a reflective mood this weekend - driving from Iowa to Arkansas and back again to deliver a horse tends to do that.

One of the things I reflected on was the lessons I learned in my career and how knowing them would have been helpful when I started as a business analyst. Here are five things that I would tell my 1998 self, assuming I would listen.

Your Job Is Not to Elicit and Document Requirements

Yes, business analysts elicit and document requirements, but those activities are a means to an end. Analysis is about understanding your stakeholders and their needs, identifying the best solution for satisfying those needs in your particular context, and then building a shared understanding of that solution. Requirements play a part in that work, especially around describing the need, but they are certainly not the end product.

Related Article: 10 Characteristics of an Awesome Business Analyst

When the teams I worked with thought that the BA’s sole responsibility was requirements, my role was diminished and I lost the ability to make sure the project was delivering the right thing. On the contrary, when I stepped up and sought to understand why the project existed in the first place and then made sure everyone on the team had the same understanding of why, the project tended to go better, I enjoyed my work a lot more, and found I had much more influence on that project and in the organization.

Projects Tend to be Described in Terms of Solutions

The common advice repeated so much it’s almost become a cliché is that you must understand the need you are trying to satisfy first, then identify the solution that best satisfies that need. Yet, most projects are still initially described in terms of a solution, such as “Redesign the cover sheet for the TPS Report.” Why? Because it’s easier for people who are facing a problem to voice how they will solve it rather than to reflect a bit and describe the problem they are trying to solve. (This is where I resist the temptation to reference an overused Henry Ford quote about faster horses).

If you want to be effective at business analysis, learn how to drive to the real need in a way that makes your stakeholders eternally grateful that you came along. Your stakeholders are certainly experts in some things, but they may lack expertise in the capabilities of technology. They fall back on solutions they have seen in other contexts that may not apply to their current need. Bringing in other perspectives (i.e. the delivery team) can provide several other options for addressing the need in more effective ways.

Just Because You Can Satisfy a Need, Doesn’t Mean you Should

Sometimes when you uncover the real need, you realize that it could be satisfied, but that it doesn’t make sense to do so. Either the viable solutions cost more to implement than would be realized from satisfying the need, or the need is not that wide spread and your team’s time is better spent on other things.

A dysfunction I have seen is that organizations do not know how to determine constructively what they will - and more importantly will not - work on. This is apparent in the organization’s project portfolio which contains more things than the organization has the capacity to do within the identified timeframe.

This is a problem that stretches all the way up to the decision makers in the organization, but business analysts have a part to play in this. Although you as a business analyst may not make decisions about what projects get done or not, you certainly can influence those decisions, and even make sure they happen, by asking probing questions and driving to understand the real reason for projects. It’s not easy, but it’s better to raise the questions and drive some influence rather than keeping silent and not having any impact.

Learn as Many Techniques As You Can

There are several different techniques that are helpful for business analysts and BA Times is chock full of articles about how to do them better. With so many techniques available, it’s very helpful to be aware of as many techniques as possible and to really understand why you use them and when they are most helpful. There are enough great resources out there that you can pick that up when you need to actually use the technique. I’d much rather have a broad understanding of a wide range of techniques and when they are applicable then to be an expert in a few techniques. I find I’m much more flexible in my response to different situations and more useful on the projects on which I work.

People Don’t Want You On the Team Just Because You Are A BA

Throughout my career, I’ve had the opportunity to work in several different organizations on many different projects. When I started at a new organization, I was on a project because that project needed a business analyst. After that, I worked on future projects because of what I did and how I did it which included, but was not limited to, business analysis. Those experiences led me to the conclusion that while all projects need business analysis, not every project needs a business analyst.

I don’t think that rules requiring every project to have a business analyst help. Projects require a different amount of analysis. Let the business analysts work on those complicated projects that require a little of analysis, and coach people on the projects that are more straight forward.

Conclusion

There’s a lot more baked into these lessons that I didn’t have room to share here. In my subsequent posts, I’ll dive into more detail into each of these lessons and share a bit more about how you can apply each of these lessons learned. I’d also be interested in hearing what lessons you have learned, and if your experiences have been different than what I’ve described above.

Read 9445 times
Kent McDonald

Kent J. McDonald helps teams discover the right thing to deliver. His more than 20 years of experience include work in business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, nonprofit, and automotive. He shares resources for effective business analysis and product ownership in IT at http://kbp.media and practices those ideas as Product Owner for the Agile Alliance.

Kent is author of Beyond Requirements: Analysis with an Agile Mindset and co-author of Stand Back and Deliver: Accelerating Business Agility.

Comments  

0 # Vikram 2016-09-02 02:19
Good Read!!!
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-09-14 16:24
Thanks Vikram.
Reply | Reply with quote | Quote
0 # Ravi Nandi 2016-09-02 07:31
Very true. Even I have experienced most of this this being a BA. Great Write up!
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-09-14 16:25
Thanks Ravi.
Reply | Reply with quote | Quote
0 # Racquel 2016-09-02 10:18
Very good read. Well shared Kent.
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-09-14 16:25
Thanks Racquel. I enjoyed sharing.
Reply | Reply with quote | Quote
0 # Nhu Vo 2016-09-07 18:52
Many thanks for the post. Sometime we just did it naturally so it's really great to have a summary like this. IMHO, for those who are new to BA will find it's a bit to general but just keep these in mind and one day you will turn the corner and realise that they are all true. Cheers! Thanks again Kent.
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-09-14 16:27
You're welcome Nhu.

I agree that these ideas were fairly general. That's why I'm following up with five articles that go into each idea in a bit more detail. The first one was published today (https://www.batimes.com/articles/your-job-is-not-to-elicit-and-document-requirements.html) I'm writing the remaining ones over the next few weeks.
Reply | Reply with quote | Quote
0 # Sudarshan Singh 2016-09-15 03:21
Thank you!
IT is really help me to understand my current organization expectation.I am new as a BA role and facing this problem like people making corner...please keep sharing..
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-10-11 14:09
Hi Sudarshan,
Glad you found the article helpful. I'll plan on sharing more - there are five more posts coming in this series :)
Reply | Reply with quote | Quote
0 # Mai Anh Tyagi 2016-09-20 12:49
Hi Kent, I can't agree more on this point from your article:
- While all projects require certain business analysis activities, not all projects need a BA.
- A business analyst's primary role is to facilitate communications between business and technical stakeholders, in a way - helping teams discover the right things to deliver.

Thank you for sharing your insight.
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-10-11 14:10
Hi Mai Anh,
Happy to share my insight.
Reply | Reply with quote | Quote
0 # Hashim 2016-10-05 19:57
Totally agree with the first two points, especially the second one. So many projects I have worked on are just influenced by stakeholders who have had a previous experience of some tool and their bias for the same solution becomes obvious when actual requirements are mapped against a proposed solution
Reply | Reply with quote | Quote
0 # Kent McDonald 2016-10-11 14:11
HI Hashim,
Thanks for your feedback.
Yes unfortunately past history plays a big part in people's views of solutions and we all unfortunately suffer from bias of some sort. It's important to keep that in mind when identifying solutions for a new problem.
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250