I am amazed at the different reasons why people think projects become late.  Team members frequently blame "management" for unrealistic goals, managers frequently blame team members for lack of technical prowness or planning abilities.  Mark Horstman has asserted that the economy has actually forced organizations to become more efficient, yet everyone seems to blame lack of resources as a reason.

My assertion is that teams focus too much on "protecting" individual project tasks and not enough time protecting the entire project.  Task deliverables typically don't fulfill organizations goals by themselves - it requires the entire project's deliverables to meet the end customer's needs.

I have recently started a podcast series on 3 behaviors, that I refer to as Serial Schedule Killers, that will cause projects to fail almost immediately.  If you are finding your projects are prone to slip (according to the latest Standish Group Chaos 2009 report 68% of all projects fail), you might want to check it out:

I'd be interested to hear your thoughts on Student's Syndrome, Parkinson's Law, and Bad Multi-tasking and how prevalent it is on projects in your organization!



pmhut's picture


I have published an article that rhymes with your podcast, why most projects finish late. The article has a paragraph examining the student syndrome.


Project Management - PM Hut

jason_koch's picture
Training Badge

 I read an article recently (maybe HBR?) which commented on this very issue. Most projects finish late.

By defining our projects as a series of tasks with a "if it's done right" duration of X, we are setting ourselves up to fail.

The assessment, which resonated with me, was that projects are more or less defined as a series of tasks that are to occur in some sequence. Generally speaking, it is assumed that the duration of each task is well defined and well known. How often is that really the case?

We all know that some tasks will balloon. As soon as one task is delayed, you are now behind schedule. We put in contingency, put this is really just a buffer. How do you know how much contingency to put in.


The flipside is, any projects that are early or under budget were also improperly estimated .. food for thought.


stephenbooth_uk's picture

 There's a quote, from Patton I think, "No plan survives first contact with the enemy."  That's certainly the case with project plans.

The last line of Jason's comment probably contains the key reason why, 'estimated'.  Projects, pretty much by definition, are something you haven't done before (although you may have done similar things before) so your times and costs are estimated.  Any estimate is going to have some margin for error, the more experience the estimator has and the closer the project and the conditions it exists in are to past projects  the smaller the margin of error.  Projects are also inherently risky, they're something you haven't done before or do only rarely so the 'Christmas rule' applies.

I believe, based on my experience, one reason projects tend to finish late rather than early is that most people are optimists.   They tend to err on the side of thinking things will tend to go right so tend to assume that work will adhere to schedule.  I've also noticed some tend towards Pollyannaishness, they don't want to consider things that might go wrong.  For this reason strong risk management is vital.

Probably a more common and major reason, again in my experience, for projects to fail is scope creep.  There's often a strong drive to get started on building the solution.  The customer wants to see something concrete for all the cash they're spending, the project manager wants to get going on the 'real work' and the delivery teams are raring to go.  Analysis, finding out what the customer actually wants/needs, gets rushed through and the delivery teams get imprecise or precisely wrong specs.  When the solution comes to be presented tot he customer they say "But that's not what I want!"  "But that's what you said you want!" responds the project manager and so the blamestorming and redesigning begins.  Then the project gets trapped in Change Control Hell and delayed more.  Change Control Hell leads to Change Control shifting to JDI ("Just Do It", some of you may be used to seeing another, less polite, word in there as well) method.  Chaos ensues and eventually the customer gets something vaguely like what they wanted and goes away wondering why projects always fail.  Agile methods, done properly, can reduce the impact of scope creep.  Unfortunately the implied conditional in that sentence usually returns a false so leading to project failure.

