Episode 234: Agile and Project Portfolio Management - Part 1 (Free)
This episode is sponsored by The Agile PrepCast for The PMI-ACP® Exam:
One of the seemingly larger challenges out there for corporation that use both Agile and Project Portfolio Management (PPM) is integration of what seem to be two very different philosophies. But more than that... you will have to overcome three fallacies about Agile and PPM.
The first fallacy is that people think that agile project management doesn't provide executive visibility, the second that they don’t have reliable “Scheduled Finish Dates” and the third that Agile and traditional practices simply aren’t compatible.
David Blumhorst (http://www.linkedin.com/in/dblumhorst/) begs to differ. He co authored several articles and a white paper on this topic and he outlines a simple and straightforward way to realize the best of both worlds.
This is part 1 of our interview with David. In it we discuss how integrating Agile with into a PPM framework is no different than integrating a more traditional project methodology, but that there are four four exceptions, which we’ll look at in detail. And then we move on to 5 areas of estimation how a PPM framework with standard metrics can be created for Agile. We will talk about the first two, which are Scheduled Finish Date and Percent Complete.
Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.
Cornelius Fichtner: Hello and welcome to Episode #234. This is The Project Management Podcast™ at www.project-management-podcast.com and I am Cornelius Fichtner. Nice to have you with us.
One of the seemingly larger challenges out there for corporations that use both Agile and Project Portfolio Management is integration of what seem to be two very different philosophies. But more than that, you will have to overcome three fallacies about Agile and Project Portfolio Management as well.
The first fallacy is that people think that Agile projects don’t provide executive visibility, the second that they don’t have reliable “Scheduled Finish Dates” and the third that Agile and traditional practices simply aren’t compatible.
David Blumhorst begs to differ in regards to these fallacies and says: ‘Nope, it ain’t so.’ He co-authored several articles and a white paper on this topic and he outlines a simple and straightforward way to realize the best of both worlds.
This is Part 1 of our interview with David. In it we discuss how integrating Agile into a Project Portfolio Management framework is no different than integrating a more traditional project methodology, but that there are four exceptions, which we’ll look at in detail. And then we move on to 5 areas of estimation how a Project Portfolio Management framework with standard metrics can be created for Agile. We will talk about the first two here – Scheduled Finish Date and Percent Complete and then continue with the third, fourth and fifth next week in Part 2.
And now, let’s pour some Agile oil into that Portfolio water and see if they do indeed mix. Enjoy the interview.
Female voice: The Project Management Podcast’s feature Interview: Today with David Blumhorst, Vice President of Solutions and Services at Daptiv.
Cornelius Fichtner: Hello David. Welcome to The Project Management Podcast!
David Blumhorst: Thank you, Cornelius. Glad to be here.
Cornelius Fichtner: So we want to talk about Agile and Project Portfolio Management. My first question to you is: What’s your personal interest in this topic? Why talk about, write about Agile and PPM?
David Blumhorst: So this goes back ways because I’ve been in project management a long time since the late 70’s mostly in technology whether it’s in engineering and development areas or in IT, I’ve actually ran IT and was an executive in the IT Department at PeopleSoft. And my whole time as a practitioner, we were always following the more traditional Waterfall style project management methodologies and I kept saying there’s got to be a better way. There’s got to be a better way.
I was at a PMI Chapter Meeting several years ago and was talking to a project manager who run construction projects, typical construction projects and we were talking methodologies. I said: “You know, the thing that gets me about the standard Waterfall stuff is when I’m managing a software project and when push comes to shove and I’m up against a deadline, there’s not a dependency I can’t figure how to break to make it work. Requirements are not yet done, fine! Let’s start on the modules where they are done.” So I realized early on that it’s easy to move things around and still make software work and basically, get it done and get it done on time.
The traditional Waterfall method wasn’t serving that. It comes out of the construction industry. It makes sense there. By the way, the construction guy replied to me and said: “I understand you can do that in software. But if I’m building a house, I can’t put a window in if a frame is not there.” Honestly, very hard dependencies whereas in software, there are very soft dependencies and I thought, there’s just got to be a better way.
Some of the first better ways that came along were extreme programming and that was really the start as I recall at least in my memory of Agile and as they came out with that, there is a group who came out with the Agile Manifesto which really spoke to me as it spoke about involving the customer in the process directly instead of just getting the handwritten requirements, delivering software instead of just delivering the spec. It was all about making things work instead of making sure we fill out all the check boxes and dot our I’s and cross our T’s in the project management process.
So that’s really what got me started into really taking a good hard look at Agile and liking what we do with Agile. And it really is all about almost as it says at the beginning of the Agile Manifesto finding better ways not just an on how to deliver the software but there were a lot of things in technology that were finding are amenable to Agile.
Cornelius Fichtner: And how did you get started in Project Portfolio Management? How does that play into your personal background?
David Blumhorst: So the PPM started when I was running the IT department at a company called Clarent back in the late 1990’s and early 2000’s. We grew very rapidly as a lot of companies did back then and we ended up, I think it was like 22 offices in 16 countries around the world. I’ve got projects spinning up left and right to roll out infrastructure, roll out a new software. I was like: “Okay, we’ve got to get a handle on this. We got to understand where our investments are being made, which ones are worth making. We can’t just do all of these at once. Even though by then we have gone public, raised a bunch of cash which was common in the late 90’s. You still can’t do it all once. You got to make some decisions.
And so, we started a project management office there and a steering committee to go with it and a process for selecting which investments we would make and therefore which projects we would spin up to deliver those business investments as we went through the years there. That was the start of it. I realized that that was in the IT space anyway – a new and growing area and a needed area. So IT wasn’t always in a position of saying yes to everything then not being able to deliver everything.
I started doing some consulting in that area. I also then ran the ITPMO at PeopleSoft where we had a pretty large portfolios you might imagine and a lot of requests for work that we had to sort through and became very interested in and started obviously working on how do you both figure out which investments to make and match that up with your supply of resources both dollars and people to make sure that we’re doing the right things.
It’s often said that project management is about doing things right. Those kind of PPM processes are about doing the right things, making the right investments. So that’s where that came from.
Cornelius Fichtner: Okay! So that’s how Agile and PPM meets your background. If you’ll look at Agile and PPM just on the surface, there is sort of a discrepancy there. Since we’re going to try and match those two, let’s talk about the one question that maybe on most people’s minds: Are Agile and traditional practices compatible?
David Blumhorst: To me, that’s kind of an ‘of course’. When I think of Agile, it’s another way of delivering business value. Traditional projects are a way of delivering business value. As project management geeks lose focus, lose sight of that sometimes as we start thinking: “Oh I’ve got this method and it’s Agile, Scrum and we do sprints and releases and do stories or I do the PMBOK® Guide method and we gather functional requirements and do text specs and do development and testing.
But in both cases, we’re trying to achieve something. We’re trying to deliver software in a lot of cases. We’re trying to say: ‘Turn on that new web channel for sales so we make more money in the company. There’s a business outcome at the end of the line.’ Both of these are just ways of getting to that business outcome at the end of the line. Agile takes a much more iterative approach so you’re delivering business value on a regular, hopefully frequent basis. Traditional practices used to take more of a big-bang approach. They’re mixing it up with some iterative stuff as well.
To me of course they’re compatible. They’re both looking to deliver business value and we want to be able to measure what’s the business value we’re trying to deliver, when they are going to deliver it, how are we going to make sure it’s right, that kind of stuff.
Cornelius Fichtner: Alright! You’ve given me a perfect segway here because what I’ve done before our interview, I’ve reached out to my followers on Facebook and said: “Hey, I’m going to be interviewing David and we’re talking about Agile and PPM. What are your questions?” and we got one from Elizabeth Harrin from London. She has also been a guest on the program before.
Here it goes, she says: How can portfolio management which takes a long-term strategic view based on outcomes fit with Agile methods which are typically time-boxed over short periods and focused on outputs? I think in order to answer that, we have to do a whole interview on this topic, right?
Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.
- Last updated on .
- Hits: 18350