Overview of the PMBOK® Guide Seventh Edition – Lesson 3 Transcription

Please find below a transcription of the audio portion of Jeff Bongiovani’s Overview of the PMBOK® Guide Seventh Edition – Lesson 3 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.

Melanie: Hello. Welcome. Melanie here with Team MPUG. Welcome to Overview of the PMBOK Guide Seventh Edition Lesson Three. We invite you to join in today with questions and comments by using the chat feature in the GoToWebinar control panel. You can see that up here on the slide. You can click on that and pull it right out and expand it for easier input. Today’s PMI activity code, I’ll have up on the screen here in a minute. For those of you attending live today, we will add this to your transcript automatically. We also invite those of you attending live today to stay on after the hour for an overtime chat with today’s experts. The mic will be open and recording off for a free flowing discussion and Q&A. Now I’d again like to introduce our five star expert Jeff Bongiovani.

Melanie: 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 20 years. Jeff, a big MPUG welcome back. I mentioned the five star because I saw this event is up on PMI. And so far, views at MPUG are five star so thank you for that. I’ll hand the presentation over to you.

Jeff: Fantastic. Let me find out where I’m presenting from. There we go. All right. Well, a great afternoon to everyone. And for those of you who had joined us for the first two sessions or at least one of those two, welcome back to you. And for those of you who might be joining us for the first time, just a bit of a rundown, the sessions up to this point are all based on PMI Standard for Project Management and A Guide to Project Management Body of Knowledge, Seventh Edition. Most of what you’ll see here today, if you have a copy of the PMBOK Guide Seventh Edition, you’ll be able to pretty much read along or at least get the idea of what’s going on. Now up to this point, session number one of our series, we were discussing a system for value delivery, which meant for the most part, PMI wanted to paint five primary contextual concepts defining the system for value delivery. Meaning to say creating value, organizational governance and systems, functions associated with projects, the project environment, and product management considerations all provide the context for how project management could be conducted.

Jeff: Answering these questions kind of is the segue and a guide into understanding how they’re setting up the Seventh Edition as being, well, let’s just face it, radically different than their legacy editions. Meaning to say that the Seventh Edition is inclusive of the Sixth, but it’s more of a high level concept and leaving to, and as we had discussed in that first session, leaving to the practice guides as well as other standards. In addition to that, as well as the PMI standards plus to lead the way for the immediate processes, the techniques when it comes to things like estimating or requirements management and things along those lines. So the Seventh Edition is striving to be more than its process-prescriptive past and be more principle-driven, and understanding that the Sixth Edition was a solution, if you will.

Jeff: Here are our process groups. Here are different processes. Here, you could try this order, but then understanding, wow, that’s really a straight line through a lot of scattered dots. Especially when they released the Sixth Edition, giving this agile guide. And they say, well, you know, if all else fails, you could try this agile guide as well. But nevertheless, the Seventh Edition does admit, hey, managing projects is an unsolvable game. There is no one particular path, just one that you discover and refine more and more depending on whatever that endeavor includes. The central focus theme was a system for value delivery and really a high level understanding that optimizing the value delivery components and information flow through understanding and conducting proper governance core functions associated with projects, the internal external considerations, and product service management considerations.

Jeff: As we move through into the second session, we’re examining the fact that, hey guys, the way that you wrote the original editions or at least the Sixth Edition is that you had a breakdown of knowledge areas. You said, okay, these are the things, the 10 aspects of what you need to know to properly manage a project. You have your integration, scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholders, right? And then once you’re done all of those, let’s give you a standard. Let’s go ahead and piece those and put those in order for you. So taking the knowledge areas and saying, here, initiating, here’s how you start. Then planning. Now, bear in mind, this is all iterative, right? The planning, the executing, the monitoring, controlling, and hopefully you’re getting it right and refining and improving until bam, closing. Right? Out of those 49 processes, you really had a lot of things you could memorize and say, oh, I can get that right on the test because I know all of the ITTOs or all of the inputs, tools, techniques, and outputs.

Jeff: PMI took a stand back and said, you know what? This is too predictable. This is too process-oriented. It’s too rigid. It’s not like a machine. A project is more organic in a lot of cases. And so what they did was, and I’m going to use the term flip the script, if you will. They started out with their glorious introduction saying, look, we’re going into more systems engineering angle at this. We’re prescribing, if anything, the system for value delivery, but we’re not going to give you the specifics, here’s exactly how you get it done, because the industries, products, environments are so extremely diverse. So we’ll teach you these principles, right? If you have this proper mindset and way of thinking about things that begins with these 10 project management principles, that should set you up and support and guide your way through the rest of it. Tailoring and defining for each project or each type of project or each type of let’s say deliverable, or even still the entire product itself or service that you’re delivering, that this should set you up for success.

Jeff: So they begin with the standard and then they follow with, by the way, here are your performance domains. Now that’s the focus of our session today. But of course, let me reiterate. The project management principles really come across as, okay, the mindset. Everyone from A to Z, top to bottom, bottom to top within the organization cares about organizational and team success, understands the duty of those who are accountable for the work and does what they can to enable them. And I said last time, and I’ll say it again today, you can’t be all of these things, not 100%. I mean, if you’re going to do anything, just say 98%, right. At least have 2% humility. The idea is that you have to have goals to strive towards. If you said in a perfect situation, yeah, in a perfect situation, where do we fall short of being any of these things?

Jeff: You know, employees consistent risk evaluation. Okay. So we could admit we’ve had standup meetings where we didn’t mention risks or we didn’t evaluate or reevaluate or oops, didn’t close out that risk that should be closed out. But the point of the matter is that in having these as the guiding light or the light at the end of that long dark tunnel that you have to traverse to, whatever, the idea is that this set us up for our project management success. And they also in a way underlie. And once again, as the system of value delivery was formulated upon those five questions, in that context, this takes that context a little bit further and said, okay, well, if we’re to mold that concept a little bit further, these are the principles to embody, these lay the foundation for the performance domains.

Jeff: So what are the performance domains? Right? Welcome to our session three. Today you have to understand the performance domains section of the PMBOK Guide Seventh Edition spans 122 pages. If it were easy enough to come across and get all the information across in, I’d say roughly 50 minutes, they would’ve written this down in five pages. So our expectation here is really, we want to give the greater context, understand these domains from a general sense, just to get to know what’s in there. And then I’ll leave all the reading up to you, because it sure is, it’s a really… Well, okay. So I’m quite a nerd. It’s a fun read for me because I like systems and stuff like that, but I don’t want to underlie the importance. It’s like eating your vegetables. In which case, there’s a lot to do with the performance domains that you can see remnants from the Sixth Edition.

Jeff: You can already tie it to things that you might be doing. As I was introduced, I was a software and programming instructor for many years. I understood, no students going to come in and from beginning to end comprehend and be able to spit back every single detail from the beginning to end of class. If at anything, what they’re looking for, seeking for are just nuggets of decent information. Something practical that after the fact of hearing it and practicing through it makes something better. And so if anything, we may not redefine our entire organizational way of performing project management, but at least we’ll have some semblance or idea of something extra to look for, some additional consideration. With that said, from processes to principles, right? If you look very carefully, and I’m going to show you much larger on the next slide, the idea was that a guide to the project management body of knowledge, that performance domains that they’re talking about breaks down into eight performance domains.

Jeff: The domains themselves are quite descriptive and they talk about techniques and considerations. From it, basically you can find fitting into those performance domains a wide variety of different techniques, even including, like I said, inclusive of the Sixth Edition, but a lot of the principles practiced within systems engineering theory as well. So these eight, we’re talking about the stakeholders, team, development approach and life cycle, planning, project work, delivery, measurement, and uncertainty. You can sort of read within that a linear progression. You start with your stakeholders and learn about what you’re doing, right? No, it’s in the same sense that those of you familiar with the Sixth Edition, we still have kind of like, oh, well, do we start with uncertainty? Do we start with planning? No, everything is considered all at once. Meaning to say, yeah, your stakeholders might not appreciate your development approach and life cycle, and of course there’s a greater uncertainty because of that.

Jeff: And because there are certain standards that you have to follow, then you’re stuck planning a specific siloed, and let’s say waterfall kind of way. And because the stakeholders then determine, yeah, you get the idea. But from it, we can start to mold an idea of greater considerations. I would treat it more like verification and validation, right. Within the guide, each performance domain, if you’re reading through it has an introduction with an overview definition of terms that they’re using. The primary concepts and considerations, that would be the bulk of the material. Then they talk about interactions with other performance domains. What’s the impact uncertainty has on, well, pretty much everything? And then ultimately, they have a little section and segment that’s called checking results. What I’m going to try to do today is I’m going to show you the introduction with the overview and definition of terms used.

Jeff: Definitely getting into that, because that gives you a broader overview of the performance domain. Then I’ll show you within that, all of the different sections and talk very high level to those different sections that they have, the concepts and considerations. Then I’ll show you the checking results section as well. We’ll talk through those. Now, what we’re not going to be able to get to today is really the latter sections or the sections that fall afterwards. I’ll talk about that or infuse some of the concepts from it. But two sections exist afterwards, the tailoring, models, methods, and artifacts. Don’t be surprised if you’re reading through something like the uncertainty performance domain. You’re like, where’s the risk register? Where’s the talk about risk? Where’s my risk checklist? Where is that? Those are definitely going to be mentioned in some parts of tailoring, the models, methods, and artifacts. But bear in mind also that PMI has published an entire guide to risk management. You go, you get that standard, right? You get that practice guide and read through that. That’s where all your documentation stuff is. That’s where it exists. It’ll definitely point the reference to those. The sections on tailoring, models, methods, artifacts, they expand upon even more when it comes to performance domain concepts.

