4.1. DEMAND-SIDE RESOURCE MANAGEMENT

John nodded, so Chris continued. "When it comes to managing the demand for resources you could easily confuse yourself with a broad array of potential resources. So, just like with classifying projects, we strongly advise portfolio managers to stick to a few. We recommend focusing on skills—the people you can use; the technology environment—the systems and/or platforms that are required for project success; and facilities—the physical space and infrastructure needed both to deliver projects and that will be impacted by project outputs."

"Okay, okay, that's great." It was clear that John was totally engaged in the conversation now. He was scribbling notes on the paper napkin. "So, just to recap, I should only worry about demand for three types of resource:

So, how do you propose we plan for and manage skill resources?"

"John, you're as sharp as a nail," interjected Bill. "I believe that Chris was just about to tell you that!"

Chris continued as John listened with his pen poised to make more notes. "The classic resource constraint is not having enough people with the right skills or experience to deliver project outputs. As in any problem-solving exercise, the first step is to gain a clear understanding of the scale of the problem. What we recommend as the best way to assess potential resource constraints is to get your most experienced project managers to undertake a review of all boulder and rock project plans and, based on their experience, provide estimates of required skill sets over the lifetime of each project. What you're looking for is a list of key skills sets in terms of proportion of full-time employees (FTEs), the timeframe they are needed for the project and the magnitude of any identified constraint. . ."

"Hold on, you've lost me." John looked puzzled. "Give me a specific example so I know what you mean."

Bill stepped in, "Okay, so what Chris is describing is actually a two-stage process. First, get one of your trusted project managers to review a boulder project plan and make a list of all the skill types needed to deliver it, broken down into monthly blocks. There's no need to be any more granular than monthly, otherwise you'll start to get lost in the detail. Of course, the project will need a project manager, and if it's a boulder, probably also a project administrator—both for the full life of the project, say twenty-four months. Let's say this project involves all your retail stores—how many is that?"

"Oh, let me think. . . thirty-six."

"Great, so let's say that you'll need the attention of each store manager for at least one full day a month for the first nine months, rising to two full-days a month for the next six months, reaching a peak at implementation time of one week a month, and then only half a day a month for the final months of the project. You do the same for the store operations manager, retail systems analyst, and so on. That's stage one of this process and you will have lists of required people skills for each project for each month over your portfolio planning horizon.

"The next stage is when your office combines these skill estimates to get a high-level view of the portfolio-wide resource demand, by month and by skill type. This allows you to model resource hot spots across the portfolio within the planning horizon—a hot spot being defined as where there is likely to be a resource shortfall in the order of magnitude of two or three times the expected need. And, this is a key point—you may want to write this down." Bill couldn't help smiling as he tapped the paper napkin in front of John, which was already filling up with notes.

John didn't respond. He was waiting to hear the next gem from Bill. "Keep things simple by focusing only on potential resource shortfalls with an order of magnitude of at least two. Don't forget that this is a strategic planning exercise and one of the key outputs from this process is to trigger meaningful conversations with the key decision makers. Your office—the portfolio management office—doesn't have any executive decision-making powers. I like to think of your role as that of air traffic controller. You marshal the facts, present them in a logical manner, and provide options with implications so that decision makers can make informed decisions. We all know that in some circumstances a gut decision may be the right one to make, but only after we have reviewed all the facts. You don't see air traffic controllers working off their gut, right?"

"Hold on, Bill. Let's keep our feet on the ground here. I take your point and, no, I don't have any budgetary control over the projects within the portfolio—that belongs to the business sponsors as it should. However, what if I'm wrong? What if my so-called experienced project managers who review the resource plans mess things up? How stupid am I going to look then?"

"John, this is the whole point of the exercise. It doesn't matter if you are wrong. One of the reasons we recommend keeping these planning estimations at such a high level is that you avoid wasting time and energy debating silly points of detail. You're only focusing on resource constraints that are significant and that will only have a significant impact on significant projects (the boulders and rocks). You shift the debate away from whether your portfolio planning skills are good or not, and onto the real issues of how best to allocate limited resources across the organization to deliver the maximum value."

"Wow—I get it. This is fantastic!" John was smiling again.

