PMI-ACP Exam Domain: Continuous Improvement

1. Continuous Improvement Section Overview

One goal of all project managers is continuous improvement. And so we want to continue to get better and better and better. And so that’s a goal that we have in our projects, but it’s also a goal that you’re going to see in the ACP exam. So we need to talk about, about continuous improvement and how it’s directly tied to exam and project success. And that’s the goal of this section. So we’ll begin by talking about continuous improvement in quality, that quality is prevention driven, that we don’t want mistakes to come into the project. Then we have a similar term, that’s quality control. And that quality control is inspection driven. So we’re going to look at quality, quality assurance and quality control. And how do those affect continuous improvements in our project? There are three success criteria that I’m going to give you right now for continuous improvement, that you want to know these for your exam. And so they’re really important.

How do you know you’re successful in a project? The project got shipped, the leadership remained intact, and the team would work the same way again. So those are three items that tell you where you’re successful. So know those three items. We’re going to talk more about them in this section. There’s a term that we often have in project management, having a post mortem. A project post mortem. What we’re done, what went well, what didn’t, an opportunity for lessons learned well, a little bit different and agile. And that’s we’re going to have a project pre mortem. So we’re going to look for failure before it happens, that we’re anticipating or imagining the worst case or failure. And then what can we do to react to that and to mitigate that before it happens?

So we’ll talk about that in this section. We’ll also look at retrospectives, not just for our project, but for people improvement. So what’s going well with our team? How can our team improve and what should we be doing differently? So we’re going to look at people improvement. We’ll talk about retrospectives. We’re also going to talk about Sprint reviews. And then we’re going to move a little bit into the PMI code of ethics and professional conduct, because that’s tied to our role as a project manager, in that we have some organizational rules and policies in PMI and both where we may work. And there will be a few questions on your exam about the code of ethics and professional conduct. So we’ll hop in there and take a look at that. All right, let’s get in here and knock out this short section and keep moving forward. See you in just a minute.

2. PMI-ACP Domain Overview: Continuous Improvement

I know for many of you this is your favorite exam domain because it’s the last exam domain and it’s continuous improvement for the PMI ACP exam. So in this little domain, it’s only 9% of your exam, about eleven questions. And it’s all about people, processes and product. So what are the tasks for continuous improvement? One periodically review and tailor the process. Improve team processes through retrospectives. We want to seek product feedback through frequent demonstrations. We do that in our reviews. Create an environment for continued learning and then use a values dream analysis. That’s not a dream analysis. Here’s some process improvement. Use team analysis to improve processes. Spread improvements to other groups in the organization. So even I need some continuous process improvement. All right. Moving forward with our lessons learned, at the end of each iteration we do a lessons learned. We allow lessons to be applied in the next iteration and then lessons are repeated until they are learned.

Continuous improvement in quality. These are tied to one another. That you may recall that quality assurance is prevention driven, where quality control is inspection driven. Now, our goal is to not allow mistakes into the product, but we do testing to find mistakes. So we do testing to ensure they are not released out to the customer or escaped defects from our project.

Now, one approach for continuous improvement is called kaizen. That kaizen is a Japanese word meaning change for the better. It’s small incremental steps. So we do this. One way that we do this is by plan, do, check, act. So you plan it, then you do the work. You check your work and you act upon those results. In Agile, you may see this as planned, develop, evaluate and learn. But kaizen is an approach we can do to take small incremental steps. All right, let’s take a small incremental step now and finish this domain about continuous improvement in Agile.

3. Implementing Continuous Process Improvement

One of our goals in an agile project is to have continuous process improvement. In this lecture, we’re going to talk about how do we improve the processes in an agile project. Let’s begin by talking about tailored tailoring, the processes and agile. Before we go about tailoring processes, though, it’s really important for us to agree and to understand that we must embrace a proven method and understand that method before we go about tailoring and changing the agile processes. So just a word of warning for your exam know the process and understand it before you go about changing it. Yes, we can adapt agile for each environment, but this introduces some risk with Tailoring because we’re changing a proven process, a proven method, to something that may be somewhat unknown or uncertain. We have to consider the risk and reward when we go about changing and tailoring processes. Now, rather than create a standard process, if we’re going to tailor or fine tune, it that we say every project has to do the process this way. It’s better to create processes for each project as needed. So we have some risk and reward and some trade offs.