Jeff: You’ll notice that question there, have we tailored our processes appropriately for the environment, industry, team, product or service, et cetera? That’s the idea and that really is what the primary concept is with tailoring is the idea that… And why it follows is that now that you’ve read basically a full spread of considerations in a range that’s feasible, that now let’s talk about being able to refine those and start asking questions about how we can develop our own approach understanding these performance domains. So tailoring does, it involves understanding the project context, the goals, the operating environment. Ultimately, you have to consider here, tailoring is trying to get that line through all of those different dots. You’re trying to come up with a process oriented like you could see even an equation that tries to solve how to connect those dots. And what are those dots? But delivering as quickly as [inaudible 00:17:09], get it done right now, minimizing project costs, cheap, right? Optimizing the value delivered.

Jeff: Oh well, this is so high quality. How did you get it done in three minutes? Creating high quality deliverables and outcome, providing compliance with regulatory standards. Don’t you break laws, right? Satisfying diverse stakeholder expectations. And some of us want to really underline diverse stakeholder expectations in that. Because one department wants it nice and beautiful, and the others trying to just publish the minimal viable product, you know, that particular thing. And ultimately, adapting to change. So these adaptations, tailoring, what then do we focus on? And to pull an excerpt out of that section on tailoring, what do we tailor? What do we tailor to? But the life cycle and development approach selection, that’s one major one. A lot of times a project can fail, ultimately because the product itself, the components, the complexity wasn’t necessarily considered, or at least there were vulnerabilities.

Jeff: Once you reached a point where you said, wait, we have to go back and there’s rework, and then we have to rethink this. Now the requirements are changing. It’s like, oh, darn, maybe we should have gone with a more iterative approach. But we were locked into a very waterfall approach when we first started out with that. Processes, so the processes that help to support the project itself, the things that nonetheless get the job done. The level of engagement, the tools, as well as different methods and artifacts. You’ll see at the very end, ultimately, documentation plays an extremely large part. I mean, you’re not going to memorize everything. Ultimately, how you communicate, what you communicate in let’s say your lessons learned logs and how you’re even describing specific assignments and the requirement fulfillment in let’s say different assignments plays an extremely strong role.

Jeff: But you know, perfectly, and we’ve come across this before during projects, it’s like, all right, let’s take a look at our artifacts library that isn’t necessarily a hundred percent organized and let’s go ahead and sift through our 300 different emails that we’ve received over time. Yeah. Definitely, there has to be the communications planning involved with that as well to more of a lean and effective type of method. Ultimately, how to tailor. You’re looking at the overall organization and ultimately tailoring for the product, which means the product to deliver itself, the deliverable itself, pieces and parts. Maybe it’s multiple pieces or parts that are assembled into one thing. Maybe it is the service itself. Maybe it’s a service that has many different appointments over time, but nevertheless, the project team. When we talk about that, the project team these days, those of you who are trying to wrap around… Hopefully at this point, coming to a successful solution to the hybrid and virtual environment.

Jeff: But I’m working right now with a team that we’re putting together a cybersecurity manual. I’ve got team members who are out in California. We have people in Iowa, Tennessee. Not only that, but locally here in the Maryland, Baltimore area that we have some people who go into the office and some people who are working remotely. Working with how to communicate and setting up that without that, as they call it the Zoom or teams exhaustion over time. That comes down to also the culture, the team culture. Are we all about that team hood and high fives and everybody being engaged? Or are we overworked? And because we can’t see each other face to face in the virtual environment, we don’t know it. So really looking for opportunities to boost the culture. All right. Now into the domains, right? Let’s get into the domains. Here you go. Go ahead and squint. I’m just kidding. I’m going to break this across multiple slides.

Jeff: I just wanted you to see though, here are the eight. Now you’re looking at this and you’re like, now you’re squinting and looking very close at your monitor. But my point for pointing this out is that you can see almost like a graph, an upside down graph. Measurement, man, they couldn’t say enough about measurement, right? That’s why this thing is so tiny. All the text is so small. But if you were to just pause, if you’re watching this on record and you were just to pause, you’re going to see what’s posted across multiple slides that follow. But you could definitely start to see things like, oh, okay, stakeholder. I remember that. They had a stakeholder section before. Team. Okay. They got resources. They had that as a knowledge area. Things along the lines of where we get into like earn value analysis, fall under measurement, where you talk about baseline performance as opposed to, okay, how do we get to baseline? How do we get our baselines? Where do I go to read all about our baselines?

Jeff: But you see ultimately, they have an entire planning section so that’s not unfamiliar. The idea to show you this is that across these eight different sections, they do, they give a lot of information. They give a lot of different considerations. They got charts. They’ve got graphs and diagrams. And if anything, those of you who did take the time to read through the previous guides will most likely find the same exact information, just more and placed in a different context. First up, I’m going to move, changing the slide. Let’s talk about stakeholder performance domain, right? The stakeholder performance domain. Now, when they’re talking about that, it’s your typical unusual, you should understand this already with stakeholders. Building productive working relationships with stakeholders throughout the project, right?

Jeff: Obtaining the stakeholder agreement with the objectives. Ensuring the stakeholders who are project beneficiaries are supported and satisfied. Managing stakeholders who may oppose the project or deliverable so that they don’t negatively impact project outcomes. We should understand stakeholder management. If we don’t, the idea is that with each person that you encounter, you really have to see it through their eyes when it comes to managing and producing on that project. You have to understand when that one, oh, goodness, I speak from experience. When that one is going to wait two days before the assignments due to just say, hey, why don’t we change this to that? Right? There has to be written into, and I’m not saying that there’s that Venn diagram with stakeholder management and risk management, but most definitely there is. Right? There is. The idea is that when it comes to stakeholder management, we have to understand providing constructive feedback, impact, being honest and forthright and transparent, but also diplomatic.

Jeff: In some cases, building a filter. Nevertheless, when we’re talking about our stakeholder analysis, we should be familiar with stakeholders, anyone who will be impacted by the project. Often talking about, okay, so we have to cut power into a hospital wing for a half hour while we do these updates to the computer system or whatever. Like, okay, so the patients are going to be impacted. The nursing staffs going to be impacted. The doctors are going to be impacted long term. That’s a lot of stakeholders, right? But do they hold the power and influence? You got to get this done. Right? Choosing or picking the date or the time would be more appropriate. A method of systematically gathering and analyzing quantitative, qualitative information to determine whose interests should be taken into account through the project. I like that. So these people over there, we don’t care about them. Or at least after the lawsuit and settlement, we’ll be fine. Not really. Okay. But nevertheless, you get the idea.

Jeff: The stakeholder analysis is really the matter of getting to know all the people who will be impacted, how they’ll be impacted, and finding a feasible way if possible, molding or shaping the way that you would plan events to happen to get those deliverables out and deliver. So really it’s short, right? Stakeholder performance domain section, it’s short, but it’s significant in the sense of the complexity, understanding the complexity, the level of engagement, how to conduct analysis and prioritization, engaging and monitoring. Now within that, what I wanted to do, and I’m not going to have enough time to do this for every single domain, but just to give you an idea just of what this domain contain. The domain contains, let’s look, complexity, right? The number, the turnover, the influence, the power and interest.

Jeff: As far as the first phase, second phase, third phase, you might be dealing with one department, one division, and then it moves on to someone else or something else with a completely different vibe or environment. And so the turnover, the influence of power and the interest is definitely something to be considered. Engagement, promoting the productive involvement. When we’re looking at the identity and identify, understand, analyze, prioritize, engage, and monitor, that cycle which they talk about. When we talk about productive involvement, we really need to say, okay, well, if they are an influencer on this project and really their requirements will ultimately be the ones that we have to follow, we have to have some sort of touch base meeting at a pace that seems best when it comes to turning around things. Especially also with stakeholders who have a strong influence but are prone to change their mind.

Jeff: Like I was citing before speaking from experience, that you want to be there as soon as they change their mind. You say, wow, don’t remind them of this. Don’t remind them of that, because then they’ll change their mind. No, remind them, give them all that information so they change their mind now rather than three weeks from now when somebody in a random conversation mentions something. When we talk about analysis aspect, considerations, power, the impact, the attitude, the beliefs, the expectations, the degree of influence, get the idea. This whole notion of progressive elaboration is something extremely important, especially when it comes to the requirements for a project. But since requirements are so tied in with stakeholders so it does, it follows that you really need to get to know the stakeholder and where those requirements come from.

Jeff: When we’re discussing, when I was discussing the concept of how things are broken down, the stakeholder performance domain checking results follow through with, okay, here’s the outcome you’re looking for. Productive working relationship with stakeholders through the project. You’re looking for a stakeholder agreement with project objectives. Stakeholders who are project beneficiaries are supportive and satisfied. Stakeholders who may oppose project or its deliverables don’t negatively impact the project results. You could see it pairs up with that introduction, but how do we go through and check whether or not these things are happening? Right? So productive working relationship with stakeholders can be observed. Okay. That denotes, we can observe them. It’s not undercover. It’s not unknown to us. We’re not avoiding the stakeholder altogether. We have an open and friendly relationship, maybe not, professional relationship with the stakeholder per se, but is something we have investigated.