Looking at Ron's post:

  • Lack of resources can be a reason why projects fail to deliver to time, cost and quality.  If something is going to take 100 person days to do and you want to deliver it in a week then you need to have at least 20 people (probably more due to control overhead) to do it.  Presuming it will parallelise like that of course.  If you've only got 10 then you're trouble.  The other alternatives are to extend the time or change the deliverable to something that can be delivered in the required timescale.  Lack of proper resources can also be a problem.  Maybe this task requires 100 person days where your people are at skill level 1 but can be done in 50 by people at skill level 4.  If your 10 people are at the higher skill level then you've got a chance of delivering to time and quality, though higher skilled people tend to cost more per hour so cost may have to flex.
  • Protecting tasks is quite natural for most people on the project.  With the exception of the project manager and executive (or similar) people on the project aren't accountable for delivery of the project.  They're accountable for delivery of their task(s) and have no incentive to harm delivery of their task(s), maybe by releasing a direct to work on another task, to serve the goals of the overall projects.  Actually they probably have a strong disincentive as their review goals (on which their pay and continued employment depend) will be based on delivery of their tasks, not the project as a whole.
  • Student Syndrome, been there done that, although I did tend to start earlier on assignments earlier than most of my colleagues.  Sometimes there are valid reasons and the management culture of a company can drive that behaviour.  I can think of a number of times I've been asked "Why are you working on [high priority task and long duration not due for delivery for some time], you could be working on [Low priority and short duration task due earlier but not immediately]."

My recipe for project success?  Plenty of analysis up front.  Methodology that supports strong Lessons Learned and Risk Management.  A paranoid 800lb Gorilla as risk manager.  Reporting follows 'little and often' model.

I don't have a podcast to plug but my employer has developed a methodology for big transformational change that you might want to look at if you're doing big transformational changes:

It's free to use and complementary to PRINCE2, MSP and various other methodologies for Project and Programme management.



Skype: stephenbooth_uk (Please note I'm on UK time)

DiSC: 6137

Experience is how you avoid failure, failure is what gives you experience.

Jason Wilmot's picture

To paraphrase from the Mythical Man Month:

How does a project slip by a year? One day at a time!

Tiny slips from different fronts accumulate to produce a larger slip. Focusing on meeting small individual milestones is required.

superjac's picture
Training Badge

Something I experience a lot in my current role is being beaten into submission with my schedule. It happens nearly every time. A small project will come up, and my manager will say, "how will this take?" Let's it's something small like reprinting all the current company brochures. I say it will take a week. He says it is non sense, that he could go right now and have them ordered in 3 hours. Of course that won't ever happen, but he could. A small battle wages for a moment while we debate actual hours and elapsed hours then settle on splitting the difference. My one week is reduced to three days. Then the project is late. My project is late.

robin_s's picture
Training Badge

sounds like the illustration in the book "The Goal" - where the boy scouts are on a hike, and the line of boys going single file gets more and more spread out over time.  A combination of statistical variation and dependent events.  If the beginning of one task is dependent on the completion of another, every bit of delay throughout the project adds time that can't be made up. 

royd's picture

some thoughts from my experience - ymmv

a practical way to try to mitigate student syndrome is to have tasks with binary completion with the same frequency as the project is reported. They get to be reported as done or not  - i.e. late or not sooner rather than later. Then if a task is late something must change to get it back on track not just ignored M&M have a cast on that.

I have seen Parkinson's law when the prize at the end of the project is less compelling than the person's own view of thier bit of the project, e.g. an engineer loves to improve the implementation of their small part of the project, and does not have the burning desire to have the end product first in the market to balance against this. This connection between work and final product is crucial and a key responsibility of the PM.

Bad multi tasking seems to go hand in hand with a fire fighting culture and everybody being 'busy' . This is a cultural issue made more difficult to fix because the people who are most senior in the organisation are those must successful in that environment and who have the least actual incentive to change it. A PM may have some success by ring fencing those people working on tasks on the critical path - and for people next in line to pick up the baton so any early finishes can be passed on.

as previously mentioned other key reasons

bad initial requirements that then get changed after some implementation

estimates for tasks that are only for duration and not based on the size or complexity of the task - from which the duration is then derived. Even if there is no formal way of doing this - the act of separating the task complexity from the resultant task duration is a very useful mindset.

no risk management - i.e. risks identified and the top ones with actions explicitly in the plan to mitigate them