But what we’re actually doing is with each project we tailor and adapt based on the size and the complexity of the project, rather than create one process that’s unique or a standard rather for all of our agile projects in the organization, as I mentioned, there’s risk and reward of process tailoring. So first, embrace traditional agile processes, as I’ve mentioned. Then you can go about changing and tailoring. But we want to understand why do you want to change and adapt? What’s the benefit that this is going to bring you? Is it worth whatever risk you may be exposed to by changing and adapting these processes? Of course you can use a hybrid model.

A hybrid model is where you take elements from different agile methods and you combine those to best fit your environment. And really, there’s no right or wrong hybrid model. You’re really tailoring processes to what works best for you and your team and your organization. The whole goal is to get the thing done. The second goal, of course, is to do things well. So you do the right things, but do the right things well. Systems thinking is an approach where we first understand the systems level environment, where we understand how it should operate, how it is operating, and then what can we do to improve upon those efficiencies? We do this by classifying the projects based on complexity and uncertainty. And what we’re classifying really are what are the project requirements and what’s the technical approach. So what’s the best approach to reach the end result of the project, to reach the goals of the project. When we do systems thinking and we do tailoring of processes, we’re looking for a balance between simple and highly chaotic. So it’s a really broad window here.

When we go about systems thinking and tailoring processes. We do want to do some process analysis before we go about changing processes. So we want to review and diagnose issues that we are having with our Agile methods. Why are we having these problems? Are people not embracing it? Do they not understand it? Do they not like it? So let’s dig in before we start tailoring. And so we want to find what does and does not work. We do this before we tailor a process, but also after we tailor a process. We want to see if the changes that we’ve made, are they having a positive impact on the project? Are the processes working now that we’ve done the tailoring? And if not, how come? What do we need to adjust and adapt? We also look for anti patterns of methodologies.

This is just a big way of saying we’re looking for approaches that don’t work for our project or our organization. And we want to keep an open mind here. We don’t want to say that these just don’t work. It’s why don’t they work? Why aren’t they being embraced? Why are they not successful? So we want to look for processes where it’s a onesizefitsall where you have to use this process the same way on every project. It’s kind of a command and control approach. We also look for intolerant processes, any processes that say you must, you have to, you’re required to. There’s no opportunity for tailoring. All right, those are anti patterns, heavy methodologies where the process or the approach is so heavy and what you have to document and who you have to talk to and who has to sign off. That’s not what agile is. We don’t want Agile to grow into this heavy stuffy methodology.

And we certainly don’t want embellished methodologies where we have a meeting to have a meeting, or you fill out this form to start this work item to report to this. That’s just crazy. That’s not what Agile is about. Well, at the other end of that spectrum, we have to look out for untried methodologies. So if we’re trying something new, we need to track it and monitor it and see if it works. We also want methodologies or look out for methodologies or approaches that have only been used once before. So just because you used it once before and it worked, doesn’t mean it’ll happen again in the future. So it’s okay to use new methodologies and it’s okay to use methodologies that are fairly new, but we continue to track and to monitor those to see what effect they have on our project. There are three success criteria that we need to pay attention to in our Agile projects.

