Episode 235: Agile and Project Portfolio Management - Part 2 (Free)

Play Now:

This episode is sponsored by The Agile PrepCast for The PMI-ACP® Exam:

This is part 2 of our interview with David Blumhorst (http://www.linkedin.com/in/dblumhorst/) in which we discuss that combining Agile and Project Portfolio Managment is not really that much different than if you used traditional project management approaches.

In part 1 we talked about agile project portfolio management. We discussed the four exceptions you need to be aware of when integrating agile project management with PPM and then we looked at how you need to adjust your PPM framework to include include 5 standard metrics for Agile. They were Scheduled Finish Date and Percent Complete.

Here in part 2 we will move on to the other 3 metrics and then David and I open up the white paper from Daptiv and look at the graphic that clearly shows how straightforward integrating Agile and PPM can be. (A link to download the white paper is on our website. Please grab it from there.)

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner: Hello and welcome to Episode #235. This is The Project Management Podcast™ at www.project-management-podcast.com and I am Cornelius Fichtner. Nice to have you with us.

This is Part 2 of our interview with David Blumhorst in which we discuss that combining Agile and Project Portfolio Management is not really that much different than if you used traditional project management approaches.

If you remember in Part 1, we discussed that there are four exceptions you need to be aware of when integrating Agile with Portfolio Management and then we looked at how you need to adjust your PPM framework to include 5 standard metrics for Agile. We looked at the first two and they were Scheduled Finish Date and Percent Complete.

Here in Part 2, we will move in to the other 3 metrics and then David and I open up the white paper from Daptiv and look at the graphical representation that clearly shows how straightforward integrating Agile and PPM can be. And by the way, a link to download the white paper is on our website so you may want to grab it from there and have it at the ready as you listen to this so you can actually see the graphic.

And now, class, take out your blenders and let’s all mix Agile and PPM. Enjoy the interview.

Podcast Interview

Female voice: The Project Management Podcast’s feature Interview: Today with David Blumhorst, Vice President of Solutions and Services at Daptiv.

Cornelius Fichtner: Third metric: Scope Changes.

David Blumhorst: Scope is much more fun in Agile.

Cornelius Fichtner: Yeah! Because it changes constantly.

David Blumhorst: Because it changes constantly. Traditional is meant to be the “We’ve got a plan in place. We’re delivering in 8 months. Boy, if you change your mind on anything, that’s going to change your date. It’s going to change your budget. We got problems here and we’re going to fill out this lengthy form called the Scope Change Request and it’s going to go in front of the steering committee. Duh-da, duh-da. It’s going to get funded and in a month, hopefully, we’ll have that scope change approve and we move forward.”

In Agile, your scope is the total story points of all the stories in the project. If the customer comes up with something new they want to do, add a story. You have now changed the scope. If you don’t have time for it, you might deprioritize something as you go along. But scope changes are simply adding, subtracting, changing stories around and they flex as you go.

Because you are iteratively delivering, say, every couple of weeks or every month, it’s much easier to take a look at what’s coming up instead of saying: “It’s setting stone, we just finished the design. We’re halfway through the coding. If you change now, we have to go back and change the design and change the stuff.” Instead of saying that, you can say: “You know what? In 2 sprints out, we should be able to squeeze that in, we’ll just move some things around, may be deprioritize something,” or “we found that this story was actually going to be less points so and so anyway. Let’s squeeze that in there.”

Because you’re constantly doing a full cycle if you will, each release of design test deployed. You don’t have that locked-in spot where you have to freeze everything and say we’re going forward from here. So it’s easier to put scope changes in. It’s easier to adjust for scope. And from one of the whole purposes behind Agile is its flexibility and like I said, you do that simply by adding stories and deciding if you just want to add to the total stories or deprioritize some stories to keep the scope to the same timeframe and total size.

Cornelius Fichtner: Fourth metric that you mentioned in the white paper: Actual Cost Versus Budget.

David Blumhorst: Yeah and every project has a budget and actual cost. When you start a budget, when you start a project, you’re typically going to fund it. So you have done your estimating whether it’s by doing some planning and thinking about what the total story points might be or in traditional, laying out a high-level task plan and figuring out what resources you need, what capital you need, et cetera.

Both Agile and traditional are: “Here’s my project. It has a start. It has a finish. What is it going to take to do it? That’s my budget. The actual I’m recording as I go and I’ll be logging expenses. Say, we bought the hardware. We bought the software licenses, et cetera.” The major expense of course in any project is the labor which is where we differ a little bit.

In the traditional project methodology, we will be logging our time for actuals and applying a rate to that to come up with the actual labor cost versus the budget. In the Agile, assuming we have a dedicated team, we don’t need to have to log their time for that. If they are a dedicated team, we just take their blended rate typically as opposed to actual salary. But take their blended rate. Put that against the project and just rack that up to get the actual cost.

In mixed environments where the Agile team isn’t really dedicated or there are players that aren’t dedicated, they probably will need to log their time again but it would be just against the Agile project not against each task in the project because you’re not looking at the task in a project. In Agile, they’ll tell you how you’re doing against your estimates. That’s the story points calculation so you could actually log that time simply at the project level to get your actual cost.

Cornelius Fichtner: And the fifth and final metric you discussed is Project Health.

David Blumhorst: Project Health is always a fun one.

Cornelius Fichtner: Red wire, red, green and orange, right?

David Blumhorst: Red, yellow, green or in Europe now, they like to go with red, red, amber, green, RAG, it sounds better. Project health in my mind has always been somewhat subjective. There are objective measures we’ve used such as in the traditional model, what percent complete are we against what percent complete should we be at this timeframe. You can do the same sort of thing with Agile if you want by looking at the story points. What percent complete are we versus what percent complete should we be given the elapsed time of the project. That’s a simple way to do it.

Most good project health measures, I got to tell you as a practitioner, I like talking to the project manager, talking to the executive stakeholders, talking to the customers looking to see if there are any issues that are coming up and making it a more subjective measure. I know there’s a lot out there about making it an objective measure whether it’s based on a percent complete, on earned value and its metrics, the CPI and SPI, those are all good objective measures to check with but I also like to have good project managers on the case of Agile, a good Scrum master or a good product owner in that case, give me your good subjective feel. And in that case, both Agile and traditional are the same. How are things going? Are we going to get there on time? Are we going to get there on budget?

And most importantly, a meter of project health and this is something you can’t really measure with those objective standards. Are we going to deliver the business target, the business value we were expecting to deliver? It’s something I say about projects over and over again. If we hit the scope right, if we do it on time, if we do it on budget and then at the end of the day, the customers says: “Yep! Yeah, you did all that but it didn’t work for me. It’s not what I need.” We threw away the time and money. It really didn’t work. So health to me, big sense is: Are we heading toward the business target we had in mind that we set up on this project and on this journey?

In many ways, Agile is better equipped to do that than a traditional Waterfall method because it breaks its stories down by business value and business things that can be delivered. If I deliver something early in the project, that looks like it’s not quite working out. We can then still have time to adjust because we’re not doing this big thing at the end. So it’s easier to adjust if we see health slipping, it’s easier to adjust if we think the business value isn’t coming through the way we need it to than it is in a traditional, that’s the still the project health to me is more of a subjective call even though we might have some objective measures behind it.

Cornelius Fichtner: Let me throw something out there because when I originally read about these 5 metrics in the white paper, and now especially after listening to you, I got the feeling that it’s been confirmed, there is no difference. The metrics are the same. All we have to do is we have to figure out way of how do we get these metrics so that when an executive looks into our portfolio, they can get visibility into the project. They want percent complete. They want to know about scheduled finish date. They want to know about actual cost versus budget. We know how to do it in traditional very well because we’ve been doing it for years and years and years. And now in Agile, well, there are just different ways of approaching it and different ways of figuring out what is the metric here. Is that impression correct?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.