Tune in to the seventh installment in our 9-part video series with renowned resource management expert, Donna Fitzgerald.
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 where she currently serves as the Executive Director, Donna spent ten years with Gartner Research. As a lead analyst in the PPM space, she covered a range of critical topics including IT resource capacity planning, demand management and strategy execution.
In this video, Donna explains why the business case is actually the secret weapon that ultimately drives resource capacity planning. You’ll also learn:
- Why the business case needs to be a collaborative process that creates accountability for what is requested and what is delivered
- How to avoid sunk-cost thinking and assess what a solution is worth
- How to determine the viability of a business case in 20 minutes or less with one simple question
Transcript: The Secret Weapon that Drives Resource Capacity Planning
A common question from clients who are embarking on doing resource capacity planning is how to get the initial forecasts on the contents of the portfolio to put into the system because obviously you’ve got this great tool you need to go to FTEs, what are you going to do? There’s kind of a short-term fix and the right fix. For a moment I’m going to draw out the right fix and you’re probably going to be surprised at what this is. So the secret weapon that ultimately drives resource capacity planning is the initial business case. Now, this is not a one-page, I’m not talking 35 pages. This is usually, according to Donna, is about five pages but, more importantly it’s a collaborative meeting. The biggest problem with everything in IT is the high-level swag. I want XYZ. I think it should cost a million dollars. I think it will take 20 people. And then in the old lingo when the project manager got there, they threw out all of that and they started again doing full-blown requirements. We just saw a project that was supposed to be that big became that big. You can’t run a business that way. What we’re aiming for is some level of accountability of what is requested and what is delivered.
This doesn’t take a lot of details so I want to tell a quick story. I was doing a training class for a client and I asked then on business case through resource capacity planning and I asked them to get a real example of something that they didn’t know how to justify. They knew it was important because it was part of the strategic plan but they didn’t know what to do with it. So we brought in eight people, somebody from finance, somebody from purchasing, a couple people from the area of requesting, a couple from IT and we had the users say, this is why we’re asking for this. Let me be clear. We killed it in the first 20 minutes. How can you kill a whole business case in 20 minutes? By asking one question. What is it intended to deliver and why is it going to solve the problem? In this case it was a request for an IT application. I asked the question, what’s it going to do that nothing does now? The answer is we already have the reports in Excel. Are you going to get any more information? Uh uh. It’s going to be the same. Why are you doing it? Because it’s prettier and it’s in support of the strategic objective. I said, I don’t think it’s worth the time or effort or anything and everybody sagely nodded their head. We then said, so what’s the real problem?
Well, in their case it turned out the real problem had to do with labor negotiations and who was doing what in the shipping area. Not even IT at all. Fundamentally a lot of this of what we’re trying to smoke out is, is the business case solution solving the problem and how much is it worth? If everybody in the room tells you the business case is solving the problem, the problem is well articulated and everybody agrees it’s worth some amount of money, we’ve got so much information. We can then do a high-level, and I’m using old words but it doesn’t really matter, we’ve still got to figure out what the work estimate is and how fast and compare that to the how much is it worth. Because one of the things that happens here is everybody agreed it’s worth a million. This comes out at $2 million. Is it worth a million more? If this gets to the point where it’s going, a lot of people get sucked into sunk cost logic. What we’re really talking about it, is it worth it at double the price. Maybe yes and maybe no, but we can start to get this. Once we’ve got this confirmed at a high level (now Murphy’s Law still pertains) we all understand reality, we’re not there yet. We’re just trying to get to the point where we have the capacity. We need to know how many projects against our capacity, but we need some decent data. Now, am I proposing that this has to be done for everything? No. Some things are small. Some things really don’t matter because we’re not going to start them in the first six months and we can catch up with it later. But we have to know this level for anything we’re starting, we’re planning on starting. By the way, there’s a secret to that. If we have to know this and actually be able to answer those questions and people can’t, then they’re not ready to start. Just think, we’ve saved six months of futile effort.
I’m really not joking about this. I had one client who, for political reasons, the company started a CRM project but none of the users wanted it. The project manager for that project had 17 people assigned to him to do the CRM package. No one wanted it. No one would make any decisions. So by the time I arrived to do an assessment, I found out he was down to three people on his team and had quietly reassigned all the other people on his team because there was no work.
This is really, really important. Is there a reason to do this? Do we believe we can actually create it for a price that it’s worth? This is critical. If a user or a requestor can’t tell you how much it’s worth, not you and IT answering how much it will cost, them answering by any context they want, how much they want to pay. Now, we’ve got this and let’s say this came in at $5 million. Essentially IT is coming in with a no-bid. They can’t figure out how to come anywhere near the million. And, you know what? That’s the right answer. This is an important concept because all too often work flows into the IT pipeline. It’s not ready for prime time. It’s not well thought out.
IT functions as a delivery organization. In fact, many parts of IT are literally called IT delivery of something that should never be done in the first place. The front end of this, now when we get capacity numbers, we really understand. We can look anybody in the eye and say, this is the business case, this is what it’s worth, we have actually come to an agreement that we have a tolerance of another half-million. If it’s two, we can’t do it. We’ll cut scope and this is how many people it is. And that then can be compared against all the other things that might happen because the dollar can only be spent once and if something is not ready for prime time, why start it? There’s no urgency on something we have questions about. We can always put it in later by canceling something else not quite as valuable.
So, there are ways to get to capacity but it’s all in getting better control of the front end because other than that, let’s be honest, you’re making up the numbers and the more numbers you make up, the more you’ve unintentionally for the best of all reasons, started to undermine the thing that is really the linchpin of your portfolio process.