"Great! Think of it this way. If you are facing a potential portfolio of a hundred projects and you go through this exercise—analyzing resource requirements across the enterprise and map potential critical constraints—and you facilitate a debate within the executive team, which results in only eighty projects being given the go-ahead, but with enough of a resource contingency to significantly increase their chances of delivering the expected value within the planned timeline, then you have avoided a whole world of pain—both for the business and for yourself. You know as well as I do that once projects start, people become emotionally invested in them—they become a part of their sense of success. So, if a few months down the line you pop up and declare that the business doesn't have enough resources to deliver all hundred projects, what do you think those who are invested in the twenty candidates for the chop are going to think of you? It's never an easy discussion, is it? This way you can neatly side-step the emotion and do the cutting before anyone has invested too much of their ego in it."

Bill reached under the table and fumbled with the lock on his briefcase. He clicked it open and pulled out a few sheets of paper. "Look here—I brought along a few items that I thought might come in useful tonight." He slid a sheet of paper over toward John. It looked like a page from a color presentation. "This summarizes what we've just been talking about. The point is that, at your level of the organization, you need to keep things at the aggregate level. You can keep this."

"Bill, if this was the only thing you told me about tonight, I think I'd forever be in your debt. Only today I had our senior VP of store operations pretty much spitting at me over my recommendation to cut one of his pet projects. If only we had done this earlier. . ." John looked wistfully at the sheet of paper.

Figure 4.1. Figure 4.1

"So, let's run through the other resource constraint areas. Next we have the technology environment. John, are you with us?"

"Sorry, I was just thinking how I could have totally taken the wind out that SVP's sails if I had that skills analysis on my desk. Go on, I'm listening—tell me about technology constraints."

"So, another key area of potential constraint is in the ability of your technology environment—the capacity of your computer systems or platforms to cope with the demands of your project portfolio. Again, the principal here is to keep things simple, otherwise you could be lost in a blur of techno-speak. The way I recommend portfolio managers to approach this is to get the technical experts to analyze plans for the number of times a project impacts—or touches—a specific technology environment or domain in any month. It's the same as with people skills, you want to keep the timeframe in the 'per month' ballpark and simplify the technical interaction to something like 'touch.' You'll need the technology expertise to understand whether two or three touches is significant in a time period compared to, say, twenty touches, which may have little or no impact at all."

"But isn't that rather subjective?" John interjected.

"Of course it is but, as with skill constraints, what you're really seeking to achieve is an informed debate with your technology experts. Listen, John, your role at one level is no more—and no less—than a facilitator of resource allocation decisions. You don't make those decisions. What you do is present the facts and describe the implications in terms that the decision makers can understand. Sure, you should also make recommendations, but most of these are going to be pretty self-evident and those that aren't, well, those kinds of decision can only benefit from being debated in an open forum—which you provide."

"When you put it like that, my role sounds rather exciting and in the thick of things. After that meeting with the SVP of retail ops today, on top of all the hassle I was getting from the project managers, I was starting to wonder whether I really wanted to keep going. Thanks, Bill. If nothing else, you know how to spin things the right way!"

Bill smiled and looked down at the papers he had pulled from his briefcase. He plucked one from the pile and handed it over to John. "This is how a resource constraint analysis might look. It's summary data and you can easily see that information engineering resources are severely overbooked. Like I said, this gives you the necessary ammunition to go and talk with the right people."

Figure 4.2. Figure 4.2

"It's my pleasure, John. I love this stuff. Done right, it can transform the performance of an entire enterprise. Anyway, we have one more resource constraint to discuss: facilities. By this I mean physical infrastructure, networks, office space, real estate, and so on. When looking at this I break it into two components: facilities required for delivery of the project, and facilities that are going to be impacted by the output of the project. So, to illustrate, the delivery component includes office space—desks—for a project team, network connections, office support—printers, faxes, computers. Outcome facilities means, for example, real estate that is going to be acquired or divested as part of delivering a project, like a new or expanded call center. The way I suggest you analyze this is to look for blocks of greater than ten people that need facilities for more than three months. So, as an example, a new project starting in Arizona may draw in a team of fifteen people for six months, five from Denver and ten from New York. What I've found is that trying to analyze moves that are shorter than three months or for less than ten people you get lost in the details—plus, these are usually capable of being absorbed in the normal course of business."

Bill sat back and took a drink from his glass. Chris sat forward and continued. "So, John, there you have the three key demand-side resource constraints: skills, the technology environment, and facilities."

"Thanks, Chris. I understand those—but what's your advice for managing these constraints from the perspective of the portfolio office? Bill has already eulogized over meaningful discussions with the decision makers, but aren't there things I could be doing before running off and seeking decisions on cutting projects?"

"John, of course there are. As we see it, you have four levers at your control to manage capacity constraints. These are: