Guide · How to digitise
Performance drops in the first weeks after go-live and climbs above the old level from month three. The stages, the critical moment and seven strategies.
In short
Updated September 2026 · 9 min
The company moved from Excel and email to a new system, and two weeks later reports take longer and someone proposes going back to how it was. We go through the same valley with every client who starts on the platform, which is why we budget 30 days of intensive support for exactly the critical period. This guide covers what the Valley of Despair is, in which weeks projects die and the seven decisions that make it shorter.
The Valley of Despair is the period when performance drops after a major change, before climbing above the old level; every organisation goes through it. A new system, a new process or a reorganisation produce the same drawing: a plateau at today's level, a drop, a slow climb and a higher plateau. The good news is that the drawing repeats, so it can be planned for.
The model starts from the stages of adapting to change described by psychiatrist Elisabeth Kübler-Ross. John Fisher adapted them for organisations in the Personal Transition Curve, presented in 1999 and revised in 2012. The version in this guide is the one simplified for software go-lives, with five stages instead of twelve.
The drop has a simple cause. The old processes no longer work and the new ones are not yet understood, so every operation takes longer and produces more errors. It is not a sign that you chose the wrong solution; it is the sign that the change has started.
The curve also carries a less comfortable message: the old level is only exceeded in the fourth stage. Weeks, not days, pass between go-live and the first visible benefit, and the decision that matters is taken in that interval. Whoever expects the benefits in week 2 will look for them exactly when they are furthest away.
The five stages of the curve
Everything “works”: Excel is slow, but everyone knows it and nobody asks where anything is.
The system is live, the old processes no longer work, the new ones are not understood; productivity drops and the temptation to quit appears.
The team understands the new processes, double-checks and moves slowly, but without chaos.
The new processes become natural; the first visible benefits appear and resistance turns into acceptance.
The new way of working is “normal”, performance exceeds the old level and nobody wants to go back.
The dangerous moment is not go-live but weeks 3–5 after it, when chaos peaks, the benefits are not visible and someone proposes postponing. At go-live there is enthusiasm and tolerance for errors. By week 4 the tolerance is used up, and the first fast report has not appeared yet.
The lines in the meeting are the same everywhere: “this software does not work”, “let's wait a bit”, “I told you so”. None of them describes the software; all of them describe the stage. The gap between the line and the reality is what the decision-maker needs to see.
Postponing is abandonment under another name. You have spent money, time and energy and gone back to where you started, with licences paid and data migrated for nothing. The cost is paid a second time on the next project, when people remember that “we tried that and it did not work”.
Nobody warns you. Software vendors sell a linear trajectory: we implement, we train the team, everything gets better. A consultant who tells you week 4 will be the hardest is not discouraging you; they are giving you the date on which not to take decisions.
What is said in the meeting
What is actually happening
An MEP (mechanical, electrical and plumbing) firm with 40 employees moves from Excel and WhatsApp to one system; the first eight weeks look alike anywhere. The firm is fictitious; the scenario is the one we see at every go-live. Before the start, everything “works”, slowly and with information lost:
| Process | How it worked |
|---|---|
| Material orders | Excel sent by email to the manager |
| Project tracking | Shared Excel file on Google Drive |
| Reporting | Manual, every Friday, 3 hours |
| Documents | PDFs by email, folders on local drives |
| Team communication | WhatsApp and phone calls |
No line in the table is red, and that is exactly the trap of certainty: information is lost in silence, and nobody measures what the Friday report costs.
In weeks 1–2 the system is installed and the team trained. The first orders are entered wrongly, the manager cannot find the screen from the demo, two technicians refuse the mobile app, and the director receives an incomplete report. In weeks 3–5 half the team has gone back to Excel “temporarily”, the data sits in two places and someone says in the meeting that they warned everyone.
From week 6, those who stayed in the system see the first benefits. The Friday report comes out in five minutes instead of three hours, and the manager sees every project on one screen. The team starts asking for new features, and Excel becomes the “backup”, then disappears.
From month three, Excel is closed, the data is in one place and the director asks why they did not do this sooner. Between those two moments sits week 4, when the situation looks like this:
The Valley cannot be removed, but its depth and length depend on seven decisions taken before and during go-live, none of them about software. Three are taken before the start, one at the start and three in every week of the Valley.
Before the start, show the team the curve and tell them the first three or four weeks will be harder, that it is normal and that it is temporary. An expected difficulty is tolerated; an unannounced one is read as a defect.
Also before the start, pick two or three internal champions, people open to change, and give them early access, extra training and the explicit role of helping colleagues. Colleagues listen to them better than to an external consultant, because they talk about the same orders and the same projects.
The third decision is the calendar. Plan the go-live in a quiet period, not at peak season, and accept from the outset a drop in productivity in the first weeks. When the drop is in the plan, the pressure to go back to the old way drops with it.
At the start, remove the way back. Run the systems in parallel for one or two weeks, then switch for good. As long as Excel remains an option, the team goes back to it at the first difficulty. It is the most contested decision and the most effective one.
During the Valley, celebrate the small wins: the first automatically generated report, the first order without errors, the first month without manual reconciliation, said out loud in the meeting. Provide constant support, not one training followed by “figure it out”: a short weekly question session, a dedicated channel, one-page guides for the common operations. And measure, sharing the numbers every Friday, even if they improve slowly.
The metrics are defined before the start; otherwise in week 4 you have nothing to compare against and the discussion stays about impressions. Three or four are enough: the time per order, errors per week, reporting time and one satisfaction question for the team.
Before and during go-live
The model describes adopting a real change in how people work; in three situations the drop is not the Valley and waiting does not help.
Before go-live, show the team the curve and say in which weeks it will be hard; it is the 30-minute meeting that changes the most. If the team is already in the valley, the meeting is the same, it just happens today. If you are still choosing what to digitise first, the guide on digitisation before automation explains why the order matters.
It depends on the size of the change and how quickly the old systems are closed. At a company with a few dozen employees changing one core process, the bottom is in weeks 3–5, the climb starts in week 6 and the new way of working feels normal from month three. Running in parallel with Excel makes it longer.
After week 6, the same operations must take less time than in Excel, at least for the people who use the system daily. If that does not happen, it is a product or configuration problem, not a stage. The Valley of Despair is recognised by what follows it, not by how bad week 4 feels.
Yes, after one or two weeks of running in parallel, long enough to be sure the data is in the system. As long as Excel remains an option, the team goes back to it at the first difficulty, and the data ends up in two places. The backup is useful for a week and becomes an excuse from the third.
You do not quietly relaunch the system as if nothing had happened. You name the problem in the meeting, set a date from which Excel is closed, give daily support for the first two weeks and share the metrics every Friday. The second attempt needs more structure than the first, not less.
One workflow goes live on a real project, with a success criterion set together.
One email a month, only when we publish. Nothing else.
Eurostat 2025: Romania is last in the EU for AI adoption in enterprises again, 5.2% against a 20% EU average. What the gap means for SMBs and where to start.
Read →AI automates well only what it understands, and it understands only what is clean. Digitisation → context → automation, explained on one real case.
Read →Linear and scalable growth are the two ends of one spectrum. Four questions show where your business sits and how automation moves it to the right.
Read →