A Digital Project Is Not a Technical Job
A digital project gets treated as a software job. Yet software is the easy part. The failure figures point the same way: consulting estimates sit around 70 percent, and these projects do not sink for technical reasons.
The code runs, the system is up, nobody uses it. That is where the problem sits. The technical side completes while the business side never begins. Payment happened; the work stayed the same.
Why Is the Question Being Asked Now?
BU BÖLÜMÜN ÖZETİ
- The technical barrier disappeared
- Buying gets mistaken for deciding
- The budget flows one way
- Responsibility gets handed to the technical side
Four developments brought it forward.
The technical barrier disappeared
Installation used to be a genuine obstacle. Servers, licences, specialists. Now opening an account covers it. Once the easy part got solved, only the hard part remained — and the ease misleads the eye. Installation finishing gets mistaken for the job finishing.
Buying gets mistaken for deciding
Once payment goes through, the job feels finished. Yet the real decisions come afterwards. Who will use it, when does the switch happen, what becomes of the old method? Without those questions the project stops at installation. The gap never shows on an invoice.
The budget flows one way
Money goes to software and nothing remains for transition. Training, data migration and habit-building never enter the calculation. What does not get written also does not get allocated. Habit-building costs time nobody set aside.
Responsibility gets handed to the technical side
The project goes to IT or to an outside firm. But they are not the ones who will change the work. When the decision-maker steps back, the project loses its owner and technical delivery finishes while use never starts. Nobody took on the step in between.
What Is Wrong?
BU BÖLÜMÜN ÖZETİ
- “The right software will fix this”
- “This is an IT job”
- “The team will settle in eventually”
- “A big project brings big results”
Four assumptions make it harder.
“The right software will fix this”
Browsing the software catalogue never ends, because the blockage does not live in that catalogue. Even the best product on the market sits idle once installed and abandoned. Buying another licence is the most comfortable way of postponing a decision. Movement in the account feels like progress.
“This is an IT job”
Technical setup belongs to IT. But which process changes and how people will work is a business decision. Without that distinction the technical side completes and the business side never starts. Both parties wait for the other. Neither notices the project has stopped.
“The team will settle in eventually”
Settling does not happen on its own. While the old route stays open, staff remain with what they know. Calling that stubbornness would be wrong; nobody gave them a reason to prefer the new way. The old route also stayed open.
“A big project brings big results”
As the scope grows, the chance of finishing drops. An abandoned large project delivers less than a completed small one. It also leaves a reluctance behind. The second attempt gets harder to sell as well.
The Real Mechanism
BU BÖLÜMÜN ÖZETİ
- Decision 1: which problem
- Decision 2: who runs it
- Decision 3: in what order
- Decision 4: which tool
A digital job passes through four decisions and three are not technical.
Decision 1: which problem
What are you trying to solve? It should be writable without naming a tool. The problem definition comes before the tool choice. This is a business decision.
Decision 2: who runs it
Is there an owner? Work without a name attached does not advance. Ownership is a matter of follow-up rather than technical skill. Also a business decision.
Decision 3: in what order
How many jobs are open at once? Without sequencing, everything advances a little and nothing finishes. Again a business decision.
Decision 4: which tool
The only technical decision, and it comes last. If the first three are settled, the choice gets easier. If not, even the best tool changes nothing.
Who Is Affected, and How?
BU BÖLÜMÜN ÖZETİ
- The business owner
- The small team
- The business working with an outside firm
- The business with an IT team
Four profiles.
The business owner
The person deciding is also the person using. That is a real advantage; no persuasion is needed. But there is a risk too. Not knowing the technical side, they hand the whole thing outward. Yet the first three decisions are not technical and sit squarely in their territory.
The small team
The easiest environment. Everyone sees everyone and blockages surface immediately. The usual omission here is failing to write an owner. Whoever installed it does not run the transition, and the job hangs in the gap.
The business working with an outside firm
The software comes from outside while the process stays inside. The firm finishes the technical part and withdraws. If nobody records who runs the transition, the project stops there. Contracts include a technical delivery date but no adoption date; that line is yours to add.
The business with an IT team
The project gets handed to the technical team easily. But the business side is what changes the process. IT can complete the setup without being able to decide on use. Both sides then wait for the other and nothing moves.
Decision Order
BU BÖLÜMÜN ÖZETİ
- One: write the problem without a tool
- Two: name the owner
- Three: put them in order
- Four: then look at tools
Four steps.
One: write the problem without a tool
One sentence, no software name. If you cannot write it, the project has not matured yet.
Two: name the owner
One name, half an hour a week. A blank field means the job will not advance.
Three: put them in order
More than three open jobs and none is advancing. Which one finishes first?
Four: then look at tools
With the first three settled the choice is easy. Without them, tool selection becomes another form of postponement.
Where to Start?
BU BÖLÜMÜN ÖZETİ
- Write the problem
- Set the measure
- Assign the owner
- Split the budget
Four jobs, one hour.
Write the problem
Where are you stuck? Twenty minutes, no tool names.
Set the measure
Which number changes? One is enough.
Assign the owner
Write a name. A role works too.
Split the budget
Software and transition. The second should not be zero.
What Not to Do?
BU BÖLÜMÜN ÖZETİ
- Starting with a tool
- Handing everything outward
- Skipping the transition budget
- Opening too many jobs at once
Four traps.
Starting with a tool
When the first conversation is about software, the project gets shaped by that tool’s limits. The problem stays where it was, and a year later the same blockage continues.
Handing everything outward
Technical work can be outsourced. Problem definition, ownership and sequencing have to stay inside. Once those go too, the project loses its owner.
Skipping the transition budget
The licence gets bought and nothing remains for use. Most abandoned projects come from exactly this. Installation completes, use never starts.
Opening too many jobs at once
With three or four projects running together the focus scatters. Everything looks like it is advancing but nothing finishes, and the half-done work accumulates.
A Solid Digital Foundation
BU BÖLÜMÜN ÖZETİ
- The problem definition
- The success measure
- The owner list
- The open job count
Four stones.
The problem definition
One sentence, no tool named. Written fresh for every job.
The success measure
Which number changes? One measure, written before the project starts.
The owner list
Who is responsible for which job? No blank fields; a blank job does not move.
The open job count
How many projects run at once? Three is the ceiling, and the rest wait.
Frequently Asked Questions
Sık Sorulan Sorular
The first three decisions need no technical knowledge. You know where you are stuck, who can follow the work and which job should finish first. Technical knowledge only enters at the fourth decision, and there you can ask. The real risk runs the other way: when the technical side makes all four decisions, the project drifts from what the business needs. Nobody knows your work better than you.
The split can be made cleanly. The firm owns technical delivery: the software works, the data moves, the integration completes. Someone inside owns adoption: who uses it, when the switch happens, when the old method closes. If that second role goes unwritten, the firm finishes and withdraws and the project stops there. Contracts carry a technical delivery date, never an adoption date. A name and a date are enough.
The setup is theirs, the decision is yours. IT can assess which software fits without being able to decide which process changes. Without that distinction both sides wait for each other. The practical fix is simple: write a technical owner and a business owner separately. The two talk for half an hour a week, and most blockages clear in that half hour.
Shrink it rather than restarting. The biggest damage from a stalled project is the loss of confidence, and a large restart deepens it. Pick a single piece instead and complete only that. A small finished step restores confidence and makes the second easier. Also write one line on why it stalled; the same cause can meet you again on the second attempt.