Barbecue IA: Why Do Software Projects Go Off Track So Often?
Episode 1 of Barbecue IA explores why software projects so often exceed budgets, miss deadlines and fall short of expectations.
Ideas on the Grill
Episode 1: Why Do Software Projects Go Off Track So Often?
"We do not judge people here. We put ideas on the grill. And sometimes... they come out stronger."
I have read hundreds of articles on project management. They all talk about agility, methodologies, communication or organisation. Yet projects continue to exceed budgets, miss deadlines and fall short of expectations.
So let me ask you a very simple question.
Why do software projects go off track?
This may surprise you, but I have hardly ever seen a project start from a need that was not real.
When a company invests in software, it does not do so for fun. There is always a genuine problem to solve.
The need is real.
The problem comes later.
So the need itself is not wrong... but what we do with it is?
Exactly.
At first, we address one specific need.
Then someone says:
"While we are at it, we could also..."
And that sentence is dangerous.
One idea leads to another.
Then a third.
Then a fourth.
None of them is absurd. Quite the opposite. They are often relevant.
But taken together, they turn a simple project into a complex one.
Wait...
Are you saying that a project fails... because the teams are trying to do a good job?
That is a paradox.
The problem is not wanting to do a good job.
It is wanting to do everything.
All at once.
We often confuse quality with completeness.
We assume that good software is software that has thought of everything.
I believe exactly the opposite.
Good software is software that solves one clearly defined need extremely well.
Everything else can come later.
Yet users always ask for more.
A new feature.
An improvement.
A shortcut.
Do you say no?
Not often enough.
And I think many developers are like me.
We like to help.
We want the client to be satisfied.
We want them to say:
"They even thought of that!"
The problem is that every small "extra" seems harmless.
But by the end, they form a mountain.
So perhaps the real problem is not the client.
It is our inability to say:
"Not now."
Yes.
Because there is another mistake.
We often assume that a requirements document can be complete.
I do not believe it can.
After more than twenty-five years developing software, I have never seen one that anticipated everything.
And that is normal.
We cannot predict every exception.
Still less the exceptions... to the exceptions.
How software is really used only becomes clear when someone actually starts using it.
So in the end...
You are no longer trying to build the perfect project.
You are trying to build a project that accepts being incomplete.
Exactly.
To me, the right approach is almost counterintuitive.
First, build the agreed scope.
Nothing more.
Make sure the initial need is genuinely covered.
Observe.
Test.
Listen.
And only then...
improve.
Software should grow with its users.
Not in its designer's imagination.
I think I have just understood something.
Throughout this discussion, I expected you to talk about agile methods, Scrum or software architecture.
In reality...
you have mostly been talking about humility.
Accepting that we do not know everything.
Accepting that a project finds its shape as it moves forward.
And above all...
resisting the temptation to build the perfect version before validating the first one.
What Survived the Grill
A software project does not go off track because there are too many ideas.
It goes off track because we try to deliver all of them before validating the first.
See you next week.
A new idea will go on the grill.