Why Projects Fail Before They Start
By the time a project is visibly in trouble, the cause is usually months old. The budget overrun, the missed date, the system nobody uses, those are symptoms. The decision that created them was made in the first few weeks, often in a meeting that felt productive at the time.
Projects rarely fail because the work was done badly. They fail because the wrong thing was agreed at the start, and nobody had the standing to say so.
Nobody wrote down what success means
Ask three people on the same project what a good outcome looks like and you will often get three answers. Finance wants lower cost. Operations wants fewer manual steps. The sponsor wants something to show the board in October.
Those are not incompatible, but they are not the same, and if they were never reconciled the project will try to serve all three and satisfy none. Worse, when a trade off has to be made in month four, there is no agreed basis for making it.
The fix is dull and effective. Write down, in one paragraph, what will be true when this is finished that is not true today. Have the sponsor read it out loud. If it cannot be said in a paragraph, the scope is not settled yet.
The sponsor is a name on a slide
Every project needs someone who can make a decision that costs money or upsets a department. Not someone who receives updates. Someone who decides.
When that role is nominal, the project stalls at every fork. The team escalates, the escalation goes to a committee, the committee asks for more analysis, and six weeks disappear. Meanwhile the people doing the work are told to keep going, which means they keep building on an assumption that was never confirmed.
You can test this cheaply. Ask who can approve a two week delay or a ten percent budget increase without convening anyone. If the answer takes more than a sentence, you have a governance gap rather than a delivery problem.
A project without a decision maker does not stop. It just gets slower and more expensive in ways nobody notices until the end.
The current process was never mapped
A surprising number of projects set out to improve something nobody has described. The team knows roughly how the work flows, the sponsor knows roughly what the complaints are, and the plan is built on that rough picture.
Then implementation starts, and the exceptions appear. The three customer types that are handled differently. The manual workaround that exists because of a rule from 2019. The spreadsheet that quietly reconciles two systems every Friday.
None of that was in scope, because none of it was visible. Now it is either an overrun or a system that people work around from day one.
Mapping the current state takes days, not months, and it is the cheapest insurance a project can buy.
The people who have to live with it were not asked
There is a difference between consulting people and informing them. Both involve meetings, so it is easy to believe the first happened when only the second did.
The staff who do the work every day know where the exceptions live and which shortcuts keep the week moving. If they are brought in after the design is fixed, two things happen. The design misses something practical, and the people who could have caught it have no reason to defend it later.
You do not need consensus. You need a small number of the right people involved early enough that their input can still change something.
The plan has no room in it
Plans built backwards from a date are plans built on hope. Every task gets the time that is left rather than the time it needs, and the contingency is whatever is at the end, which is always the first thing spent.
Two habits help. Estimate the work before you look at the deadline, then have the conversation about the gap honestly. And build the plan around decisions as well as tasks, because waiting three weeks for an answer delays a project just as effectively as three weeks of work.
A short list to run before you commit
Before a project gets funded, five questions are worth forcing an answer to.
- What will be true at the end that is not true now, in one paragraph.
- Who decides when there is a trade off, by name.
- What does the process look like today, including the exceptions.
- Who has to change how they work, and have they been asked.
- What happens if this takes twice as long, and is that survivable.
If any of those has no answer, the project is not ready to start. That is not a reason to abandon it. It is a reason to spend two more weeks on definition, which is almost always cheaper than the alternative.
Where we usually come in
A lot of the work we do sits in exactly this window, before delivery starts. Clarifying what is actually being asked for, mapping how the work runs today, naming the decisions that have to be made and by whom, and turning a vague ambition into something a team can be held to.
It is less exciting than a launch. It is also the part that determines whether the launch goes well.
ExperTechSolution works with businesses in Pompano Beach, across South Florida and remotely. If you have a project that has not started yet, that is the best time to talk. Book a consultation, or visit www.expertechsolution.com.
