CHAPTER 3

Resource-Driven Planning

While it is tempting to assume that limited resource is a subset of a cost constraint-sometimes it just isn’t. If you only have access to five people and a cat, then a project planned for six pairs of hands is not going to work! At least not in the way you thought it would. The simple fact is that money and resources are rarely as interchangeable as sponsors like to believe. As we see in the following examples, sometimes no matter how much money you have, the resources—whether it be people or physical assets—are just not available.

Planning Around Scarce Resources

The change of signaling technology from analog to digital was implemented to improve the safety and throughput of trains on the East Coast mainline track in the UK. Critical to the project was the ability to prove that the new signaling system was safe and that there could not be any ‘live-side’ failures. Getting it ‘about right’ was unacceptable; peoples’ lives were at stake. The process for testing was well defined and non-negotiable. The only people who could execute and sign off the tests were called first principle signal engineers and were very special–you could not go out and rustle up a few more, no matter how much budget was released.

The rail authorities had set a provisional completion date, but nobody knew whether the testing could be completed by then. There was a strong temptation to just get on with it, but it was a very public project, and a large number of stakeholder groups had legitimate interests in its progress. The railway authority needed to be able to tell the railway operators a firm end-date so that they had time to respond and to advise the public of the new train timetables. The project needed a commitment-to-readiness that had a high probability of being achieved.

So was this a project where the critical constraint was time? ­Absolutely not! Safety was paramount, and could not be sacrificed in the name of expediting completion. Was it, in fact, the kind of project where the ­fundamental constraint is fulfilling a specific requirement in a particular way? That was tempting, and indeed planning had begun on that basis. Under that kind of constraint, the project would need to be planned and managed as discussed in Chapter 5. But the operational imperative of knowing when the work was to be completed worried the senior ­project manager involved. He knew that providing gold-plated assurances as to end-dates does not feature in the planning of such projects. So, he ­wondered, what was the fundamental constraint?

The determining factor when establishing the completion date was the rate of clearance of signals, and that was carried out by, and could only be carried out by the first principle signaling engineers, and it was their availability that limited throughput. This insight stopped the planning process, as it would lead the project down the wrong path. This project needed to be planned as a resource-constrained project.

Armed with the evidence that signal testing was the most critical activity in the project, the project manager persuaded the project board of the importance of planning around the resources–not the outputs, not the tasks, but the resource–and more specifically these scarce or ‘golden’ resources: first principle signaling engineers.

When a category of resource is the constraint, the best approach is to deal with them not as resources but as assets. They are the generators of future value in the project schedule. They need to be ring-fenced, protected from lower-value tasks, and never be kept waiting for work. The supply to them needs to be managed and sequenced as the throughput of the whole project is determined by the throughput of this resource.

The result is that the scarce resources are ‘leveled’; reducing peaks of usage, and scheduled to near a hundred percent utilization.

It might sound simple, but in practice, it isn’t. To be effective, leveling may require activities that seem to be unitary to be split. Parallel activities have to be enabled and managed, sometimes forcing the implementation of such unusual scheduling practices as finish-to-finish sequencing. The purpose is to optimize the allocation of the scarce resource. Sometimes it can lead to physically impractical solutions, and it usually requires a detailed understanding of the specifics of the activity.

The project management task was now to establish two things that were at that time unknowns. What was the clearance rate for a tested-as-safe signal? And, how many signals needed to be tested? Questions not asked before and not necessary to ask in a project planned under mission-critical criteria. Finding this information, establishing an inventory and a ‘job card’ for processing the items in it, sounds straightforward but it took many iterations to eliminate the phrase “I think” from the vocabulary of the project. “I think it took me 2 hours.” “I think there are 23 signals in that segment.” “I think I can clear these signals this week.” When you are responsible for the delivery of a project based on throughput, you do need to know–for sure.

When the answer was finally known, it turned out completion would not be in November as the rail authority had suggested initially, and it would not be the following March that the harassed signaling project manager had promised. It would be the following September because that was how long it would take with the first principle signaling engineers available to the project to clear the 4,318 signals.

The problem of communicating this September go-live date to the by now punch drunk railway operators, who had been seeing end-dates come and go, and then to the public, was handled magnificently. Rather than explain what might appear as poor project planning, the external stakeholders were advised that the summer timetables would be continued throughout the winter and into the following summer, in response to suggestions from the traveling public. Everyone liked that.

