Building the perfect ITSM solution: How Jira Service Management Prototyping delivers results
Are you tired of expensive and inflexible IT service management (ITSM) solutions that don't meet your current business needs? If so, you'll want to keep reading.
- February 28, 2023
In this blog, we’ll introduce you to the Jira Service Management Prototyping approach, which offers an iterative and incremental process to configure, test, analyse, and refine Jira Service Management. Our prototyping approach allows customers to collaborate and provide continual feedback to ultimately build a fully functioning Jira Service Management solution that meets their needs. By the end of this blog, you’ll understand why Jira Service Management Prototyping is a faster, more flexible, and cost-effective way to build the perfect ITSM solution that will help you deliver value quickly while accommodating changing business needs.
Jira Service Management Prototyping
When a customer wants to set up Jira Service Management, following a discovery engagement, we typically help them build a Jira Service Management implementation that we initially refer to as the “prototyping” stage.
What is Jira Service Management Prototyping?
Our design and implementation methodology is based on a cyclic process of prototyping, testing, analysing, and refining the Atlassian products. Based on the results of feedback the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a final design and configuration of Jira Service Management.
During the prototyping phase, customer collaboration and interaction with the Jira Service Management product is used as a form of continual feedback for informing and evolving the configuration, as successive revisions, or iterations of the product’s configuration are implemented.
We will continually collaborate with the customer to build a fully functioning Jira Service Management service project that meets their needs. This involves initial activity to apply the configurations and customisations required to adapt Jira Service Management’s out-of-the-box templates. This will involve tailoring of the customer portal, issues types, automations etc.
The customer will use this implementation in real world scenarios at a smaller scale over a period of time (maybe focusing use on a certain team or service) so stakeholders can provide feedback allowing for changes to be made incrementally. This could be a short period of or a much longer time frame – it really depends on individual customer circumstances.
Once the customer is satisfied with the implementation, we will move to the next phase: go-live and deployment. This could involve scaling up and adding additional users and / or transitioning users from an existing system. If the customer is transitioning from a pre-existing Service Management solution, a short term pilot would normally run in parallel with the existing system – typically for 1-2 weeks – to iron out any potential issues.
This approach is not to be confused with a Proof of Concept (PoC) which is traditionally a demonstration of an abstract concept, “can Jira Service Management do this or that?” The prototyping phase is simply a build phase that incorporates a continuous loop of feedback and incremental improvement that increases the implementation’s likelihood of being fit for purpose when fully deployed. The intention is to evolve a working solution that meets the customer needs, provides an opportunity to share best practices, and introduce it into the business in the most effective and efficient way.
Why iterative prototyping?
Often, we work with customers using a variety of legacy/enterprise ITSM tools. The resulting implementation was often a product of a significant upfront services engagement a number of years ago. Customers in this situation often report that they are evaluating new ITSM tools for a number of reasons:
- The initial configuration of the existing system may no longer be suitable for current business needs.
- Adapting the deployment may require specialist consultants, so takes time and is expensive.
- Licensing costs of some enterprise ITSM may no longer represent the best value for money as customers often realise that they are paying for a feature set that they don’t fully utilise.
We see the following advantages of a Jira Service Management Prototyping approach:
- Minimises risk & disruption – changes are made incrementally and not all at once, with continuous feedback from key internal stakeholders.
- A solution fit for purpose – the incremental approach means configurations are robustly tested over small increments. There is an increased chance the final solution is aligned with your goals and delivers business value. We consistently receive extremely positive feedback from customers following implementation.
- Suits Jira Service Management – Atlassian have greatly improved the templates and pre-configurations that come with JSM out of the box. Quite simply, fewer services are required to implement JSM than once needed.
- Continuous Feedback – In Jira, there are normally multiple ways of doing the same thing. Prototyping allows continuous feedback from stakeholders as the system is configured. This ensures the resulting system is suitable for customer requirements.
- Provides a coaching and mentoring opportunity for the customer and for the solution architect to share Atlassian and industry best practices that are incorporated into the final design.
Hands On / Hands Off?
One of the most attractive features of JSM comparatively is its speed of deployment & flexibility. This can help customers achieve a rapid & sustained ROI as they end up with a tool that not only delivers value quickly but also has the capability to easily accommodate changing business needs in the future.
Certain other enterprise-class ITSM solutions, whilst being very comprehensive and impressive, often require significant input from specialist consultants to both set up and change. This can make it expensive, and takes more time to stay on top of everything post-implementation to ensure you’re continuing to deliver value. It’s not uncommon to find users just bypass inadequate and inflexible systems creating a whole new set of problems. What’s wrong with Excel & email anyway :-).
Clearvision’s JSM projects include quite a high amount of mentoring, training & support in the mix in our projects. This supports hands-on involvement from the customer, and for a good reason. The degree of customers’ hand on involvement will vary, but the customer always needs to be present. Our intention is to provide the knowledge share to upskill customers so they can effectively manage JSM relatively autonomously in the future. As the saying goes, if you teach someone to fish, you feed them for a lifetime! Going to live is not the end.
Clearvision provides a “Total Support” packaged offering that includes break-fix & admin support, solution consultancy advisory, mentoring & training services. This ensures customers have access to required expertise as and when required post go live.
Neither Clearvison nor Atlassian possesses a crystal ball. However, the only thing we can guarantee is that something will change, and your business will have to adapt in order to deal with it. JSM is a great platform that helps customers achieve this.
A Word About Migrations – Customers who are moving to JSM from another ITSM tool may want to explore migrating key service management data, such as Asset/CMDB records, into Jira Service Management. We advise caution and ask the following questions.
Purpose of Migrating Data? Is there a genuine business need for this going forward? If it’s just records and auditioning purposes, there are likely more appropriate and cost effective options.
How Useful is that Data Likely to Be? A key aspect of Service Management is effectively & efficient resolving active requests. How useful is it to access an 8 year old ticket of an employee needing assistance with a password reset to a system that is not even in use anymore? Also, due to system differences the structure of the migrated data will likely be different than how it was represented in the previous system. For example, SLA information is lost and SLAs are reset on all imported tickets. It is generally not advisable to import historic incidents or service request tickets.
Costs & Effort – Yes, data can be migrated. However, there are limitations, and often a lot of manual intervention is required. Is the cost of migrating this data justified by the benefit it will generate?
Jon Olsen
Jon assists the Sales, Customer Services, and Delivery team with commercial support covering quotes, proposals, customer queries, RFIs, tenders, escalation points for commercial issues and C&Ns, as well as shape commercial processes and practices. Outside of work, he enjoys marathon running, cycling, triathlons and trekking having ticked off Kilimanjaro, the Inca Trail, and Everest Base Camp. He appreciates a craft ale as a great way to replace calories well spent!
Share this blog post on your social.
Related Articles
Visit our blog for expert news and articles from the Atlassian world. On our resources page you will find recorded webinars, white papers, podcasts, videos and more.
The Software Blog
Read our blog for articles offering best practice advice written by Atlassian experts, as well as the latest news concerning your software.
Software White Papers and Guides
Dive deep into Atlassian software with our white papers and guides on individual tools, partner products, services, and best practices, written by the experts.
Expert Webinars
All of our webinars are pre-recorded and available to watch on-demand. Enjoy everything from partner features to application demos and updates from Atlassian experts.
