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?

Search This Blog