About Us
Site Map
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Contact Us



Common Elements and Features of a Rescue Plan

"Building a project plan is a combination of art and science. So many different techniques, variables, and permutations are available for the exercise that no two project plans can be identical. Building a project plan is not like building a car, a chair, or a widget, although there have been many attempts to industrialize the nature of business and technology projects in the past few decades. While some success has been achieved, we are very far away from building a factory floor-like process that cranks out project plans based on a tested and accurate blueprint."

"Even Enterprise Resource Management (ERP) solutions, which are arguably the most factory-like of the technology solutions that have been developed, require a significant amount of customization in most organizations. In fact, even ERP training programs often need to be modified to suit the specific requirements of a team of business users. Isn't training just training? Even at this level, the solution is not a 'cookie cutter' or repeatable factory floor approach."

"So what does this all mean for projects in general? There will always be differences at some level of the project (for example, vacation schedules will vary, decision makers will have different personalities, and team expectations may have gone up in terms of compensation expectations)."

"Project plans will always be affected by an inherent measure of uncertainty. It's your job as a project or rescue manager to build them in such a way to meld best practices with flexibility to produce a predictable result."

"While project plans are unlikely to be identical across projects, there are still some significant commonalities. The following elements must be incorporated into every project plan:
  • Timeline  This includes the standard start and end dates for the project. This needs to be extended with a clear statement of any remaining contingencies that are still available to the team if other problems arise before reaching the end date. Clarity around this is important for building an honest rescue plan that will survive the inevitable ups and downs of uncertainty through the dedication of the project team.
  • Milestones  Milestone events are prerequisites for another unit of work that leads to the completion of the project. Identify every significant milestone event that leads to the ultimate end goal of the initiative and mark it clearly on the project plan. Missing one of these is a giant red flag that requires an immediate corrective response. Again, be honest about including any contingencies that are still available if something does not go according to plan.
  • Deliverables  Identify the name of a deliverable, when it needs to be completed, and who needs to sign off on it. Try and allocate ownership of each deliverable to a single resource. This reduces training requirements and administrative overhead, while building a sense of strong accountability.
  • Resources  Start by identifying the roles and responsibilities and get very specific about the individuals who will be involved. Also indicate when these resources are needed, how they are brought onto the project, their level of involvement, the milestone dates, and the deliverables they own.
  • Activities and tasks  Start and end dates for every activity, subactivity, or task. Keep the process more general by identifying duration for the unit of work. This will make it easier to shift the items around in the schedule. Anything that is critical should be tied or linked to a milestone. Also, try to allocate a group of related items to the same resource(s).
  • Budget  This could be derived information based on resources and their timelines on the project. However, we recommend exercising caution when trying to maintain a budget and a timeline in the same toolset because it can become a logistical nightmare. It is more efficient to track budgets at a higher level - for example, many units of work - rather than trying to use every low-level item (for example, hours) to generate a total number. Information at this level is uncertain and difficult to maintain.
  • Dependencies  Use a milestone to identify every major dependency in the project plan. Every linked activity or task should then end in a clearly identified milestone. This makes it much easier to move milestones around the plan along with all their associated activities.
  • Contingency  Being open, honest, and accurate about the contingency that is available in any of the remaining deadline dates will improve your ability to react to future obstacles. Show the contingency directly in the project plan using named activities, or consider positioning the milestones to visually reveal the slack time that is available in the life cycle.
  • Objectives  Explicitly reading through the project plan with clearly stated deliverables, roles, responsibilities, and timelines should make the project objectives clear to the reader. This is not intended to replace the project charter but may be a good indication of how well the plan tells a story that can adapt to future uncertainty."