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

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?

Project Management Knowledge Areas

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. Standard Project Triple Constraint Triangle
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. Iron Triangle with Quality
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. Risk Management Overlaid on Triple Constraint
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. People Involved with a Project
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. Project Communications Management
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. Project Integration Management
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. Where is Stakeholder Management


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!

Reblog this post [with Zemanta]

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.

I’m a professor of project management at the college where I work. My students continually amaze me with their insights, passion and all-around awesomeness. I figure they deserve access to more answers than I can give them by myself. This site is for them.
  • Pingback: Tweets that mention Ten Knowledge Areas Went Out to Dine…One Got Ignored and Then There Were Nine » Papercut Edge -- Topsy.com()

  • Hey Geoff, love your diagrams.

    One or two issues with some of your assertions (which may or may not change the nature of your arguments).

    The diagram you provide is out of date.Changes made to the guide in the 4th edition of the PMBOK provide greater clarify around the place and importance of stakeholders management. The “Identify Stakeholders” (in the Initiation Process Group) and “Manage Stakeholder Expectations” (in the Executing Process Group) are a better representation of the needs associated with dealing and managing stakeholders. So, in summary, I'm not sure, based on the revised version, whether or not your concerns are still valid?

    What do you think?

  • Heya Shim! Thanks for commenting! Got a link to a more recent diagram than the one I used up top? From my perspective my main argument is that stakeholder management kind of gets buried underneath a bunch of other stuff, and isn't called out specifically as an area that requires specific knowledge. Personally I think it does.

    Identify Stakeholders and Managing Stakeholder Expectations are certainly important aspects of any project, but it seems kind of one-sided to me. There's no relationship management, and the importance of soft skills such as negotiating and influencing seem kind of whitewashed by saying “manage their expectations”.

    I guess my big beef is, the PMBOK sort of suggests “use your negotiating super powers” and leaves it up to the reader to figure out what the hell that means. It makes a big assumption that the reader actually has negotiating super powers. LOL

    Personally, I'd like to see “stakeholder management” called out as an area all its own, so it can be picked at and gone over to identify what skills and tools a novice project manager needs to be effective at it.

    That's my thoughts anyway. 😀

  • craigwbrown

    Hey Geoff

    I agree with everything you have said, but at the same time kind of don't.

    The issue is the definition of project management. Projects are defined by their boundaries. Projects are supposed to be delivering specific and unique things. But the same definition applies to programs.

    I think there may be another dimension to this problem; In the PMI world view programs deliver complex solutions to multiple stakeholders, and projects are the simple once product, one customer type scenarios.

    Given the complex world of corporate projects, maybe there is no such thing as a corporate project, and that they are all programs of one size or another.

    Given this premise project management is only a part of the knowledge required to deliver, and that stakeholder management should be the main focus of the delivery phase of program management (I haven't checked.)

    Beautiful graphic by the way 🙂

  • craigwbrown

    Shim, Geoff – I think Geoff is right. The new PMBOK takes a kind of sales approach to getting a project over the stakeholder line. What would be better is a marketing based approach where there is a mutual effort by both customer/stakeholder and provider to find and extract value.

  • Heya Craig! Thanks heaps for the comment! You raise a good point that a project is defined by its boundaries and by extension, multiple stakeholders shouldn't really be an issue at that level. The question is, when multiple stakeholders are involved, where in the P(3) hierarchy should we be looking?

    I think of relatively simple IT projects that get hacked to bits by corporate communications, legal or branding. Secondary stakeholders, but influential nonetheless. If there is no program or portfolio oversight to such a project (as is often the case), what's the PM to do?

    I really like what you say that “given the complex world of corporate projects, maybe there is no such thing”. Your comment changes the playing field a little, doesn't it? It makes me think that a pure project by definition could exist in a vacuum. But in a large organization, that can't be…there's all kinds of external influences on a project in a corporate environment.

    Thank you, Craig…that's some good food for thought!

  • See…that I totally dig! There's that two-way, mutually supportive back-and-forth I find the PMBOK leaves me high and dry on!

  • Anonymous

    Hey Geoff,You know I’m no expert here, so I can’t really e-speak on how to improve PMBOK, or even if it needs improvement. It appears though that no one questions the importance of stakeholder management, just where the line in the sand might be drawn as far as coverage by PMBOK.Changing the subject a bit, and bringing out my best spoon, perhaps what is needed is to throw away the triangle altogether, and move to a different visual aid. I suggest the snowflake, as indeed, every project is fragile and different, yet starts from a center core. I propose that core to be communication, and then have radiating arms representing Time, Scope, Cost and Quality, then each of those having radiating arms covering the subgroups of those. The better balanced all those areas are, the more “perfect” the snowflake in terms of symmetry. Stakeholder management is the underlying building block of the snowflake, water, as it can move through various stages depending on the temp (ice, liquid, gas…). Plus, this way, you can keep adding to the arms as needed, creatively, and without being constrained by inflexible shapes….. ;>)Hope I didn’t tangent too much!

  • Look mate, I'm not a real fan (or otherwise) of the PMBOK. At the end of the day it is only a guide and common sense still needs to apply. Having said that, and just in fairness to the guide it is important to note what the guide actually say about the management of stakeholders. So here it is: “Manage Stakeholder Expectations—The process of communicating and working with
    stakeholders to meet their needs and addressing issues as they occur.” Seems pretty straight forward and appropriate to me. How one execute the requirements at the heart of this section is a matter for individual style and finesse.

  • Stephan

    Hey Geoff
    Great article. I agree completely regarding the knowledge required for stakeholder management. However, it is not something specific for project management, hence the fact that only the bare essentials are covered in the PMBOK.

    Generally, PM's are assessed on three major areas
    * PM skills & knowledge, which is covered by the PMBOK
    * General management skills & knowledge
    * Business domain knowledge

    Good stakeholder management, influencing, negotiating, understanding organisations etc. is part of the broader general management domain. It is impossible to include all this into the PMBOK (cause then we should also include strategic management, general accounting principles, payroll, IT management, …).
    Althouogh you are dead right that stakeholder management is important, it is not fair to say it is lacking in the PMBOK. We should limit the PMBOK to the specifics of Project Management.

    Best Regards,


  • I'm right there with you, Shim. From my perspective the PMBOK doesn't do me a lot of good at this point in my career. Like any other seasoned PM, I do what I do, as the situation calls for it. However, for those starting out, the PMBOK is widely acknowledged as the place to start.

    What I'm pointing out is that I find stakeholder management to be buried, and not called out as its own knowledge area. If the PMBOK acknowledges that team members and vendors require specific skill sets to manage, why not stakeholders?

    It's true that “how one executes the requirements at the heart of the section is a matter for individual style”. But that statement also assumes that a PM knows how.

  • Heya, Stephan, thanks so much for your insight! 🙂

    I hear what you're saying. I'm approaching this from an apples to apples point of view, and I may just be completely out to lunch.

    If what you say is true, that stakeholder management should be exempt from the PMBOK because it's a higher level knowledge area, then why don't human resource management and procurement management fall outside as well?

    Insisting on knowledge areas within a project ensures a PM can either acquire for themselves or resource them. Flagging knowledge areas says to the reader “for you to be successful in your projects, you need to get these skills on the table”.

    I agree that “general accounting principles” or “payroll” are much broader than a project–you can take them or leave them and still get your project done. But project stakeholders are every bit as fundamental to a project as the project team and the vendors that support it. Without stakeholders, a project has no context. Doesn't that make this knowledge area specifically relevant to PM?

  • derekhuether

    Geoff, this post made me take pause and really think about page 43 of the PMBOK. If I understand what you're writing, you believe there should be a knowledge area dedicated to stakeholders, just as the project team is noted in the Human Resource Management knowledge area? If that is the case, the Communications Management knowledge area could easily be renamed to Project Stakeholder Management. Stakeholder management inputs, outputs, tools, and techniques are all contained there. But, let's be clear. Those are the basics! The PMBOK is kind of a one-size-fits-all guide. It is your style and leadership that will truly management those stakeholders effectively, not the guide.

    As for breaking the rule you wrote about in paragraph 3, I don't agree with that. Your decision tree should account for possible deviations of the original plan. If a change meets certain criteria, then you should give yourself the flexibility to deliver that value. You don't want to empower the squeaky wheel to drive your project, but at the same time, you want them happy. I understand it's hard to write this out in a short comment, when stakeholder expectations are subjective and not objective. But, I believe in high level processes that allow flexibility, while delivering value.

    What do you think?

  • Heya Derek! Thanks for the comment! Yes, you've hit it on the head. I believe there should be a knowledge area dedicated to stakeholder management specifically. Here's why.

    First off, let me put page 43 of the PMBOK out so we're talking about the same thing. (Yes I totally typed it out myself…*flex*)

    Here's what I don't like about it. That line, Communications Management, is very one-way. Everything about that line says “feed the stakeholder”. But we know that stakeholder management is a very dynamic back-and-forth of push / compromise / accept.

    As a knowledge area, I could take someone specifically trained in communications, put them in that role, and they'd do a great job communicating information and delivering messages. Which is perfect, because that's what the knowledge area is all about. But I wouldn't expect them to take my stakeholders for a beer and try to sway them to my way of thinking.

    I might, however, be able to take someone with say, oily sales skills, assign them to my stakeholders and have them manage the relationships (been there done that).

    You could totally argue that stakeholder management is covered under Integration Management. But like I said, it's pretty sketch.

    I guess I'm saying, I feel these are crucial areas of a project, and require specific know-how to be effective.

    Regarding my paragraph 3…a) OMG you're assuming I have a decision tree ROFL and b) I'm fully in support of completely breaking rules if it will meet an objective…as long as the consequences are fully understood.

    Whew that was a long answer! 🙂

  • Heya Bob thanks so much for joining the conversation! 🙂

    Expert or not I think you have a great visualization there. Projects are fragile and different, and I like the water metaphor. LOL It makes me think of making my nice, tidy little project framework out of popsicle sticks and setting it in front of the Hoover Dam. ROFL

    Seriously, I think those are great suggestions! 😀

  • I would say to most of the above comments about the PMBOK that we must remember that the PMBOK is only a guide and does not claim to be all encompassing. I see your point in the broader sense, but since the textbook definition of “stakeholder” includes the project team (Human Resources management) as well as vendors (Procurement Management), I would argue that the PMBOK 4th edition does an adequate job in this area.

  • Hey Christopher, thanks for commenting! 🙂

    I would disagree with you that “stakeholder” includes the project team and the vendors. In a project setting, the stakeholders are another body entirely whose needs are not at all addressed within the HR management and Procurement management knowledge areas. However, I'd grant that Integration and Communications management try to placate them.

    It's true that the PMBOK is a guide, and I don't expect it to cover every single possible concept…but I find stakeholder management to be particularly sketchy in a body of knowledge that's meant to promote project success. Project stakeholders have the power to completely knock a project off the rails should they choose to…in legitimate ways that vendors and the project team can't and don't.

    Those are my feelings anyway. 😀

  • Hi Geoff,
    Great post.
    I think there's a point worth mentioning here –
    The PMBoK Guide has a serious flaw in how it's laid out, and one that is serving to confuse a lot of PM's.
    The Processes and Process Groups are the important pieces and should be the focus, not the Knowledge Areas.
    First the processes were laid out by looking at how projects were managed and then dividing those processes into the different KA's. The original six were taken from how const cos had divided them and used them already. The following three were brought in after those three were agreed to. In fact, as I've been told, Integration Mgmt was created simply as a holding area for those Processes that didn't fit in existing KA's. So when you have something like Stakeholder Mgmt (btw – asapm and their NCB refer to it as Manage Stakeholder Relationships because you can't actually manage Stakeholders), because it cuts across so many areas it's impossible to contain it, which then leads to confusion.

  • Hey, Trevor, thanks for your input here today! 🙂

    I fully acknowledge that the process groups should be the focus. It's through the execution of those processes that a project gets delivered.

    However, the inclusion of knowledge areas says to me, “if you're going to get through these processes successfully, here are the core skills you need. You can do them yourself or delegate them, but they must be at the table.”

    By extension then, I should be able to assign someone who possesses skills in a particular knowledge area to the relevant KA tasks associated with that process group. Looking at the table from the PMBOK when I look at “Communications Management”, I could assign a communications person whose job it is to disseminate information and deliver messages. That's very unidirectional, but it's is fine, because that's what the KA calls for.

    That's not stakeholder relationship management (as you rightly call it) though. That requires another set of skills that I don't see in any of the KAs. Given the number of projects that run into problems as a direct result of poor stakeholder involvement, don't you think these skills deserve a second look? Someone else commented here that they feel this knowledge falls outside the scope of project management, but I would personally disagree.

    Cheers, Trevor! 😀

  • Geoff,
    I agree that these skills are missing, but I'm not sure I agree with your point about the KA's. I actually think this is 'why' they're missing. You pointed out that by including the KA's “here's the core skills you need.” I think that by including them they've actually limited the skills thought to be necessary – “here's what I need to know.” Couple that with the number of PM's that are being certified through boot camps and forced to focus on the KA's rather than practical application and you have a problem.

    Later you said I should be able to assign someone to a particular KA. Again, I think that's backwards (and the fault of the KA.) You should be able to assign someone to a Process. That's going to make sure they pay attention to all the interlocking factors. If I assign someone to “Identify Stakeholders” and “Collect Requirements” I think I'm going to get a lot better results than assigning them to Scope Mgmt or Comm Mgmt.

  • Hey, Trevor! Thanks again for commenting! 🙂

    Regarding your second point (I admit it was a run-on sentence), I said you should be able to assign someone “who possesses the skills in a particular KA” to a process group. By phrasing it that way, I was intending to show that the KA is discrete…if you take a person who's skilled in that KA, they should be able handle all tasks in each process that are relevant to that KA. If that made sense.

    I agree with you that the processes are the areas that need focus. But it's the PMs responsibility to make sure someone is at the table who possesses the skills associated with a KA to deliver those processes. In my interpretation (which could be out to lunch), the KAs in the PMBOK are essential to the project. You could trade up on business analysis, development skills and testing knowledge depending on what the project consists of, but the KAs are needed for all projects. If the KAs are satisfied, the processes can be satisfied.

    And I apologize if I'm rambling…it's late in the day and I've, er, had more than one drink tonight. LOL

  • galleman

    Geoff, et al.
    I've come to realize that many corporate projects and best run as “continuous maintenance” activities. I speak to a Carnegie Mellon class in the Masters Program with one of the technical leaders at PayPal. They've cracked to code for corporate projects using Scrum. The boundaries are the annual budget and the pipeline of requests for improvements in the PayPal business offerings.

    The idea that the PayPal system is a “Business System,” in the same way the FedEx system has trucks, planes, and IT – read “World on Time” – removes many of the restrictions of the definition of a project.

  • Hey, Glen! I really really like that analogy. It really stops us from looking at corporate projects as discrete entities, and gives them a broader context that I think is much needed.

    Thanks for that, Glen! 🙂

  • Stephan

    Geoff, sorry for my late reply. Apparently the e-mail notification doesn’t work.

    I see your point, and I agree on the relevancy of stakeholder management. I think the HR and Procurement management KA’s only cover what is relevant for PM out of those domains. Just like what is relevant for pm regarding “stakeholder” management is covered under the communications KA. We could change the “communications management” to “Stakeholder communication management “, but what does that brings us?

  • Hey, no worries…I’ll have to look into the e-mail notification and see why it’s not working.

    From my perspective I see communications management as too unidirectional to cover what I’m trying to speak to here. The communications KA is meant for straight reporting, but doesn’t address the relationship. We know that insufficient stakeholder involvement is cited as one of the top reasons for project failure. Involvement is a two-way street of push / negotiate / compromise. I think the communications KA is still necessary, but something else is needed to address relationships with the stakeholders. And I think it’s a skill that’s directly germane to PM success. IMHO. 😀

  • Stephan

    The fourth edition took on the “Manage stakeholder expectations” process to address the need you’re describing, so maybe in one or two editions we’ll get there 😉
    Nevertheless, I think these are the harder “soft skills” of project management, which on any account cannot be learned from a book. Personnally, I find it covers the subject enough, being a “Guide” and all. But that is my humble opinion :-).

    Looking forward to new posts!

  • Cheers my friend! 🙂 You finally got me to run out of steam. LOL
    Thanks for a great discussion!

  • Pingback: IT Project Value vs. Waste – Now in “Real Time”! «Papercut Edge()

  • Pingback: Change control is important? | Blah blah blah()

  • Pingback: Nine Destructive Project Manager Behaviours: Part 3 of 9 «Papercut Edge()

  • Pingback: Ten Knowledge Areas Went Out to Dine…One Got Ignored and Then There Were Nine «Papercut Edge « Rubber Tyres –> Smooth Rides()

  • Pingback: Is the PMP losing its value? «Papercut Edge()

  • This is a very neat take on the Knowledge Areas… Will definitely revisit this blog. Thanks.