The most useful thing a client ever told me about their own company was that urgent work got agreed at the water cooler.
Someone would catch someone else by the lifts, explain that a customer needed something, and it would get done. No ticket, no record, no way for anyone else to know it had happened or what it had displaced.
This was a company of more than a hundred people building software and hardware for the automotive sector. It worked, in the sense that things shipped.
What nobody could do was see the whole picture: which teams were overloaded, what the status of any global initiative was, or what had been quietly deprioritised to make room for the lift conversation.
They came to us asking for help implementing Jira properly. They were right that they needed it. They were wrong about what the first step was.
What needs to happen before you implement Jira? Before configuration, three things need to be agreed: who owns each stage of work, what states a piece of work genuinely passes through, and what "done" means at every handoff. Jira does not produce these answers. It encodes whichever ones you already have.
Why Jira Implementations Struggle
Jira is the most configurable tool most organisations will ever adopt. Every field, status, workflow transition, permission scheme and screen is a decision point.
When a company has already agreed how work flows, that flexibility is a gift. When it has not, the tool quietly converts each unresolved question into a configuration object.
Watch how it happens. Who signs off when scope changes? Nobody is quite sure, so an approval status gets added to cover it. What does "done" mean? Engineering and QA give different answers, so both get a status. A stakeholder wants visibility into something, so a custom field appears.
Six months later there is a workflow with fourteen statuses that nobody can report on.
Each of those statuses is a fossil of an argument that never finished.
This is what I mean when I say tooling mirrors your operating model. Jira will not impose one on you. It will reflect the one you have, at higher resolution and considerably faster than before.
If the underlying governance is unclear, a good implementation makes the confusion easier to see and harder to ignore. That is genuinely useful. It is also not what the people funding the project thought they were buying.
The Mistake Is Sequencing
Most companies buy Jira at the moment the pain becomes visible. Someone cannot answer a question about status, a release slips without warning, and the conclusion is that the team needs a proper tool.
Procurement is the easy part. Licences can be bought in an afternoon.
What cannot be bought in an afternoon is the agreement about how work actually moves through the company.
That agreement has to exist before configuration, because configuration is only the act of writing it down in a machine-readable format. Trying to discover your operating model during a tooling project means negotiating organisational politics under a delivery deadline, with an administrator waiting for answers.
Who Owns What, When Nobody Owns Anything
The hardest version of this shows up in companies that have grown without a dedicated project or product function.
Work gets coordinated by whoever notices it first. Priorities get set in the corridor. It works right up until the organisation gets deep enough that the person who notices first is no longer the person who can decide.
Jira has no way to represent "whoever notices first." It needs an assignee, a reporter, a component owner and a transition rule.
Before any of that can be configured, three questions need real answers:
• Who decides when scope changes, and does the answer change with the size of the change?
• What states does a unit of work genuinely pass through, as opposed to the states we would like it to pass through?
• What does "done" mean at each handoff, specifically enough that two people would agree whether a given ticket qualifies?
If those cannot be answered out loud in a room, they will not be answered by a workflow scheme.
How We Approached It
We opened with a discovery phase and did not touch Jira during it.
That ran as a series of online working sessions over several weeks, iterating on a map of the end-to-end flow, plus a full-day workshop on site that produced more progress in one room than the preceding fortnight of calls.
Worth saying plainly: the in-person day was disproportionately valuable, and we would not try to run this entirely remotely again.
What we were mapping was how work actually flowed, how teams actually interacted, what genuinely needed to be tracked, and where things were getting stuck.
The output was five things, and none of them required a licence.
A named owner for each active global initiative, so every significant piece of work had a person rather than a department attached to it.
A defined set of decision-maker groups, with responsibilities written down and the conditions that trigger each of them made explicit.
A visual map of the product workflow, showing every point where it branches, the dependency each branch creates on another team, and the places where it reliably slows down.
An agreement on who may submit an idea, and who is accountable for approving it and pushing it into production.
One specific broken handoff, fixed. There had been no defined route for a software R&D lead to request new hardware development from the hardware team. It had been happening informally, which is to say at the water cooler.
Only once that existed did we open the tool, and then we moved in phases rather than all at once. The changes hit the organisational and operational structure first. The tooling reflected them afterwards.
What the Tooling Looked Like Once the Process Was Settled
Three connected layers, each doing one job.
Ideas enter through Jira Product Discovery, using the simplest intake form we could design, moving through evaluation and management approval until an approved idea becomes an active global initiative.
Work gets tracked in Jira, on global schemes that standardise workflows, fields, screens and issue types across the board, with exceptions added only where a team genuinely needed one. Projects map to the manufacturers they build for, with dedicated spaces for the teams that needed their own. Every team has a board showing its actual workload and current focus, and the cross-team requests that used to happen informally now run as automated intake between projects.
Reporting sits in Confluence: an executive status template for each active initiative, and a single overview page listing all of them with status, due quarter and a note from the owner.
The three layers are linked. From any one of them you can reach the approved idea, the work underneath it, and the current status report in one click.
The honest outcome statement is this. We did not shorten a cycle time we had never measured.
What changed is that a company with no reliable visibility into its own global work now has a weekly cadence for reviewing all of it, with a named owner for every line.
Problems become visible and actionable before they become blockers, which is a different thing from moving faster, and more valuable.
Then, and Only Then, Map Jira to the Process
When you get to configuration, the discipline is restraint.
Structure projects around value streams rather than teams, because teams reorganise and value streams mostly do not. Let statuses represent real handoffs between people and nothing else. Standardise globally and allow exceptions only where a team can explain why.
Add a custom field only when a specific decision depends on it, and name the decision. Start with the smallest permission model that is defensible, because every custom scheme is a support ticket you have volunteered to receive forever.
Complexity should have to earn its place. The instinct to configure for every edge case on day one is the same instinct that produced the fourteen-status workflow.
Are You Ready to Implement Jira?
Run through these honestly before you start.
1. Can you draw your end-to-end process on one page without arguing about it?
2. Does every stage have a named owner rather than a team name?
3. Do you have a single agreed definition of done per work type?
4. Do you know who decides when priorities conflict?
5. Do you know which handoffs currently happen informally, and have you designed a route for them?
6. Have you identified who will own the configuration after go-live, with time allocated?
7. Can you name the three questions leadership wants answered, so reporting can be designed backwards from them?
More than two no answers means the tooling project is premature.
The right response is to spend a few weeks on the operating model first, which is cheaper than spending six months discovering it one custom field at a time.
The question I would genuinely like answered: has anyone seen a Jira implementation succeed where the process work happened afterwards? I have not, and I would like to be wrong about that.
Frequently Asked Questions
How long should discovery take before configuring Jira?
For a company of around a hundred people, a few weeks of iterative sessions plus at least one full day in a room together. Less than that and you are documenting assumptions rather than testing them.
What if we have already implemented Jira badly?
The sequence does not change. Map the process, agree the ownership, then rebuild the configuration against it. The difference is that you will also have to migrate data and manage the memory of the first attempt, which is why doing it in the right order the first time is cheaper.
Who needs to be in the discovery sessions?
The people who do the work and the people who decide priorities, in the same room. Discovery run only with team leads produces a map of how work is supposed to flow. You want the version where someone says out loud that it actually happens by the lifts.
Should Jira projects be organised by team or by product?
By value stream wherever possible. Teams reorganise; value streams mostly do not. At our automotive client, projects map to the vehicle manufacturers they build solutions for, with dedicated spaces only for the teams whose work does not fit that shape.
Do we need Jira Product Discovery as well as Jira?
Only if idea intake is one of your problems. If ideas currently arrive by conversation and nobody can say which ones were approved or why, a separate discovery layer is worth it. If your intake is already clear, adding it is extra surface area.
Still deciding whether Jira is the right tool at all? Start with Is Jira Right for My Company?.
Once the process is agreed, the harder problem is getting people to use what you built: How to Be Successful with Jira: Lessons from a Real Implementation.
PM Peer helps scaling companies get the operating model right before the tooling decision. If the checklist above produced more no answers than you expected, that is the conversation we have.