PMI-ACP Exam Domain: Problems, Issues, Detection, and Resolutions Part 1

1. Problem Detection and Resolution Section Overview

Problem detection and resolution is not a large topic on the PMI ACP exam, and this isn’t a particularly large section. However, these are important topics that if you know these, it’s only going to help you pass the ACP exam, but it’s also going to help you be an agile project manager. So in this section, we have a lot of information to talk about, but it’s all focused on problem detection and resolution. So we’re going to talk about creating a safe and open environment to surface problems where your project team can communicate problems without any type of fear of backlash. Really important idea. And also we’ll talk about maintaining a visible list of threats and then what do we do with that threat list and how do we keep an eye on that, like a watch list throughout the project, there are four themes in this section that I want you to embrace when it comes to problem detection and resolution.

And that’s one, understanding problems. Two, detecting problems. Three, managing threats and issues, and then four, solving problems. So we’re going to see that theme throughout this section, and I guarantee you’re going to see that same theme on the ACP exam. So pay attention to those four items. Throughout this section, we’ll also look at reviewing lead time and cycle time. This is some terms that you’ve seen throughout the course. We’re going to go back and look at these and talk about what issues or problems may come up tied to lead time and cycle time, and then how long does cycle time take or how long does lead time take.

And we’ll look at a term called defect cycle time that is important for your exam. Tied to this, of course, is whip, that we’ve seen whip several times in the course, our work in progress, and then throughput. So cycle time, whip and throughput and how are they all related to issues and threats or any problems in our project. A graph that we’re going to look at in this section that you really need to pay close attention to is our risk burn down chart, that it is how risks are measured and tracked and eventually how they are mitigated and eliminated throughout the project. And we want to see our risk severity decline the closer we get to the end of the project. That we do not want to see an uptick or a triangulation or a triangular mode of risk where we have a peak and then it drops sharply, that we should see a gradual, steady decline in our risk. And we’ll talk about the risk burn down chart in this section. So pay attention to that point.

2. PMI-ACP Domain Overview: Problems, Issues, Detection, and Resolutions

Welcome to domain six for the PMI ACP exam. This domain is all about problem detection and resolution. So it’s a smaller domain, but it’s still an important domain for your exam. It’s only 10% of your ACP exam, so about 1012 questions. This is all about practices for prevention, identification and resolution of any types of threats or issues that may pop up during the project.

So some tasks that you’ll have to do problem detection and resolution you want to create a safe and open environment to surface problems. Engage the team in resolving threats and issues and then resolve those issues or reset expectations. Maintain a visible list of threats and issues, maintain a threat list and then add any type of remediation efforts to the backlog. There are four themes when it comes to problem detection and resolution. You have to understand the problem first, you have to understand why is this problem existing? What’s its effect on the project, its likelihood of happening? So I have to understand the problem. Of course, before I can understand the problem, I have to detect the problem. I have to know that a problem exists. And then once I’ve detected it and I understand the problem, then I go about managing those threats or issues.

And then that leads me into finally, our goal to solve problems, to mitigate that problem, to solve it, to avoid it, to remove it, whatever the case may be. But those are four themes that we’ll see in this section. Now, all of this is tied to risk management. You know that risk is an uncertain event or condition. In an Agile, a risk is always a negative factor. So what are we going to do with those risk events? How do we respond to those risk events and manage those? Well, that leads into our conversation about probability and impact. So we’ll talk about how do we find probability, how do we find the impact, how do we begin to create a risk score or an expected monetary value? And then of course, throughout the project we’ll do risk identification and tracking that’s it not a particularly large domain, but it’s an important domain. So let’s hop in now and look at this idea of problem detection and resolution.

3. Resolving Issues: What’s the Problem?

Let’s talk about problems. In any project, whether you’re using a predictive approach or an agile approach, you’re going to have problems. Problems are just part of what your job is as a project manager.

Now, in an agile approach we work with the project team, with the developers and the product owner, the customers, the end users, all of our stakeholders to look for solutions to problems. Now of course, the role these individuals play in the project is going to vary. Obviously your development team is going to be more involved looking for solutions than what a customer may be. But we consider all of our resources when we go about finding solutions to problems. Now, two problems that we have to address in a project are issues and risk. Risk are uncertain events that can have a negative effect. In an agile project, risk are uncertain. Events that have not yet happened. If they do happen, they’ll have some effect. And we call this probability and impact and we’ll look more about probability and impact coming up.

