Lessons Learned: Schedule Detail and the Student Syndrome

Until my database is updated with the results from the last five teams of the spring 2014 semester, this will be my final blog post on the topic of Lessons Learned.  Today I’m going to examine the Time Knowledge Area.  Yes, I know in previous posts I have discounted its supremacy at the top of the list, but I’ve also stated how important this Knowledge Area is to project management.  I am still not convinced of its position, but it is probably in the top three, so let’s see what we can learn from the students on this subject.

Here is the Lessons Learned histogram from 16 teams:

May 2014 Lessons Learned Chart

I’ve selected two of their comments from the Time Knowledge Area to discuss:

  • “The leading cause for missed deliverable dates was the lack of a detailed project schedule. The schedule should have been consistently monitored.”

As a consultant, I have encountered many approaches to planning and there are some strong opinions regarding level of detail.  Some organizations prefer to manage with a high-level schedule, but they often find it does not give them the necessary visibility to manage effectively.  For example, if a task entitled “Complete Five Tests” is 120 days in duration and behind schedule, how does the Project Manager know which test is driving the work?  Sure, he or she can (and should) discuss with the task owner, but because the schedule is also a reference and communication tool, it should clearly convey that information.

Yet a schedule planned in great detail will become an administrative burden to maintain and may be too complex to use effectively.  A schedule that contains a preponderance of tasks planned by the hour generally fall into this category – and all those activities will need maintenance and status just like the others.

So, although there are no hard guidelines, a good rule of thumb is to minimize tasks with duration shorter than the status period.  For example, I’ve had students create schedules with tasks of a few days’ duration – yet they only status once a week.  Their schedules are typically between 100 – 200 tasks, and therefore the administration isn’t too onerous.  But they fail to capitalize on their investment of detail because by the time they realize a task is late, several days have already elapsed because they don’t status on a daily basis.

  • “Team members often aim to complete tasks by the due date instead of finishing tasks earlier.”

Many readers may recognize one of the key tenets of Critical Chain in this comment.  According to Wikipedia, Critical Chain is “a method of planning and managing projects that emphasizes the resources required to execute project tasks.”  So there are two components of Critical Chain: planning and also managing.  We can think of the first as a mechanical approach to project management and the second as a behavioral one.  (In this post, I’ll capitalize the references to the Critical Chain methodology, but write about the critical chain – similar to the critical path – in all lower case.)

From a mechanical standpoint, the critical chain is similar to the critical path except the former takes resource contention into account, challenges the team to work to aggressive finish dates, and creates buffers at strategic points within the schedule.

During the course of the term, I teach my class Critical Chain concepts and many teams insert a buffer in their schedules to protect the project end date from delays along the critical chain.  Well done.  In most cases, it has proven imperative to on-time completion when unanticipated problems occurred.

Some of the behavioral tenets of critical chain require tasks to be completed as quickly as possible so the deliverables can be transitioned to the next owner in the chain.  This is especially important for critical chain tasks, which will drive the finish date of the project.

One could attribute the comment from the team to the “student syndrome.”  (This is the tendency of people to start assignments shortly before they’re due.  Don’t feel smug – we all had the same approach in college!)  However I have seen this behavior with adult teams as well.

Typically, increased awareness and some training will do the trick.  The key is for everyone on the team to understand the link between the delay in the start of the task and the increased risk the student syndrome represents to the project.  For example, even though the task owner may think he/she has plenty of time to complete the task, a delayed start means all safety time may be consumed.  What if the task owner has to take off work for illness?  There’s no recovery time anymore.  Also, a delayed task start on critical chain tasks – timed to complete with the planned Finish date – virtually ensures the best the project can do is finish on time.  Of course, that means the project must experience: perfect material deliveries, no illness or vacation by staff working on critical chain tasks, no resource acquisition issues, and no unanticipated problems.

If you want to talk more about how Critical Chain schedule or behavioral techniques can help your project, give me a call. Contact information is in the footer below.

Tagged with: , , , ,
Posted in Blog Entry
Ask Eve: Submit Your Question News & events

News & Events

The Risky Business of Small Projects (Part Three)

Risk Knowledge Area

In this space, I have discussed some tools for Risk Management on a

The Risky Business of Small Projects (Part Two)

Risk Knowledge Area

One of the great things about my Project Management course at the University

The Risky Business of Projects

Risk Knowledge Area

I teach Project Management at the University of Arizona, and my graduate students