But also for your exam the project got shipped, that means we’re a success. The leadership remained intact, we’re a success. The team would work the same way again. That’s a success. Those are three key points for successful projects. Know those for your exam project got shipped, leadership remained intact. The team would work the same way again, there are some success patterns to pay attention to as well. At our methodologies interactive facetoface communication is the cheapest and fastest channel for exchanging information. We’ve seen this a couple of times. Excess methodology, weight is costly. Larger teams do need heavier methodologies. And by methodologies we’re talking about process, procedure, rules, adherence. More formal projects with greater criticality require greater ceremony. So again, projects that are important, they have a high priority that they’ll be critical. If it fails. It’ll be a disaster. If the project fails, well, then we need a more formal approach in our planning, in our iterations, our daily stand up, our sprint reviews and retrospectives. So more ceremony that it’s not as casual as we might be in a smaller project that’s not as critical to the organization. More about methodology, success patterns, feedback and communication reduce the need for intermediate deliverables. So feedback, communication, it keeps us going. Everyone’s in sync. We understand the definition of done discipline, skills and understanding. Counter process formality and documentation. Remember in Agile we want working software rather than documentation. So by having disciplined skills and understanding we don’t need as much formality. It’s one of the pleasures of working in Agile. Efficiency is expendable on bottleneck activities. Just because you can be efficient doesn’t mean you’re productive. So if we have a bottleneck, it’s not that someone’s not working efficiently, it’s there’s some other reason why. Well, it could be someone is not working efficiently.

It could be a competency problem or it may be the system, it may be the software or the activities that are happening where that bottleneck activity exists. Value Stream Mapping value stream Mapping this is a lean manufacturing technique that’s been adapted by Agile. It’s really it’s a visual map of your whole process. How do you move through the project? And we’re looking for delays, waste and constraints for your exam. Know how to create a visual stream map. You identify the product or service to be analyzed. You map out the current processes, whatever steps or queues, delays. How does information flow through that process?

So you map it all out, you make a picture of how does the process work and then you review the map for anywhere there’s delays or waste and constraints. Then the next step is to create a new value stream map. So how would you like it to work? And then you develop a roadmap for creating this ideal optimized state. And then you revisit and you refine and optimize. Here’s an example of a value stream map. So this is the business unit and order in all the way to order out. So it shows iteration planning and then it shows the test code and so on. And how we get from the beginning all the way to the ending. We’ve probably have all heard of a project post mortem where you review the project once it’s done. This is a project pre mortem where it aims to find failure points before even happen. So what you do is you imagine the failure, you generate the reason for failure, consolidate the list, and then revisit the plan. So this is a visioning exercise where we’re trying to see where are their failure points before we get there.

4. Working towards Continuous Product Improvement

At the beginning of an Agile project, so much is unknown. There’s a lot of uncertainty about what we are about to do. But through progressive elaboration, through iterations and adaptive planning, we formulate our project plan. We formulate what we’ll do in this iteration. Well, that formulation is based on the product requirements. It’s based on the prioritization of our user stories and features. Well, as the project evolves, so too does the product. So part of an Agile project is continuous product improvement. That just like projects, products are iteratively and incrementally approved. This is a collaboration between the project manager, the product owner, and the development team that we’re all working together to create a better product to accomplish the vision and the goals of the user or the customer of the thing we’re creating.

One of the first steps we do for product improvement is a product review that we have a product feedback. So what’s happening is the development team is creating the product in an iteration. At the end of that Sprint, we have a Sprint review. And in that Sprint review, we do a demo. So that’s where we get our initial product feedback. Now, based on what the product owner tells us and any customers that tell us that are in the demo, in our Sprint review, we take that information into the next meeting, which is the retrospective. Remember, the retrospective is we consider the feedback and we look back at the project, we look back at the last iteration and how can we improve upon that? So that’s one of our key places for product reviews and to get feedback. If you’re familiar with W. Edwards Dimming, you probably have heard of the PDCA.

The plan do check act cycle. Well, Dimming is kind of the grandfather of quality. And this was an approach that he used for quality, that you plan your work, you do your work, you check your work, and then you act accordingly. So this is another way we can get project feedback is plan, do, check, act.

PDCA might see that on your exam. Probably you don’t need to know Dimming, but be familiar with PDCA plan do, check, act. When we look at our product, we want some feedback from our team, from our product owner, our customers, or end users or whatever representatives are in the meeting to experience the demo. So we’re looking for feedback. So questions that we ask or we look for answers to in this meeting, does it meet the customer’s needs and expectations? Does it work? And are all conditions met? So if we met everything that constitutes success, did we break anything while building this? How can we improve efficiency?