Now, issues, these are really risk events that have occurred. So if you have an issue with the code isn’t compiling or you’re having an issue that you can’t integrate at the end of the day or there’s an issue where a team member gets mad and they quit, those are all the end results of risk. Even if you detected those and identified those or not, those are risk events that you now have to deal with the results. So risk are uncertain, they’ve not yet happened. Issues are certain, they’re happening right now. Our first step to find resolution is to truly understand the problem. We know problems can just mushroom if you ignore them.

So problems also have a ripple effect. That’s the integrated nature of project management. If we have a problem in our estimating duration that could have an effect in communication, in cost and even the scope in quality and so on, that you can have a ripple effect or a domino effect into the rest of the project. Certainly what happens in one area of the project affects all other areas of the project. And that’s really a term that we’ve not heard at all in this course. It’s from the PMBOK. It’s chapter four on Project Integration management. That what I do in one area of the project has a direct influence on the remainder of the project. And even though we’re talking about agile, that principle still holds true in an agile environment.

So what I do in time, cost, scope, quality, human resources, communications, risk procurement and stakeholder management, what I do in any one of those areas of the project, any one of those knowledge areas will directly affect the remainder of the project. Most of us, when we see a problem, we think about what’s the financial impact? Basically, the longer a defect or a problem is left unaddressed, the more expensive it’s going to be to correct that problem.

It’s no different than going to the dentist. If you have a toothache and you know there’s a problem there, but you just dread going to the dentist. Now some of us will go immediately to the dentist, there’s a problem, or we’ll go in for our regular checkups and so on and detect that problem. Other people really afraid or fear the dentist, so they put it off until they can’t stand the pain anymore. Well, at some point the longer you wait, the more expensive and the more damage that problem is going to create.

So in Agile, the same is true. We want to be on the lookout for problems and address those early as possible in our projects. Here’s a little curve that shows us where problems are discovered. In green, these are a good location to find problems. In red going to be more expensive and more painful to fix. So basically, early on is good to find problems. They may have a defect. So pair programming, continuous integration, design or programming defect via our testdriven development stakeholders being involved, we do some modeling, maybe even some independent parallel testing. So all of those are early in the curve, the curve representing the duration of our project. Now, as we get later in that timeline and we begin to move up towards completion, it becomes more expensive to fix a problem.

So through a review or inspection later in the project, get some system testing, maybe you found a design defect or requirements defect towards the end with user acceptability testing, those are all going to be really expensive and more difficult than fix if we had located those early in the project. So the interesting thing about Agile, remember, it’s all value driven. So the most important requirements are done upfront and that’s to get value, early delivery of value.

But it’s also important to find and address risk early in the project to avoid those expensive defects and problems late in the project. A term that we’ve seen a couple of times is technical debt. Technical debt is this backlog of work caused by a lack of regular cleanup. So it’s your maintenance and standardization, really. It’s refactoring that we’ve talked about. So technical debt is if you don’t do refactoring or if you don’t clean up that code, it’s going to cause problems for supporting and issue resolution and even the integration could be affected.

So refactoring takes time, but it also saves time and it saves headache. And it’s just a good standard way of integrating our code. Or before we integrate our code, we should refactor. And that time it takes to refactoring should be included in the estimates. We need a safe environment for our development team. We don’t want our team to feel repercussions when they go to experiment. So we want our people on the team to feel safe and to feel empowered that they can experiment and look for better solutions. And then when people get stuck, they should share the problem with teammates. Safe environments are coaching opportunities. So remember in coaching that we meet people halfway. We make them feel safe, that we aren’t telling them what to do, but we’re helping them find solutions. Part of servant leadership. Let’s talk about failure modes. There will be times in a project when things fail. It’s just going to happen. It’s just natural. So we need to consider these five points about people and failure.

