Please find below a transcription of the audio portion of Jeff Bongiovani’s webinar, Overview of the PMBOK® Guide Seventh Edition – Lesson 2, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience.

Melaine: Hello, welcome. Melanie here with team MPUG. Welcome to overview of the PMBOK Guide, seventh edition lesson two. We invite you to join in today with questions, comments by using the chat feature in the GoToWebinar control panel. You can see that up on the screen. You’re welcome to grab that out of the control panel and expand it out so it’s easier to type in there, especially if you’re my age. Today’s PMI activity code is on the screen. For those of you attending live today, we will add this session to your MPUG transcript automatically. That usually takes a couple days. For those watching on demand, please remember to hit the submit button following the session. That’s just for our folks on demand, and that will add it to your transcript.

Melaine: Now I’d like to introduce, or welcome back, our expert, Jeff Bongiovani. Jeff is currently the training and development manager for Edwards Performance Solutions. As such, he oversees the production and maintenance of courses on project management, systems engineering, software development, business process improvement, and cyber security. Jeff is also a trainer with over 20,000 hours of classroom experience spanning 17 years. We’re privileged to have him here with us today. Jeff, a very big welcome back, and I will make you the presenter. Thank you.

Jeff: Okay, thank you. Let me get my slides up and going. Hopefully everybody can see. Well, welcome back and welcome aboard, if you were not in the first session. But nonetheless, just to say all of the content here today in this, as well as in the previous and upcoming session, that’s all taken from the PMBOK Guide seventh edition, meaning mostly the standard as well as the guide to the project management body of knowledge.

Jeff: Last time, that is through session one, one of the main or primary things that we had focused on was the message across the entire guide as being a system for value delivery. That is within the standard project management, there are five primary contextual concept for defining a system of value delivery. And what was anticipated was through the pages, as we look into the 12 various principles, as well as the eight performance domains, that we would be answering these questions.

Jeff: The conceptual concepts like creating values, like how do projects operate within a system to produce value for organizations and their stakeholders? How does governance support a system for value delivery? What are the functions that support projects? What are the internal and external factors that influence projects and the delivery of value? And how do portfolios programs, projects, and products relate? And last time, what we had really done was we began with really a comparison between the seventh edition and the sixth. That is the previous version of it.

Jeff: And one of the things that was introduced at the beginning of the guide was the fact that the sixth, more or less, is inclusive within the seventh edition. That they wanted to think broader, a larger perspective. In which case the idea was that PMI wanted to move from being a process prescriptive that is guide to be more of a principle driven guide. And ultimately that you could view the sixth edition as one way to “solve” specific games. That is that project management isn’t necessarily, it really isn’t a solvable game. But for the most part, understanding the different factors and facets that play into completing the work and building value within the organization are going to vary, and vary widely.

Jeff: So the central focus and theme being that a system for value delivery was really just asking the right questions and considering the right aspects, optimizing value delivery components and information flow through understanding and conducting the following governance core functions associated with projects, internal, external considerations, product service management considerations. Now they do a quick synopsis and a concepting of each one of those different factors that I showed you on the previous slide. But nonetheless, that the greater part of the guide between the 12 principles and the eight performance domains that we were going to explore in depth the variations of solutions.

Jeff: So that brings us to our session two, the project management principles. Now to provide a little bit more context, and I had spoken about this before, that those of you who may have had the experience of working within the context of PMI’s first, second, third, fourth, fifth, sixth additions that you got this sense that, okay, so we have our knowledge areas, we have our various domains. And ultimately we get into kind of a standard that would focus on the various process groups, where we would practice each one of those different knowledge areas.

Jeff: And so as this has switched, what I wanted to do was provide a forum here, a presentation that addressed the previous becoming now the present and making sense of that. But also to provide this as a lesson. It’s not that we’re unlearning what we already know, but rather channeling and focusing on certain facets or qualities of what we’ve learned from our past successes and mistakes, and how that plays out in this seventh edition.

Jeff: Having said that what I wanted to do is bring back the breakdown or the outline that PMI provides within the seventh edition. So they lined it up. They said, “Here’s the sixth edition. This is how we organized it.” And if you squint or just move closely to the monitor, you could see there are your 10 knowledge areas of integration, scope, schedule, costs, quality, resources, communication, risk, procurement, and stakeholders. Not necessarily in that order. Because what would happen was, in the standard for project management, it would take and provide the 49 different practices within these five different process groups.

Jeff: So how to practice the knowledge areas within each process group. That was really what the standard for project management was. We got the guide, which was the knowledge areas. And of course, a little bit about, hey, you want to consider this, you want to that. But it ultimately was, here’s a process you can follow to practice those knowledge areas from beginning to end of your project.

