Project Managers are Not Business Analysts

 

Kevin says in his comment:

Business analysis is how you figure out what done means. Project management is how you figure out how to get to done.

I disagree. Business analysis is the elicitation and definition of what everyone else wants to have in the product. Project management is understanding what’s driving the project, and leading the team to fit as many of those “what everyone wants in the project”, with the desired quality in the time frame. Business analysts don’t get to define “done.” They don’t have enough context. (Yes, there are some business analysts who can do this, especially if their PMs don’t. I bet Kevin is one of these multi-talented folks.) The PM and the project team define “done” and how they will get there, not the BAs.

Labels: project management

5 Replies to “Project Managers are Not Business Analysts”

  1. Heh. That’s not what it says in the PMBOK…the PMBOK disclaims responsibility for what is being done and says the PM is only responsible for how to get it built. Most books on project management don’t tell you how to figure out what needs doing, either. I haven’t had a chance to read yours yet and unfortunately there’s no table of contents on Amazon.
    I disagree that the BA lacks the context. I think most skilled BAs have a better grasp of the context than the average PM. The problem with assigning that responsibility to the PM is that most PMs are conditioned to get a project delivered and get out, and so they have no longer-term ownership of the solution. Their role pressures them to finish on time and on budget, and a cancelled or changed project is seen as a failure, even when that decision might be the best for the business.
    On the other hand, I can assure you that BAs are being taught to think of their role as owning the solution, rather than just collecting information from stakeholders. The BA role is becoming much more analogous to product management on the commercial product side. My day job is developing the body of knowledge that’s being used as the basis for BA certification, and a third of the content is devoted to figuring out if you’re building the right solution for the business, not just recording what stakeholders happen to want. We’ve run extensive surveys among the BA community to confirm that BAs really are doing this work…it’s what is actually happening, not just the way the IIBA wants the role to be.
    Now, I’ll agree that there are some PMs out there with really good BA skills who’ve learned how to apply those in the context of their project management. But where I think I disagree is that I don’t think the project team ultimately owns “done”. The customer and the stakeholders own “done”. The BA (or product manager) is just the project team member in the best position to articulate to the team what “done” is.
    Actually, I have the feeling that we’re disagreeing over terminology, so let me try to put it a different way. Project management assumes that the product to be built can be any arbitrary thing. It doesn’t really matter what you’re trying to do, what matters is how you figure out what work is involved in getting that product built. Business analysis is all about figuring out what the product is and what the end result you’re trying to achieve is, but doesn’t tell you how you can reach that end result. In the end you need to do both.

  2. We are talking about different meanings of “done”.
    The PM does not determine what needs done for the business, but he does determine what needs done for the project to reach its target. The project targets are derived from the business targets and the BA contributes to determining the business targets.
    For example, the PM may be assigned to organize a party. So he decides that what needs to be done: food, music, location, invitations, etc. But he does not decide why that there should be a party.
    The BA may decide that the company needs more exposure to the market, improve its reputation. A party may be one way, a TV commercial may be another way.
    The management team discusses the options and decides to spend resources on the party. The project is born.

  3. I believe that I agree with both Johanna and Kevin. I think there must be an agreement between the project team and the customer as to what constitutes “done.” I think it is primarily the responsibility of the project manager to secure this agreement. As a key member of the project team, the business analyst should be a contributor to defining the terms of the agreement, but not the only contributor. Neither can figure out what “done” means by themselves, and it doesn’t make any difference if the customer does not agree and refuses to take delivery of the end product.
    I agree with Kevin that most skilled BAs have a better grasp of the context than the average PM, and conversely, most skilled PMs have a better grasp than the average BA. That being said, its best for the project if both are skilled.
    I am developing a BA training class, so working in the same area as Kevin. I am teaching BAs not only to own the solution but own the process that defines the solution. This is still not sufficient to define “done” because the there are many elements to a project, such as testing, budget management, personnel development, lessons learned, etc., that impact project completion. These are responsibilities of the PM.

  4. As Dr. Cooper says, “There are two ways to win – Do projects right and Do the right projects.” I contend to win you must do both. The PM is usually charged with ensuring the project get done right. The BA (or product manager, etc) is typically charged (along with the strategy committee) with doing the right projects. The new trend I have been seeing is somewhat also what you have alluded to in this post. It is having PM’s and BA’s work togetehr more closely, or giving complimentary skills to the PM’s and BA’s. You can see this trend in the texts like “The Project Manager’s MBA,” etc. There is a recognized gap. We can no longer accept just doing projects right. The PM must know what it means to ensure the project is still the right one to do and how to interpret the information for a kill or go decision. The BA must know how to interpret if the project is getting done right for the same reasons.
    In my line of work we are going down this competency development maturity – not for all PM’s and BA’s – but select players. So we are moving from PM’s to BM’s (business managers). The role of the PM must extend beyond time, cost, and scope for crucial projects. If that means they must also be involved in success tracking, or when is done actually done, then we must do that. How else will they learn to call an early failure a success so we can move on to something more fruitful?
    The transition is not easy or quick.
    Your thoughts welcome.
    Tom

  5. The BA knows what *done* means for the *product*. But she doesn’t know how to build the product.
    Actually the PM also doesn’t know how to build the whole product. So, he builds it in steps called projects.
    So, he gets to decide what *done* means for a *project*, which is necessarily a subset of what the BA thinks as *done*.
    Out of the two, the BA is a dreamer. The PM is the realist. He *knows* it at his heart that the *done* state as meant by the BA will never be reached.
    But PMBOK puts the devine responsibility on his shoulder that what he means by *done* is actually done.
    Regards,
    aa

Leave a Reply