The project was delivered at the re-baselined end-date and hailed as a success by all the stakeholder groups. It is a good demonstration of how upfront planning, focused on the right constraint, allowed the project to deliver to its success criteria–a firm end date, and no signaling incidents.

Resource-constrained projects do not follow the standard CPPRRSS planning sequence. The steps are illustrated in Figure 3.1. Resources and the processes they can deploy effectively are tightly bound together, and there is rapid iteration between them. The critical information is productivity, in this case, the rate of clearance. (It is worth noting here that when the processes chosen are highly skilled resources carrying out intellectually demanding tasks, the project manager needs to establish additional interim and management products to allow monitoring of progress—see Figure 1.4 on components of a PBS for an explanation of interim and management products.)

Fgure 3.1 Planning in resource-constrained projects

Making Resource Demands Visible

In the rail-signaling project, the first principle signal engineers would always be the bottleneck. The sensible thing to do was, therefore, to manage them as golden resources. On some projects, the bottleneck resource varies, with different work-packages relying on different types of scarce resources. Planning under these circumstances becomes a matter of structuring sets of tasks around resource availability, rather than a logical sequencing of activities.

High Speed 1 (HS1) was the UK’s first high-speed rail linking ­London to the European network. It was also the first new British railway in 100 years and the UK’s largest-ever single construction project. The program had 80 work streams at its peak, but the real complexity came from the delicate balancing of political, corporate, and environmental interests; moving services across London; building and decamping to a new depot; and most importantly taking staff and passengers on the journey from the old service location in Waterloo to the new one at St Pancras.

Every business unit in Eurostar was involved in the program as well as many external partners and suppliers. Existing operational services had to continue undisturbed during the program execution. So, the staff was asked to contribute to the program while pursuing their day job. The challenge for the project was to create credible, transparent and agreed-to work demands. The planners had to be sure who needed whom, and when, and to communicate this information in two directions; to the individuals and the project planners.

Table 3.1 is an extract from one of the resource impact charts used to assess resource ‘hot spots.’ It is an analysis of the organizational ­breakdown structure against the proposed work streams for the ­program. What it highlighted was, not when people were needed–that is ordinary scheduling–but when tasks and activities could be done because key ­people were available then. This is using resource management as the driver of your schedules.

Table 3.1 Identifying critical resources (extract from Eurostar resource plan)

Workstream	Projects or primary products	IT	Legal	Commercial	Distribution	Comms	Engineering
Distribution density	GDS in UK (2.5)
	Cross partition ticketing
Share of wallet	Journey plus enhancements
Business ­intelligence	Eurostar business intelligence
IT infrastructure renewal	IT infrastructure renewal
Intranet	Intranet
Commercial ­workstreams	Image and brand values
	International GDS access (GSA/BSP)
	Internet portal connections to the Eurostar reservation system (ERS)
Operations ­workstreams	Interfaces between French and UK train maintenance systems
	Maintenance scheduling process across the fleet
	Specialization of the workload at individual depots

Need to consult on solutions

Need participation

Need dedicated resources

Limited Resources Demand Different Options

Even when the resource is neither specialist nor particularly difficult to find it can still become scarce when there is competition for it, a situation that is uncomfortably familiar to many project managers. Moreover, it does not have to be people in short supply.

The FIFA football world cup took place in South Africa in 2010–in the build-up and the two years following the games South Africa ­struggled to source enough bitumen for its road construction projects. (Bitumen is a by-product of oil refining and is used to produce asphalt for road surfacing.)

The situation is dire and is significantly impacting the industry. It is not just large construction and asphalt companies that are being affected, but small companies too, which is having a ripple effect on other ­business sectors…[particularly] in the road-building ­industry–the South African Roads Agency reported that 35 major road projects had been severely delayed by the shortage.

—SA Bitumen Association

Many projects languished. Planned on the basis that resources would be available when the need arose for them–one of the most common assumptions made by project managers–they had stalled when the bitumen was not forthcoming. Other projects, using planning techniques that were based on the availability of the scarcest resource, did better.

Having identified that completion would be impacted by bitumen shortages; the companies running these projects initiated early actions to source alternative locally available paving products and got them approved. A series of risk management actions triggered and justified by the planning approach that prioritized resources.

There is one function in today’s industry that has a habit of creating highly competed-for resources; IT. Currently, particularly in the retail sector, but also more generally, the demand for SAP specialist skills is driving up contract rates, delaying projects, and frustrating businesses. The response by some is to look for alternative solutions, and alternative technologies, driven, not by dissatisfaction with the SAP solution, but by the constraints put on them by scarce resources.

