Common sense and Michael Krigsman tell me that bigger projects fail more than smaller projects. However, this does not match what I have experienced in the past. From what I have seen, project size does not have a significant impact on its odds to fail.
First – how do we define size ? Size can generally be expressed in terms of effort, which in turn drives duration and headcount. occasionally we do run into situations which are akin to asking 9 women to deliver a baby in 1 month – but assuming that doesn’t happen , there is a logical way of arriving at duration and headcount from a WBS. There are always compromises made between the triple constraints – scope, schedule and budget. Once all the stakeholders agree to this – project is good to go.
Now, assuming this exercise is done – size is generally not a reason for failure any more. The reason is that in this planning exercise, you should have covered the effort required to mitigate the risk for duration and headcount. After this planning exercise irrespective of size – all projects start on the same footing.
It could be argued that bigger projects are harder to plan and hence should fail more. However I am not sure if this is a true statement entirely. The reason is that planning for a bigger project is done on a larger scale with a more intense process and will have better scrutiny than a smaller project. Since the planning effort is proportionate – size should not be an unmitigated risk after that. For example – if headcount increases, then there is more overhead on communication. But once you factor that increase into the schedule, this risk has a valid mitigation. and so on and so on…
Then there is the risk that we fail on execution. This is not rare – but the question is – does it depend on size? As an example – lets say a small project was commissioned to build a UI in 5 days. Planning was done in an hour on a whiteboard, and the stakeholders were 2 people. It only needed one developer to write the code and test it and move it to production. Total cost was calculates as say $2000. In execution, it took 6 days to finish because one of the stakeholders was out sick for a day and hence could not clarify a requirement in time. Cost over run is $800. What is the chance that this failure gets highlighted in blogosphere? ZERO or NEAR ZERO. As a percentage – cost slipped by 40% and schedule slipped by 40%. But since the materiality was so low, it is not worth spending time to analyze it. And guess what – in most cases, people won’t even say that this was a failure.
But on a project that is $10 Million in size – a 40% miss is enough to get some serious blogosphere attention. Then we need to find out what went wrong – and point fingers at the SI, the customer, the product vendor, the weather and the macro economic factors.
My point is – as long as we compare projects and their risks apples to apples, I have not seen big projects fail any more than smaller projects. The difference is that when big projects fail, they fail SPECTACULARLY, and hence they overshadow the similar failure rates of smaller projects. Several decades later, we still talk about sinking of Titanic. Since that time, more people have probably dies of smaller accidents – but do we talk about them?
Lookin forward to hearing your perspective on this topic…
And Vijay Says... 
Having managed big and small projects I’m inclined to suggest that systemic failure favours smaller projects. What I mean is that often, smaller projects suffer from poor management and often, unlimited scope creep. Larger projects, because of the investment being made receive a lot more scrutiny, whereas, “flash in the pan” projects tend to find themselves abused, both by stakeholders and by the project managers themselves. You would not trust a large project to an inexperienced PM but you might find yourself convinced that since the project is “small” that an inexperienced PM would be “just right”.
LikeLike
I could see how common sense wise it would be easy to think big projects would be more apt to fail-they have more pieces to monitor, more opportunity for failure. BUT-I think bigger projects have more money involved-more people looking at it-more accountability, so I think its highly probable for smaller projects to go wrong simply for the fact that they don’t often get as much attention or monitoring by higher profile stakeholders who can strike fear in the hearts of the working minions.
LikeLike
Size is less relevant than project duration. The longer a project runs, the more likely the world will change around it making it irrelevant, and causing the project to blow up.
SABER was something like a US$1.6 billion project (in today’s money) which was delivered on time and on budget. Whereas Telstra transformation (1.something billion), AU ATO transformation (830 million, at the last count) and a host of others are in a similar ball park, but flamed out spectacularly. The difference is that SABER was from the early 70s when the business world moved a bit slower; the few years it took to get the solution out the door wasn’t a problem. Whereas Telstra et al had to deal with a business environment that changes every quarter, requiring new products and a slew of change orders. Often the change orders start flowing before you’ve even finished requirements analysis.
So the problem isn’t the size of the project per se, but the duration between project initiation and final delivery. Big projects just take too long for most of them to be delivered successfully today.
r.
PEG
LikeLike
There’s very little doubt in my mind that smaller projects fail less often for many reasons. That’s not to say that there’s a guarantee either way. Call it agency theory or whatever you like, smaller projects have fewer moving parts.
LikeLike
Thanks for chiming in, Phil
If there is no guarantee either way – then why would size matter?
LikeLike
Big or small is a term that can be associated with projects solely by stakeholders depending on various factors which can be the returns associated with the project or what are the environment dynamics in which the project has to be executed. And if these factors are assessed and listed properly during creation of the project charter, then success or failure are results of how well the project plan was put forth and how well the risks associated were identified and planned for.
You mentioned WBS (work breakdown structure) which is a planning tool from the manufacturing sector. I myself use it extensively for activity definitions and also identify complexity and estimate relative efforts for the same but unfortunately its something very few people really identify and use (my belief).
Overall this is a very nicely written article but would have loved to read about some experience from you or the readers.
LikeLike