Reviving Projects from Slipping Schedules (Part 5)

Project schedule slippage is quite common in most projects and even the successful projects would have faced schedule slippage at some stage or the other. And it requires certain corrective actions from the project manager to bring the schedule back on track. However, when the schedule slippage is very drastic and the schedule keeps slipping even after multiple rescheduling, then the project would be considered an ailing or a failing project, and such projects need to be revived or resurrected through the project management techniques. Reviving failing projects involves multiple dimensions such as

• Examining the project environment and taking corrective actions
• Using tools and techniques such as root cause analysis, Pareto charts, and weighted decision tables to identify the root causes and prioritize corrective actions
• Focusing on specific areas of the project and inspecting these areas. The earlier articles (Recovering Troubled Projects Part1, Part2, Part3, and Part4) explore the requirements and other phases of the life cycle to illustrate how potential problems can be unearthed in these areas.

This article focuses on project schedules as a specific pain area causing project failure and suggests remedies.

Types of Project Schedules Slippage:

A project schedule can slip for a number of reasons both unavoidable and avoidable reasons. The unavoidable reasons have to do with the intricacies of task execution, risks materializing, dependencies delaying the project, and so on. When a project slips because of unavoidable reasons, there are standard techniques such as crashing and fast tracking that are used by the project managers to pull the schedule back or reschedule the project with consensus among the stakeholders.

The avoidable reasons have to do with how well a schedule is drafted and used, how estimation is carried out, the methodologies used and so on which deal with the skill, application of the skills, and the processes used in drafting and using project schedules. Therefore, in the case of failing projects, it is the avoidable reasons that are of more interest as applying best practices can lead to avoiding or reducing schedule slippage in not only the current project but in future projects also.

Top Reasons for Schedule Slippage

The main reasons that have to do with the skills/application/process are:

1. The schedule was not drafted properly
2. The schedule and estimates don’t match
3. Task breakdown in the schedule does not match the project life cycle chosen

• Schedule not Drafted Properly:

  One of the top reasons for project slippage is the project manager not having a grip on the project schedule because of unusable project schedules. In this case, a project schedule typically gets drafted, used initially for one to three weeks, and then the project schedule gets into cold storage. Rather than this project schedule driving the project, the project gets driven independent of this schedule and is tracked using ad hoc schedules drafted separately on an Excel sheet or a Word document. In such a case, the project manager would not have a clue as to how the resources are loaded, what is the critical path and when the project tasks are slipping, which tasks to speed up to bring the project back on schedule, and so on. The project manager would not have visibility of the current end dates of tasks and the end dates of the entire project without the help of a properly drafted MS Project schedule.

  Why does this happen? Why do MS Project schedules get consigned to back shelves? The main reason typically is that these schedules are not drafted completely and hence they are unusable. It is not necessary that tight schedules are unusable. The main reasons are listed below:

  What are Unusable Schedules?

• • Task breakdown does not correspond to the actual tasks that will be performed in the project;
  • The Task breakdown is not detailed enough
  • Overall effort in the schedule (Sigma of resources multiplied by their duration in the project) does not match the estimated effort.
  • Resources not optimally loaded
  • Task sequence does not reflect Software Development Life Cycle (SDLC) model etc.

Why do Unusable Schedules get Created?

• • Creating a schedule is similar to writing code; there is a huge difference between ‘good’ code written by a college student and a ‘professional’ code written by a seasoned programmer. Experience counts.
  • Learning does not happen by default
    • • Just by working in a professional environment, a novice programmer turns into a professional programmer. The same cannot be said of schedules as not everybody gets a chance to go through the rigor of creating effective schedules
      • If one gets driven rigorously by customers or senior managers with project schedules one is more likely to become professional in creating schedules. Otherwise, they tend to remain novices as far as project schedules are concerned regardless of how talented they are or how experienced they are.
  • Not enough time is spent on creating the schedule.

A Complete Checklist to Decide if the Schedule Created is Usable or Not: 

• • Does the overall effort in the schedule match the effort estimated earlier?
  • Do the task breakdowns of schedule and estimation match?
  • The duration of sub-tasks corresponds to the effort estimated in the estimation.
  • Does the task sequence match the life cycle model chosen?
  • Are resources optimally loaded?
  • Has parallelism of tasks been identified and made use of optimally?
  • Have all activities from the life cycle covered?
  • Is the granularity of tasks sufficient to enable team members to draw up individual schedules?
  • Does the schedule enable allocation of work to team members on a weekly basis with clear scope, activity, and deliverable?
  • Are milestones properly identified?
  • Can you track the project easily with percentage completion?
  • Can a status report be generated easily using the schedule?

Solution: By going through the above checklist, if one finds that the schedule is unusable, then following the guideline below would help in creating a proper, usable schedule:

1. Create an activity breakdown that is granular enough and adheres to the 8 to 80 rule. Ensure that the activity breakdown is in alignment with the life cycle model chosen.
2. Identify predecessor relationships based on the life cycle model.
3. Assign activity durations based on the estimates carried out while submitting the proposal. The total work in the project after assigning duration should match the original effort estimation.
4. Assign resources
5. Optimize resources. This is the most important step in creating project schedules. The resources should neither be underloaded nor overloaded. It is because this step is not given due attention that a vast majority of the schedules become unusable.
6. Optimize the schedule based on standard techniques such as Crashing or Fast tracking and then baseline the schedule.
7. Use the schedule for regular work allocation and tracking by creating weekly plans from the schedule for every team member and update the ‘actual start’ and ‘actual finish’ each week.
8. Re-plan (Re-schedule) if there is a delay in the schedule that crosses a threshold (Re planning criterion) mentioned in the schedule management plan.

• Schedules and Estimates Don’t Match:

  Duration estimation is a very critical element of a project schedule and if not done properly, this alone can lead to slippage of tasks and in turn slippage of an entire project. Many times, the effort estimation carried out to determine the budget and the overall duration is not used as a base for determining task durations. This happens because the breakdown structure used in the original estimation has no correlation with the activity breakdown structure used for the schedule. Because of this mismatch at the micro level, task durations have to be determined once again, independent of the original schedule.  Thus all the knowledge and insights used during the original estimates, the summaries of discussions held, and the rigor of the methods used during the original estimates are not available during the assignment of duration to tasks. Task duration is determined ad hoc based on the experience and will be more prone to errors.

  A solution to this problem is to use estimation methodologies that have a closer match to the activity breakdown structure created for a schedule. There are many deliverable-based estimation methodologies that breakdown the application features into the deliverables that will be developed during the project and this helps in arriving at a closer match between the breakdown structure of the estimates and the breakdown structure of the schedule and thus the schedule can leverage all the background knowledge used during the estimation.

  MVC Points is one such estimation methodology used for estimating web applications developed in Java and .Net technologies. This methodology breaks down requirements into the GUI elements, business objects, and controller elements to be developed to realize the requirements. And while developing the schedule, the activity breakdown can be organized around the same deliverables identified in the estimates thus bringing a closer match between estimates and the schedule.

• Task Breakdown in the Schedule Does Not Match the Project Life Cycle Chosen:

  The task sequence followed in a project would correspond to the life cycle model chosen. Many times, this life cycle model is not kept as a reference while drafting the schedule, and hence what is followed on the ground will quickly deviate from what is written on paper. This is a serious problem, especially in the software industry as new life cycle models get introduced with little difference from the earlier ones. Hence, the project managers quite often find it difficult to see the lines that demarcate the different models. For instance, it is hard for project managers to differentiate between an ‘iteration’ of an Iterative model, an ‘increment’ of the Incremental model, and a ‘sprint’ of the Scrum model. As a result, the activity breakdown in the schedule becomes vague and as the team is forced to follow a sequence dictated by the life cycle model, the actuals start deviating from the plan.

  A solution to this problem is to understand the distinguishing factor between the life cycle models and structure the activity breakdown of the schedule on the lines of the life cycle model.

  In order to understand the difference between the life cycle models, one needs to appreciate that it is the ETVX model that makes each life cycle model distinct. The ETVX model stands for Entry, Task, Verification, and eXit and defines the phases in a project and determines the Entry criteria that should be satisfied in order to enter a phase, the Tasks performed in a phase, the Verification criteria used to verify the Tasks and output of the Tasks and the exit criteria to move to the next phase. For instance, an ‘increment’ of the Incremental model and a ‘sprint’ of the Scrum model sounds very similar. However, the difference is in the ETVX model and a few other rules. An increment consists of all the phases of a waterfall model such as Requirements, Functional specification, Design, Coding and Testing followed in a sequence. However, in a sprint, it is not mandatory that all 5 phases of the waterfall model are implemented or implemented in a sequence.

  Having understood the difference between the life cycle models, the next step is to align the activity breakdown to the life cycle model. A project schedule of an incremental project would consist of multiple increments. Each increment would be organized around the phases within an increment and within the phases, the features and activities as shown in diagram 1 below.

Diagram 1: A typical activity breakdown for an incremental project

While in an agile project, the activity breakdown would be based on sprints, and within a sprint, the activities are broken down based on user stories. A typical activity breakdown structure for a scrum model is shown below in diagram 2:

Diagram 2: A typical activity breakdown for the project following Scrum

Project schedules can not only slip but can go into a deep irretrievable pit if the projects are not governed by proper schedules, generally referred to as ‘usable’ schedules. There are 3 main reasons for schedules becoming unusable and the project manager can avoid all the 3 reasons by enhancing his or her know-how about project schedules. This article has explained the specific areas of knowledge that the project managers should develop awareness about, provided useful inputs in a few of these areas, and has pointed to further references for additional exploration.

Also, Read Related Articles: