The Modern Analyst Blog for Business Analysts

Howard Podeswa
Howard Podeswa

10 Things I Wish Someone Had Told Me When I Was Starting Out As A BA

I am no longer a Webinar virgin. Thanks to the good folks at the IIBA, this week I had my first Webinar experience as an interviewee as part of the IIBA’s ‘ABC’ (Authors, Books and Conversations) series. The host, Julian Sammy, was brilliant in being able to pick out the questions that would be the most difficult for me to answer. (I hear that’s what makes him a great BA, too.) Of course, afterwards, I was regretting not being able to do a ‘do-over’ – until I remembered that I could – sort of – thanks to my MA blog.

Hockey Valley, Howard Podeswa, 1999, Oil on canvas, 48" x 48"Julian’s toughest questions were about the 3-way connection I saw between psychology, business analysis and art; I’ll leave that for later. But there was a BA question that I didn’t have a ready answer for, “What are the most important things you wish you had known when you were starting out as a BA?” Maybe it’s because it’s been so long since I have been in that position. But the memories have begun to come back.

So, for Julian - and anyone else who might be interested: here, then, after some thought, is what I wished someone had told me when I was starting out:
1. See every BA engagement as an opportunity to learn about other people - and not just to learn about another system: I thought my success or failure as a BA would be all about my analysis skills. I have since found out it hinges more on my ability to connect with people from a wide variety of backgrounds and cultures.

