Project Management Central

Please login or join to subscribe to this thread

Topics: Business Analysis/Requirements Management
How long does it take to be a good business analyst?

There's been some changes within our department where the BA role is now under the "umbrella" of the project manager. The BA roles were reduced to one so now the PMs are taking on the role of BA (including writing BRDs) for small scale projects. While I get that some of the PM skills can be translated to BA I have not ever had to write BRDs or be responsible for facilitating and leading requirements meetings. I was sent to one training class (online) that was about 4 days long. Now I'm being asked how long will it take me to "get up to speed". The former manager of the BAs is no longer responsible for BA work, the one BA transitioned to PMO is new too and my manager does not have BA experience. What is a fair answer? I am also being asked what it will take for my success and that I can answer that I should have coaching and support from an "expert" BA. I'm a bit lost here and looking for input/suggestions...
Sort By:
Page: 1 2 next>

Rebecca -

Sounds like a really tough situation! Eliciting and analyzing requirements is both an art & a science, and without support to help you develop these competencies, it will be a challenging road ahead. I would definitely agree that support from a seasoned senior BA will help out a lot.


I would call myself a good BA after doing that for couple of years. Good BA grows with experience. It takes to do several projects to get comfortable with the outputs, to get confidence in understanding key users and it takes a lot of time to get the skills of decomposition of the requirements. There are so many aspects in good BA work, it is heavily related to business process management and understanding IT systems architecture. Another success factors are in communication skills, ability to connect business issues with possible IT solutions. It’s complex.
But I don’t want to scare you though:) my point is more that BA is a solid discipline as PM is. There are definitely people who can be both in terms of skills, but I think it may become an issue of responsibility, there will be challenges with change management and setting the right project priorities, if the two roles are combined.

Business Analyst is about to avoid ambiguity. "Good" is a subjective matter that must be transformed into objective one. So, first thing is that. Second, the worst thing an organization can do is putting Business Analysis below Project Management. Business Analyst starts working before a project exists and continue working after the project end. To be effective as business analyst and project manager a critical thing must be understanding: business analyst focus is "the thing" to be created while project manager focus is "the process" to create it. "The thing" plus "The process" is equal to "The Solution" and business analyst extend its scope of work to the solution. Most of them that started the business analyst role definition (contributing to create role definitions and standards with the IIBA thar was the organization which created the role) and execution have cover both roles in the begining. BUT except for people that can switch making a shift in their mind is not effective. Business analyst and project manager behaves and think totally different. Business analyst must let their customers fly while Project manager must land their customers.

I manage software projects, Business Analysis especially defining requirements has been a challenge for me. I have been doing some online learning to ramp up my skills. The PM role and BA lots of similarity but BA is more specific and as a PM you need both skills. I play both roles in my Projects, I am involved from the planning to execution.

We do not have BA's at my company. Gathering requirements is the responsibility of the project manager and in some cases the developer. This has been a challenge at times and there have been many instances when major requirements were missed or not fully realized.
I am not a BA, but I have been gathering requirements for many years. These are my thoughts.
Many people approach gather requirements as "What do you want?". You need to really understand their process and what they actually need.
The art of gathering requirements is to keep asking questions.
- Why do you need this feature? - to solve this problem
- What is the problem exactly? - problem xyz
- Is this the only way to solve the problem? - I don't know
- Let's document the problem first and then look for the best solution.
Do not try to do a design during requirements gathering.

I think it takes time to do both jobs very well. Especially on "large" projects, it is a full-time job to manage the project and to manage the product requirements. So, trying to do both will usually mean increasing the risk and compromising the quality of the project and the end product.

Tough situation. There is certainly an art to proper business analysis. As I have mainly been in IT, it is a line of translation from the pure business side to IT. It is an art (and science) in facilitating discussions with the appropriate SME's and eliciting the information needed. Walk them through a day-in-the-life of and create a story. Many times business units do not have formally documented procedures. More of an established 'this is what we've always done'. Finding out the decision and pain points is important. Relationship building and trust are important (aren't they always, though!) There are guides and processes that you can utilize to walk them through.

In my previous role I performed both as the BA and PM. I liked it. Mainly the projects were relatively small, so it was manageable. Large projects could pose significant challenges.

Good Luck.

This is sometimes really unpredictable up to what extent the impact could go due to change in the organization. I think, you are not liable for any lack in your competency requirement for any specific project, it is the organization who should assess and plan how an affected employee would address this impact. It could be on job training, facilitate coordination among other experts within and outside the organization. I think, if possible, it could be a better idea to let them know very clearly your level of competence as BA and make an informed decision.

Like any role, there is the knowledge/skills you have beforehand, and those that you gain during the role. There is no real answer as to when you will be up to speed, it will depend on your ability and training and the context of the role. But one good thing is with an absence of BA's, look at the bright side, it is your opportunity to shine. Take the opportunity to get trained up which can include some form of mentoring from a BA consultant even briefly, which I am sure your manager will approve. Make this a requirement of "getting up to speed".

BA role is always been overlooked and not taking into account and I agree with that most of the time Project Managers and/developers gather the requirements but IT Professions always don't have the business point of view that's why we end up just gathering requriements that are not adding value to the business and features that are not even being used .BA instaed analyze the why this requirement is needed and from there usually requirements change and evolve .
Page: 1 2 next>  

Please login or join to reply

Content ID:

"When you want to test the depths of a stream, don't use both feet."

- Chinese Proverb