Jeff: We have a line of investigation as observations that we can write to. However, the movement of stakeholders along a continuum of engagement can indicate the relative level of satisfaction with the project. But let’s just rest on that for a moment when we’re talking about the complexity and the change of and the turnover and the longevity and the influence. Basically not saying that you have a dossier on each one of these stakeholders, but you at least have addressed and you have a track record. You have this documented or at least is something that you consistently look at. So if it is a standup meeting, you have a list of stakeholders and you speak to each one not every single time, but whenever necessary. Significant number of changes, modifications to project and product requirements in addition to scope may indicate stakeholders are not engaged or aligned with project objectives. Well, it may be, but you’ve had these discussions, right?

Jeff: So this implies that you’re having those discussions with the stakeholders, that you know whether or not they’re aligned with the project objectives because you reiterate the project objectives, that you bring it to mind. You have the clear vision as we discussed with the project management principles. There it is at the very bottom, a review of the project issue register and risk register can identify challenges associated with individual stakeholders. So there’s your risk register and there it is coinciding with your stakeholder management. Well, we get it, stakeholder performance, team performance, right? When we’re talking about that, we’re looking at those involved in the project building and maintaining a strong sense of shared ownership, growing a high performing team, demonstrating applicable leadership and other interpersonal skills within all team members. So it depends, right? The structure and authority within whatever is considered the team.

Jeff: And you may have had this discussion before, depending where you fall in organizational structure within a spectrum. When I say a matrix-based organization, it’s like, okay, so we have solution areas, if you will, and then we have various different projects that are going on that utilize our resources from those solutions. So I may myself as the manager of training and development may be engaged at any given time on four or five different projects under different program or project managers. Maybe I’m the program or project manager, but when we’re looking at how things are structured and the team dynamic, that’s really where we’re talking about the focus here. Now out of anything, making a strong team also means making stronger team members and offering opportunities for those team members to shine. So if we’re looking at this, right? Project team management and leadership. Servant leadership, what does that mean? There’s something that I was talking about last time with the project management principles and emphasizing leadership techniques and styles.

Jeff: If we’re talking in terms of emotional intelligence, I think I was discussing the different styles within that authored book. The idea is that a lot of times we think, oh, the perfect leader is the one who is the democratic leader who listens to everybody, they all have this cumulated opinion and things like that. That’s perfect. That’s great, until there’s gunfire or there are bleeding victims all over the street and we got to get things cleaned out. It’s like, oh, let’s hold hands and sing songs. The idea is that leadership, different styles of leadership are called for in different situations. Now, ultimately I agree, the servant leadership is a leadership perspective that I’m going to be supportive. So in being the most supportive person I can as a leader, I need to learn how to turn different aspects of my leadership on and off. I need to know when I need to be a pacesetter and say, look, the customer is expecting this on Friday. We need it there on Friday and just keep kicking them until they get it done.

Jeff: And then after Friday, you take them out for ice cream. Then you sit back and say, okay, look, I was a little harsh on you, but let’s all get an idea. What did we learn from this situation? Now you’re being a leader that’s hearing everybody’s opinion. I’ll sit back, you guys lead the way. Tell me what’s going on. And so the point is that we learn our leadership skills by rising and adapting to our own skills in that situation to sort of drive what that situation needs. Now you’ll look at some of these other names in the section, establishing and maintaining vision, okay. Not eyeglasses, right? But the idea like here are our objectives. Here’s the vision and what we need to get across. We need to be first to market. We want to have our name out there in shining lights, whatever the vision is. But to facilitate the team growth, you start to concentrate in things like the critical thinking, motivation, interpersonal skills. Like I was saying before, really been moving into a hybrid environment, it’s tough because you have to look for more opportunities to bring people in.

Jeff: So here, the outcomes, we want shared ownership, high-performing team, and applicable leadership and other interpersonal skills being demonstrated by all project team members. We would hope that we don’t have to kick them in the butt to get things done, that they would do it themselves because they believe in the mission. And if somebody’s not doing that, that we as a leader are not going to sit there, well, you don’t have the right attitude. You’re not cut out for this. But the idea is that how can we foster that attitude? How can we grow that in love for the company and love for the work? And it might be proposing more situations where they have their key input. Maybe they’re the right player on the wrong team in other words. Some of the double check is ultimately keeping the team engaged, keeping a conversation and fostering an environment where they’re free to express their opinion. That’s for the most part.

Jeff: Now this is where we get into more of the technical side, right? We’ve been talking principles, be a good person, practice communication, get to know them, that sort of thing. But when we talk more about the technical aspect of things and when we look into let’s say agile practices versus waterfall practices, and we were talking about how do we plan things out and how we work with it. The development approach and life cycle performance domain, wow, the longest one that’s written out is now starting to examine, okay, what are we making and how are we delivering it? And so there’s a lot that starts right here. Development approaches that are consistent with project deliverables. I’m not going to read through all of this, but you can read the development approach, the life cycle, what do they mean? What’s deliverable, cadence, project phase? I mentioned one of the projects that I’m working on right now is building a cybersecurity training manual for certification, right?