More Resource!

One of the reasons why the early Star War films have lasted so well is that though fantastical; there are many recognizable parallels with our world. Darth Vader, the scary adjutant of the sponsor of the project to build the Death Star, visits the project to check on progress. The project manager, when challenged, nervously exclaims, “I need more men!” Somethings never change.

More resource is a frequent project manager refrain, but it is not always well-founded. Consider the CECA project:

It is early February, and it has come to the attention of the PMO that all is not as it should be with the project. Up until now, based on status reports, for the past 20 weeks, the project appeared to be on track, see Figure 3.2. All planned tasks had been completed, albeit at a higher than expected cost. This was due; it was noted, because one of the resources was consistently taking 50 percent more effort to complete her tasks than anticipated, probably because the estimates had been prepared with more experienced, and therefore more productive, staff in mind.

Figure 3.2 The reported performance to date

Testing must start on 14 April to meet the release date; this is not optional. With 10 elapsed weeks to go, the resource plan showed 74 effort days available. The problem that the PMO had picked up was that the outstanding change requests had increased the scope of the project (the number of outputs required) by an additional 25 percent, which meant that the effort demand was now 111 effort days, taking it well past the required end-date. So, the real situation, when plotted, looked like Figure 3.3: the planned curve was now above the delivered curve, so the project was no longer showing that it was on track. By extrapolating the delivered curve–the dotted black line in Figure 3.3—it is clear that, at that rate of productivity, delivering all the outputs would make the project late.

Figure 3.3 The real state of affairs

The PMO sat down with the project manager to discuss options.

Naturally, seeing the problem as a resource shortfall, the project manager asked for more resource. The PMO pointed out two facts: the project manager hadn’t dealt with the resources he already had particularly well, as at no stage was the under-productivity of the team addressed, and secondly, with only 10 weeks to go, there just wasn’t time for someone to be recruited, inducted and made productive to make enough of a difference.

“What other options are there?” the project manager asked. Delaying the start of testing was not an option. One or two calendar days overrun might not prove disastrous, but the business dates posed an immovable barrier. And warming to his task, he pointed out, given the significant increase in scope during the first two-thirds of the project; some contingency had to be built in to absorb further increases.

He could, he supposed, reschedule, changing the allocation of tasks and crashing the schedule. On its own, though, these actions were unlikely to give sufficient extra productivity, or enough contingency to guarantee completion dates.

“What about re-scoping the project?” the PMO manager finally suggested. A cursory examination of the project mission identified that a few of the products did not have to be delivered by the testing deadlines, and enough of them to make a big enough difference. And, provided a rapid follow-on project was initiated to implement them, the additional costs imposed on the business would be bearable.

For this option to have any merit, however, it had to be sanctioned immediately. It would necessitate a re-plan, and a reschedule—to stop work on the now non-essential aspects—and it had to be agreed by the sponsor and key stakeholders, including the CEO. The options were presented to them as shown in Figure 3.4.

Figure 3.4 The options—cost vs. risk

No one chose ‘more resource.’

CECA is a project that we have used many, many times on our courses and workshops. The vast majority of even experienced project managers select the ‘more resource’ option, and we wonder why? In CECA, the interaction between low productivity and increase in scope is often overlooked in the hunt for a single silver bullet. The focus of attention of the project managers tends to be on activities and staff allocation, while the answer lies partly in dealing with project productivity of the team and of an individual; and more particularly further back, in the project mission itself. More resource, particularly in the later stages of a project, is rarely the best option!

When the Team Is Fixed

There is yet another way in which projects can be constrained, sometimes unintentionally, by the lack of resource required to deliver the project.

Many project managers, particularly running internal projects, find themselves managing ‘rectangular’ effort curves. That is to say, even though projects have known and predictably changing demands for resources over time, most project managers run a team of a fixed size. The characteristic shape of the required effort from project teams was shown to follow Rayleigh’s curve in work done by Slim and Putnam on workforce build-up (MBI) in projects (see Figure 3.5).

Figure 3.5 The Slim-Putnam curve

Running fixed teams can lead to productivity problems, but they are not the subject of this discussion. What is; is how to manage the resource availability-constraint that running a fixed team might impose?

The Slim-Putnam curve describes the level of productive effort required to deliver a project. When you superimpose the available effort from a fixed team, you get graphs similar to that shown in Figure 3.5. What it shows is that during the early stages it is difficult to engage the team members fully, as tasks are not ‘available’ for them to apply effort and this is also true as the project begins to wind down. The shaded areas under the ‘fixed team size’ line represent paid-for-labor that does not result in valuable project work. In such situations project managers can become distracted, finding work for team members, which may end up actually impeding work necessary for project completion.

