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

4. Finding and Detecting Problems.

Continuing our conversation about detecting problems in Agile projects. Problems are going to happen, and sometimes they’re really obvious what the problem is. Other times we have to be Sherlock Holmes and do a little detective work to find problems, defects in our project. And a lot of times we have to do that by inspecting, working with our team to get feedback, asking questions. So these are all approaches that we’re going to talk about in this lecture. One of the first places to begin looking for problems is just use your daily stand up. Recall one of the questions, one of the three questions in the daily standup, are there any problems or impediments to the team members? So asking your team members, asking the people that are closest to the work is one of the first steps to detecting problems in an Agile project.

And this just makes sense, right? As the PM, we’re not doing the work we are facilitating. We’re being a servant leader. So we need to ask, well, are there problems? How can I help? And the team has to trust you enough to tell you what the problem is. Remember, we need that safe place. We need a safe environment where the team feels that they can experiment or come to you with a problem without a fear of repercussion.

If the team is going to feel like they’re threatened or coerced because of the project manager’s reaction, when there is a problem, they’re probably going to be less inclined to share the problem with you. And that just makes things worse and worse. As we lead to this conversation, we need to talk about or review these two terms, lead time and cycle time. Lead time is how long something takes to go through an entire process. So, for example, from concept design all the way to shipping, now cycle time is a subset of lead time. So cycle time is how long something takes to go through a part of the process.

So, for example, from just coding to testing. All right, I’m going to use a metaphor here to give something that we can all relate to. We’re going to build a house. This house has several phases. So we start with the planning phase where all the blueprints and the permits and so on are created all the way to the last phase, which is landscaping.

Now, within this construction of building the house, we have planning, and then we have the foundation, and then we have the framing, and then we have the plumbing and the electrical, and then we have the sheet rock, and then we have the interior, and then finally we have landscaping. All right, so there’s all these different phases. Lead time would be how long it takes to go from planning all the way to landscaping, let’s say six months to create the whole house.

Cycle time is a subset of lead time. Then we would say, well, how long is it going to take to go from the foundation all the way to plumbing and electrical. So it’s just within the entire project. So what this does is it helps to see whether it may be bottlenecks or opportunities for improvement or you’re trying to predict when you’re going to use resources or need resources or have key deliverables.

So these are all tied to lead time to go through the entire process. Cycle time, how long does it take to go through a portion of the process? Here’s another way to look at lead time and cycle time on our friend the Canban board from backlog development, user acceptability testing, deployment, that’s lead time, all four processes, all four phases. I should say cycle time would be just how long to go from development to deploy. So it doesn’t count the backlog. So it’s a portion. Now project cycle time is the project duration is the cycle time for the entire project. So that may seem a little contradictory. What we just looked at, we said lead time was the whole thing. Well, project duration means I want to go from here all the way to done.

So project duration is the cycle time for the entire project. The average amount of work the team can get done in a time is also cycle time. So how much work can you do? Like we saw in our Canvan board, how much work can go through development, UAT and deploy? Productivity is the rate of efficiency at which the work is done.

Now productivity could also be the amount of work done per team member. So productivity, how efficient, how quickly can you get the work done? It could also be how quickly does each individual team member do the work, how productive is each individual? Now defect cycle time, it’s the amount of time between when the defect was discovered and when it was fixed. The longer your defect cycle time, the more expensive that defect is going to be. Because there may be other things that have been built on top of that defect that now it has ripple effects. Defect rates are all about defects that slip by the testing team. And these are called escaped defects. They’ve escaped the entire process.

Now escaped defects are the most expensive defects, not just financially, but it could also be a reputation or a confidence level. So escape defects, no good. You want to try to capture defects within the project. The defect rate measures the frequency of defects found. So how many defects do you have that’s your rate. An increase in escape defects, that’s a problem that’s going to tell you there’s something happening with the testing or even with the development. Why are these defects getting out to your releases? Variance analysis now variance, it’s just the difference between what was planned and what was experienced that we are planning on the project being done by July 31.

Well, we’re getting into the middle of July and it looks like more likely it’s going to be done at the end of August. That’s a variance. So we said middle of July. Now we’re looking at the end of July. Now we’re looking at the end of August. You could also have a cost variance or even other tracking items. You could have variance in scope. Whenever you have a variance, there’s some causal factor. There’s something contributing to why the variance happened. And there’s a couple of terms that you need to know for your exam. All right, we have an average day to day differences. Some days, your team, they’re just going to be on fire. They’re just going to be working perfectly and smoothly, and things are just going well. And other days they’re going to be a little bit more sluggish and not as productive.