Jeff: The only thing is that all of the requirements for passing the exam and receiving that certification are still actively being written. But our overall vision is that we want our name Edwards to be number one. We want to be first. When you search for that certification, we want to come up first in all the search engines. We want to be synonymous with it, right. We want to be first to market. We have the brand new cutting edge materials. This is exactly what they said yesterday and we’re teaching that. And so to try to maintain that is, wow, it’s very aggressive, but it means that ultimately we can’t necessarily write a 700 page manual, right? Just open up Microsoft Word and there’s 700 pages and having 20 people writing in it all at one time. Sorry, Microsoft. But there are a lot of issues with that, right? When we talk about the project life cycle and within it, the development approach, we sought out to say, no, we have to design this in the different chapters and segments.

Jeff: We have to order this in such a way what’s more predictable about what has to go into it than not predictable. So it’s definitely in the segment, once you start reading through, that you’ll start to say, oh, that’s why the life cycle makes a little bit more sense to go through. Or the ITTO makes a little bit more sense when we’re trying to approach it that way. When we look at the different sections here, what I like is that they talk about delivery cadence and they give a few examples. For example, they’re talking about one where they’re setting up, let’s say, or establishing a retirement community or something like that. Well, landscaping is what it is and building the building is what it is. A lot of those are very predictable. You have codes and things like that that you have to follow. But ultimately, once everybody gets settled in and stuff like that, setting up activities, how do we do that? Do we set up an activity website? Do we do it iteratively? Do we set up the main site?

Jeff: Then we start adding to it over time. How many activities should we have by the end of the year? That sort of thing for these folks to be engaged in. So that’s ultimately what they’re looking at is this product or service is delivered multiple times across an entire calendar or this is just delivered once. Here is your airplane. There it is. There’s your web app followed by a bunch of bug fixes over the next five years. How does that work? How do we establish the way that we’re going to set up to plan the work based upon the product itself? Do you have development approaches consistent with the project deliverables, the project life cycle consisting of phases that connect the delivery of business and stakeholder value from the beginning to the end, project life cycle phases that facilitate the delivery cadence development approach required to produce project deliverables. It makes sense. You’re talking about stakeholders and team. I mean, they’re with you part of the way, all of the way, most of the time, but nevertheless, that’s who.

Jeff: And this begins in with the what of the project management aspect. And of course it follows, right? The planning performance domain, right? The planning. Estimating and being able to work with how you are going to perhaps iteratively deliver deliverables and setting them up. But when we talk about some of the vocabulary here, the estimates, quantitative assessment, likely amount or outcome of variable such as cost, effort, durations, resources. This is where we get into our traditional planning concepts. Now they’re not going to fully go all out with work breakdown structures and you’re looking at logical dependencies, your lag and lead and all of that stuff. But nonetheless, just generally speaking about like crashing, for example. When we talk about crashing or we talk about the overall let’s say critical chain theory, although that won’t literally say critical chain, but we’re talking about reserves and understanding estimates along those lines that definitely it is addressed here.

Jeff: So the sections involved within the planning performance, planning overview, different variables to consider, how it coincides with delivery, estimating, and presenting adjusting estimates, schedules, dependencies. They do talk about adaptive scheduling. So if we’re talking, okay, so this is more iterative rather than hyper predictable, this is to the less predictable, that there are ways in which we have molded or shaped that. You could see already when we get to some of the other latter performance domains that plug in with this. You say, okay, so they’re leaving the best for last, like uncertainty. There’s traces of uncertainty everywhere, right? But it is something where they do the development or at least laid out the development of the PMBOK Guide in what I feel to be a very appropriate way. They’re like, now that we’ve talked through all this, reflect back.

Jeff: Once we have this planning and we talk about the work performance and we talk about measurement and things like that, ultimately we do integrate a lot of the solutions for planning and how we plan based upon the anticipated risk to either mitigate or avoid, to work around and not even negative. But when we talk about positive and opportunities that we sort of design in such a way or plan in such a way, staff in such a way to ensure the greatest outcomes. You’re looking at any sort of plan, right? Well, some of the things here, evolving information is elaborated to produce the deliverables and outcomes for which the project was undertaken. You know, in that case, there is the progressive elaboration where you’re drilling down, you’re getting to know more information details about requirements, and therefore about the deliverable and about the outcome. That’s ultimately what you may find. The more details that you understand about something completely or can radically change the way in which you plan for things to happen.