How can quality be improved? How can we share lessons learned? So these are all questions that we ask of the product team, the project team that we’re asking in demos and in our reviews and in our retrospectives. In our demo, we’re doing some feedback or we’re gaining feedback. So what are we demonstrating early in the project? Maybe a prototype, a simulation? And then eventually we can actually do a demonstration, a software demonstration. So these are just three product feedback methods. At the end of an iteration, we want approval.

So our sprint reviews, we want approval. And that sets us up to go into sprint planning for the next iteration. So remember, a sprint review is held at the end of a sprint. It demonstrates the new incremental build. What did we do in the last one to four weeks that our sprint was we want our business partner to approve the work. And then that allows us to go and start the next sprint. And technically, what we’re doing before starting the next sprint, we have our retrospective. And then we do our sprint planning meeting. And then the next sprint can begin. You.

5. Leading Continuous People Improvement

In this lecture, we’re going to talk about continuous people of improvement. I think for a moment, all the way back to the beginning of the course, we talked about people product and process. So we’ve talked about process improvement, talked about product improvement. Now let’s talk about people improvement. We want to help people to improve in our agile projects. Let’s begin by talking about our retrospective. Remember, our retrospective is with the development team or the delivery team, where we talk about what’s going well, talk about what could use improvement, and we address what should we be doing differently.

So these are three questions in the retrospective that we ask and we discuss with the team why do I even need a retrospective? Retrospectives help the team to improve productivity, improve their capabilities. We look for opportunities for quality improvement and also capacity improvement. We want the team to be more capable and to have more capacity, to do more work efficiently and accurately and to reach our goals in the project. When you’re preparing for a retrospective, there are some good ideas that you want to do when you start the retrospective, especially early in the project and especially on your PMI exam. So know these recommendations for setting the stage for a retrospective. First off, encourage participation. We want people to participate. So part of that is we have to facilitate the participation.

We have to encourage people to participate and get them involved early and let them know it’s their retrospective. We’re just the facilitator. The next thing we do is we set the ground rules. So we set expectations, we set the ground rules and then we move forward. We define what people want from the retrospective. So it’s not just our meeting as the PM, what’s the project team? What do they want to get out of this? So the development team will share what their goals are in the retrospective. One way to facilitate this and keep people involved just have people check in with one or two words. They might just say present or happy or excited or angry.

Who knows? But just a quick way to start the meeting is where do you stand on the project? Just one or two words. Ask the team to commit, to focus. Let’s focus on this retrospective and get it done and share and go to the point and let’s go. We might also want to look at the ideas. Are people explorers? Are they just shoppers? Are they vacationers? Or do they feel like a prisoner in the project? So an explorer is more like a leader and someone that’s excited and taking charge. A shopper. They’re being selective about how they participate a vacationer. They don’t really care. They’re kind of laid back and relaxed in a prisoner, they feel like they’re a prisoner. They don’t want to be there. We also need some working agreements for the retrospective.

And that goes back to our ground rules that will all agree to play by the rules and participate and make this a valuable conversation. In the retrospective, we want to extract data, so we ask questions. We facilitate people contributing, and we want people to contribute. So what are the meanings of their contributions? There are some approaches that we can take to gather data. One way is to create a timeline. So let’s say your sprint lasts for four weeks.

So let’s create a timeline over the last four weeks as a group and show what did or didn’t happen in the last sprint. Triple nickels. This is a little game you can do where you have one approach, says you have five groups, but it’s just groups spending 5 minutes on five ideas five times. So see, it’s three fives. Pretty ingenious, right? So you have groups spending 5 minutes on five ideas five times. Color coded dots. This is a way, especially if we have a timeline, where we can use some color coded dots to track the team’s energy when it was high or low throughout the duration. You could also just use a whiteboard, make a timeline, and create kind of a histogram of when were you high, when were you low? As far as your emotions or how you felt about the project. Or you could do mad, sad, glad. So we have that timeline and we look at different events and how did that make individuals feel?

