The board is configured. The workflows match the process. Training happened.
Six weeks after go-live, three teams are updating Jira the morning of the steering meeting and running their actual work somewhere else.
This is the most common failure mode I have seen, and it is a change management failure presenting as a tooling complaint, which is why it usually gets escalated to the wrong person.
How do you make a Jira implementation successful? Treat it as an adoption problem before a configuration problem: design it with the people who will file the most tickets, train each team in the week it starts using the tool, and read every workaround that survives go-live as a requirement you missed. Most implementations that fail skip all three.
What the Shadow Spreadsheets Are Telling You
When a team keeps a spreadsheet after go-live, the instinct is to read it as resistance and respond with enforcement.
That reading is almost always wrong. The spreadsheet exists because it answers a question the new setup does not, and the person maintaining it is doing unpaid work to stay effective.
What people resist is losing the workaround that was keeping them effective.
So find the spreadsheets. Every one of them is a requirement you missed, stated more precisely than any requirements workshop would have produced.
Ask what question it answers, who reads it, and what happens if it disappears. The answers fall into three buckets: a view Jira can already produce and nobody knew how to build, a view Jira can produce after one configuration change, and a genuine gap that tells you something about your process rather than your tool.
The shadow system is not always a spreadsheet. On our automotive engagement it was partly the previous tool, still running while it was being deprecated, and partly conversations by the lifts.
The same principle applies. Anything people are still doing outside the system is information about what the system does not yet do for them.
Handled that way, the shadow system becomes the most valuable artefact of the whole rollout. Handled as insubordination, it goes underground and you lose the signal.
Buy-In Has to Happen Before Go-Live
The sequence most rollouts use is design, configure, train, launch, then handle objections.
By the time objections are handled, people have formed their opinion. Opinions about tools are unusually durable.
The version that works puts the people who will file the most tickets into the design conversation early enough that their objections change the configuration.
This is slower, and it only works if the input is real. If nothing in the design changes as a result, the team will notice, and you will have spent the goodwill without buying anything.
Choosing your pilot team
There are two defensible strategies here, and it is worth being deliberate about which one you are running.
You can pilot with the most receptive team. That is what we did, and it worked: you get a working reference implementation, a group of credible internal advocates, and momentum going into the harder teams.
Or you can pilot with the hardest case, which surfaces design problems earlier and costs you the easy win.
The mistake is picking the receptive team by accident, calling the result validation, and then being surprised when a difficult team breaks the design three months later.
Choose the friendly pilot on purpose. Then go looking for the stress cases yourself.
Roles and Permissions: Start Embarrassingly Simple
The pressure during setup runs entirely toward complexity. Every stakeholder has a case for restricting something, and each sounds reasonable in isolation.
Granting them all produces a permission model nobody can explain, which then blocks work at the worst possible moment.
Start with the fewest schemes that meet your legal and commercial obligations. Standardise globally and add exceptions only where a team can articulate why. Add restriction only when a specific incident demands it, and write down which incident.
A permission model you can describe in two sentences is worth more than one that is theoretically correct. The theoretically correct one will be routed around by people who need to get work done.
The same restraint applies to fields and issue types. Every field is a small tax on every person who files a ticket, collected forever, usually in service of a report someone requested once.
The Training Mistake We Made
We opened with a single company-wide training session. It was well attended, it went well in the room, and it did not stick.
The reason is obvious in hindsight. Most of the people in that session had not yet touched Jira and were not going to for weeks.
You cannot retain instructions for a tool you are not using, on a process you have not hit. What actually registered was the message that a new tool was coming. That has some value as change communication and very little as training.
What we do now, and what is working considerably better, is team by team.
We scope and gather requirements with the team leads first, so the configuration reflects how that team really works. Then we train the whole team at the point they are about to start using it. Then a feedback session, where the things that do not fit come back to us and get changed.
Training has to arrive within days of the work, and it has to cover what that specific role does.
A wiki page is not a substitute, because nobody reads documentation mid-task and slightly annoyed.
What helps is a one-page reference per role, a named person inside each team who has been briefed properly and can answer a question in three minutes, and a standing session about a month after each team goes live, once real questions exist.
That last one is consistently the highest-value hour in the whole rollout.
Five Signs Your Jira Setup Is Working
None of these are about Jira.
1. Leadership stops asking for status decks, because the answer is already visible.
2. The shadow systems disappear on their own, without anyone being told to stop.
3. Boards get updated while the work is happening, rather than the morning before the meeting.
4. A new joiner can file a correctly formed ticket in their first week without asking.
5. Reports are generated rather than assembled, and nobody reconciles two versions of the same number.
If none of those are true a quarter after go-live, the problem is very unlikely to be in the configuration. Another round of workflow changes will not fix it.
I am interested in one thing in particular from anyone who has run a rollout: did you find the shadow systems, and what did they turn out to be asking for? That question has produced more useful information for me than any formal requirements process.
Frequently Asked Questions
Why do Jira implementations fail?
Almost always on adoption rather than configuration. The common pattern is a technically correct setup built without the people who file the most tickets, rolled out with generic training, then defended by enforcement when teams keep working somewhere else.
How do you get teams to actually use Jira?
Change the configuration in response to their objections before launch, train them in the week they start using it, and make sure a colleague rather than a helpdesk answers their first questions. Enforcement works last and least.
Should we roll Jira out to everyone at once or team by team?
Team by team, in our experience. A single company-wide launch means training people weeks before they need it, on a configuration that reflects nobody's specific way of working. Sequential rollout is slower on the calendar and faster to adoption.
What should we do about teams that keep using spreadsheets?
Treat each one as a requirement rather than as resistance. Ask what question it answers and who reads it. Most turn out to be a view Jira can already produce, or can produce after one change. The remainder tell you something true about your process.
How long before a Jira implementation is actually adopted?
Expect a quarter per team from training to habit, assuming training lands close to the work and someone inside the team can answer questions quickly. If nothing on the five-signs list is true after that, the problem is not the configuration.
The process work that came before this rollout is covered in What Needs to Happen Before You Implement Jira, and the engagement is summarised on our case studies page.
PM Peer runs Jira implementations as change programmes with a configuration component, in that order. Tell us what is not sticking.