Combine BA/PM?

This is my second article on the same subject.

Yesterday I was going through Business Analyst Times and came across with some interesting facts about the so called PM/BA role.

Some people might take this as a direct attack to their practices and so called best processes throughout the years and might take it personally.

My first question is, is it fair enough to ask for a person to bare both the roles on a project?

These two are against to each other.

Good BA should look at the customer’s needs and should be able to convert them in to format which ease the life of the developers and the testers. He should be able to list down and develop all the requirements from the customer’s side. In some cases he should be knowledgeable enough to figure out the customer’s needs and propose something workable for them. He should be smart enough to identify the priorities and develop requirements accordingly. Then the developers can identify the customer’s needs and convert them in to a working piece of software and testers can start deriving test scenarios or the transaction sets to see the health of the application.

PM on the other hand is there to control the scope, budget, time, resources and quality of the deliveries. Some might argue that controlling the scope is somewhat business analysis task so that PM can wear the BA hat easily.

Someone will suggest that for smaller projects, you can get the PM to work as the BA as well.

Yet again it’s a burden for the company. If it’s a small project, let a senior dev or test resource to play the BA role on behalf of the team. Otherwise you will be ends up with increasing the project costs. Rarely the pay rate of PM goes below a developer or senior engineering resource. Companies might think that they are keeping their PM resources idle by giving some small project(s). That’s not PM’s fault, it’s an issue with the company’s forecasting and the sales team. If your sales team can not bring down projects which create enough workload for PM’s and if your resource management team can not foresee the resource requirements for the projects, then you have to deal with those. You have to fix that issue first. Please do not try to screw the lives of your PMs by adding something opposite to the PM practice in to their bag due to inefficient marketing and resource management teams.

Following comments were taken from the BA Times. Those were published by very seasoned Bas with number of years working experience against their BA portfolio.

“They are also the advocates for different goals. The PM needs to think time lines and the lining up of schedules, resources, and events. The BA needs to ensure that critical requirements are met and that the system is useful to the customers. That's not to say time lines don't concern the BA, but it snot his/her primary focus. It's through dialog that these two can compromise and work together to build a system that can be workable and on time.

If you combine this role, you'll always have someone who leans too far on either side of the fence.”

“It guess it all depends on what you expect a BA to do.

If you expect your BAs to simply document the work of others... then there isn't much of a difference. However, if you expect your BAs to play a significant role in the overall project then there is a significant difference between the skills set of a PM and a BA.

A BA is the keeper of the "what's delivered". They know not simply the requirements and design they also know the "intent" of the customer of a project. They play the role of "keeper of the faith" with the customer. The BA knows the "what's" well enough that they can "know" the systems impact of a change or issue.

The PM is the keeper of the "when it's delivered" or "how it's delivered". They know all the work items and which have to occur in which order. They know when each comes in to play and when they will be delivered. They are the "keeper of the schedule". The PM knows the "when" well enough to know schedule impact of a change or issue.

These are distinct skill sets... The ability to hold the entirety of a project in one's head well enough to do both the BA and PM role is a huge task that very very few can do well (if any can.)

I guess the real distinction between the skills of a BA and a PM is not that one can't do the role of the other... After all... most of us can use a paint brush, and we can paint a house. The issue isn't ability its skill. And, its the nature of the skill sets of a BA versus a PM. The best BAs I know have a more abstract way of thinking. They tend to model reality as a set of generalized rules. This versus the best PMs I've met who tend to a more concrete and defined way of thinking. They tend to conceive of reality as a series of discrete events driven by specific rules.

Another way of looking at would be... PM are hearders... BAs are guides. Both get you where you're going... they just do in in very different ways. Are the skills the same? No. Is the out come... perhaps... but the journey certainly was different.”

“As a BA, I TOTALLY agree with you! We actually have combined PM/BA roles in my organization now and it has had it's share of issues! We are currently in the process of separating those individuals into either the PM or BA role. There are a lot of soft skills that a BA needs to have vs. soft skills a PM needs to have. Like you said--different brain wiring! Combining the two into a single role is NOT the way to go!

My vote is an emphatic and resounding NO!!!!!”

“A combined PM/BA role might be practical on small projects or on simple projects (or if such a person is willing to work 16 hours a day). Any project of moderate complexity needs to have dedicated focus by a PM and BA to insure the PM is not being distracted by the often very time consuming details of analysis (or other aspects). This is also necessary to insure that resources are being properly utilized and that the PM has time to think proactively about the project to anticipate issues and alert stakeholders to needed course corrections before major issues arise. This is one of the most important functions of a PM.

Most projects I am involved in require several BAs and at least one PM, all of which can generally expect to work more than full time. Combining a PM/BA role would be a major risk for a project of any complexity or size for the above mentioned reasons, which would need to be added to the project risk register and monitored throughout the project. I speak from experience currently as a BA on larger projects having been a PM, developer, DBA, data modeler etc on various past projects. That's my 2 cents worth.”

“I'm a BA that is forced to play both the PM and BA role in more and more projects. It is a challenge because the roles have principles that conflict.

Unfortunately, I see a lot of companies moving in this direction. And I also see many professionals promoting themselves as a "PM/BA".

I personally believe the roles are best left separate especially considering many BAs have no interest in PM work and vice versa.

Is PM/BA/QA next?”

“Indeed... not "wired different" (per say)... Rather, focused different. Can a BA transition to a PM role and vice versa? Absolutely. But can one person do both roles effectively, no (IMO). Its bad for the workload, its bad for the appropriate project controls, it is distinctly two different function. The PM and the BA are peers in a Project... They keep different aspects of a project in-alignment with the business/customer goals.

Anyone seeing some sort of merger of the roles is also seeing a much smaller scope for each role... They are under-utilizing their BA and PM resources.

It comes down to how one defines what the roles are. In some companies the two roles are easily combined because the actual scope is significantly limited and really is much more administrative in both cases. In other companies I've seen the roles of the BA and PM having a much greater definition and each is a high distinct skill set and responsibility set.”

Throughout the years we are discussing about the same topic. But some organizations purposely combine these two roles for following reasons;

• They want their employees to work like slaves
• They do not want to spend a penny more to improve the work life of the workforce
• They never think about their customers
• They think their customers and employees are dumb asses (one suppose to pay contract fee on time and other suppose to work for less)

You can add many more to the LIST

Ultimately what happens is both these fellows will get frustrated and move out!!!