Jeff: Look what happened here. In the seventh edition, what did they do? They moved that to the forefront. And instead of having it be more about the process, or more out the practices, it’s now what principles are at the core of a system for value delivery? So we’re going from practices to principles. It doesn’t tell me what to do. But it does tell me how I should be, and how I should think, and what I should prioritize. Which it’s kind of a fascinating thing. I don’t think it’s wagon and horse. I think it’s rather a matter of rear wheel drive versus front wheel drive. They’ve just moved how this system is moving forward to the very beginning. It also creates more of a top down approach because as you see within the progress here, and I think what they’re getting at is more or less this concept here.

Jeff: You have the PMBOK Guide seventh edition starting out with an introduction, a conceptualization of here’s the focus value delivery, right? System for value delivery. Here are the principles. Here’s what you are to prioritize. Here’s what you fashion your overall purpose and objectives and goals for the project management system you’re creating. And then ultimately then, bam, here’s how we test whether or not we’re doing well with the project performance domains.

Jeff: And in which, and we’ll see this in the final and third session, they break those down into eight performance domains ranging from, of course, the stakeholders, team, development approach, and life cycle tailoring… Sorry. That’s not it. Planning project work, delivering measurement, and uncertainty. And when we talk about tailoring models, methods, and artifacts, that’s when they get into all of the things concerning here’s your risk register. Here’s how you create a requirements traceability matrix. Here’s what you could consider when you’re doing your project work. Here’s how you set up a work breakdown structure. That sort of concept.

Jeff: So what I did here was, I guess hopefully you appreciate I did the little color boxing, but to reiterate this idea that the sixth edition is not something that PMI is abandoning, but rather is building a larger spectrum around of conceptualization. So down across the bottom, you can imagine, well, here’s the PMBOK Guide, sixth edition. That’s one way to do it. And the way to do it fulfills and is hitting all those performance domains with A pluses, then by all means practice that. And then you’ve got unknown theory two and unknown theory three. And it says, ultimately, if you come up with your own tailored type of process, and you’re hitting an A plus on all of those domains, you’re practicing all those principles, yay. You’re doing the right thing.

Jeff: And I could say the sentiment that it was, most of my coworkers, as well as other colleagues around the biz, if you will, was that it’s kind of like, “Well, okay, they’re no longer telling me what to do.” That sort of thing. They had a good thing going, and they’ve kind of lost it. But I don’t think 100% that they’ve lost it. And we addressed that in the first session that very much the practices and standards, all of those are kept alive. And that you have this brand new PMI standards plus where they publish articles and other on the fly guides, if you will.

Jeff: So moving into what PMI considers the project management principles, as we break them down, moving forward as all 12, these are principles for professionals, and served as a foundational guideline for strategy, decision making, and problem solving. And if you could see over on the right hand side, really there’s this Venn diagram that says, okay, there are things that are specific to projects, and there are things about general management principles, but ultimately there’s an overlap. And we have to integrate more of what we can find on the functional end of an organization within the project end of things. And I always think, oh, wow, here we go. It’s like who’s going to win, right?

Jeff: But for the most part, depending on the style of organization, the structure of how you put together your organization, or work within from it could be anywhere from truly siloed, functional base work with sporadic projects led by each functional manager to a matrix organization where it is that you have an assigned PM who gathers up people from their normal functions or teams ready to go, or 1099s, a bunch of subcontractors. But ultimately they may overlap a little bit more depending on where we are.

Jeff: So these principles, they’re broadly based, right? So the idea is that there’s an umbrella and it can be interpret it in a number of different ways, but as long as you align with the essence of what they are, you’re getting it right. They’re aligned with the PM code of ethics, right? The project management code of ethics that PMI publishes in professional conduct, responsibility, respect, fairness, and honesty. They were identified. And once again, I shared with you in the first session this, and once again, PMI wanted to justify and wants to justify the fact that, yeah, okay, so we polled a lot of people from around the world, project practitioners, wide variety of industries, cultural backgrounds, organizations, and different roles, experience. We wanted to make sure that these principles kind of were something of a common thread between all of that.

Jeff: So here they are. It’s 12. And to be perfectly honest, there are a lot of lists. There are a lot of definitions. You can’t go far in any one of these theoretical courses with it. Here are the top five. Here are the top seven. Here are the the 23 considerations. Well, here’s the idea of 12, right? And you might think why 12? My goodness, there’s so many. But you think about the different dimensions that you have to cover. And just looking over these various names. And as we move forward with today’s session, I’m going to break down each one of these and really illuminate what PMI is trying to get out of each one of these principles, and why each one is necessary as a separate item.

Jeff: But from the variation of what we probably already expected, like number six here, demonstrate straight leadership behaviors, right? That’s one. But what is this? Be a diligent, respectful, caring steward. What? What is that, right? Never saw that before. Or okay, so create a collaborative team environment. We expected that. But build quality into processes, deliverables. Tailor based on context. There are some things in here that maybe have been touched on in previous additions of the PMBOK Guide, but never were really drawn out, highlighted, underlined, and put at the forefront to really drive what would come next, and a theory of how to conduct one’s self.

