BA World Ottawa - Should the PM be in the BA's business?

 digg it |   delicious |   StumbleUpon |  reddit 

BA World Ottawa continues to be a great success with track sessions, panel discussions, and the final panel "throw-down" event.  The day started not with a keynote, but instead a series of round-table discussions on current BA Topics.  I think this is a great change-up to the traditional opening, is a wonderful way to initiate new connections, and a terrific way to kick-start the grey-matter first thing in the morning being an active participant rather than in listen-only mode.  

I was fortunate enough to moderate a round-table discussion on whether PM's should be doing BA-focused tasks.   The table included a wide variety of roles to my surprise.  There were of course BA's but also QA professionals, project managers, and even a trainer.  What emerged was a general concensus that the PM should be focussed on 'process' execution to drive the initiative while the BA needs to be focused squarely on what is to be built (as expressed by the requirements) and why (mapping to business objectives). 

Of course these two things are connected at the hip and you need to have very effective communication between the roles, but in essence each needs to focus on these two distinct aspects. The experience of the BA's at the table, each of whom had experienced a PM getting too far 'in their business' at one point or another, was that it happened mostly with new PM's or PM's who were insecure in their position and felt the need to micro-manage as opposed to simply being the result of poorly documented roles.   Another interesting experience was one whose company had a core group of BA's but would bring PM's in from the outside for each new project.  This meant that the subject matter expertise would reside with the BA and thereby limiting a PM's ability to go too far into BA tasks, and arming the BA with the information and knowledge needed to effectively 'push-back' on PM's who went too far.

All agreed that inter-role communication is one of the biggest sources of error on software projects.  Based on this it was proposed then that the ideal situation is when the PM and BA functions sit with one person so that there should be no communication issues.  One argument against this was put forth by another BA at the table who currently has a very good relationship with their PM and finds their ability to challenge each other on almost every aspect of the requirements and process would be lost if one person was doing both jobs.

There are clearly pluses and minuses to each arrangement and by the end the group felt that while each should focus on their core tasks (PM-process; BA-what&why) it would be more a function of the particular individuals involved and their ability to communicate and collaborate more than any other aspect that would determine how far they 'crossed the line'.