Tune in to the second 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 reveals the heuristics that can help make resource capacity planning easier. You’ll also learn:
- The Pace Layering concept used by Gartner
- What qualifies as a system of record versus a system of differentiation or innovation
- How to get control over your systems of record to free up time for innovation
Transcript: Heuristics that Can Help Make Resource Capacity Planning Easier
Are there any heuristics that can help us make resource capacity planning easier, especially when we’re starting out? I’m a big believer that if we have to reinvent the wheel and think about everything from the bottom up, it’s going to be really difficult. Now I’m going to show you something that I found to be one of the foolproof, easiest ways to actually think about this and it’s actually based on a concept called paste layering that Gartner uses. So within an IT context, it starts out by saying that many of the products or IT applictions, because it’s important if you’re going to products that it’s still part of this, so systems of record. What’s a system of record? A system of record is your general ledger system, it’s your payables system, it’s your supply chain system if you’re talking standard, it’s those systems that you spend a lot of money on, a lot of time on, but nothing about that system is unique in terms of its application. Every company has a general ledger. It also doesn’t generate revenue; it doesn’t generate customer satisfaction. It’s an internal facing system. Conventionally when you talk to IT organizations, roughly 70 percent of the work done in IT is to support the internal operations of the company, so we’re going to call it at a systems of record level. Our next box is called systems of differentiation and we’ll say 20 percent. This is where we’re starting to talk about something that actually is tailored to your industry and is a competitive advantage. Tailored to the industry isn’t as important as is competitive advantage because this is where every dollar spent I make money off of it because it allows me to do something unique.
The third box and ultimately most important for the future is systems of innovation. Just say 10 percent. So what does this mean? One of the things that back when I was with Gartner we talked about was if we’re trying to redesign our business practices to allow us to become more innovative or allow us to become a digital business, we’re going to need to get money from somewhere. We can’t just magically pull it out of the air. The logical place to pull it in the IT budget is out of the systems of record. Back of the envelope there has been a lot of discussion that reducing that 70 percent to 40 percent would give us enough money to both operate the company and start doing the investments we need to do. This is extremely important because what it says is, “I need to control this.” Now one of the things back in 2009 I wrote some research that said to get control of this, treat each of these as a product. That’s a great fantastic concept, but what it says is there is no such thing as a help ticket. There is no such thing as work someone requests where I’m going to absolutely fulfill that request. If we start treating things like a product, that means if I get five I wanted two, turn it upside down and paint it green, whatever it is. If I get 10 requests, I in the role of a product manager, which I’ve actually been, I’m going to take those 10 requests and possibly come down to one request that is well thought out that will bring in the capability that we might need on a system of record because we all know that the vendor upgrade cycle may be too far out. I once saw features that the client desperately needed that I was going to add to a product when I worked for Oracle and my governing board said, “Those are five years too late, Donna.” We never could have lived without them.
So, yes there are needs to change here but we need to treat it as a product that supports our company and not a variety of IT systems and we need to provide product management on there. Now, what does that get us? If we have 100 people there and we’re going to take that down to something, maybe the first year we’re taking it down to 90, maybe the second year we’re going to take it down to 80. Okay that’s moving it down a little. How do we do it? By reducing the investment. That starts to free up time for systems of innovation. Now, systems of innovation are really what we want quickly. Again, this is very, very important because we don’t want things that are not mission-critical getting in the way. So if we do a system of innovation, in theory we care about time to, we’ll call it market. That’s the traditional word, but time to implementation, we want as little as possible, i.e. things from this area to delay us from getting this in production.
Now, all of this, and systems of innovation for most companies this is so new that they tend to take this as a dedicated basis and it may be a 10-1 payoff, but I’m really not going to spend a lot of time talking about it because those are very clear, very dedicated resources. I don’t include the Google approach giving every developer a Friday to do innovation into what I’m talking about. I don’t know very many companies that can afford to do that. This is a very dedicated group. But here we have a chance to start to take this, we’ll say, up to 40 percent by freeing resources. Now, if we continue with our current approach where this is driven by project enhancements and tickets, all of which by our current perspective we are obligated to do, we’re never going to get it out. So if we start rationing the headcount, go to products, use product managers so that we know we can get a handle on the demand. Start putting the resources here, start making sure that they are as close to dedicated as we can, this means that every person on this for the time they’re required, cannot be less than half-time and I’ve talked to developers who say be very clear. I want as much concentrated time as I can and that means Monday, Tuesday, half of Wednesday. If you ask me to do something else it’s half of Wednesday, Thursday, Friday and the real developer answer is heck, if I’ve got 16 hours of code, just get out of my way. I’ll work all 16 hours in one day and then I’ll take Friday off. Come on. We’re talking about developers here.
So, this approach, it looks radically different, but it’s a model. It’s a quick heuristic model because when you look at your total headcount you can say arbitrarily, I’m not going to spend more than 60 percent of my resources on that. I am NOT and if I’m going to budget 60 percent, I’m actually going to budget it. Whatever decision I make, that’s where I’m going to hold the number. With the clients I’ve worked with I really don’t care where they start. You can start at 70 and 20 and 10 and just start to get familiar with what that looks like. Get the controls in place and then make a decision. Do you have mission-critical things that are coming out of nowhere? So you need to start peeling off some of the resources. Getting control of this, hiring product managers, reducing that gives you an opportunity to start slow but make continuous progress.