Resource-constrained scheduling


Posted on 11th September, by JimYoung in Blog. No Comments

Resource-constrained project scheduling sounds nasty.  It is needed when the availability of resources or lack of resources dictates our schedule.  A lack of resources may result in resource overloading or stretching.  For example, Jack finds that his project workdays consistently and considerably stretch beyond eight hours (or about 6.5 hours if we were realistic about productivity).  In this situation we need to get Jack off the rack to reduce tension and reschedule his workload such that it is achievable.

ggggggg

Resource-overloading is often the consequence of poor estimating or simply that the project has been assigned a low priority.  Other higher priority projects get first access to our organisation’s limited resource pool, and even those projects may have under-estimated their resource needs (sometimes deliberately by sponsors keen to ensure their projects are approved, but not in our organisation of course) and later, when reality intrudes, such higher priority projects need to use resources earmarked for our lower priority projects.  Unfortunately, lower priority projects are usually assigned to new project managers who then find they need to quickly learn about resource-constrained scheduling – hence this blog item.

A schedule shows us what tasks are to be completed when and is often illustrared as a network diagram or Gantt chart, where Gantt is sometimes an acronym for “God Alone kNows The Truth.”  We need to schedule tasks when resources are available.  Often this means that due to resource limitations our projects will take longer.  We typically identify and resolve such scheduling issues or resource over-loading using this process:

  1. Prepare a network diagram that shows durations and resource needs for each task.
  2. Develop a resource histogram (bar chart) that shows resource requirements for an early start schedule.
  3. Superimpose on our histogram the actual availability of resources or the resource constraint.
  4. Adjust the project task schedule to not exceed the resource constraint, typically with the consequence that the project takes longer.

ggggg

Shown above is a project network diagram with 11 tasks with finish-start dependencies. Each number above the task node denotes the estimated duration (say workdays) of the task, while the number below the node refers to the resource requirement (say people).  It is assumed that the availability is restricted to six people for all periods of the project. The histogram above shows the resources needed for an early start schedule.  Each task is represented by a rectangle with the horizontal length the task duration and the vertical height the resource requirement.

This earliest start schedule shows a resource conflict between workdays 8 and 13 since the total use of the resource by tasks 3, 4, 5, 6 and 7 exceeds the limited availability of 6.  In order to solve this resource conflict, tasks need to be shifted to where resources are available.  The solution below shows the revised minimum duration for this project would be 24 days.

gggggggg

However, if the project duration is now too long, more resources are not available, and we cannot out-source work, some options might be:

  1. Reduce project scope and/or remove excessive functionality.
  2. Eliminate any specification ‘gold-plating’ (settle for good enough).
  3. Accelerate tasks, particularly critical tasks, perhaps by more efficient work methods or by working overtime (sometimes for a diminishing return) and weekends.
  4. Split tasks to smooth the resource profile, which is about eliminate or filling gaps in the resource histogram.
  5. Determine a more judicious distribution of multi-skilled resources.
  6. Remove non-essential task dependencies to create more float and greater scheduling flexibility.  And perhaps a change from a start-to-finish relationship between tasks to a finish-to-start relationship might help.

Most often resource leveling requires tasks to be delayed until resources are available.  Most project management software can level resources automatically based on a set of rules that determine which tasks to delay, split or adjust.  For such rules to eliminate or minimise resource shortfalls see “The Framework” textbook at page 219. The problem is that there are often too many factors affecting a schedule that software cannot properly contend with.  Resource scheduling algorithms are notoriously non-optimal.  They are blunt instruments.  So, in my experience manual leveling is often the best strategy.  Or perhaps we could use the automatic facility and then tweak the solution manually.

Incidentally, sometimes a distinction is made between “resource leveling” and “resource smoothing” – the difference being that resource smoothing is used only for tasks that are not on the critical path (ie, non-critical tasks), whereas resource leveling has no such restriction, and usually extends the critical path of a project.  You might remember the “l” in leveling results in projects of “longer” duration.

gggggggggggggg

Simple exercise with solution.  Here you could practise scheduling project tasks to comply with resource constraints while minimising project duration given the following information:

h

Assuming that task durations cannot be altered, determine how the project can be completed in 10 days?  Here’s the suggested approach:

  1. Finish drawing the network diagram shown below.
  2. Plot only the critical path on the blank Gantt chart – also below.
  3. Show resource requirement for critical path tasks on the resource histogram.
  4. Plot non-critical tasks where resources are still available.

gggggggggggggggggg

gg

g





Comments are closed.



Blog

My latest thoughts on Project Management and life.

Free Book: “Managing Smaller and Medium-Sized Projects” by Dr Jim Young PMP

I acknowledge with sincere appreciation the contributions to this book from numerous clients, student, colleagues, friends and project management practitioners. Their sometimes unwitting input...

The “Lean” Project

Lean is an often-used adjective in business these days, but there’s some confusion over its exact definition. In essence, the goal of Lean is...

Monte Carlo Simulation

The Project Management Body of Knowledge (PMBOK Edition 6) advocates the use of Monte Carlo simulation for performing quantitative risk analysis.

In the project management...