Jeff: But nonetheless, what you get out of this is that no one organization or individual can necessarily do all of these things perfectly. That’s something that we have to face, that we take it with a grain of certain humility. But nevertheless, that as we look into this, that enabling change to achieve in vision future state, that number 12, adding as an anchor, is something that definitely we keep our eye on the overall mission, which is organizational success and personal contribution, ultimately arising to individual success within the organization.

Jeff: So let’s kick things off with number one. You’ll notice I’ve number coded each one of the principles in the top right hand corner. Because you figure if we just had four to go through, it’d be fairly obvious. But 12, wow. Just want to make sure that I’m illuminating the fact that we’re going through all of them. So when we say stewardship, right? Be a diligent, respectful, and caring steward. Now I got to pause. Because then you say, “Well, Jeff, hold on. Does this mean project managers should be this way? Should project team members, team leader? Who are we talking about here?”

Jeff: To be honest, it applies to everyone from the top of the organization down to the very bottom. To the dude that’s sweeping the floors to the guy that’s cutting the paychecks. This is everyone. We’re all a team within one [inaudible 00:16:57] organization. And hold on, just wait. When we talk about organization, we said that in the first session, it means anything. Even just contracts drawn on the back of a napkin. But the ideas here, it has different meetings, right? Stewardship, different meanings, applications, depending on the context. It involves being entrusted with the care of something. Focuses on the responsible planning use management of resources and upholding values and ethics.

Jeff: This is somebody, when we use the term stewardship, it’s somebody who’s caring, who’s looking over this, who’s entrusted with the care of something. This isn’t just, oh, do your best. Getting the best return on investment. No, this is making sure that this is has the end result that’s going to make everybody happy, right? That will make it through the other day and be shining and happy. But stewardship encompasses responsibilities both within and external to the organization.

Jeff: So for the most part, things as you can see here, operating in alignment. Follow the rules, right? And understanding because this denotes that we understand the organizational objectives, strategy, mission, and sustainment of its long term value. For those of you who are practicing the stewardship and are at the top, you’re in the C-suite. You are maybe the CEO, or whoever’s responsible for deriving the overall strategy, vision, mission for the organization. Maybe the consideration here is how do we bring out the stewardship in people? How do we offer the objectives and the strategy and the vision? How do we make everybody a part of that?

Jeff: The commitment to and respectful engagement of project team members, including their compensation, access to opportunity, and fair treatment. Everyone has that access to opportunity and fair treatment. Understandingly that there are some who seek to have more opportunities than others, and put their foot forward more than others to enthusiastically engage work. But when it comes to the other concepts for the stewardship, the diligent oversight, organization, finances, materials, and other resources used within a project, the idea here is in just citing an example, not with Edwards where I am now, but in previous encounters, understanding what a worthwhile prioritization of hours is.

Jeff: For example, back when I was teaching for a certain training company for a number of years, one of the things that we had were prep days, right? We had certain prep days where we were granted a certain amount of hours to ensure that when we were going to deliver our next course, that we do a fantastic job. Now, there were some who took their prep days and they would sit and watch YouTube videos all day. They’d be like, whatever, that sort of thing. And then we had other folks who would use their entire day with their prep day to study the next upcoming course.

Jeff: And then there were other people who not only studied the course that they were working on for the next day, but became better at studying, knew exactly what to look for, and how to set up for the next class. And not only that, but studied something that they weren’t yet teaching. No, it was the last person there that made the most of those hours. But choosing between to spend your hours with this or that, that’s part of that diligent oversight. That’s the team member contributing the best they can because they understood the value of their hours that they were being compensated for their time and energy.

Jeff: Now, are we asking too much? Maybe. But for the most part, maybe that’s all in the hiring process. Maybe that’s all in peer pressure. I don’t know. But the ultimate thing is those terms of integrity, care, trustworthy, and compliance. That’s the idea. We’ve set up the rules, we’ve set up guidance. But also, there’s a little bit more than just the meeting the parameters of the job. There’s a little bit more than just what you’re accomplishing within the 40 hours and charging to a time code. There’s something more to it. There’s spirit behind the letter of that law. So in which case, stewardship reflects understanding and accepting of trust, as well as actions and decisions that engender and sustain that trust.

Jeff: So it’s fascinating out of these principles, the number one thing. I hope that it was a deliberate choice. But PMI definitely put this first because who cares about the rest of the principles, who cares about any collaboration, who cares about tailoring if you’re not in the mindset that the organization’s needs and the individual needs and the people around you are important? See, you can’t really do any of the rest of this stuff. You really can’t. And really it is, it’s a learning factor. It’s something that you experience. But it’s something that the organization, if you really think about it, it’s the organization’s giving back to the individual. That’s why, let me back up for a second, commitment to respectful engagement of project team members, including their compensation, access to opportunity, and fair treatment. It’s not just what the organization is asking of the individual to contribute, but what they can contribute to make this whole thing go much smoother.

Jeff: So then we look at principle number two, the creating a collaborative project environment. So we understand there’s the authority, the accountability, the responsibility aspect of things. And as you’re drawing up lines within that racy matrix, that we understand that within those, the authority, the accountability, responsibility, that’s much more than that. That what we’re trying to do is ensure that communication is going smoothly. That there is the diversity of skills, knowledge, and experience that we’re tapping into. But we’re also taking note of there’s a lot of knowledge transfer that goes from one project to the next project.

Jeff: In fact, I was explaining the other day that, being a trainer, you can train somebody to use software. That’s what I was used to. Hey, click that button, get this response. Then there’s the broader or spectrum of things saying, hey, if you’re trying to establish a number of different templates for your team to use, here’s the process that we use. Now, let me show you how to use the tool to set that up and how to train the team, how to use those templates.

Jeff: But then there’s ultimately the training that is very difficult to give. That is, behind the scenes, how did Jeff come up with that process? Why did he tell me that this was the best process to get? Well, you had to be in the trenches there when that one template blew up, or the other employee couldn’t find where that template was on their darn drive. Then they went to the shared drive and all of that. And all those things being considered. That’s the knowledge transfer as well.

Jeff: The collaborative project environment is one where we share those experiences. Where we can have kind of the open dialogue and the transparency. Where we understand, no, I’m not going to understand where to go. That I have to understand how to communicate with a certain level of clarity. So the free exchange of information and individual knowledge is extremely important. In fact, that was in the sixth edition as well. And I just remembered that there’s that knowledge when you’re looking at the lessons learned log, or the risk register, where there was a little bit of pain and suffering that went behind that lesson learned. I mean, unless you’re going to write kind of like a novel or something where it’s like, the day was dark. It was stormy outside. Everyone was crying in their cubicles. You’re not really going to write that. You just write the lessons learned.

Jeff: But the idea is that you need to pass along that knowledge, that information. And we have to take it seriously. The guy in the corner, that’s saying, “I wouldn’t do that,” you got to kind of… Well, unless they’re stakeholder management. They usually say crazy things. But the idea is that you have to make sure that everybody’s voice, if they’re especially an expert in that particular area. It might be easy now, but it’s going to be difficult doing all the makeup work. Oh, we should have listened to so and so. That’s the idea. Collaborative project team environment. Everyone’s a stakeholder, everybody’s involved in that team. Everybody has a fair shot at voicing their ideas.

Jeff: Oh, did I miss one? Oh, there it is. So the other here, and you figure, wait a second, we just talked about that. But it kind of leads into, well, okay, effectively engage with stakeholders. We know the definition of stakeholders, or if we don’t, stakeholders can be individuals, groups, organizations that may affect or be affected by, or perceive themselves to be affected by its decision, activity, or outcome of a portfolio program or project. The idea here was that they wanted to spotlight, the fact that stakeholders come and go.

Jeff: Stakeholders are human. They change their minds. What they prioritized at the very beginning of the project, they have these aspirations. The sponsor is like, “Man, this product’s going to make us so much money. I can’t wait to get started.” And then as we get halfway through the project, and then they release the product. And then they start to realize, wow, it’s not making as much money as it used to. Now they’re looking at slashing the budget and crunching the project schedule, and saying, “Can we get this out?” They’re removing people. Too much money that we’re spending on this. So things change over time.

Jeff: But the idea is that we have to still maintain that proximity. We have to know the heartbeat of that stakeholder, and all the people within that project trying to get something out. Now I eliminated, or shed light on the stakeholder that is the customer. But we also have to consider the people on the team. They’re considered in that stakeholder group, the PMs. Even people who are tangentially impacted by this, the functional managers from whom you’re stealing those vital project resources. Everyone’s got a stake in this. So when movements are made and changes are put forth, or schedules are created, that we have to understand the ripples in that pond outward.

Jeff: In which, and I’ll save you the suffering of reading through this entire table, but nonetheless stakeholders can affect the many aspects of a project. So it’s worth calling out from the schedule, the cost, the project team, the plans, the risk, the quality, and the ultimate success, that stakeholders are any people who have that aspect of influence. Where they’ll light you… Okay. three, two, one. Okay. Moving on.

Jeff: So we’re stewards. We’re creating a collaborative environment. We’re engaging the stakeholders. And then it comes back to that theme of value. All right. Well, if we are the stewards, and we are creating the team, and we’re bringing the stakeholders in and understanding the needs of everything, the right needs to have is the focus on the value. So PMI does define value. Now this is where it first appears, right? We’re defining value. So they want a system of value, right? The system of value creation for the entire organization. The worth, importance, and usefulness of something. Now value is perceived different ways by different stakeholders. Customers define value in the ability to use specific features or functions of a product. And organizations can focus on business values to determine financial metrics, such as benefits less the cost of achieving those benefits. Or in other words, what sort of returns are we going to get from it, or profit? I like how they worded that, right?