Jeff: The timing is essential, or learning that now that some of the graphic design work is best left to the very end once everybody’s figured out ultimately the context and the writing above and below. But a lot of that, a lot of the graphic design work in a, let’s say a presentation or a manual or any book is something that may be extremely time consuming. But the idea is that once everything is said and written, if you do it last, you get a stronger idea what needs to go into the diagram that’s more supportive. You have all the texts. And then ultimately, the idea is that you’ve minimized how much rework is going to be done on that. Because towards the end, we start to find that people don’t have to double back. Work performance. What’s interesting here, when we look into work performance, this is really about communications, engagement, managing physical resources. What used to be an entire knowledge area for procurement is now housed within the work performance domain. You’ll see things like the bid documents, bidder conference, explicit knowledge, and tacit knowledge when it comes to how things are shared or communicated.

Jeff: Actually, that’s extremely important. I mentioned that last time, the explicit versus tacit, and how tacit knowledge, personal knowledge, that can be difficult to articulate or share such as beliefs, experiences, insight. Just like, why did you do it that way? I just had a hunch. But you know, how a person feels after the project isn’t necessarily something that’s communicated. But nevertheless, I mean, unless you’re investigating, we had all these HR complaints that tacit knowledge is something that can’t be necessarily imbued with a lot of the quantitative numbers. And so when we’re looking at performance, I was moving to the next slide, because I know, I know the time, right. But the idea is that the narrative a lot of times when it comes to work performance is more expressive in understanding and living in that project, the project vibe if you will, or the story that could be told about the project is more telling than just the numbers and the lessons learned log. So there is something to be said about all of that.

Jeff: Now, the work performance domain. The ideals there, efficient and effective project performance, project processes that are appropriate for the project and environment, efficient management of the physical resources and procurements. Like I said, all of these checks, if you go back and read, most definitely will help guide getting started out. The tailoring section as well is full of wonderful things when it comes to each one of the different domains, in fact, but it’s something worth reading. When we talk about delivery performance, right? Delivery performance domain, this is the establishment like what are your requirements? Right? As far as deliverables, requirements, requirement solicitation. But it also is infused a lot with the scope and scope definition, the decomposition. Being able to measure quality, the cost of quality, and ultimately a lot of other costs. For example, what is the cost of change and what happens? What is the cost of failure? Ultimately, this is setting up to be able to measure all of these things, but at least providing that context.

Jeff: Like I was just saying, I’m sorry, but when we talk about the different sections here, the scope definition, decomposition, completion of deliverables, delivery performance is more or less the establishment of how you are going to measure your delivery and how you perform within that delivery. So laying out the baseline and the expectations, if you will, in the realities of doing business. Let’s see here, I want to fit everything in. I tend to, when I set these things up, I want to talk about so much and I love talking about it. Measurement performance. This is the longest one. Now the idea of measurement performance, here’s the idea, measurement performance, reliable understanding of the status of the project. One thing that was just beaten into my mind through reading the Sixth Edition and just memorizing it and understanding it and being one who thrives on data analysis is that you cannot do analysis with unreliable data.

Jeff: And so the reliability of information provided is essential. It’s absolutely important. Unbiased, reliable data. But it’s also got to be actionable data, right? Because ultimately, it’s information that’s going to help you to make decisions along those lines. The great part about this, the great part about this particular domain is not only are they talking about what to measure, but they’re also talking about different ways that you can perform measurements. They did an excellent job. I think they did an excellent job. Although you probably want to read more about it in a practice guide for further breakdown, but you’ll see the right hand column there for the performance domain really goes into forecast of estimate at completion and estimate to complete. And for those of you who are familiar with earned value analysis or EVM, if you will, as far as earned value management, these are important factors. I mean, okay.

Jeff: One thing that you should be in a confident position to state says, okay, I can do the rework on this like you expect me to, but here’s what happens if we add to our schedule those additional, let’s say that additional day of work. By my estimates, this is going to take us into the next week. I just want to caution you. Now the point is that we want to get it right. What you’re asking to change will improve the quality overall. And so you get the idea, right? It’s like, well, this ties into, does this make it more marketable? Does this make it more, let’s say attractive to customers? Is this something where we are spending those eight extra hours to redo all of this? Because now, my goodness, that’s just going to double sales that sort of thing. The customer is just going to love us that much more and ask us back next time. You really have to use this in conjunction with the overall business plan.

Jeff: I have to tell my teammates all the time, when they have a great idea, well, maybe I could redo this whole section, redesigning all these diagrams to make them look pretty. And I said, yeah, how many hours and how many customers have to pay for that extra time for the redesign? The idea is really integrating the investment and being able to measure and compare with that investment. So this, this very much so is worth the long read. It’s the longest section with a lot of screenshots, but nevertheless, the idea is to design and develop in such a way into, let’s say, build in to your planning and development a means by which you can arrive at accurate measurements. One more thing about it when I was working on an e-learning project two years ago, it’s first time that personally I had ever worked within one piece of software to put it together. I was used to different software. And so it was appropriate to say, okay, they budgeted 500 hours for me to get the list of modules accomplished.

