Submitted by rjholohan on
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!
Ron, I have published an
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
I read an article recently
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.
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:
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: http://www.champs2.info/
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)
Experience is how you avoid failure, failure is what gives you experience.
Mythical Man Month
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.
This doesn't answer why projects slip but. . .
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.
from "The Goal"
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.
Student's Syndrome, Parkinson's Law, and Bad Multi-tasking
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