Sunday, 01 June 2008 19:00

An Examination of BA and PM Skills Profiles

Written by  Robert K. Wysocki
Rate this item
(1 Vote)

In the previous article I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the "BA/PM" for lack of an appropriate position title. Requirements gathering and management was the thread in that article that inextricably links the BA and the PM in the Agile Project World.

In this article I want to look under the hood of this new professional that I am calling a BA/PM. Using the PMI PMBOK and the IIBA BABOK I will list the skill and knowledge profiles of the BA and the PM. A comparison of those two profiles will show remarkable similarity between the two. This should come as no surprise to anyone and will further support the creation of the BA/PM professional, at least in the agile project space if not the entire project space.

My hope is that I will have captured your interest and attention enough for you to share your thoughts and ideas whether you agree with me or not. I welcome opposing positions and the opportunity to engage in public discussions.

BA and PM Skills and Competencies

The following table presents a high-level comparison of the skills and knowledge of the BA and the PM as derived from the BABOK and the PMBOK.

skillschart.png

Is it any surprise that the two lists are nearly similar? From the perspective of the BA all of their work is done as part of a project and so they must have all the skills of a PM to match the complexity of the projects they manage. From the perspective of the PM, not all of their projects will have a BA component but they must have at least a working knowledge of the BA skills.

Assessing Proficiency Levels

Once a BA/PM position family is in place, the BABOK and PMBOK columns will be replaced with the position family,  and the column check marks will be replaced by the minimum proficiency levels as defined by Bloom's Taxonomy, which is shown below:

Level 0:          I never heard of it.

Level 1:          I can define it.
1           Familiar with the terminology
2          Understands the basic concepts

Level 2:          I understand what it can do.
1                    Knows how it is used
2                    Can explain key issues and benefits
3                    Understands organizational relevance

Level 3:          I have limited hands-on experience.
4                    Has a working knowledge of basic features and functions
5                    Aware of relevant standards, policies and practices
6                    Requires assistance and supervision
7                    Can apply it in a limited (homogeneous) environment

Level 4:          I have extensive hands-on experience.
8                    Knowledge of operational issues and considerations
9                    Understanding of benefits and drawbacks
10                Working knowledge of relationships and integration
11                In-depth knowledge of major features, functions and facilities
12                Awareness of usage in other environments
13                Can work without assistance or supervision

Level 5:          I can adapt it to a variety of situations.
14                Theoretical background and understanding
15                Expertise in all major features, functions and facilities
16                Experience in multiple environments (heterogeneous)
17                Knowledge of and contribution to "best practices"
18                Ability to consult and coach others

Level 6:          I am recognized as an expert by my peers.
19                Extensive experience in multiple/complex environments
20                Industry and marketplace perspective
21                Historical and future perspective
22                Influencing wide or high-impact decisions and initiatives
23                Leadership on architecture, policies, strategy and "best practices" 

In order to be proficient at say, level 4, there must be visible evidence that the 10th through 15th behavioral characteristics are present in the person's work habits. Neither the BABOK nor the PMBOK offer enough detail to assign a minimum proficiency level to each skill. Until there is a standard BA/PM position family, the need for a skill is just noted without a proficiency level assigned. In constructing this table, I started with the PM skills profile I developed, beginning with PMBOK and factoring in client contact for the past 20 years, and supplemented it with added skills and knowledge as noted in BABOK.

Professional Development of the BA/PM

With the need for the BA/PM professional firmly established let's take a quick look at the BA/PM professional development program. The first piece of this puzzle is to define the BA/PM position family. Neither BABOK nor PMBOK has anything to contribute to defining the BA or PM position family. Here is my first take on that definition.

  • BA/PM Team Member
  • BA/PM Task Manager
  • BA/PM Associate Manager
  • BA/PM Senior Manager
  • BA/PM Program Manager
  • BA/PM Director

I intend to define these more precisely in a subsequent article and to suggest a professional development program structure for consideration.