That people make mistakes. I mean, mistakes are just going to happen. I’ve made mistakes. I know you have. Well, I don’t know if you have, but you can know that I have. I certainly have made mistakes in projects. It’s natural. It’s just how we react and recover from those mistakes. When we fail as a project team, we want to fail conservatively. Remember that. Fail early and then fail fast and learn from our mistakes. So we don’t want to have a large build up and then fail at the end where we’ve wasted a lot of time and a lot of effort.

So look for opportunities to test and see if a solution will work before investing long periods of time in that solution or that proposed solution. We prefer to invent rather than research. So oftentimes if we go research, we might find a solution. But there’s also the creative side that can we invent and find a better way to do the work. Where creatures have a habit, what worked in the past, we try to make work again. And then often we are inconsistent.

So we don’t always keep the same amount of work hours per day or we don’t always do what we know we should do. So we’re inconsistent. These are all things that contribute to failure. Now that we’ve talked about failure, let’s talk about something a little bit more upbeat and that’s success. As successful people, we’re good at looking around. We’re good at looking to see what other people are doing and what other people have accomplished. I’m a firm believer in that what one person can do, another person can do. Just like this exam. I passed this test because I did it. I know you can do it. Look around.

Look at all the people who have passed this exam. If all those people can do it, you can do it too. You’re competent, you’re smart, you have the abilities, you can pass this exam. Now that is an example of we are good at looking around. Look what other companies are doing. Look what other people are doing. If they can do it, you can do it. As well.

As individuals, we are able to learn. I may not know how to do an approach or agile or a development or a piece of software today, but you can learn. We are able to learn. We’re also malleable, meaning that we can change and adapt. Do you ever meet those people that are just so opposed to a solution and then over time they come around and they agree it’s a good solution. People can change and adapt. As successful people, we also take pride in our work and so we want to have a good solution. We want this to be successful. That’s one of the greatest things.

I like to work with developers because they usually don’t take no for an answer. They hope this won’t work, they’ll make it work. Those are my favorite kind of developers anyway, that they take pride in their work and they’ll figure it out. It’s like a puzzle and they have a unique mindset to figure things out and to make it work and to take on that challenge of making a solution. How do we create some success strategies?

Well, we have to balance discipline with tolerance, so we can’t always be experimenting. At some point we have to move forward and get work done. We start with something concrete and tangible, select the requirements and then we can build on that. We can copy and alter. We also need to watch and listen. So be observant and observe, not just other people, but what’s happening in the project, what’s our workflow like, what’s our lead time or cycle time, how are people responding and working on different days of the week? So watch and listen. And that allows us to copy and alter.

And then we also want to support both concentration and communication that we need to have the opportunity to go to a cave, remember our caves and commons, not an actual cave, but to go to a cave and to be quiet and to think and concentrate. But we also need to be able to communicate. So we need some common areas.

So there’s a lot of different strategies here for providing opportunities or signals or places where people can go to concentrate, but also to have an open environment where we can freely communicate with one another. We want to match work assignments with a person. So remember, our agile teams, though they’re self led so early in the project, you may have to facilitate that process, but we eventually want our teams to step up and to take on that role of being self led. But we want to look at talents and we want to look at skill sets and look at the tasks that we have to do and assign work accordingly.

We want to retain the best talent. As a project manager, you know, who has the best talent on your team, that’s the person you don’t want to slip away. So while we want to foster a good environment and to keep everyone involved and to create synergy and to create a well rounded, well diverse team, there’s also some individuals that have the best talent that are the technical leaders, use rewards, that preserve joy.

And what we mean by this is, yes, rewards and recognitions are good, but make it something valuable make it something the individual is interested in. If you’re just printing out a certificate and you’re the great job for developing. All right? Some people may appreciate that, but it’s not the same as getting a $1,000 bonus or getting two or three days off with pay. So use rewards that preserve joy, that make people feel appreciated, but also to recognize and reward the hard work that the team has put into the project. Ideally, combined rewards.

Now, this one’s a little iffy here, but combined rewards to allow not just one people, not just one person, rather to win. Remember the zero sum Awards, like poker? Only one person can win. So combined rewards, like for the whole team. And then also we get feedback. Remember, our Sprint retrospective is where the team looks back. It’s just the team and the Scrum master or the PM, and they think about what happened in the project, what worked well, what didn’t, and how can we adapt? How can we overcome these challenges in the next iteration?