Jeff: So I began a burn down chart. And you’d think that something that’s iterative, you’d say, oh, less documentation, it’s so much better. But the idea is that with the burn down chart, I was logging, I know I’m such a nerd about this, but I was logging in hours and categorizing those hours to what I was doing at that time. What that leads to down the road is better estimates when it comes to saying, well, chances are I’m going to spend 50% of my time doing this. So bear in mind, the concepts of tracking and managing the quantitative data is just as important as we were discussing with the qualitative narrative in that. So reliable, like I said, understanding the status of the project, the actual data, timely appropriate actions to keep the project performance on track. These are all of our checks for this particular matter. All right. Last but not least. Oh man, he’s so far behind, but no, he’s not. The uncertainty performance domain.

Jeff: Here’s the idea, uncertainty. When you think of it in terms of risk management, but there’s more to it. Because when we talk about uncertainty, the thing that comes to mind is the Stacey Complexity and Uncertainty Model where we’re talking about waterfall is predictive. But as you are moving further out and having a looser understanding of what the requirements are, everybody seems to disagree on everything. Then you start getting into this chaotic territory that is manageable if you use iterative approaches. When we talk about uncertainty, it’s engaging uncertainty and not knowing. I don’t say, go ahead, run full steam right into the fog, drive your car at a hundred miles an hour. There might be a pile up in there. But asking the unasked questions is part of it, exploring new grounds, but doing so safely and carefully.

Jeff: The idea here is that we want an awareness of the environment which our projects occur, including, but not limited to the technical, social, political, market, and economic environments and being honest. Taking off the rose-tinted glasses. Not to be too far. But the point of the matter is awareness. That’s what we’re driving towards. Awareness defeats uncertainty. That’s the only thing that narrows that gap between when I look at the dichotomy between planning and doing. When we say planning, what do we plan for? But we plan for the wide range of the expected, based on the reality, which we’ve gone through. When we execute the plan, when we monitor and control the plan, what are we trying to do? We’re trying to sustain the walk of principles and goals to stay the course despite all of the various things that may try to tear it down or prevent us. And so awareness is ultimately what fuels a stronger plan in the long run. When we talk in terms of the uncertainty, there’s ambiguity, right?

Jeff: Unclear, difficulty identifying cause of events, or having multiple options from which to choose. The complexity, because there are so many moving pieces or parts that coincide that make it difficult to come up with one solid plan of action. Volatility, right? The possibility of rapid or unpredictable changes that may undermine all of the progress. Then it comes down to the risks. You’ll see that as far as the subsections are concerned, listed out. But I do very much appreciate the fact that they go into, say for example, reframing. Reframing when it comes to working with complexity. When you’re looking at it from viewing the system from diverse perspectives, brainstorming can help with that. Then ultimately, balancing the types of data rather than only using forecast data. It’s got interesting stuff in there.

Jeff: Let’s say here, because I have in my remaining negative one minute, I think what it boils down to is there’s a lot. There’s a lot to read in here. It’s 122 pages. Thank you for sticking around for the remainder here. But when it comes down to it, the cornerstone stakeholder management does, it depends on meaningful and productive engagement, right? Team performance is enabled by seeking opportunities for the team to contribute, learn and grow. The development approach and life cycle is determined by the product in the context of, well, pretty much everything. But especially the uncertainty within the product and context. Position being ultimately you do on a position you’re planning and estimating, and delivery performance to gather the meaningful measurements. And it comes down to practicing effective documentation, elegant and lean. I will say, just a remark because this closed out all of our sessions that I like these changes, but only because I’m not locked in to the traditions of the PMBOK Guide.

Jeff: In fact, I was only introduced to the PMBOK Guide five years ago. Going into it, understanding different project management theories and systems engineering, so like, oh, this is pretty handy. But nevertheless, I think that coming at it from this larger point of view, systems point of view may appeal to me, but I think positions project managers in a broader way of thinking for future generations within organizations. I want to thank you all for spending the extra two minutes, but that’s that for that. Thank you very much.

Melanie: Thank you very much, Jeff. It was another great session. Your timing, almost perfect there. For those of you attending today live, a big thank you. Thank you for choosing MPUG to go over your skills with today. I have the PDU up here on the screen. For those of you wanting to chat with Jeff after the session, I will open the mic so please stay slightly past the hour with us. And I will, for those of you leaving, I’ll share a link tomorrow with this recording, a link to the upcoming sessions next week, and a quick survey so please share your thoughts again. Thank you all for coming today and we look forward to seeing you at the next session. Thank you, Jeff.

Jeff: Thank you.