The point ‘td’ is the point of maximum resource demand. For this project, and with this fixed team size, the resource available is less than the amount of effort required, which results in the peak moving to the right ‘td1,’ and that causes end-date slippage. It is quite a well-known story to many project managers. Adding resource in an attempt to hasten the completion of a project is a good a way of delaying it. To finish a project you need to shut tasks down, not open new ones.

The second problem with fixed teams is more to do with managing capability than capacity. Experienced project managers realize that there is no point in planning a solution that the individuals on the team are ill-equipped to deliver. When you have access to the necessary skills, it is appropriate to plan for the best technical solution. Otherwise, the plan needs to set out what is managerially best, which involves structuring the work so that both the effort time and the calendar time are predictable.

Of course, there is a downside to modifying solutions to suit the available skills, which is why unintentionally imposing resource constraints is not such a good idea. Several years ago, a large financial company ring-fenced specialist IT and financial analyst resources and dedicated them to their business transformation programs. The early successes and extra pace they achieved turned, within a couple of years, into staleness and sameness as new problems and new opportunities were solved using the same set of solutions. This fixed team approach was abandoned as a failed experiment after four years.

A useful insight into project teams comes from work done on the impact of turnover on a project. Research on the factors that affect project productivity found that increased churn rates negatively affected project performance. So, you are not surprised. The interesting finding is that a small amount of turnover increased productivity! (See Figure 3.6.)

Figure 3.6 Impact of churn rate on project productivity

What would cause that? Well, it turned out that when a new member joined the team, the project manager, and the team revisited, rehearsed, and re-communicated the project mission, what the project was for–what its purpose was, who was contributing to what, and what the status of the project was. The accidental value of this was that it refreshed the project team’s understanding, and their perspectives and roles were re-invigorated. It makes you wonder if doing this by chance were so valuable, what would the gain be if it were done deliberately?

One of the strengths of some Agile teams is that the members do have daily meets; they do share a common picture and make use of techniques they are well versed in—a genuine team environment. There is, however, a distinct possibility of a similar unintentional resource-based constraint being applied as experienced by the financial services program team. The skills combination within the team, in the end, determines the set of solutions, and the sequence of delivery and in so doing detaches delivery from the reality of business-driven needs.

When Project Managers Are the Problem

A banking group had recognized that its IT portfolio of projects was stalled. Projects made it onto the portfolio register, but would then not progress for months, if ever. What was the cause and how could throughput be increased?

Over the period of a year, there were between 40 and 60 projects in the portfolio. The portfolio register showed that there were 22 project managers managing between one and three project-starts a year. (In this sector, with IT-intensive projects, this is about average, depending on the level of skill of the project manager.)

Although the total number of project managers looked about right, on closer inspection of the nature of the portfolio it became apparent that there were insufficient PM2 (medium experience) and PM3 (high ­experience) project managers, see Figure 3.7.

Figure 3.7 The mismatch between the ­profiles of projects and project managers

Type 2 projects (classified through an analysis of size and complexity) were being assigned to PM1 (low experience, junior) project managers who lacked the skills, behavior, and attitudes to drive these more complex projects.

To improve the throughput of projects in the portfolio, a number of strategies are possible. The number of projects in the portfolio could be reduced, or made much simpler in structure and scope. Alternatively, the skills of the project managers would need to be raised through training and/or recruitment. The four basic strategies are set out in Table 3.2.

Table 3.2 Strategies to cope with PM/portfolio mismatch

Strategy	Impact time	Challenges/risks
Reduce the number of projects	Short-medium term	Governance processes need to be improved to ensure fast decisions about project priorities
Make projects less complex	Medium term	Skilled portfolio analysts required to break down projects. Improved portfolio management (in particular interdependency management) required
Recruit	Short term	Increased costs and potential for tensions with existing staff if too many contract staff brought in. Increased induction and management overhead to deal with new staff intakes
Re-skill	Medium-long term	Loss of project effort to training time, coaching and mentoring time. Skills may still be lacking

The banking group used a combination of the four strategies. First, they had mapped the project interdependencies–how one project affected others in the portfolio. Then they had the projects restructured, splitting or aggregating them to simplify and reduce the number of dependencies, making the projects more ‘do-able’ by the project managers that they had. They also eased the time constraints on some projects, and where it proved difficult to reduce the complexity, provided coaching and mentoring to less experienced project managers working on projects that were assessed as ‘challenging.’

