15 June 2010

Scrum and the PMBOK

In the first installment of this discussion I mapped my perception of what scrum delivers against the PMBOK’s Integration Management knowledge area and appended a few simple observations. Today I want to discuss why I zeroed in on integration management as the first place to look. By doing this I want to try to set a context and address some constraints to this discussion.

I went to integration management because I think that Integration (with the capital I) is the main role of the project manager in the sort of projects I work on. My projects are usually larger ones ($5M+) and I work in large organizations that rely on formal systems and structures to keep order and balance competing internal priorities.  The technical challenges are solid, and so are the organisational change issues.

Usually these projects are paid for by a sponsor who is a senior manager within the organization, or the section of the organization that the project is operating in. But the decisions on scope are often made by the middle and frontline management stakeholders. Instantly in this situation you are faced with the challenge of the people who decide what goes into the solution aren’t the ones paying for it.

It takes a certain amount of organizational maturity to overcome this problem, and often scope control and stakeholder management is always difficult. There are quite specific techniques to deal with these challenges though, and they are not in my experience embedded into the typical project approach. Instead sponsors rely upon the talents of the people on the project team to coral or otherwise align the disparate wants and desires of the stakeholders.

That’s not to say that there are not specific systems and processes that can achieve balance. One example is provided by Glen when he starts us of with the balanced scorecard as the source of our project requirements. Another is Robin Goldsmith in a Modern Analyst article from last year called BAs will falter until they discover REAL business requirements.  This is all fundamental to running a business and so maybe we are doing the customer’s work for them if we step into this space?

I suspect that if all of us looked at the projects we are working on today the majority of us would say we are working the wrong project. And the reason for that is often that projects are started for the wrong reasons, even if they are started with the best intentions.

Projects are about delivery, not about choosing goals and choosing organizational strategies. The PMBOK for example dedicates 2½ pages out of 467 pages to project initiation, and about half that space is taken up by 3 diagrams. That’s about half a percent of the total knowledge in the BOK.

Let me summarize project initiation for you; justify your project with a business case or other tool, develop a charter so everyone knows the project goals and scope, and then identify who your stakeholders are. Identify any organizational issues that are going to trip you up and go for it.

Organizations have more complete processes than this, but they are beyond the scope of the PMBOK. You may find these processes in Portfolio Management manual, product development methods and strategic planning processes. But fundamentally project selection is not the project manager’s job.

Some organizations require a 3-6 month period of maturing the thinking about a project before it really kicks off. Other places will kick a project off after a boozy lunch and a good idea.

The truth is that neither method is better than the other to any great degree, as long as you follow up the initiation process with good sense. And however it’s done; it’s usually done by someone different to the person who has to deliver the project.

When I compare scrum to PMBOK I am comparing tools that help manage the delivery of projects, not the selection of projects or setting of project goals.

Integration management includes the processes that report on progress and manage the balancing act between cost, scope (which for me implicitly includes quality) and schedule. And given that the project is defined when you turn up the unique competency the project manager brings is the ability to deliver these two things in a way that helps the project close out successfully. The other knowledge areas are useful, but not *core* to the job and not particularly Project Management specialist knowledge.

Coming up:

  • Why a Product Backlog is like a WBS which is like a PBS
  • Why procurement management and human resource management knowledge areas are not core to this discussion
  • How Scrum needs to be augmented to address Quality Management
  • And Sundry other discussions about PMBOK and Scrum.

What do you think? What do you want to hear discussed next?


  1. "Other places will kick a project off after a boozy lunch and a good idea. " First off, I can't remember any PM/IT blog post that made me laugh...

    But seriously folks, I think what this is about is Governance, the means of selecting which projects to initiate. I remember sitting in a big meeting years ago where an IT Manager presented a description of their big project and its progress to Senior Management. The CEO listened attentively, complemented the presenter when they finished, and said "If this project is so big and important to this company, why have I not heard of it before today?" The very next day, the CIO called me in (I was a methodology guy) and told me to come up with a process to evaluate and approve/reject proposed projects...and I did, using a gating approach where proposals for large projects had to be documented and submitted to a Governance body for review; and it just wasn't by each project, there would be many proposals evaluated at the same time, compared to each other, and only a few would get the go-ahead to use the limited resources available for projects.

    So, it is a good thing to do, the merits of a boozy lunch aside. If the PMBoK doesn't address this, some other body should, and a web search would probably find some candidates.

  2. I can't wait to see how a semi-random list of needed created by users is going to look like a MIL-STD-881A Work Breakdown Structure. This is going to be fun.

  3. Craig,

    Why would the PM's roles be different in the Integration phase than in other phases?

  4. Personally I don't think every project requires a MIL-STD-881A WBS to be effective.

    "Often projects are started for the wrong reason, even if they are started with the best intentions"....wow, Craig I don't think anyone could have phrased it better. That is the TRUTH

  5. Hi there, awesome site. I thought the topics you posted on were very interesting. I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.

    Scrum Challenges