Putting It All Together

I would certainly like to hear your thoughts on the BA/PM professional. I'm sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.


Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Read 6679 times Last modified on Tuesday, 27 March 2012 12:46

Comments  

0 # Michelle Jodoin 2008-06-02 06:04
I've only skimmed this articled so far, but I'm confused already. There's no "X" in the BABOK column next to "Requirements Gathering" or "Requirements Management". Seems to be a rather large typo since "requirements" are the main focus of the BA.
Reply | Reply with quote | Quote
0 # David Wright 2008-06-02 07:02
First, I agree with the first comment. Secon d, where is Project Control, what a PM does most? Third, why is Requirements Management a sub-point of Project Management? I could ask more questions, but would like answers to these first. Overall , the list does not feel 'right', would like to see the references to relevant sections in each BOK for each list item.
Reply | Reply with quote | Quote
0 # Daryl Allen 2008-06-02 07:53
Also agree with the first comment and would like to add that there are other issues with the table. An example, there's no X for "Schedule Development" from the PMBOK.
Reply | Reply with quote | Quote
0 # Adam McClellan 2008-06-02 07:59
Here’s something I’ve noticed about both articles: they conflate the question of whether a single person can be skilled at both the BA and PM roles (yes, they can) with the question of whether one person should play both roles on a single project. In my experience, having distinct PM and BA roles on medium-to-large projects is beneficial for two reasons: 1. you divvy up the considerable labor to be done in defining a solution and monitoring its creation 2. you bring multiple perspectives to bear on the work I think it’s likely that, in order to give themselves increased flexibility in staffing projects, more companies will start looking for people who can switch between the BA and PM roles. But I haven’t seen any innovations, technical or otherwise, that would save enough labor or replicate the benefits of another perspective to the point that one person could do both jobs well.
Reply | Reply with quote | Quote
0 # Katherine Lemond 2008-06-02 09:29
Our company is having this same discussion. The other piece missing is the level of respect associated with the two professions. A PMP garners a certain level of respect that is often not associated with BA's. Clients can be very confused by having one person wearing both hats, as we have worked very hard to distinguish the skills needed for each. While this theory may work on small scale (i.e. scope) projects, it really isn't doable on a larger scale. There may be overlaps in the job roles, but the expected proficiency/ski ll level is different.
Reply | Reply with quote | Quote
0 # Don Joy 2008-06-02 09:42
No Meeting Management requirement for BA? And NEITHER is required to have Writing Skills?
Reply | Reply with quote | Quote
0 # Benito Agbulos 2008-06-02 12:42
Don't know exactly where you're going with this but BA and PM responsibilitie s just can't be handled by one person. Maybe it will work for small projects but surely not for medium to large projects. Agree with the other comments, re errors in your table.
Reply | Reply with quote | Quote
0 # adi 2008-06-02 20:01
As a PM with huge respect for BA skills I'm looking at this list with surprise as it sure doesn't represent the variation of emphasis on the skills listed. Also, during the times I've had to do double duty the PM role has been the one that got short shrift as the people management, comms and planning suffer in comparison to the very real 'hard requirements deliverables as a BA. Best to keep the roles separate and do them both well. It's been hard enough getting business to recognise these are 2 separate disciplines and skill set. Why go backwards?
Reply | Reply with quote | Quote
0 # Janet Wood 2008-06-03 03:03
Huh? There are a lot of the skills listed under Project Management Skills that I can't remember seeing any explicit reference to in the BABOK. And quite a lot that ARE there that I don't see in the BA column (Requirements Gathering, Requirements Management). Please show us how you put this list together. It is possible that your list supports your basic contention, but I feel that that's because the list is WRONG, not because what you trying to prove is right. It's easy to prove a point if you select the basic arguments, but I think you need to prove those first. Like many of those who have commented above, I believe the roles ARE separate and need to remain separate, so I'm not going to be convinced easily and certainly not by some carefully crafted "evidence".
Reply | Reply with quote | Quote
0 # Jackie Shale 2008-06-03 04:28
I agree many of the competencies and skill sets overlap, many overlap with other professions as well. What is the purpose of each role? Can you draw the line clearly between their responsibilitie s?
Reply | Reply with quote | Quote
0 # Richard Walsh 2008-06-03 05:16
There are some great points made above. My two cents is that these roles do have similarities (obviously), but in a realistic project environment the roles still need to be separate. Perhaps a realistic BA/PM organization would be comprised of organizational branches of BAs and PMs that work very closely together, but never a team of people that perform both roles at once.
Reply | Reply with quote | Quote
0 # Alexandra Gorman 2008-06-03 05:35
Of course, I agree with everyone's points above... I also agree that the skills and competencies overlap; however, on a project, it's not only their responsibilitie s that are different... Their focus is different. As a BA, my primary job is to follow THE REQUIREMENT. As a PM, their primary job is to follow THE PROJECT. One of the biggest differences is that the PM can almost never leave the parameters of a project which may go outside the realm of the written requirements, whereas a BA can never leave the parameters of a requirement, which may go outside of the given project. Blurring the lines between BA and PM make these tasks too difficult - it means that there are no longer any parameters or lines, which talks to constant and continuous, self-inflicted SCOPE CREEP.
Reply | Reply with quote | Quote
0 # Craig 2008-06-04 04:36
I agree wiothy the sentiments above. I agree that there is confusion between capabilities expected from practioners of each role and of the role itself. I do both, at different times and I feel my strengths come from understanding both roles. But what about PM/Developers? Are they any less effective because their domain epertise originates with technical design and development skills rather than business and modelling ones?
Reply | Reply with quote | Quote
0 # John Dean 2008-06-04 06:18
This comparison of the BABOK and PMBOK is completely spurious. At its heart, the PMBOK describes a set of tools that can help a program manager deal with the complexities of very large projects. Comparing it to the BABOK is nonsense.
Reply | Reply with quote | Quote
0 # ANDREW GUITARTE 2008-06-04 07:08
The questions that needs to be asked are these. (1) Are project managers more effective if they possess BA skills? The answer is YES. (2) Are business analysts more effective if they possess PM skills? The answer is YES. Are PMs or BAs more effective if they perform the job of a PM and BA at the same time? The answer is... (That's what I want to know.)
Reply | Reply with quote | Quote
0 # David Genest 2008-06-04 09:37
On the surface, these are some good ideas. One major concern is this. Would this role have the necessary authority to GET THE JOB done? IE - in certain circumstances the PM MUST use their muscle.
Reply | Reply with quote | Quote
0 # adam2 2008-06-04 10:49
Hi All, as per the first comment...the table formatting was off and we have fixed. Apologize for that. Thx, BAT imes!
Reply | Reply with quote | Quote
0 # David Wright 2008-06-04 16:53
well, it is prettier now but no more helpful. How about taking oneof the items with x's for both and showing us what each BOK says about it.
Reply | Reply with quote | Quote
0 # Tiffany Rughoonundon 2008-06-10 09:02
Wow...I wish I had the luxury that those individuals who wrote the IIBA manual had in not having to manage meetings and quality, project close out, using project management software, and creating charters. I have never experienced any PM conducting acceptance testing but this could be my experience only. I also have quite a bit to recommend for staff and career development, especially for some PMs I have had to work with in the past. I do agree that for medium to large projects that there needs to be a PM and BA. It would be very stressful if it were only one person performing two roles. I actually think the project would run over in projected hours unless you had multiple BAs working the same project to accomplish the tasks for the project. I know this from working experience when my group did not have any PMs. However, for small projects I definitely say a BA can handle it.
Reply | Reply with quote | Quote
0 # Joe Medica 2008-06-11 06:50
Not to pile on, but, I have to agree that MANY skills are missing from each of the descriptions above. Meeting management, negotiation skills and writing are definitiely requirements of both BAs and PMs. I agree with a few of the comments above that listed requirements under the Project management header weakens the presentation of those skills as a distinct skill set, and makes it easier to lump all of it under PM. I also agree that Medium and larger projects CANNOT function with a BA/PM person as one role - there is simply too much to do for one person. It can be set up that way, but it is really a question of SHOULD it be set up that way... I would also counter that small projects should have the roles separated whenever possible. This gains a benefit in that the department can assign additional projects to BA and PM resources if they function as only one role. This means that the department can complete more projects, and the resources can become more efficient and focused at what they do. Besides, as we all know, if you are the sole resource on a project, you WILL overlook things, or make assumptions that will come back to haunt you. Again, possibility wars with reality - reality is, it is much more efficient for the resource and the department to focus resources as opposed to having wide angle resources that can cover multiple roles. Lastly, I just want to point out that I have already been a BA/PM in previous roles, and I agree they CAN co-habitate. I strongly disagree about WHETHER they SHOULD though, for reasons above.
Reply | Reply with quote | Quote
0 # Mike Murphy 2008-07-08 15:41
There seems to be flaws in the logic with this BA/PM idea. A very talented person on a very small project could play the role of PM, BA, Architect, Developer, and QA. Does that mean we should combine all those roles? The fact that a person who performs Role A well and who also might perform Role B well does not support the conclusion that Role A and Role B should be combined. Roles have responsibilitie s, and the responsibilitie s for BA and PM on a project are very different. Think RACI. Should BA and PM know about entire lifecycle? Yes, the more so, the better they'll perform their respective roles. But it is not a valid conclusion to say these roles should be combined. For example, wouldn't a really good Architect be very good at eliciting requirements? And understanding how to design for quality? and design for testing that quality? and managing tasks and costs to deliver to the customer? Why not suggest combine Architect and BA or Architect and QA or Architect and PM? Good luck with your non sequitur quest.
Reply | Reply with quote | Quote
0 # Grace Hanney 2008-08-01 09:43
A comparison of the BOK Tables of Content is not a true indicator of overlapping tasks. For example, Risk Management. Risk Assessment and Management at the PM level is Project risk; are we on time, on budget, on scope, do we have the correct resources, etc. Risk Assessment at the BA level is requirements risk - will the function perform as expected, interface mapping, did we capture all the processes, etc. BIG difference! I think you'll find that if you compare the actual tasks outlined in the two books, you will see that the focus is quite different.
Reply | Reply with quote | Quote
0 # Joseph Ruffolo 2009-04-08 02:23
I believe that PM and BA roles share many of the core capabilities. I have had all my BA staff attend project management classes. HOWEVER, the role and focus for PM and BA are different. Combining the roles on anything but a small project or as part of a maintenance team is a big mistake. A project or program manager needs to focus on the project features, scope and project plan. A business analyst needs to focus on the business and functional requirements and bridge the gap between the business SME and the development team.
Reply | Reply with quote | Quote
0 # Denise Arruda 2012-01-31 22:50
I have been a project manager since 1999. Since them I have run many software and IT Infrastructure projects. They have mainly been small to mid size projects, but I have never had a BA assigned to my project. I have always worked under the premise that it is the PMs role to gather, document and verify the requirements. The PM is working with teh customer to understand what the customer requesting and the what are the project deleverables. I have seen large projects where additional BA's are required based on the workload, but the PM heads the requirements effort. I agree that these roles should and in many cases are combined
Reply | Reply with quote | Quote
0 # Victoria 2012-02-01 09:28
From my own experience - and certified from both PMI and IIBA, yes alot of the skills compliment the role of the other which is why I believe my success is due to the level of expertise my team has. My role is enchance their skills, remove obstacles, change management and communication at all levels. Every PM needs an excellent BA as his right hand and every BA needs a PM to make things happen. When asked to be both one or the other role suffers.
Reply | Reply with quote | Quote

Add comment


Security code
Refresh