15 June 2009

Business Analysts and Project Managers: chalk and cheese?

See Elizabeth Harrin, author of A Girl’s Guide to Project Management and is the author of Project Management in the Real World at the IRM UK Business Analysis conference in London on 29 September.

Business Analysts and Project Managers: chalk and cheese?

Business analysts and project managers often find themselves working together on projects, and not always with great results. Project managers and business analysts don’t always see eye to eye, and this leads to conflicts on the project team. It’s not always about a clash of personalities; it’s more often just different approaches to working, different goals and different methodologies.

Elizabeth Harrin will be tackling these differences in a presentation at the IRM UK Business Analysis conference in London on 29 September. “I'll be talking about how project managers and business analysts attack the same topic from different angles and addressing how to work effectively together,” she says. Drawing on her own experience as a project and programme manager – and from a brief spell working as a business change analyst herself – she’ll discuss why project managers don’t intrinsically value business analysis and to avoid a “them and us” attitude.

This presentation will provide a real insight into what project managers think about business analysts and how BAs can use this to their advantage to drive home successful solutions.

“I think there’s a long history of tension between the BA and PM communities,” Elizabeth says. “It’s because both sides bring something different to the table and don’t understand the value of what the other party brings. I don’t think we talk about it enough, so I’m looking forward to opening up the debate.”

The conference runs from 28-30 September 2009. Full details and the programme are available online. IIBA and BCS members are entitled to discount on the conference fees.


  1. Anonymous3:13 am

    When this situation appears, I'd suggest that the clear and concise definition of "roles and responsibilities" is missing.

    This is a crital core procecss defined in PMBOK and all other project management process description.

    Without the RAM (Responsibility Assignment Matrix) participants have overlapping responsibilities, missin responsibilities and this lays the ground work for what is described here.

    Get RAM, put names in the boxes, hold people accountable, get back to work.

  2. ERlizabeth's talk promises to open up a good discussion.

    At one level Glen's advice is good and solid. However in many organisations influences outside the project team cause conflict - job and role descriptions, process compliance and qulity objecti8ves, expectations from external stakehodlers about who is doing what, etc.,

    Life should be easy, but it often isn't.

    Those of us who work in projects all the time understand each other and (usually) how to work together. When we are working with 'regular folk' things get trickier.

    Same goes for organsiations who are in the procss or learning about projects.

    As a PM a RAM is a great tool. As a team member dealing with the outside the situation is more fuzzy.

    Which leads me to the rhetorical question; Do you give your stakehodlers tough love or do you risk over servicing them?

    One path leads to dissatisfied stakehodlers and potentially damages your personal reputation, while the other has a pretty high risk of cost and schedule over-runs.

  3. Craig,
    You don't have a RAM if you don't have EVERYONE identified. The RAM is not static in the sense of building it during the chartering session.

    It is updated every time some comes or goes.

    The role of the PM is to "manage" the stakeholders. In defense it's called "kepping the program sold."

    The RAM is not for the PM it's for the Project.

  4. Gln,

    I agree with that, but with the caveat that often people don't play by the rules you agree to at the beginning.

    That's where you need to step in and deal with things.

    Maybe drawing their attention to the RAM is one solution option. Maybe others are needed.

    I wonder what Elizabeth will say at her talk?

  5. Knowing what the roles and responsibilities are doesn't mean that people actually abide by them or respect other people's contributions. BAs and PMs are often 'on the same team'. In my experience PMs know what they have to do and what BAs have to do - it doesn't make them like it any better.

    The challenge for the PM is keeping the team together when the role someone plays is not considered important to other people on the RAM. I'm rambling a bit but my point is that writing it down doesn't make a person's contribution valued: we need better relationship management to handle that.

  6. Anonymous9:31 am

    I work as a consultant and have taken on roles from pure Business Analysis, Tech PM and in some cases both at the same time, which is a lot harder. Sure I have had to twist may head around in some instances being creative and in others being deadline focused. I have had the fortunate experience from seeing it from both sides. As a consultant one often has to get into the details but not loose site of big picture. Ultimately it comes down to the entire team being valued and understanding their contribution and responsibilities on the project. Remember people are involved in making projects happen, leaders in the team must make the effort to understand each other and build trust.