And then that opens up the idea of gathering data because people are contributing and talking about where they mad, sad, or glad? Some other approaches here. You could do a satisfaction histogram. This is just a bar chart showing satisfaction about any particular areas or issues. A team radar is an assessment of performance improvement. Where do we need to improve and what are we doing well, locate strengths? What went well or not so well in the iteration. You might also see this as a SWOT analysis where we look for strengths, weaknesses, opportunities, and threats. SWOT and then like to like, compares reactions to different iteration events. So you went from like to love to hate to indifferent like to like. We do want to generate some insights in the retrospective or based on what we’ve gathered. So we evaluate the data, so we make insights based on the data. We do this with the team. This isn’t a solo activity for the PM. This is done with the project team.

Another way to gather data is to do brainstorming. We’ve seen this a couple of times over the course. Quiet writing. Take five or 10 minutes and people brainstorm on paper, then share the results. Round robin go around the room. Everybody takes a turn yelling on an idea or a thought or a free for all. Just everybody yells everything whenever they feel like it. Another exercise you should be familiar with is The Five Whys. Sounds like a rock band, doesn’t it? But the five whys is we ask why five times? And what this does is it helps us find cause and effect causal factors.

So we’re looking for the root cause of a problem. A similar cause and effect exercise is a fish bone analysis. It looks like a fish bone, the blue box. You see, that’s the effect that we’re trying to solve. And the little boxes are causal factors or contributing causes. So it just is a way to facilitate the conversation of what might be contributing to the problem in the project. This is also known as an ishikawa diagram. So it’s a fishbone diagram, a cause and effect diagram, and it’s also known as ishikawa. Based on a retrospective, we decide what are we going to do? So let’s create an action plan. In our action plan, one approach we can take is to use what’s called short subjects.

Are we going to keep this approach? Are we going to drop it? Are we going to add new approaches? We can do smart goals, specific measurable attainable, relevant and timely. Will. We do circle of questions where each person asks a question on how to resolve or improve upon an issue or an area of the project. And then the next person of the circle answers the question. We can also do some retrospective planning games. How to reach process improvement goals? So we take what our goals are and then how are we going to plan accordingly?

Recall that a game is just a way of saying how do we achieve something? It’s a planning process. Then we close the retrospective plus or delta what to do more of and what to do less of. We can say what’s helped hindered and then a hypothesis to act on those items that we got out of the retrospective. The team can also discuss the benefits of the retrospective. And this gives a great insight to what we want to do next time in the retrospective.

How can we improve upon our return on time invested? Finally, we have some appreciation where the team members give appreciation to one another based on efforts from the last iteration. You might do team self assessments. This is an opportunity for individuals to score their performance and their self in the project. So this is done individually. Or you could do it with a team as a whole. So you have thinking, collaborating, releasing, planning and developing. So you score each one of those categories and then that gives us some goals to improve upon the next generation.

6. Continuous Improvement Section Wrap

All right, great job reaching the end of this section about continuous improvement. And so let’s take a recap of this very short exam domain and what you need to know for your PMI ACP exam. We talked about continuous improvement in quality. Recall again that quality assurance is prevention driven. Quality assurance is planning for quality. Quality control is inspection driven. And, of course, you can’t inspect quality into a product.

You can expect the quality to see if it exists in a product, but inspection doesn’t improve the quality. Now, in our projects, we have three success criteria. The project was shipped, the leadership remained intact, and the team would work the same way again. So pay attention to those three success criteria for your exam. A particular term that you need to know for your test that we saw in this section was the project pre mortem. Instead of a post mortem, we do a pre mortem. It aims to find failure points before they actually happen. So imagine the failure upfront generate the reason for failure, we consolidate the list, and then we revisit the plan.

So we’re trying to anticipate problems so that we can mitigate the problems before they actually come into fruition. In this section, we also talked about retrospectives and how retrospectives can help us with our people to allow our people to be improved. So we asked questions like what’s going well? What areas could use improvement? And what should we be doing differently? It’s not an accusation, but it’s a way to introduce the topic and to see what is or is not going well. Retrospectives, of course. Give us four things improve productivity, improve capabilities, quality improvement, and capacity improvement. All right, great job finishing this short section. I’m sure you’re ready to get this thing over with. I am, too. We’re really close to the end of the course, so let’s just wrap it up. Keep going. You can knock this out today. I’ll see you in the next section.