Ten Knowledge Areas Went Out to Dine…
One Got Ignored and Then There Were Nine

Change control. Project managers everywhere know the term. When a stakeholder requests a change to project work (scope), the impacts of that change need to be formally assessed. If the change will result in more time or money, the project manager needs to inform all stakeholders of the changes, and get their approval before the change can proceed. It’s the proper way to contain the project “iron triangle”.

Many project managers I know would rather commit seppuku before they’d allow a stakeholder to make a change without following proper change control procedures. But are there circumstances where rigidly adhering to process could hurt the project?

According to the PMBOK, these nine areas cover the gamut of knowledge required to manage a project.
(Image courtesy of Viva IT)

To many, project management process is immutable. The rules of PM are clear, and there are no exceptions. When I think back over my career, though, I can think of many times where breaking the process was the right thing to do. In almost all cases, I was making a concession for a stakeholder, and eating the cost. Surely the PMI must cover this–from my perspective, no process is immutable, and sometimes breaking the rules is completely appropriate.

After thinking about it, I decided to pull up the old “project management knowledge areas” to see where “stakeholder management” could be found. What I discovered was that stakeholder management has been lumped in under “communications management”, and in my opinion, it’s heavily glossed over.

The thing is, stakeholders are free-willed people. They will follow the PM’s processes only for as long as it serves their interests. If at any point, they decide the PM isn’t supporting them, they’ll start to marginalize the PM and do whatever they want. Any project manager who’s faced this knows there’s a lot more work greasing the stakeholders and keeping them happy than just providing them with status reports.

I looked again at the PM knowledge areas diagram above and decided I didn’t like it. Instead of making all the process groups parallel blocks, let’s organize them in a way that lets us see how they relate to one another. Click on any image for a larger view.

Knowledge Areas 1. Time Management, 2. Cost Management and 3. Scope Management
We’re all familiar with the triple-constraint “iron triangle” commonly associated with managing projects. Let’s draw it here, and instead of “time”, “cost” and “scope”, let’s put the corresponding project management knowledge areas.
Knowledge Area 4. Quality Management
Frequently the “iron triangle” is drawn with “Quality” at its heart. This shows that quality is affected by the triangle’s boundaries. We can include that process area here.
Knowledge Area 5. Risk Management
Project risk is essentially a potential derailing of the previous four knowledge areas. Let’s draw a circle around the triangle and label it with the corresponding knowledge area.
Groups of People Involved with a Project
Okay, so here’s where I start to knock things around. Projects are composed of three main groups of people. They are the stakeholders, the project team, and any vendor teams who provide goods or services to the project. I’m laying them out parallel to what we’ve drawn so far.
Knowledge Area 6. Communications Management
The next knowledge area focuses on communications. This area includes work such as developing a communications plan, setting up standard templates for routine communication, determining what needs to be communicated and how. According to the model at the top of this post, most interaction with the stakeholders occurs here. Any project manager will tell you this area is a beast.
Knowledge Area 7. Integration Management
This process group ties all of the knowledge areas together. It’s essentially the high-level structure of the project, and is where the charter is developed, where change policies are set, and where ground rules are established.
Knowledge Areas 8. Human Resources Management and 9. Procurement Management
So we’re left with the final two knowledge areas / process groups. Human Resources Management focuses on the “people” aspects of the project team. This includes things like team building and working with functional managers to develop staff, among other things. Procurement Management is associated with all things vendor. Managing the relationships, contracts and negotiations, etc.

So here’s my big issue. These knowledge areas provide specifically for human resources and procurement. Basically, the PMI acknowledges that keeping the project team and vendor teams aligned with the project are two discrete areas that require special knowledge. Managing stakeholders, on the other hand, is pretty sketch. You could argue it’s covered somewhere between the communications and integration management knowledge areas, but let’s face it, it’s pretty buried. Is everyone okay with this?

Let me ask the question a different way: is it okay to assume that effective communication and change control is sufficient to keep the stakeholders playing ball? Frankly, I don’t believe it is.

Here’s the thing. Keeping your stakeholders in line is a lot harder than just providing them with standard report templates containing earned value summaries. The project manager has to maintain stakeholder relationships. He or she has to understand how stakeholders fit within the context of the organization, and against one another. More than anything, the project manager needs to be able to negotiate, influence and use a whole array of soft skills to keep those stakeholders marching to the same beat as everyone else…usually without power or authority beyond that of his or her station. The PMBOK acknowledges all this, but (in my opinion) doesn’t really offer anything tangible that could prepare a new project manager for the realities of stakeholder management.

It’s not just the PMI. I find the area of stakeholder management to be specifically neglected by all the process bodies I’ve ever come across in my career.

I’d like to know what you think. Is stakeholder management a skill or art all its own that requires special knowledge? If a project manager is planning out the project, should he or she consider that knowledge requirement and take active steps to fill it? If so, how would that impact project execution?

Or do you think existing models are more than sufficient to cover stakeholder management, I’m clearly not looking deep enough, and perhaps I should just put a sock in it?

Put your ideas and thoughts in the comments section below!

Related articles by Zemanta

• Build a High-Performing Team in Just 61 Minutes! (edge.papercutpm.com)
• 40 Ways to Build Trust on Your Project Team (edge.papercutpm.com)
• How to Create an Effective Project Management Process (businesspundit.com)
• Mistakeholders (languagelog.ldc.upenn.edu)
• What Are the Steps of Implementing a Project? (business-project-management.suite101.com)
• Project Management – Beyond PMBOK ” ViVi’s Kaleidoscope (linusfernandes.com)
• Estimation is a life cycle and living process ” Adventures in Project Management (linusfernandes.com)

If you liked this article, and would like more leadership tips delivered straight to your mailbox as soon as they’re published, please subscribe to get free updates by e-mail or RSS.