That’s just people. It just happens. We have up and downs in productivities, so you have an average day to day difference. All right, that’s to be expected. Then we have special causes of variances. Something unusual causes a problem. You had a power outage for a couple of days. Three of your key team members caught a flu. Those are special causes. Anything that’s not an average day to day, that’s a special cause. When we address variances, we often look for trends. So a trend is where we’re seeing a pattern of events, could be good or bad.

A trend in variances mean there is whenever a certain condition or circumstance is created, it’s going to create a variance. So you can begin to predict what’s going to happen in the future. When we look back and we do a measurement of past experiences, those are called lagging metrics because they’re behind where we are right now. We’re looking backwards to see what’s happened. Leading metrics is where we begin to predict based on what’s happened in the past, where we are now, we begin to predict what’s going to happen in the future.

So those are leading because they are ahead of where we are now. Trend analysis. Our goal with doing trend analysis is to predict performance or problems so we can mitigate those or avoid those in our project. Within our project, we also have control limits. Now, a control limit is an upper and lower control limit. Basically, it’s boundaries.

It’s a window that we want performance to stay within. Now, you would say, why do I need an upper control limit? Lower control limit I can see, but why upper? Well, it may be unrealistic to say we need 100% accuracy without one defect at all. We might be able to achieve that, but it may take us longer and be more expensive to reach that 100% accuracy. So we might say we want a 95% accuracy, or we want no more than two defects per release or whatever the case may be.

And then a lower defect. We would say we don’t want any less than this amount. If we have greater than this amount then we’re in trouble. If we have less than this amount then we’re doing okay. Basically, it’s a window. You don’t exceed it and you don’t go below it. Whip and can bands are a form of control limits. Remember, in our whip, is our work in progress or can ban we say how many items can be in development? Development could be in testing at a time.

5. Managing Project Threats and Issues

In all projects, we need to manage threats and issues. Threats and issues are often hidden, or they sneak in or they come about because of conditions or changes in the project. Well, risk, we know, is an uncertain event or condition. And I want you to grab this term, this idea that risk, threats and issues are anti value. So much of your exam and so much of agile projects are founded on the idea of delivering value. So threats, issues, and risk are anti value. So we want to get rid of antivalue. Risk, we know, is an uncertainty venter condition.

So risk, it’s antivalue, it is a threat to the project success. If you recall in our product backlog, that we have all of our user stories and we prioritize those with the product owner, we should also prioritize our items, our stories that have the greatest risk. And so we want to move those up into the top portion of the backlog as well. Our goal is to not do a whole bunch of work in the project and then come to one key risk that could threaten all the work that we’ve done. It’s better to take those risk laden events and do them early, so we can fail fast, fail early, and attack those risk events and learn from what’s happening and mitigate those or resolve those early in the project.

And this is the idea I was just talking about, that we do some backlog grooming for risk, where stories are ranked, as we know, on business value, what’s the priority, what’s the business value? But we should also rank them according to a risk level. And we’ll talk about the risk level here in just the next slide. Next couple of slides. The ranking is subjective. It’s often based just on gut feelings or even preferences. The return on investment for the project, you can really break that down per item. So you think about, what’s the ROI and the whole project? Well, if we decompose that, each item should also have a return on investment. So that helps for the product owner to rank the items based on ROI.

The reason why we want to know the ROI, we want to see if the risk is in proportion to the ROI. In other words, do they balance? Is there risk and reward, or is the risk really big concern and could threaten the success of that deliverable or even the success of the whole project? Now, when we look at a risk score, a risk score is the probability of the risk happening.

Times the impact of the risk happening equals a score. Now, that score, if we’re dealing with ROI or financial values and probabilities, we’re calling it the expected monetary value. So EMV the expected monetary value is the impact of the risk event, times the probability, and then that will show us what the expected monetary value is for the event. Now, these are all things that threaten the project. So here’s an example. We have identified a risk that its impact, it will cost the project $45,000. Its probability is 30%. See, it’s uncertain. We don’t really know if it’s going to happen or not, but there’s a 70% chance that it will not happen. But there’s a 30% chance that it could happen. So our impact 45,000 times 30% equals 13 five.

