A new internal tool goes live on Monday. The announcement is sent, the training session is held, and the project team moves on to the next thing. A month later, half the team still uses the old spreadsheet "just for now".
This article is for a department lead or head of operations who owns the result of a launch. It gives a plan for the first thirty days, week by week, with one purpose for each week. It is about ordinary business tools, not about any specific product, and it assumes you have already tried the tool with a first user, as described in our article on picking the first user of a new internal tool.
Why the first month matters
People decide quickly whether a tool helps. If the first attempts are slow or confusing and nobody answers their questions, they go back to the old way and tell colleagues they did. Once that habit forms, it is much harder to undo than to prevent. Our article on change management and technology adoption explains why adoption is mostly about people; the first month is where that becomes practical.
Before day one
Three things need to exist before launch, otherwise the plan has nothing to stand on.
- An owner. One named person who answers questions and decides what happens to reported problems. If the answer is "the project team", nobody owns it.
- Two or three measures. Choose simple things you can count without extra tools, such as how many of the weekly tasks are done in the new tool, how long one typical task takes, and how many questions arrive. Write down the starting values from the old way of working, even if they are estimates, and label them as estimates.
- One list. A shared place, as simple as a table, where every problem or question is written with a date, the person, the task and the status.
Week one: make the first tasks work
The purpose of the first week is that everyone completes their most common task at least once in the new tool.
Run a short practical session on the real task, not a tour of every feature. Stay reachable: the owner should be available for questions at set times, and an answer should come within a working day. Check on the second day who has not logged in or has not tried the task, and ask them directly what stopped them. Silence is more often confusion than refusal.
Do not add requests for improvements in this week. Write them on the list and say that they will be looked at in week three.
Week two: collect and sort problems
The purpose of the second week is to find out what actually hurts.
Go through the list every other day. Sort each item into one of three groups: a mistake in how the tool is set up, something people have not been taught, or a wish for something different. Fix setup mistakes at once, because they erode trust fastest. Answer teaching items in a short written note that you can reuse. Park wishes with a reason.
At the end of the week, ask three or four people one question: "What did you do this week the old way, and why?" The answers show you where the tool does not yet fit.
Week three: read the measures and decide on changes
The purpose of the third week is to look at facts and choose a small set of changes.
Compare your measures with the starting values. A rise in usage with the same number of questions is a good sign. Many questions about one step usually means that step needs a change or a clearer note. Little usage by one group usually means their task was not covered in training.
Choose no more than three changes for the coming weeks. Give each an owner and a date. Tell the team what you chose and what you left out, and why. People accept a "not now" much better when they hear the reason.
Week four: remove the old way and close the loop
The purpose of the last week is to make the new tool the normal way.
If the old spreadsheet or process still exists, agree a date when it becomes read-only, and keep that date. Running two systems indefinitely doubles the work and keeps people unsure which one is right. Make a copy for reference before you close it.
Then hold a short review with the owner and two or three users. Look at the measures once more, go through the list, and write a one-page note with three headings: what to change, what to teach, and what to leave alone. That note is the handover from the launch into normal operation.
What to avoid
- Announcing success too early. A launch is not finished when the tool is live; it is finished when the old way is gone.
- Answering slowly. An unanswered question in week one costs more than any missing feature.
- Fixing everything. Small, frequent problems come first. Rare ones can wait.
- Collecting measures you will not read. Two simple numbers you check every week are better than ten you never open.
If the tool was built to replace a shared spreadsheet, the same plan works at a smaller scale. Our article on moving from a spreadsheet to a small internal tool in 30 days describes how to build and switch over; this plan covers what comes after the switch.
What to do this week
Name the owner of the launch. Write down the two or three measures and their starting values. Create the list of problems. Then put four dates in the calendar, one for each week, with one sentence on the purpose of that week.
Sources
- Our related articles linked above.
- The plan is a general approach and does not describe a particular company, tool or supplier.
