Modernization projects get planned either too big or not at all. Too big means: one year, one outcome at the end, one number a board will not approve. Not at all means: tidying happens on the side, and after six months nothing is different.
This article describes the shape that has worked most often for me: twelve weeks, with a result after every block and a decision at the end. It is not a template plan for every system, it is an order of work and the reasoning behind it.
Important up front: twelve weeks do not modernize a system. They bring it into a state where modernization becomes plannable, and they deliver the first real rebuild as evidence.
Why twelve weeks
The number has two reasons, and neither is technical.
A quarter is the unit companies decide in. A project fitting that frame needs no special treatment. One that goes beyond needs approval across several cycles, and it gets lost in there.
After three months the starting position is a different one. People move, priorities shift, a competitor does something. A plan spanning a year plans against a world that no longer exists by the start of the fourth quarter.
From that follows the rule carrying the whole shape: after twelve weeks a decision is due, not a continuation. Either the next twelve weeks get agreed because the result convinces, or the project ends in a state that stands on its own.
That is the difference to a plan stretched across years: every block has to end so that stopping afterwards is not damage.
Weeks 1 and 2: seeing and being able to go back
The first block touches no application code. That is the decision questioned most often and the one that pays off most clearly.
Three things appear.
A baseline. Response times as percentiles at the outer edge, error rate split into expected and unexpected, saturation of the resource that runs out first. One week of measurement, so that the rhythms are in there once in full.
A reproducible route to the server, and a way back that has been taken once. Where a pipeline already exists, that is half a day. Where files get uploaded, it is the largest single item of the block and the most important one.
An environment where things can be tried. With data resembling the real thing. Without it, every later change is an intervention on the living object.
At the end of week two nothing is modernized and three things are possible that were not: measuring, shipping, rolling back. That is the state everything else builds on.
Weeks 3 and 4: the net around the first place
Now the decision is made which part gets rebuilt first, by two criteria: it changes often, and a failure there is annoying but not existential.
A net of tests appears around that part. Not across the system, there. The tests pin down what the system does today, bugs included, because that is the baseline for everything after.
This block regularly produces the first uncomfortable finding: a place where behaviour cannot be pinned down because it depends on time, randomness or a third-party system. That is not a delay, it is a result. It says something about the cost of the rebuild, early enough to change the shape.
In parallel, static analysis starts in this block, with the existing state frozen. That costs half a day and applies to every change from then on.
Weeks 5 to 8: the first real rebuild
Four weeks for the first rebuild sounds like a lot. It is not, because two things happen at once in this block: the rebuild itself, and learning the procedure.
The rebuild gets cut into two releases with a switch between them. First the new path runs for internal users, then for a share, then for everybody. Anybody thinking that is excessive has misread the purpose: it is not about this one feature, it is about the team knowing afterwards how such a thing is done.
The block includes a measurement point: the numbers from week one get taken again. What got better is then established, and what got worse as well. Both get written down, because the decision at the end rests on them.
And a rule protecting this block: the scope does not grow. Whatever turns up during the rebuild and does not belong goes on a list. The list is a result of the project, not an extension of it.
Weeks 9 and 10: the second rebuild, by the team
This block is the actual test of the whole project, and it is the one most often cut when things get tight.
The second rebuild is done by the team. Whoever built before reads the change set and answers questions. That costs pace, noticeably: two weeks for something that would be finished in four days.
What you get in return is the answer to the only question that really counts after twelve weeks: can the team carry on alone? Without this block the answer is a hope.
The timing is deliberately not at the end. Putting the transition into the final two weeks leaves no time to react to what it turns up.
Weeks 11 and 12: the buffer, and what it really is
Two weeks with no content look like waste in a plan, and in every negotiation that is what gets cut first. They are the reason this shape holds.
In practice those two weeks always fill up, with three things.
Whatever took longer in weeks 5 to 8. In almost every project there is one finding that costs a week. Without a buffer it pushes everything after it, and the first thing to fall is weeks 9 and 10.
The clean-up. The switches from the first rebuild get removed, the old path gets deleted. That is the part never done as a separate ticket and the one deciding whether the system is simpler afterwards or more complicated.
The decision paper. What was measured, what it cost, what would come next and what that would probably cost. Two pages, with numbers from your own company.
Anybody cutting the buffer cuts those three from the bottom up. What is left at the end is a project with no evidence and a system with duplicate paths.
What the price of these twelve weeks is made of is covered in What a modernization costs.
The place where every plan tears
In the projects I have been part of it is always the same place, and it is not technical: the team is not as available as planned.
The sequence is predictable. Fifty per cent of two people's time is promised. In week three there is an incident, in week five an urgent request from sales, in week seven somebody is ill. In the end it was twenty per cent, and the plan assumed fifty.
Three things help, and all three have to be settled in advance.
Fixed days rather than percentages. "On Tuesdays and Wednesdays Ms K. works on the project" is enforceable. "Fifty per cent" is not, because the share is always whatever is left over.
A named stand-in for day-to-day work. Without one, every incident is an interruption of the project.
A weekly look at the actual time spent. Not as control, as an early warning: if it is visible in week three that it is twenty per cent, the shape can be adjusted. In week nine it cannot.
The third point is the one done least often and the cheapest.
What the division of labour with an external looks like here is covered in Modernizing with an external freelancer.
What stands there after twelve weeks
At the end there is no modernized system. There is a system on which modernization is possible, and the difference can be named.
- Numbers rather than feelings. Response times, error rates and lead time before and after, from your own company.
- A way to ship changes and roll them back, rehearsed rather than described.
- A net of tests around the part being worked on, and an analysis checking every new line.
- Two completed rebuilds, the second of which came from the team.
- A list of what turned up and did not belong, with an assessment.
With those five points the decision about the next twelve weeks is a different one: it rests on experience with this system and this team rather than on an estimate. And if it comes out negative, what remains is a system that is easier to operate than before.
What those twelve weeks roughly cost and how to weigh them against the state without them belongs in the paper from week eleven. Why the big push in one go almost always fails is covered in its own article, and this shape is the answer to it.
How I cut and run such projects is on its own page.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