That’s the expected monetary value, that’s the value of that event negative on our project. And you do that for each identified risk in what’s called a probability impact matrix. So here’s a probability impact matrix. You have the risk events listed in the first column. Then we have our probability, what we think the risk events probability will be times the financial impact and you multiply that across and that gives us our expected monetary value. Ex dollar sign V. That’s how you abbreviate expected monetary value on your exam. They’re not going to show you that I just did that for habit and it saves a little bit of space there, but it’s expected monetary value. Now I want you to notice risk C in this example its probability is 10%, its impact is a positive 25,000.

So its expected monetary value is 2500. In Agile we only consider negative risk events. Now I included a positive one here just because in the Pinbox they tell us they being PMI, tells us that some risk events are positive. So just in case, just to make sure you’re well prepared on your exam, if you get one of these tables and you have to find the expected monetary value for each risk event, make certain the impact is negative or positive. So in this example, A, B and D are all a negative amount. So negative 6000, negative 15, negative 34. Risk C is positive. Just a little hint. I’m not saying you’re going to see that on your exam, but I want you to be well prepared to pass. All right, so what do we do with this information?

Well, the sum of the expected monetary value for each risk event, in this case it’s negative 52,500. If we add all of those up, negative 52 five. That’s the risk exposure for this project, negative 52 five. The inverse of that is a contingency reserve, the amount of funds that are offset just to address these risk events. So we would take 52,500 and that’s our contingency reserve. You’ll probably have two or three questions about risk, probability, impact and expected monetary value. I really doubt you see the positive risk and I doubt you see anything about contingency reserves on your exam. But be familiar with probability impact and expected monetary value. There is another way that we can look at the scoring of risk events and that’s risk severity. Instead of doing probability and dollar amounts, we do a scoring system.

So what we do is we use a simple scale like low, medium, high or one, two, three, where one is low, two medium and three is high. So we would say, what’s the probability of this event happening? We could say the probability is that it’s high. So I’m going to give it a score of three and its impact, I give it a score of one. So then our risk severity, rather than risk score, our risk severity would be three times one equals a three. So this is another approach.

You just have to pay attention to the scoring. So, for example, if we had a medium probability and a medium impact, that would be a two times two would be four. So the risk severity, two mediums is greater than a low in a medium, because a low in a medium one times three is three mediums, two times two is four. Or you could have a medium and a high two times three is six. And yes, you could have three times three, as nine would be the most severe.

All right, so you might have one or two questions on that business as well, but I think it’s pretty straightforward. Finally, I want us to look at the idea of a risk burn down chart. And we’ve talked about burn down charts with the amount of activities that we have to do in the project, and we see those go down with each sprint. A risk burn down chart is very similar. It’s our risk exposure based on where the risk happened in the project.

So over time, we mitigate, avoid or overcome the risk events, and this trend goes down. As we get closer and closer to the end of the project, the risks have been eliminated from our project. So it’s a stacked area of the cumulative project risk severity. It’s also a visual communication of risk events. When will these risk events happen or have they happened?

And then the severities are plotted on top of each other because we’re looking at the cumulative exposure from zero to 30 there on the Y axis, and then risk should diminish. So the chart diminishes as well, that we want to see a downward trend in our risk exposure. And that’s the whole goal up front. You’ve got lots of risk exposure because there’s lots of uncertainty. As you work closer and closer to the end of the project, we’re more and more certain that we’re able to finish the project.

6. Managing and Solving Problems

Most project managers that I meet are really good at solving problems. They like to play chess or do crossword puzzles or play different games because they’re just good and they, they like the challenge of solving problems. Well, that’s what we’re going to talk about in this lecture, is how do we solve problems in an agile environment? So we will use some of those natural skills.

But we want to invite people to participate and use people on our team and our stakeholders that they own the project. And so they should be involved in finding problems and finding solutions for problems. Problem solving is continuous improvement. We use problem solving games to fix the problem before it happens. We try to anticipate the problem and look for a solution. And this was what we talked about a little bit earlier, like risk identification and then finding a solution so that the risk never enters the project. We talked about the daily standups, a great place to begin our problem identification or risk identification. Are there any problems or impediments in the way of the team iteration?