2. Turn off the inner monologue while listening to other people. (See #1 above).

3. Find out, from day 1, who will have ultimate signing authority – then meet that person as soon as possible: I’ve had bad shocks early in my career when I found out that the one person I really needed to convince was the one person I didn’t know about - until it was too late. I now do everything in my power to bring that person into the process ASAP.

4. Don’t go off for too long on your own: In my earlier days, I would do a big round of interviews and then go off for a long period to produce a big ‘tome’ of documentation. I found out soon enough that it’s too much for stakeholders to absorb at once and it’s too easy to propagate mistakes – like too much or the wrong kind of documentation. Now I provide feedback frequently to stakeholders.

5. The only way to get a good user interface is through many iterations of prototyping and user testing – because most people don’t know what they want till they see it. The focus of the BA in this case is to find out what the flow of the interface should be from the user’s perspective (the ‘Basic Flow’ – in use-case parlance), as well as the alternative scenarios that need to be addressed, while the designer works to realize these flows in the prototypes.

6. Test assumptions as early as possible in order to mitigate risk – especially if this is something you (or your organization) is doing for the first time: I’ve personally worked on 2 major projects where untested assumptions about new technology resulted in long delays and lots of rework once they were found to be untrue - and I have direct knowledge of many more projects that have suffered the same fate. By testing assumptions early I am now able to reduce the impact of unexpected problems.

7. Budget your time wisely: In the early days, I blew too much analysis time on small parts of the business area. I am much more careful now in planning and budgeting my time. I’ve learned to work top-down; in the beginning, I concentrate on the big picture and work my down into the weeds as the project progresses.

8. There is almost always a hidden agenda: For any non-trivial project, there is bound to be some aspect of office politics that can make or break the project. In many cases I have ended up being an unwitting pawn in someone else’s power play. In one case, for example, there were warring departments, each of which had already made up its mind about the preferred solution; the hidden agenda of the project champion who brought me onboard was to get an ‘unbiased expert’ to recommend his preference.

9. Don’t solutionize the requirements: The requirements as written, should make sense regardless of the technology solution. Otherwise, they will not be reusable should the preferred solution change – leading to lost time and effort.

10. The clients already know the answer: This is the secret lesson of consulting that I learned at the hands of a colleague (Brian Lyons) – and I’ve found it to be true more often than not. In many cases (such as process improvement projects), the clients know what’s wrong and what they need to do about it - and are really looking to the BA to confirm what they already know, or to help them formulate their thoughts. Yet another reason why it’s more important to listen than to talk.

And what about that question about psychology, business analysis and art (all of which are interests of mine)? The flippant answer is to say that these interests co-exist but they don’t necessarily connect. By maybe they do. I have an endless curiosity about people and how they live their lives – and it is a curiosity that the BA profession has helped me satisfy. As well, I have always been interested in the structure of thought – a theme that underlies both cognitive psychology as well as structural analysis. My art similarly has two recurring themes - often concerned either with the psychology of an interaction (see this series based on my experiences in South Africa) or with the way the mind organizes information (see this link for work based on organizing visual bytes of information).

So maybe there is some connecting thread to it after all.

- Howard Podeswa

This entry was published on Feb 15, 2011 / Howard Podeswa. Posted in Business Analysis, Soft Skills, Career as a Business Systems Analyst, Getting Started as a Business Systems Analyst. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  35 members liked this article

Related Articles

COMMENTS

Putcha posted on Wednesday, February 16, 2011 2:35 AM
Good points. Brief and Quick. These points should be voted & reflected in BA Syllabus for beginners. Methods and Tools if available should also be cited.

Putcha V. Narasimham ([email protected])
Putcha
Howard Podeswa posted on Monday, February 21, 2011 8:08 AM
re: Putcha. May I add an invitation to readers to provide responses to Putcha's points as well as their own lesson learned with respect to "Things I Wish People Had Told Me When I Was Starting Out As A BA"?
Howard Podeswa
Putcha posted on Monday, February 21, 2011 9:41 AM
Dear Howard Podeswa:

Yes, you can invite views from other members but a survey would be better. Let them rank the top 3 points they agree with and 3 points that are not applicable with reasons.

Then we will get to know what is happening in the practical world.

Best wishes,
Putcha
Matt M posted on Monday, February 28, 2011 8:20 AM
Excellent points, taken to heart by a new BA! I may particpate in your opinion gather or survey at a later time as some thoughts did strike me from my first (recent) experience as a BA.
As an addendum, Howard, I have two of your books (UML and Handbook) and they are excellent.
Regards,
M
Matt M
Howard Podeswa posted on Monday, February 28, 2011 9:22 AM
Thanks for the feedback, M. (Ah, the compliment. It never gets old!) If you find the time to share those thoughts, I think it would be very useful and interesting to the community. To all: Informal survey notes (on which points are most/least relevant) as well as points you'd like to add can be posted here or sent to my personal email at [email protected]
Howard Podeswa
Jim posted on Wednesday, March 9, 2011 7:13 AM
Excellant points!

My number 1 point would be: It's about solving business problems. Focus on the business, not the tools or the complexity of the solution. Understand how solutions are going to benefit the business.

You're #3 point, finding the ultimate signing authority, sounds like more of a project manager statement. I agree that it's important to keep them informed, but my replacement for that statement would be "Find the person that built the process from the ground up". They will generally be the hardest to work with, because they will challenge everything you do in the process; but for a very good reason. They actually know the process.
Jim
Howard Podeswa posted on Wednesday, March 16, 2011 9:29 PM
Your #1 point gets my vote, too.
I like your #3 point about finding the person who built the process. But I stand by mine about finding the signing authority. The PM may be the role ultimately accountable to that person, but it is the BA who is responsible for supporting the PM by liaising with stakeholders - and that includes (especially) the one who signs - and, preferably with enough lead time to revise the requirements if there are changes that need to be made.
Howard Podeswa
Rohit posted on Sunday, March 27, 2011 3:13 PM
I think #3 point goes to stakeholder analysis. The person who is most influential on the project (project sponsor) is the key to the success or failure of the project. He commits the resources (human & money) & lobbies the project idea in the business circles.

I have had 2 recent projects where most of the interaction (by me & the PM) was happening with the client CTO. Eventually we realized that the project sponsors wanted us to break the bad news to them so that they project objectives were met. Based on my experiences I couldn't agree more with #8 (there is almost always a hidden agenda) as well.
Rohit
Jim posted on Monday, March 28, 2011 8:47 AM
#8. Hidden agenda is just another word for incomplete requirements. Requirements will always be discovered. It's up to you whether they will be discovered before the "Go-Live" date, or after. You're probably spending too much time analyzing the wrong part of the business if you're finding covert agendas. Listen to the business. These projects are not your projects. They belong to the business. If you're a business analyst, then focus on the business and not what you'd like to accmplish.

These are simply conflicting requirements. There's nothing magical or covert about them. They need to be resolved, and it's your job to resolve them before the project is derailed.
Jim
Victoria posted on Monday, April 4, 2011 3:22 PM
Thanks
Victoria
BumbleB posted on Tuesday, April 12, 2011 3:46 AM
Nice! Set me thinking and I have my own list now.
BumbleB
ClaireBA posted on Wednesday, May 4, 2011 2:02 PM
Hi. Regarding point 9. Do you not think that BAs should offer a solution then in addition to encapsulating the requirements?

ClaireBA
Du posted on Thursday, June 30, 2011 7:08 AM
ClaireBA,
I think all he is saying is not to create requirements that will only apply to a specific technical solution. For example creating requirements of which can only be implemented using a language that can build object data structures: C vs. C++, if that's a good example.

Concerning #8 I guess it's just to be aware of these hidden agendas and not get blindsided?
Du
leuman posted on Tuesday, July 12, 2011 7:01 AM
All were already noted. Thanks.
leuman
DK posted on Saturday, October 15, 2011 3:56 PM
Excellent compilations, these are truly BA 101. Moreover these have deep implications such that one can refer and get new insight every time !
Note points #5 (people don’t know what they want) and #10 (client already know the answer) ‘appear’ to be in conflict, but they are true in the context. User already knows what needs to change or how to improve a process, but system User Interface is an iterative exercise even for best BA’s.
Another point I feel is crucial (related to #2) is, BA has to adapt to the style of the particular client while eliciting requirements. People have different perspectives like top down, bottom up, visual, people centric, detail oriented etc. BA needs to listen to encourage client to trust him and open up. Later to fill the missing gaps, BA has to ‘interview’ on areas client didn’t touch earlier. This approach works better than forcing one’s own process preference on the client.
DK
Mike posted on Saturday, November 5, 2011 7:37 AM
I agree with 9 in that it is very easy to be concerned with the solution during the requirements phase. Its during this point that it should be all about the what and why to the point that it is all clear and pretty much unquestionable.

However point 10 may well be true for some but in my experience its almost the reverse. Clients will certainly have an answer to their problem and want the BA to ratify or do something about it but I have found it is often the incorrect answer. Clients will have solutions that don't really address the real problem and will only provide a band-aid fix which isn't the best way to go.

mike
http://the247analyst.wordpress.com
Mike
LLMABA posted on Thursday, January 5, 2012 2:13 PM
Howard, excellent points! Psychology, business and Art = People, Processes and Tools. When I work on any project, it is all about the "people" and getting stakeholder feedback, understanding the business process and using a tool to create a visual representation of the project. It is all interconnected. Yes, BA's have to wear three hats!
LLMABA
LLMABA posted on Thursday, January 5, 2012 2:14 PM
Howard, excellent points! Psychology, business and Art = People, Processes and Tools. When I work on any project, it is all about the "people" and getting stakeholder feedback, understanding the business process and using a tool to create a visual representation of the project. It is all interconnected. Yes, BA's have to wear three hats!
LLMABA
LLMABA posted on Thursday, January 5, 2012 2:15 PM
Howard, excellent points! Psychology, business and Art = People, Processes and Tools. When I work on any project, it is all about the "people" and getting stakeholder feedback, understanding the business process and using a tool to create a visual representation of the project. It is all interconnected. Yes, BA's have to wear three hats!
LLMABA
LLMABA posted on Thursday, January 5, 2012 2:16 PM
Howard, excellent points! Psychology, business and Art = People, Processes and Tools. When I work on any project, it is all about the "people" and getting stakeholder feedback, understanding the business process and using a tool to create a visual representation of the project. It is all interconnected. Yes, BA's have to wear three hats!
LLMABA
Kirk Fleming posted on Tuesday, September 11, 2012 12:54 AM
Most excellent! I was nodding my head in agreement as I read each one, and for nearly every point a specific experience came quickly to mind. Point 3 may be obvious, but it's a fresh and concise statement of a great idea that's not part of my thinking--and should be.

The spin I'd put on Point 10, though, is that influential stakeholders generally know the 'right answer' from the outset, and that this is the path ultimately taken in the decision process. But, this may have nothing to do with the actual 'right answer' as indicated by facts, data or even just consensus. What the client may know that the BA doesn't, however, is what is 'culturally implementable'. That may be the defining element of 'right'.

Very nice Ten Things. Thanks!
Kirk Fleming
Bernie Hittner posted on Tuesday, September 11, 2012 2:40 PM
Very nice post indeed. The points made me think that indeed these must have been made available to us as well when we were starting.
Bernie Hittner
Vishal Katti posted on Saturday, September 15, 2012 8:11 AM
Thank you so much for these Beginner tips. These do confirm what i've learnt over the 2 years i've worked as a BA.
However, i would also like to add a small point to #3: Stakeholder Analysis.
Although it is imperative that we must find the signing authority, we must ensure that we also meet the most influential End-user too since usually both are not the same. Failing to differentiate and identify these two positions can lead to serious issues in the post-release acceptance and Customer Satisfaction Index.
Vishal Katti
Jiten posted on Wednesday, April 3, 2013 4:24 AM
The 10 golden rules! Amazing!!
Jiten
liz.chibvuri posted on Tuesday, February 4, 2014 4:10 AM
Great points
liz.chibvuri
Dennis posted on Sunday, June 29, 2014 10:52 PM
Good points. #9, is great, Focus on discovering the problem instead of the solution, then the solution will come easier. I'd also add, focus on the riskiest or most ambiguous issues first.
Dennis
AlvinPark posted on Thursday, September 24, 2015 5:24 AM
Wow great post...with great info..thumbs up!!
AlvinPark
Only registered users may post comments.

 



Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts.




 

ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Copyright 2006-2024 by Modern Analyst Media LLC