The tool is the false problem
JSM installs in a few minutes and is configured in a few hours, a few days for the most complex projects. What takes weeks, or even months, is everything else: aligning all the stakeholders on the service catalogue, the RACI for each process and the target governance.
As we like to say at BleuLemon, deploying JSM Cloud or an equivalent is an organisational project with a tool inside it.
The 7 main key success factors, detailed here:
- Get the scoping right
- Sponsorship and governance
- Prepare the service catalogue
- Involve users and take care of the customer experience
- Identify KPIs upstream and keep SLAs simple
- Do not cut corners on change management
- Set up the run and think continuous improvement
Scoping: define the target before configuring
Scoping is an essential stage, and also a trap you must avoid getting bogged down in, at the risk of spending months in meetings and locking yourself into choices that sometimes turn out badly when they meet the real world. It is important to accept a degree of uncertainty during scoping.
The objective
Identify the stakes, the scope, the stakeholders, the integrations, the release batches, the architecture, the KPIs and the target high-level plan.
Everything needed to answer the questions: who, what, when.
The traps
- Diving into detailed design at this stage, defining workflows and forms. The “how” waits for the delivery phase.
- Scope creep: define an initial scope and stick to it as far as possible. Related or additional needs will be dealt with in a second phase.
What we recommend
JSM can be configured in minutes, which makes it easy to prepare small visual “demos”. They make it possible to take decisions and settle trade-offs on real cases specific to each team. A “good” Atlassian consultant will know how to identify them, guide you and adjust during delivery, without burying you in jargon and workshops from the scoping stage onwards.
Sponsorship and governance: who decides, who arbitrates, who will administer?
Define the key roles during scoping and involve the business from that point on, as the future “customers” of the solution. That is what avoids the trap of the “IT for IT” project.
What we recommend
- A Product Owner who is available and able to take decisions and enforce trade-offs, relying if needed on a committee identified upstream.
- One or more “application owners” in charge of running the solution, with their future availability in mind. A “living” application always needs some administration work, to optimise it or adapt it as processes change.
- A sponsor who can prioritise and champion the project with the organisation's top management.
The trap
Beware of the myth of “zero administrators once in run”. It does not survive a single real deployment. Rely on application maintenance if needed.
The service catalogue: why it is the real heart of the project
The service catalogue answers the questions: what and who, for the project.
It is an internal IT reference, and it is defined upstream:
- What are the types of service requests and incidents?
- Who are the customers?
- Who handles each of these types of requests or incidents?
- Within what time?
- Who approves them?
- Do some request types contain sensitive or confidential data?
The trap
The one we meet most often: trying to merge the service catalogue and the JSM portal. The service catalogue has to be defined upstream; it is an internal IT reference.
Once again, a “good” consultant will then translate all of this into a user portal that is simple, ergonomic and adapted to the organisation's “business” language.
What we recommend
Assets, and not just for the CMDB. Now that Assets is included in the standard “Service Collection” offer, every JSM customer can build an advanced, structured and scalable service catalogue with this module. More than IT assets, what we build with our customers in Assets are genuine application and functional reference sets, a true integrated database.
The key benefits
- Advanced automations, based on the different attributes of each object.
- Simpler administration: no need for archaeology in scripts or automation rules… Assets is updated as easily as an XLSX file.
- Endless possibilities for change (or almost…). The combination of the Assets reference set, automations, workflows and custom fields lets us cover 99.9% of our customers' use cases.
Feel free to challenge us if you doubt it ;)
The trap
The Assets trap: a reference set that quickly becomes obsolete. Identify upstream the owner or owners of each piece of data in the reference set, to make sure it is updated regularly.
Portal user experience: the tip of the iceberg
The help centre and the portals are the only visible face of the project for 90 or even 99% of users. It is therefore essential to take the greatest care over the branding, the structure and the clarity of the portal.
The traps
- “ITIL” language. Meet the end users to understand their vocabulary, their maturity and their main future uses.
- Over-qualification and endless forms with many mandatory fields… Collect “only” the data needed to “route” and prioritise incoming requests.
What we recommend
A rule of restraint: 5 well-designed request types with 5 fields each are better than 30 detailed forms that nobody can find.
Email is often the first channel of exchange before JSM is introduced. Teams can accept it for a while and gradually convince their customers of the portal's advantages, or opt for a sharper transition, with an automatic reply and a link to the portal on the team's mailbox.
Our experience at BleuLemon
Except for very “mobile” customers, who use support from their phones or tablets, requesters understand what is at stake and most often accept using the portal quite easily.
Reporting and SLAs: measure what you need, not what the tool can produce
This is probably the factor most often dealt with last, and the most expensive one to catch up on. A dashboard can be built in an hour. Data that is missing because the field did not exist at the start can be recovered through a history migration, or not at all.
The objective
Identify, from scoping onwards, the questions the future reporting will have to answer. Not the charts people want, but the decisions they must inform: should a team be reinforced? Which request types should be automated first? Is the service level being met, and for whom?
From these questions follow the data to collect, so the fields, so the forms, so the catalogue. That is exactly why the subject must be tackled during scoping, not after a few weeks of run.
The traps
- Measuring activity rather than the service delivered. The number of tickets closed per agent is easy to produce but rarely useful… The first response time perceived by the requester, the reopening rate or the share of requests handled with no human intervention tell a far more usable story.
- Confusing contractual SLAs with steering SLAs. The two have neither the same purpose nor the same need for precision. A contractual commitment must be enforceable, so simple, documented and calculated on an indisputable calendar. A steering SLA, on the other hand, is a “notional” commitment that measures a line of work defined by the team or management. It can be more complex and tolerate a little more “vagueness” in its calculation.
- Multiplying commitments. A response time and a resolution time are enough in the vast majority of cases. Stacking three or four SLAs per request type mostly produces indicators nobody looks at and alerts everybody ignores.
What we recommend
- Define the indicators before go-live; otherwise you measure what the tool can produce rather than what you need.
- Few commitments, but achievable and understood. An SLA a team cannot meet with its current headcount is not a commitment, it is a debt.
- Decide during scoping what native JSM reporting will cover and what will need an additional tool, such as Atlassian Analytics or a BI solution. The answer shapes the budget, and sometimes the choice of licence.
- Plan an SLA review after a few months of operation. The first commitments are hypotheses. Real data will show which ones were right.
Change management: two workstreams, not one
Training agents and communicating with users are two separate workstreams, with different audiences, messages and timelines. Treating them as one is the most frequent mistake, and the most damaging: support teams end up absorbing the requesters' confusion on top of their own upskilling.
What we recommend for agents
- Train on the customer's actual configuration, not on a generic demo. An agent who has seen their own catalogue, their own queues and their own automations is operational. An agent who has attended a general JSM presentation will have to relearn everything on go-live day.
- Clearly define what belongs to day-to-day administration and what needs a decision. Without that boundary, the slightest change request goes back up to the project, or is never dealt with.
- Involve agents in the delivery phase. Those who took part in the design workshops naturally become champions for their colleagues. It is free training, and far more effective than a slide deck.
What we recommend for users
End users do not need training. They need to know where to click, what they gain from it, and that their request will not vanish into a black hole.
The message fits in three points: here is the new entry point, here is why it is better than the old one, here is what happens after you send your request. Everything else is noise.
The portal must be clear enough not to need a user guide. If instructions are indispensable, the problem lies in the portal, not in the communication.
The traps
- Communicating on go-live day. You need to announce, remind, then support. A single announcement, however well written, does not survive an inbox.
- Rolling out to everyone at once. A pilot with a volunteer team for a few weeks makes it possible to fix what needs fixing before the whole organisation forms a first impression. A bad first impression of a support portal costs you for months.
- Overlooking visible quick wins. A request that used to take three days and is now resolved in two hours thanks to an automation is the best possible argument for the rollout. Identify it early and put it forward.
Our experience
The real adoption indicator is not the number of tickets created in the portal; it is the drop in requests outside the official channel: direct emails to agents, Teams messages, people stopped in the corridor. As long as these parallel channels persist, the project is not finished, whatever the dashboards say.
Run and continuous improvement: the project does not stop at go-live
A JSM project declared finished on go-live day is a project that will slowly deteriorate. The catalogue ages, processes evolve, teams change, and the platform transforms itself at the pace of Cloud releases.
The objective
Know who administers, and with how much time. That is the question to ask during scoping, and to ask again before go-live. As mentioned above, the myth of zero administration once in run does not survive reality: a living application takes time, if only to adjust a form, add a request type or bring in a new team.
Two models work, provided they are owned:
- An identified in-house skill, with time genuinely allocated and protected. An application owner who is handed the platform on top of an already full job will end up not administering it at all.
- Application maintenance, which guarantees availability and expertise, provided the ability to decide on functional changes stays in-house.
Make the review a ritual
A quarterly review of the catalogue and the SLAs is enough, and it must have a deliverable: what is added, what is changed and, above all, what is removed. A request type used three times in a year clutters the portal without serving anyone. Removing is an act of continuous improvement just as much as adding.
Feed a backlog of changes from the pilot phase onwards. Not every idea will be kept, but a tracked request is a request that can be decided on, whereas a verbal request turns into frustration.
The Cloud-specific trap: keeping watch is not optional
On JSM Cloud, changes arrive without anyone asking for them. New features, interface changes, licence adjustments, changes to data policies: all subjects that can affect the configuration, the costs or the compliance of a platform in production.
In practice, this means following release announcements and licensing changes, anticipating regulatory impacts, particularly on data location and data use for European organisations, and testing significant new features in a test environment before opening them to the teams.
It is a few hours' work per quarter for an organisation that keeps to it, and an upgrade project for one that discovers three years of changes all at once.
What to remember
If you only remember 3 reflexes:
- Deal with the “who” and the “what” before the “how”.
- Embrace restraint: few request types, few fields, few SLAs, but understood and met.
- Plan from scoping who will administer the platform, with how much time, and on what review cycle.
The rest, the configuration, goes quickly. It is even the simplest part of the project.
PS: we said in the introduction “almost never” technical. The only truly technical limit of the tool we have come across, one that can derail your project or turn it into an unmaintainable monster: wanting a 100% multilingual tool, on the portal and above all in the agents' back-office interface… That is clearly the limit of JSM Cloud today.