Jeff: The idea of though, the worth, importance, usefulness of something being that central to value. But the different perceptions of value could range from financial value. It could range to functional value. When we’re talking about the output, when we’re talking about the method by achieving the output. This is where we’re generating that value.

Jeff: Now, the other aspect of this continually evaluating adjusting project alignment to business objectives and intended benefits and value. That value is the ultimate indicator of project success. That value can be realized throughout, at the end or after the project. The value in the benefits that contribute to value can be defined either qualitatively or quantitatively, and hence in the case of financial versus functional. A focus on outcomes allows project team to support the intended benefits that lead to value creation and project teams evaluate progress, and adapt to maximize the expected value.

Jeff: Now this nebulous general definition of value, right? But if it gets right down to it, what are we doing but testing? Ultimately when I does sign a training course, and we deliver this, not only do I help and assist, in some cases, design entire courses for external customers, but we also do so for our own organization. And part of that is, when people walk away from that training three months later, have we seen job performance increase? Have we fostered a training program that wants people to come back? They look forward, “Oh, there’s a brand new training available. Wow. I can’t wait.” Or is it one of the, “Oh, I got to do that manual training again.” And so when we talk about the value, if all things considered, if they’re coming back for more classes, or at least if they’re hitting their goals of taking the class, that’s one part of it, but it’s not all of the perceived values.

Jeff: So when we go back to, okay, we got to engage stakeholders, moving onto the fourth principle, what are we doing? We’re focusing on the value, right? So each stakeholder has their definition of what they value and what is valuable, useful. So between the business need, project justification, business strategy, these all reflect the concept of an exhibit of value, or centered around value. All right, I’m sure you’re of me saying the word value, but nevertheless. Together, the business need, project justification. In addition to benefits, possible agreements to provide the project team with enough information that allows them to make informed decisions to meet or exceed intended business value.

Jeff: So one more with this, because it is such essential theme and a concept. And you’re looking at the time. Wait, we’re at four? Earned value says that we’re not going to get to the very end. We are. But within the context of some projects, there may be different forms of values. Engineers, customers, having said it before. But what we’re doing is deliver on the vision or purpose of the project rather than simply creating a specific deliverable. And that’s the idea, that we’re looking at the project as conducted as a whole, and within the organization, the context of the organization as well.

Jeff: So what’s fascinating then is that these principles do take a little bit of a turn. Recognizing and evaluate and responding to dynamic circumstances within the surrounding project in a holistic way to positively affect project performance. Now, I didn’t write that myself, that is straight out of the pages of the PMBOK Guide seventh edition. What are we doing here? What is this all about? But you got to figure your impact to the greater whole of the organization within the operating of that project is absolutely essential. So the project is a system of interdependent and interacting domains of activity. So it’s not just impacting the outside, but it’s impacting everything, has something to do with one another.

Jeff: To that end, this is why one of the things that when we say the system is a set of interacting independent components that function as a unified whole, and taking a holistic approach, a project is a multifaceted entity that exists in dynamic circumstances, exhibiting the characteristics of a system. That’s why I wanted this graphic. I wanted to be able to say, okay, well look. We’re playing chess. All the pieces on the board have a factor of whether or not we can move one way or another.

Jeff: But here’s the idea. And I think this is what I got out of it. I like to read a lot of stuff. Last time, I delighted you with the hint towards the AI development machine learning, looking at that. Now, just to give you a little bit of chess theory. God, what a nerd, right? But in chess theory, the concept and the overall principles, besides have a strong opening and a closing and everything in the middle, just make good choices. The point of the matter is is that the making good voices in chess all centers around mobility. The more capable you are of moving in the board, and the less capable your opponent is moving, chances are you’re winning. But mobility is the concept. The ability to move and make strategic movements.

Jeff: And I always thought that was the better way to go. As long as we’re thinking in terms of how do I make informed and proper choices? Well, some of that means examining and understanding how all the things within that project, within the scope of influence, influence one another. What are the pieces on that board that influence the overall outcome? It also illuminates, once again, the fact that PMI’s moving more so towards a systems way of thinking. They even say, once again, systems thinking considers the timing elements of systems, and what the project delivers and enables over time. So it’s not just one static thing that we’re carrying out a plan. That it’s fluid, that things evolve and change.

Jeff: Now the one that’s most obvious, the demonstrating leadership behaviors, right? And because at the core of it, we’ve almost gotten halfway through the list, but the demonstration of leadership behavior is something where in the PMI talent triangle and in the previous version, where what does it take to be a leader and all of those, we haven’t lost it, right? We haven’t lost all of those concepts or principles. You can go to any leadership course, and they spell it out. And they’re like, “Well, a good leader does XYZ. A good leader is always lifting people up and not pushing them down.” And in which case there’s been a lot of, I guess it’s come into my sphere of awareness, but there’s a lot of difference between management and leadership in the sense that management is the technical of the job, but leadership is more of the framework and the environment which you provide and your team thrives.

Jeff: And so the project environment that prioritizes vision, creativity, motivation, enthusiasm, encouragement, and empathy can support better outcomes. So man, you’re taking a read through the guide. You’ll come across that list of all of these combinations of various skills, techniques, role modeling, desired behaviors, overcoming obstacles to project progress, facilitating collaborative decision making. What I wanted to add to this, and I don’t feel as if it’s missing, I just wanted to make sure that it was added to this, is that we had only delivered internally, but we wanted to make sure that we were focusing on emotional intelligence as something for our PMs, program managers, directors, and folks just generally around the organization to investigate and invest in.

Jeff: But when we talk about emotional intelligence that, oh man, I need a citation, don’t I? But when we’re talking about generally emotional intelligence, we’re talking about self-awareness and the awareness of others, and being able to basically essentially control one’s own triggers in order to navigate the best outcome for any possible situation. One aspect of the emotional intelligence library is studying the concept of different leadership styles. And you see that nice little wheel over on the right hand side. Which I always emphasize when we’re teaching this class, I said, it’s more like… Oh, I’m sorry, dated reference. But it’s more like Trivial Pursuit. You remember that? Trivial Pursuit. Yes, I’m that old. You’re moving across the board. You’re trying to get the little wedges and fill up the wheel.

Jeff: You guys, let me explain. Democratic leadership, affiliative leadership, coaching leadership, that right hand side of the wheel, if you will, is very human centered. As you get closer to the affiliative, right? Meaning to say democratic means everybody’s got an equal voice. Let’s hear what you have to say. That type of leader is putting all the pieces of the puzzle together to work in unison for the vision, right? They’re trying to get the best out of each team member to hear what each person who’s an expert has to say.

Jeff: The affiliative is really all about building the relationships between people. How do people on the team connect? You two over there, connect on this. Work together. The synergy between individual A, B, C, D, E, F, and G. And coaching is more or less, hey, let me bring you up to this speed. Let me get with you. Let me hold your hand through some of it until I can finally let go and you don’t have the training wheels on. But it’s very fascinating because you start to think, on the other side of things, do we need an affiliative leader or a coaching leader when we’re on the battlefield and there’s live fire. When a building is burning down, do we need a coaching? Like here, let me hold your hand up the entire ladder.

Jeff: And so I’m thinking leadership styles depend on the circumstance. So very much so, I guess at the firehouse, yes, there’s a lot of coaching. Yes, there’s a lot of democratic. Yes, we learn new facets and way to look at things. But as soon as you get into that incident, as soon as you get into the scene of the fire, what happens is, boom, now you’re demanding. You got to get up that ladder. You got to get water. You got to get these people out of that room. And so demanding and pace setting is let’s get it done.

Jeff: Power Skills styles do, they vary depending on the needs of the team, needs of the organization, and needs of the mission. So we can go back and we can study this list as best as possible. But we also have to think, what does it take to be a leader in the circumstance? What does it take to be a leader in that situation? Because I’ll tell you this, being a demanding leader or a pace setting leader, you’re going to wear that team out. You’re going to drive them into the ground. You’ll make them want quit sometimes with the things you say, “I need that by Friday,” and pounding your fist. Sometimes the situation calls for that, and how do we then snap out of it? Because sometimes we’re calling for a democratic when we need a demanding, right? Or the opposite sometimes. We need to democratic instead of the demanding. The idea is that we practice different leadership and emphasize different things within what we’re leading, depending on the circumstance.

Jeff: So then that brings us to, well, hold on, there’s a greater context. There’s a greater context of the PM plan. And this is where the principles taking over are absolutely important. Because when we had looked at the sixth edition, and earlier we’re talking about the overall project management plan, that’s where we’re talking about tailoring based on context. Because I’ll tell you, the plan to conduct a cybersecurity, let’s say, assessment of an organization, a NIST 800-171 organization is quite different than a PM plan in order to build, let’s say, a commercial building.

Jeff: And so looking into that, and what we value, and how we get the team involved, and how we assign work, and the authority and all of that, we’re tailoring based on the uniqueness of each project. So the project’s success based on adapting to the unique context of the project. And this is where, if we start looking into the concept of tailoring, that is more towards, not just the team, the structure of the organization, but also the actual product, I could assure you’re going to find much more success when you’re geared towards, let’s say, smart device development. And let’s say, I don’t know, technology modernization. Having a specific plan and methodology and life cycle and delivery cycle. And of course, that’s where we start to look into, in the next session, in our perform domains.