And Sometimes It’s the Project Sponsor

While we were sorting this problem out, it became clear that there was another issue lurking near the surface. One of the resources commonly under-valued in projects is access to stakeholders, and in particular, access to the project sponsor.

The level of commitment of the sponsor to a project will vary by the nature of the project, but it also varies considerably over the lifetime of a project (Figure 3.8).

Figure 3.8 Involvement of the project sponsor

In general, the peak period when attention is required from the ­sponsor is in the initiation and planning stages of the project. Because of the annual planning cycle in this banking company, project-starts bunched together at the beginning of the year. This resulted in ­particularly high demands for sponsor activity, which was neither anticipated nor serviced. This was another reason why projects got onto the portfolio register but were often delayed for several months in initiation.

All the projects in the IT portfolio of the bank had a sponsor, but there were only five sponsors for the 60 projects, giving an average of 12 projects per sponsor. As it happened, one of the sponsors was the CEO, and he was the sponsor of 19 projects. Seen as an advantage by the project managers to have such a powerful sponsor for their project, it wasn’t. They never got to see him!

Under the circumstances, it was considered apolitical to confront the CEO with this issue, so we ran some workshops to debate the following questions:

1. How many projects are you sponsoring?
2. What has the role of the sponsor been in those projects?
3. What project actions have been triggered by sponsor interactions in the past three months?

The atmosphere in the early workshops was distinctly frosty as it became increasingly clear to the individuals charged with sponsoring projects that they had no idea what was expected of them. They had not realized how much time was involved, nor how varied the types of ­interactions expected of them were. In the third workshop, the CEO of the bank stood up and took charge, saying

Here we are investing millions, and we haven’t got time to take responsibility for it! From now on, I will accept the stewardship of no more than three projects. If the other projects can’t find someone who cares enough, let them wait, or die a natural death.

and swept our. They say leadership comes from the top, and, in this bank, the impact of the CEO’s attitude toward sponsorship was immediate and enormously positive. The bank took forward four actions:

• All sponsors to be inducted into the role to ensure they were aware of the commitment required.
• Start projects when and only when business sponsorship can commit the time for engagement.
• Monitor the portfolio demand for critical resources.
• Stagger the start of projects to optimize the project resources, including sponsors’ time, available.

The combination of the restructuring of projects and the realistic scheduling of projects against the availability of appropriately skilled resources allowed the banking portfolio to address the bottlenecks in their project delivery.

Here we see the impact of project resources on the throughput of projects. In the rush to start projects, it is tempting to assume that the resources will mysteriously become available, but they don’t!

Reflections

How do you know when you are dealing with a project where the top-most constraint is a resource? The answer lies in the way risk arising from the use of resources, is treated.

When the conditions of success of the project demand access to a particular, possibly scarce, resource, the resource is not a project risk. It is a constraint (or CSF) and is an integral part of the plan; there are no alternatives. This is the case in projects like the East Coast mainline signaling project and the bitumen projects in South Africa discussed in this chapter. Under these circumstances, the planning process focuses on the following four tactics:

• Monitoring and control of ‘golden resources’
• Resource scheduling—leveling
• Investment in the development of alternative resources
• Designing the project around the resource

This situation contrasts sharply with those projects where, in the ­process of planning, you choose to use a specific resource. Under those circumstances, the use of the resource often is a risk and therefore is ­subject to additional management actions, a plan B so as to speak.

Then there are projects where it is not that you don’t have the right resources, it’s just that there are no more resources available for the ­project. What are the options now? The typical way to deal with limited resource availability is resource leveling, a technique that has the merit of simplicity but is a brute-force tool with little subtlety.

Consider for your projects:

1. Most project managers have felt they could do with more resource at some point. Which approaches have you made work?
2. When your project involves scheduling heavily competed-for resources, did you find yourself having to make compromises in the planning and scheduling? If so, how did you go about doing that?
3. Have you ever constructed a risk tree to explain the options to a stakeholder or team member? When facing a resource shortfall, whether it is staff, materials, or money, set up a risk tree to help identify the consequences of the way you intend to deal with the problem.
4. What types of allowances do you make when planning when you are obliged to use non-ideal or even unsuitable resources for some of the tasks?
5. When planning in a resource-constrained project and the resources are not co-located, why is the optimum approach to allocate ­complete work packages to a location?