Reviews and retrospectives are a great way to look for problems and to do continuous improvement. Recall that the review is where we do a demonstration and we get feedback from the product owner and perhaps our customers. So the review, the outcome of that, that feedback allows us to plan on how we will fix or improve or build upon what we’ve done. The retrospective is just with the development team and the project manager. It’s where we take a look at the feedback. But we also consider what happened in the previous iteration. How can we perform better? How can we build upon that? So reviews and retrospectives are a great place for continuous improvement.

And then before we start the next sprint or iteration, we have a planning session. So how will we achieve our goals? How will we improve upon what we’ve done in the next iteration? As I mentioned at the beginning of our discussion, we want to engage the team in problem solving. The team really owns the project. It’s their self led, they’re motivated. They want a positive outcome for the project. So we ask the team for a solution.

So what we do is we’re creating some consensus on that there is a problem, we need a proposal or solution and let’s figure it out and go get it done. Also, by accessing the team or engaging the team, we create a broader knowledge base that we’re using everybody’s brain to contribute to the solution. And then team solutions are often the most practical because they’re the people that are closest to the problem. They’re the ones that are going to have to implement the problem. As a general rule, when consulted, people work hard to generate good ideas.

Asking for help shows confidence. And then we seek others to see what ideas they have. And then we can model ourself after those individuals, we can emulate desired behavior so we see what other people have done and then we can act accordingly. Now, some considerations for team engagement now involve the team where it can be most helpful. We only want to solve real problems, so it’s not an opportunity to come together and gripe. We want to look at problems that could be a threat to the project’s success, so solve real problems. We need some team cohesion if your team’s in the middle of storming where they are doing a power struggle and seeing who’s going to lead and who’s going to follow, not always the best time for the team to come together to do problem solving.

Whenever changes come into the project, when the backlog has changed and new items find their way into the backlog, want to check in with the team, usually in our sprint planning and then follow through throughout the iteration.

When we have a solution to a problem, we want to ask and check in and follow through and see how that plan is going and what we can do as the project manager to help. Finally, we need a consideration that some problems just cannot be solved. It’s just part of life, it’s just part of projects that even with team engagement, some problems you just won’t find a solution to. So you can work around these problems or take these problems, negotiate to take these problems out of the project. And we always track and monitor. We have a watch list of problems, so we track and monitor and see what the outcomes were and that allows us to do some lessons learned on if we encounter that type of problem before. What worked in the past may work in the future. You.

7. Problems, Issues, Detection, and Resolutions Section Wrap

Great job finishing this exam domain about problem detection and resolution. Let’s come in and just take an overview or a quick recap of what we’ve talked about. In this exam domain with problem detection and resolution, there were really four themes that we need to keep in mind. You have to understand problems, detect problems, manage threats and issues, and then solve problems. We also talked about issues and risks. Remember that a risk is an uncertain event or condition that has not happened yet. It’s uncertain, but an issue is a risk event that has come true. Now, whether it was detected or not doesn’t matter.

The issue is now happens. You have to deal with that issue. In this section, we also talked about variance analysis. Remember, it’s the difference between what was planned and what was actually experienced. We talked about cost variance, schedule variance, and then other key performance indicators or other items that you’re tracking. In this section, we also looked at the causes of variance. Remember, we had just your average day to day difference. We have good days and bad days and ups and downs, just the average. And then we talked about special causes of variance. So something unusual that caused a fluctuation or a variation in what we were experiencing.

So it could be you have a power outage or an individual is sick or whatever the case may be, that that is an unusual, it’s an exception to the norm. And so that’s a special cause variance. And pay attention to that for your exam. Throughout this section, we kept an eye on risk and recall that the backlog that we groom the backlog for risk because we groom it based on business value and ant value, and risk is antivalue.

So we do some type of a qualitative and in some cases a quantitative analysis of that risk. And then we look for opportunities to solve that risk early by grooming the backlog and introducing those items into our project early so that we can look at the return on investment, we can look at the business value or the antivalue and attack risk accordingly. Now, an important chart that we looked at in this section is the risk burn down chart. Remember the risk burn down chart? It’s just a visualization of risk from early in the project to late in the project. And that over time, we should see those risks diminish. So this chart, as we see in this example, the exposure for the project should begin to get more and more reasonable as we move to the project completion. So pay attention to the risk burn down chart. All right, that’s it. Great job on finishing this section as we talked about issues and risk and resolving those in our project. Good job. Let’s keep moving forward. Almost done.