Tune in to the fifth installment in our 9-part video series with renowned resource management expert, Donna Fitzgerald.
Donna Fitzgerald is the Executive Director at NimblePM. With over 39 years of experience in product development, operations, implementation and research, Donna is widely regarded as a premier thought leader in the resource management and project portfolio management spaces. Prior to founding NimblePM, Donna spent ten-years with Gartner Research as lead analyst in the PPM space where she covered a range of critical topics including IT resource capacity planning, demand management and strategy execution.
In this video, Donna dives into the importance of building a model for what it’s going to take to get work done regardless of whether or not an organization has adopted Agile. You’ll also learn:
- Why you must talk in terms of people and hours to estimate what it will take to create an output
- Why you can’t make a logical decision when you have no basis for an ordered backlog
- Why portfolio management is still the optimum way for an organization to decide where to best spend its resources
Transcript: Does Agile Negate the Need for a Resource Capacity Planning Tool?
One of the things we’ve been talking about resource capacity planning, and a lot of people start to think that Agile doesn’t change or does change that and you don’t need it anymore. In fact, you’ve still got to build a model from start, no matter how you’re doing software development, of what it’s going to take to get work done. There’s nothing fundamental about Agile that actually changes the fact that a human being needs to do a certain amount of work to accomplish it. When we were originally working out Agile, our whole goal was to cut out excess overhead, so let’s go back to the concept that every project manager knows, a work estimate. Now a work estimate always, always, always was just a way to say that I think this activity is going to take x number of hours. Agile, non-Agile doesn’t make any difference. And it’s important to start to understand that from a point of view of planning, so we want to do 10 new things and I’m going to studiously avoid the word “project” so no one gets upset, so no one thinks the wrong thing. I want to do 10 new things and it involves IT. How are we going to do this? And if you immediately think we’ve got products so it doesn’t matter. We just kind of throw it in there somewhere and it magically comes out at the end. Come on. How can that happen? Because we have things called hours and we have things called people. People work so many hours to produce an output. That’s the way the world works. It has nothing to do with whether it’s Agile or whether it’s any other thing. What we have to do, even if we’ve gone to a product portfolio, is we need to first do an estimate of work and I know there’s going to be an issue with whether it’s story points or it’s not story points so let’s try to understand that we want to actually commit to telling management at least some direction of when they can have an output. Now let’s be really, really, really clear. Output equals money. Management gets paid to make decisions about where to spend the money and how to spend the money to make more money. I can’t spend an hour in two places and I can’t spend a dollar in two places. We’re talking absolute hard-core reality. No matter what I do, I’m continuously in a mode of trade-offs.
So now that we’ve agreed that we actually have to talk, how long is it going to take in theory to create an output. What do we do with Agile? Well, I have a lot of clients that just sort of throw a list of tasks in the backlog. And then there’s another thing that they’re going to throw a list of tasks for. So all of us in one team, I’ve got two lists of tasks randomly in the backlog just listed. And I have whatever they were working on because usually with a product most teams that I talk to now are also running some maintenance and enhancements for the entire “product suite” they’re doing. So if we say, M&E = A and we’ll take a new product (that’s B) and we’re going to take another product and we’ll call that C. The goal is to get those at least estimated. I know some of that starts to say that’s not how we do it. We only estimate tasks for the next scrum. But if I do that I have no ability to know whether or not I should insist that we work all on Product 1 or we do some things on Product 2, whether we delay maintenance. What I’m trying to communicate is that it’s not an issue of Agile or not Agile because in theory we’ve cut out all the gratuitous overhead so we are absolutely looking for as much effectiveness in creating this output as we can. But, I’ve got to know what that is. I can’t make a logical decision when I have no basis for an ordered backlog. Now I don’t need every single task in there. Tell me it’s 200 hours, tell me this is a thousand and this averages 500 and maybe I can start to do something. Now this doesn’t mean that on a Tuesday something here isn’t going to jump the queue because it’s absolutely critical. That’s life in the real world. It doesn’t matter if it’s Agile, it doesn’t matter if it’s Waterfall, it doesn’t matter what it is. That’s life in the real world, but management needs to know because what nobody ever talks about because there’s almost an assumption that it’s all for internal use, but in theory that Product 1 is actually going to drive revenue. We’ve got 500 hours of stuff that just makes the wheels move a little bit better in the corporation. We’ve got Product 1 that is actually going to generate revenue. It’s a new digital business and we’ve got Product 2 which is an internal enhancement. And guess which one management might actually want done. Guess what? Product 2 (I have a very short example here) may not make sense because it may be that this stuff we can redefine this and accomplish everything we were going to do with this by thinking smarter about this. We cut that two hours, we rationed that by being very, very smart and making sure that there was nothing unneeded in there and we delivered Product 1. That gets everybody happy; it doesn’t in this case tell management what we’re going to do. We have to do it for each product across the list of proposals.
Now obviously some of what we do, before we get into a lot of detail, is you do high level. There’s nothing wrong with high-level modeling because, as I said, this may turn out that we can cut this quickly. So we start looking for what’s driving it. Be clear. Politics may be driving it. I can’t speak to that. In a lot of organizations politics equals money, so it doesn’t matter. All we’re trying to do is drive the highest priority. We’ve always been trying to do this. There are techniques that many Agile organizations are doing now that look like they’re more efficient and more effective by building a software factory, but from a portfolio management perspective, from an overall value generated for the corporation, not so much because a lot of what portfolio management actually talks about is still the optimum way to make financial decisions about where a company wants to use its money.