Jeff: Building quality in the processes in deliverables is so funny. Every single time I would watch someone instruct on quality management, one of the 10 knowledge areas, quality management, they would say, “In quality management, we’re just going to make sure that it’s high quality. That it meets quality standards. That it’s doing what it can. Meeting those qualities.” Okay. What are we doing? We have a checklist. We run through a checklist. This is how it’s supposed to be. This is what we’re supposed to do. Have your verification and validation of all of those things. The concept of quality is to ensure that you’ve met all of the requirements, and that the requirements that you are meeting are traceable back to the larger set of requirements.

Jeff: What I like here, and if there’s anything I know that all of you probably love reading through technical manuals, but the idea is that I like this. This list. Because quality may have several different dimensions, including, but not limited to, and you look through these names. Performance, conformity, reliability, resilience. Resilience is the deliverable. Able to cope with unforeseen failures and quickly recover, right? Satisfaction, uniformity, efficiency, and sustainability. And they even have their sample questions underneath each one.

Jeff: But the idea is that if we’re building a system of quality management, and as much as we have a system of requirements management, or we have a system of risk management, as soon as we have in place that traceability matrix for the requirements, then we’re going to say, “Well, hold on, wait a second.” We ask the question, how do you want it to perform, right? In that, I mean, just looking at ways that we could break down the valuation of what it is that we’re creating in the context that we’re creating, the project plan itself, and the project process. But nevertheless have evaluative qualities to study.

Jeff: So when we get to these back four, if you will, I love the fact that what has happened is PMI has changed the way that they’re identifying and looking into risk management. No longer is it just risk management. It’s in the realm of uncertainty, ambiguity, and looking in terms of complexity. Because really what drives the overall strategy and the approach, if you will, and any of you who remember that Stacey complexity model, where we’re looking at waterfall as being like everybody agrees with all the requirements. Everybody knows exactly what they’re doing. That’s waterfall. But as soon as you start moving away, people aren’t agreeing anymore. They don’t know what’s what. They prioritize so many different things, some in conflict. And the requirements. We don’t quite understand. We’re treading on new ground. That’s when you start drifting out to, yes, that’s right. All the way in the outfield, extreme programming, and the extreme edge of agile development methodologies.

Jeff: But that’s the idea. Complexity is the result of human behavior, system interactions, uncertainty, and ambiguity. Complexity can emerge at any point during the project. For example, in an organization that up to this point had not had any government contracts, or let’s say government customers, suddenly their entire process for creating training materials now have to be 508 compliant. Bang. There you go. That’s completely different. You’re looking at the complexity, and how you now have to create a brand new quality management system. That you may have to redefine how you stand up that product. And I do appreciate that they put it in those terms. When we talk about uncertainty, uncertainty deals with the probabilities of alternative actions, reactions, and outcomes. We don’t know which way it’s going to go.

Jeff: Ambiguity is where it’s unclear. We don’t really know what it is. Uncertainty is that there are so many different avenues. Ambiguity is everything’s foggy. So the idea is that we don’t know, right? And this is why in cases where there is the uncertainty, the ambiguity, where there’s system behavior that’s complex, where there’s human behavior that’s radical, where there’s technological innovation, and new things happening, this is where those agile development methodologies and different life cycles and approaches, why those were emphasized so very much. And why they’ve taken on with popularity.

Jeff: Now in optimizing risk responses, right, the idea is that, well, hold on, wait. There we go. Risk responses, right? So we go from this uncertainty. Well, while we’re on the topic, right? Risk responses. Uncertain event condition, if it occurs, can have positive or negative effect on one or more objectives. Obviously, right? What’s important here to emphasize is that organizations, project teams that employ consistent risk evaluation, planning, proactive risk implementation, often find the effort to be less costly to than reacting to issues when the risk materializes, right? I mean, we’re not talking about lawsuit, litigation or anything, but nevertheless, having to go back, having to rework everything, having to redo everything, if we had just made intelligent choices.

Jeff: Now, when they say a consistent risk evaluation, we’re not just saying every week when we have our standup meeting that we ask, are there any risks or issues that we should discuss? Or once a month, let’s go ahead and evaluate our risk register, and look through. No, we’re talking about being able to say when we’re composing the plan, that work breakdown structure, and we’re looking at the necessity of all the work that has to be done, or even before that, we’re examining all of the different requirements that have to be met, that we’re saying, “Okay, so how do we navigate between hitting this point and this point, and that point.” Problem solving. Being able to, not necessarily avoid risk, but mitigate the risk enough, or at least be able to come up with a strategy that if the risk should happen, we’re not necessarily out hours and hours and hours of work, or thousands and thousands and thousands of dollars.

