Starting a Digital Project
A digital job begins on paper, before any software gets chosen. The industry figures show why that matters: consulting estimates put failure at around 70 percent.
This piece covers three steps for starting a digital job. Total time is one hour. None of the steps is technical, and the software choice comes later.
What Is the Problem?
BU BÖLÜMÜN ÖZETİ
- The tool comes first
- The goal never gets written
- The budget is a single line
Three scenes.
The tool comes first
The opening conversation is about which software to buy. What problem it solves stays unclear. A job that starts with a tool gets shaped by that tool’s limits, and the original problem stays where it was.
The goal never gets written
The project starts but nobody records what would count as success. Without a measure the outcome gets settled by interpretation. Everyone uses their own definition, and an argument follows six months later.
The budget is a single line
All the money goes to software. Nothing remains for transition, training or habit. Yet that is where the real risk sits; unused software costs more than its licence fee.
Why Does It Happen?
BU BÖLÜMÜN ÖZETİ
- The tool is concrete, the problem is not
- Writing a goal feels binding
- Transition costs stay invisible
Three reasons.
The tool is concrete, the problem is not
You can see the software. You cannot see the process failure. So the conversation drifts toward what is visible and the real issue gets skipped.
Writing a goal feels binding
Setting a measurable target means committing to something. Staying vague is more comfortable. But a project with a vague goal cannot be defended, and nothing remains to show when the budget gets discussed.
Transition costs stay invisible
The licence fee appears on an invoice. Training time and habit-building appear nowhere. What does not get written also does not get allocated.
How Is It Done?
BU BÖLÜMÜN ÖZETİ
- Step 1: write the problem in one sentence
- Step 2: set the success measure
- Step 3: split the budget in two
Three steps.
Step 1: write the problem in one sentence
Where are you stuck? Write it without naming a tool. “Preparing a quote takes three days” is a problem definition. “We need a CRM” is not. If the problem is not clear, the right tool cannot be chosen either and the selection becomes arbitrary.
Step 2: set the success measure
Which number will have changed when this job is done? One is enough — time, errors, enquiries or cost. Writing the measure at the start prevents the argument six months later; everyone looks at the same figure. Without it a project ends up neither successful nor failed, only forgotten.
Step 3: split the budget in two
Software cost on one side, transition cost on the other. The second covers training, data migration and the time habits take. If it is zero the project starts at risk. The ownership routine sits inside that second budget, and splitting the project shrinks it.
How Long, Where to Start?
BU BÖLÜMÜN ÖZETİ
- Three steps take an hour
- The return shows in two places
- First step: apply it to a current project
One hour.
Three steps take an hour
Writing the problem takes twenty minutes. Setting the measure takes twenty. Splitting the budget takes twenty. One hour in total, done once.
The return shows in two places
First, the right tool: once the problem is clear, the choice gets easier. Second, defensibility. With a measure in place the project stands up in a budget conversation, and the discussion moves from opinion to evidence.
First step: apply it to a current project
If a digital job is already running, put the three questions to it. Is there a problem definition, a measure, a transition budget? What is missing shows immediately. Usually both of the last two are missing at once.
The Common Mistake
BU BÖLÜMÜN ÖZETİ
- Setting too many measures
- Writing the goal in tool language
- Leaving the transition budget for later
Three traps.
Setting too many measures
Choosing five indicators looks thorough. But none of them gets followed and none produces a decision. One measure does more work than five; a crowded dashboard never gets opened.
Writing the goal in tool language
“Go live with the system” is a task, not a goal. The goal belongs to the work itself: time shortens, errors drop. A tool is a route rather than a destination, and the two get confused often.
Leaving the transition budget for later
The software gets bought first and training gets considered afterwards. But when the money runs out, so does the training. Both lines have to be allocated at the same time.
Frequently Asked Questions
Sık Sorulan Sorular
There is no fixed ratio, but it should not be zero. In a small business this is usually time rather than money: a person spending half an hour a week, a few short training sessions, a day set aside for data migration. Putting those into a calendar counts as allocating a budget; money is not always required. What matters is that the line exists at all. When it is zero, the project ends at installation and use never begins.
Almost any job can be tied to a number. Customer satisfaction sounds abstract but complaint counts are concrete. Efficiency is abstract; quote preparation time is not. Measure a signal of the thing you cannot measure directly. Using an approximate measure beats using none, and searching for a perfect one usually means measuring nothing at all.
The preparation is one hour and a single page. The same questions apply to small jobs; only the answers are shorter. Small jobs are also the ones most likely to skip it — nobody asks, so the installation happens and stops there. An hour of preparation prevents a tool sitting idle for months.