Jeff: So to that, the embracing of adaptability and resiliency. Because you think about how in the act of laying out that project baseline, and then seeing afterwards this is what really happened. Ha ha. That sort of thing. But the concept is that you lay out the baseline of your plan in the most aware, and realizing and recognizing the reality of all those things. Your actual should only be different than your baseline in as much as brand new risks are coming along, right? So in which case, building adaptability resilience into the organization’s and project team’s approaches to help the project accommodate change, recover from setbacks, and advance the work of projects.

Jeff: Adaptability is the ability to respond to changing conditions. Resiliency is the ability to absorb impacts, and to recover quickly from a setback or failure. If you design it in such a way that you can, in fact, absorb the issues, absorb the extra cost, take the extra time. And in part of the practice, of course, in risk management, what are we doing? What is it? Estimated monetary value where you’re looking at your risk reserves that you have basically the reserve above and beyond the project. And then you have somehow the CFO or CEO at their authority, pulls an extra 10 grand out of their pocket. Don’t worry. We’ve got you covered. That sort of thing. So having various reserves is very important as well. So what does that mean though?

Jeff: Number 12, the anchor, what I was saying, enabling change to achieve the envisioned future state. Change is not easy. Change is not a simple thing. In fact, investing in what does it take for change management and looking at that distribution of folks who are like, “Yeah, I’m ready for a change,” and people that are like, “I don’t think anything needs to be fixed. I hate what they’re doing here. Too many changes. Don’t give me a brand new building, or a brand new way of doing things. I like the old way.”

Jeff: Enabling change can be challenging as not all stakeholders embrace change. They don’t. Not everybody has the buy in that started this list of being a steward, enthusiastically guarding, and being able to safeguard the future change. And even still, sometimes we don’t need the change. Is it a necessary thing? But when we do need the change, when we do have the incentive, when we have the numbers in front of us, when we have the compelling evidence to put us forward, that we should be in a state to be able to make that happen.

Jeff: And so ultimately, you think enabling change in an organization, it can be challenging, but you need to address that. Engaging engagement and two way communication creates an environment which adaptation and assimilation and change can incur. So really being able to, once again, looking at engaging stakeholders and knowing where they are, building up a rapport within. A reputation of positivity is always important. But, well like I said, it ultimately is grounded in benefits realization. So have the hard coded numbers there to help sway the hardheaded audience.

Jeff: With that said, my summary this time around, I know I just got done saying all these things, but you look at this list, and I’ll read some of it, or maybe all of it. But like I said very early on, it all starts about caring about the organization and team success. It all begins with being that steward. Because all the way through, if we couldn’t care less, nothing else is happening. So the drive and the motivation. But then it comes down to understanding the duty of those who are accountable for the work, and does what they can to enable them. Truly seeks to understand the needs of stakeholders and find a reconcilable solution in all conflicts. Progressively elaborates and investigates the value in all activities. Maintains a proactive study and response method to systems within their scope of influence.

Jeff: And I’ll just pause right there. You can read the rest. But that is not the baseline necessarily. That isn’t this is what you should be. If you’re not these, forget about it. No, this is the end goal. This is what we would strive to be. This is not necessarily checklist that we could be perfect in. We have to consider that, as leaders in exhibiting the leadership qualities, that we may not be in a position to exhibit all of these qualities. That we’re working on it. And I think that’s what it comes down to.

Jeff: I think if we’re to look through the ultimate goal that’s been underlying of every addition of the PMBOK Guide up to present, it’s not that, oh, we’ve arrived. That we’re optimal. In fact, I try to say that in all of my business process improvement courses, project management courses, I don’t like to use the term optimal. Optimal, yes. Okay. Two plus two equals four. Four is the optimal answer. Okay. For something synthetic. But for something lived and human, that we could say that we’re are in a state of optimizing, and that we have our next smart goal to achieve. But I think that’s the idea. We’re working on it. But what do we work on? If we work on these things within our team, within our organization, our organization being these things, then hopefully will arrive at the end result that we want. That concludes what I say. Oh my goodness. It’s on the dot. Thank you. Are there any questions, anything in the chat? Let me see. Anything?

Melaine: We have no questions.

Jeff: No questions. Wow. And hopefully they’re all still awake.

Melaine: No. It was very informative. You’re amazing with the time as well. Thank you for that.

Jeff: Okay. Thank you. I try.

Melaine: All right. Thank you, Jeff. That was wonderful. A big thank you to our MPUG community. Thank you again for choosing MPUG to grow your skills with. We will have Jeff back to finish lesson three, coming up on May 18th. We have a little break between now and then. And next week we’ll have a session on boosting effectiveness of your MS Teams meeting, which we know everyone is heavily involved in. Again, the PMI PDU activity code, I chatted that out as well, is on the screen. I’ll share a link later today with the recording from this session, a link to sign up for the next session, and a quick survey. So please share your thoughts with us. And again, thank you all. Jeff, thank you.

Jeff: All right. Thank you.