Mary Roper

Mary Roper


Recent posts by Mary Roper

4 min read

5 Things to Look for in an Enterprise Service Management Tool

By Mary Roper on Oct 11, 2021 11:00:00 AM

Blogpost-DisplayImage-September-2021_5 Things to Look for in an Enterprise Service Management Tool

If you’ve seen the potential benefits of Enterprise Service Management (ESM) but are unsure whether your organization’s current ITSM tool is suitable for enterprise-wide use, you're not alone. Many teams often wonder if the use of IT Service Management (ITSM) capabilities currently in place can be leveraged in other business functions to improve operations and outcomes. To help, this blog outlines five things to look for in an ITSM tool that will make it a fit-for-purpose ESM tool for your organization.

Before that list of five “things” though, it’s worth stating a key point when using your organization’s ITSM tool across the enterprise.

A key starting point when looking for an Enterprise Service Management tool

There’s no doubt that successful Enterprise Service Management, like ITSM, is dependent on fit-for-purpose technology enablement. It’s important, however, to not see ESM as simply the use of a corporate ITSM tool by other business functions. Instead, successful ESM requires a change in mindset to service-based thinking, and the intelligent adoption of ITSM best practices. Additionally, it also mandates the use of the ITSM tool in a way that doesn’t force-fit the other business functions to IT’s language and ways of working.

Importantly, there’s also a need for organizational change management to facilitate the execution of your ESM strategy delivery project. This is because this is the introduction of new ways of working and is thus a people change initiative not a technology.

5 things to look for in an Enterprise Service Management tool

The right Enterprise Service Management tool will help your whole organization, especially now that the need for remote and socially distanced working has limited the ability for people to work with manually reliant processes and practices. In many ways, the replacement of these with new digital workflows, in particular, is going to be an important need of your ESM tool. But this is just one of many things you’ll need. In fact, we recommend your chosen ESM ticks the proverbial boxes against the following list of five key needs:

  1. Non-functional capabilities – These are the capabilities that, while not directly delivering the required digital workflows, allow an ITSM tool to fully meet the needs of ESM. To start, there’s the need for ease of use – for both service requesters and service providers. In many ways, these need to be consumer-like, with “consumer-grade” the new “enterprise-grade” when it comes to corporate technology. Then there are needs related to scalability, domain separation, and appropriate access controls – with human resources (HR) in particular needing to ensure that employee-related information is only accessible by those authorized to do so. Finally, there’s a need for domain-specific knowledge management to ensure that searches for help or automated recommendations – again for both service requesters and service providers – are focused on the business function context.
  2. Core service management and digital workflow capabilities – These are the digitally-enabled capabilities that help work to both flow and to be achieved. This includes request handling, whether these are requests for help, information, service, and change. Where for business functions such as HR, terminology such as “case management” will need to replace IT’s “incident management.” Importantly, these digitally-enabled capabilities are not simply the ability to move work between different groups, there’s also the need for automated routing, queue management, notifications and alerts, approvals, and service level targets to help ensure that work is moving efficiently – from the initial need through to the required outcome. It also includes self-service and self-help capabilities which provide a structured work intake method and the ability to “deflect” simple employee requests (including employees requesting updates on their requests) respectively.
  3. Cross-capability enablers – These are capabilities that enable the employee-touching service management capabilities in #2 to work optimally. For example, knowledge management capabilities allow service providers to undertake work that’s outside of their individual experiences. It also enables the self-help capabilities that empower employees to help themselves to quicker solutions with a consumer-like service or support experience. Another example is reporting and analytics capabilities that not only help to ensure that operations and outcomes are meeting business needs and service-provider obligations but also help to identify improvement opportunities.
  4. Platform-based capabilities – The ability to create business-function-specific workflows and applications that extend ESM beyond the core capabilities (that were designed for ITSM scenarios). This can cover both capabilities that are applicable to multiple organizations (perhaps even industry-specific) that are created by the tool vendor, its partner ecosystem, or the tool customer. And capabilities that are somewhat unique to your organization – a bespoke solution to a business need or opportunity. Either way, the ability for business function personnel, and not just IT’s application developers, to create these extended solutions using codeless drag-and-drop functionality is a key enabler in both rapid cross-enterprise tool success and benefits realization.
  5. New technology adoption – These are capabilities that allow both individuals and teams to be better versions of themselves. Two timely examples are collaboration and machine-learning-based capabilities. In terms of the former, the aforementioned need for remote and socially distanced working requires digitally-enabled teamwork and wider collaboration capabilities. Whereas the latter offers a wealth of opportunities that allow business functions to be all three of “better, faster, cheaper.” Whether it’s the use of machine learning and automation to accelerate process operations and outcome delivery. For example, in intelligent request triage where the technology decides which group to route a request to based on historical data patterns and in the automated escalation of requests when circumstances change or a service-level breach is likely. Or the use of machine learning to share knowledge more effectively. This could be through the provision of automated recommendations to service-provider staff or context-based self-help knowledge provided to service requesters either via traditional portal searches or newer chatbot capabilities.

The above list of five things to look for in an Enterprise Service Management tool is not necessarily everything that your organization will need but provides a great start.  If you want to find out more about the opportunities of ESM and the tools that can facilitate this framework, reach out to Praecipio Consulting and we're happy to walk through the process. 

Topics: blog automation business-teams service-management consulting-services
3 min read

Does Jira do burndown charts?

By Mary Roper on Jun 16, 2021 3:33:00 PM

Blogpost-DisplayImage-June_Does Jira do burndowns-Good reporting capabilities are essential to Agile teams using Jira Software - and for good reason! Data visualization tools are essential for promoting good communication and collaboration. One of the most sought-after reports is included in Jira Software out of the box: the burndown chart. Read on to learn how Jira makes it easy to generate and share the burndown chart with your team and stakeholders. 

The Inputs

  1. A Scrum Board: In Jira, the burndown chart is accessible through Scrum boards only.
    • To create a scrum-type board, follow these instructions from Atlassian. Column mapping is a key configuration point, as it's the basis for the burndown chart. 
  2. An Estimation Statistic: Determine how your team will measure work, and set an estimation value on each of the issues in your sprint.
    • Jira accommodates for Story Points, original time estimate, issue count, or any custom field, provided that the custom field is a numeric custom field type.
    • We know that this can be a sticking point for your team and asked our Principle Amanda Babb to shared her thoughts about Scrum Team time tracking to help you along the way. 
  3. An Active Sprint: Once your sprint starts, begin to review your team's progress. 

The Interpretation

Once the sprint starts, you can review the burndown chart along the way to understand the amount of remaining work in a particular sprint and gather feedback on the sprint itself. Below are a few scenarios that the burndown chart captures:

Scope Creep:

Scope creep is often unavoidable, so it's necessary to understand when they occurred especially if you team is no longer on target to meet its sprint goal. Here, the burndown chart reflects an increase in scope

scope-creep-burndown-chart

Opportunity for Alignment: 

It's important for the team to collaborate and land on an estimate for each work item in the sprint - not so much for the actual estimate itself but more for the shared understanding based on the requirements. This is often seen in both over and under estimates on the burndown chart. Below, the burndown chart reflects where some work was overestimated; the team is on track to the work well before the end of the sprint. 

opportunity-for-alignment-burndown-chart

Plateaus: 

Plateaus on the burndown chart are typical when you have a team who is either new to Agile as a whole or new to working together. It's an indication that the team got off to a good start early on, but didn't carry the effort through the remaining work items. 

plateau-burndown-chart

Ready to learn how Jira Software can help your Agile teams collaborate and communicate while working in Agile sprints? Drop us a line!

Topics: blog scrum data reporting agile
5 min read

Tips for Performing a Successful Root Cause Analysis

By Mary Roper on Mar 5, 2021 10:55:01 AM

Blogpost-display-image_Tips for Performing a Successful Root Cause AnalysisRoot Cause Analysis: The Under-appreciated Hero

When implementing an IT Service Management (ITSM) system, I always look forward to spending time on root cause analysis (RCA). Of course Incident and Problem Management play the central role in ITSM design- it's crucial to give your teams, customers, and systems intuitive ways to communicate when something has gone wrong. However, it is equally important that organizations spend time identifying the key driver of these problems by performing an RCA to prevent them from reoccurring. This is because, at the end of the day, incidents and problems cost your organization money, and a good RCA can help save it. It's this viewpoint that has led me to dub RCA the under-appreciated hero of ITSM and in this post I will share with you the aspects of a successful RCA that can help vanquish problems once and for all. 

It's important to distinguish between Problem Management and Incident Management. In broad strokes: the goal of Problem Management is to get to root cause, and we can understand its goal to be increasing the meantime between failures by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident; in this sense it's a proactive approach. On the other hand, Incident Management's goal is to reduce the meantime to recovery by responding and resolving fast; its approach is reactive.

What is Root Cause Analysis?

The core function of root cause analysis is to uncover the core reason why a problem occurred. While there are many different tools and approaches to perform an RCA, I've consolidated the key steps into the diagram below: 

Root Cause Analysis Blog Post

  • Define the problem: First, make sure you and your teams align on "What happened?" and are speaking to the same problem.
  • Collect Data: Then, the focus needs to be "How did this happen?" and gathering data around the problem, whether customer testimony or incident reports.
  • Identify Casual Factors: Casual factors also help to answer "How did this happen," and in this step, teams should be guided to identifying fixable causes.
  • Identify the Root Cause: Next, teams should leverage one of the techniques of the RCA process, such as the "Five Whys," Fishbone Diagram, or Fault-Tree Analysis, to drive to the root cause of all the causal factors. 
  • Recommend and Test the Solution: After the root cause has been identified, teams should work to develop a solution that gets recommended to the Executive team for approval before testing can begin. Once approved, the solution should enter a testing phase, where it can be rolled back if not successful. 
  • Implement and Monitor: Once the solution is implemented, teams should continue to monitor it in the production environment to ensure that it is working as expected. This active analysis step is why RCA is depicted as a cycle; if the solution did not resolve the problem, it could be that the problem was a casual factor and the team needs to begin the RCA process again. 

Why Does It Matter?

I've worked with teams who have a well-defined RCA process and others who are just beginning. I reference this diagram when we focus on RCA because it helps to illustrate how simple of a process RCA can be. There aren't rigid guidelines or rules to follow; organizations can adopt their own RCA policies. What many don't realize, especially those who have yet to adopt RCA as a business process, is that it has a big pay-off: cost savings.

Root cause analysis can be a cost saving tool for organizations for a couple of reasons. First, identifying and acting on problems early saves money. The longer a problem goes on the more money it costs the organization, and a properly deployed RCA process is built to help organizations become more proactive rather than reactive. Second, the main goal of the RCA process is to prevent incidents from cropping up again. If the incident does not reoccur, then there won't be downtime or lost production, saving money in the long run.  

How Can I Help My Organization Embrace RCA?

When working with organizations to implement an RCA process, there are several aspects that I help coach my clients on which can help the organization embrace RCA. They are:

  1. Talk about what went well.....and what could have gone better
    1. When the team is starting the RCA process, guide them to start by discussing what happened and framing the problem. Then, go one step further and document what went well. This will provide you data and help to explain what is not the issue or what not to blame. It's equally important to talk about what could have gone better, as this will likely begin the discussion and documentation of your causal factors. 
  2. Make it work for you
    1. In some organizations, "Root Cause Analysis" can be viewed as too formal and intimidating. I've come across some resistance to them due to their structure or even the invitee list. For these reasons, it's important to make sure you're adopting a RCA structure that feels natural for your organization. This could mean:
      1. Being mindful of the attendees, especially if the invitees include senior management and above. Ensure you include the right people in the room at the right time. Your front line team has the most firsthand knowledge of the systems or processes, and you will want them to feel comfortable participating candidly in any discovery meetings. 
      2. Having a neutral party leading the meetings. The leader shouldn't have anything to gain by the results of the RCA process and should be able to maintain a "blame free" atmosphere.
      3. Reframing RCA as something more approachable, such as a "Lessons Learned meeting,"  where the RCA process is still followed, but in a less formal way. Feedback and idea can be gathered via sticky notes and shared on a board so that it is anonymous for example. 
  3. Root causes can only solve one problem
    1. Remember that the main goal of RCA is to avoid future incidents. Teams should not be applying a previous root cause to a current or future problem- if that is the case, then it indicates that rather than identifying the root cause, the team actually identified a casual factor. In these instances, I've coached teams to go back and take their RCA process one step deeper, for example asking another "Why" question if the "Five Whys" is used. 

The goal of Problem Management is to get to root cause. Incident Mgmt goal: reduce the meantime to recovery (by responding and resolving fast); reactive
Problem Mgmt goal: increase the meantime between failures (by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident); proactive.

Ultimately, where incidents and problems cost your organizations money, RCA saves it. It is for this reason that I think of RCA as an under-appreciated hero of ITSM. While the biggest barrier to accomplishing RCA can be time, putting in the time upfront to accomplish the RCA process will prevent repeat incidents from cropping up, saving your company time and resources in the long run. By implementing a few of these tips, I hope you come to appreciate RCA as I have, and if you have any questions let us know, we'd love to help. 

Topics: blog plan incident-management itsm health-check
3 min read

Three Things No One Tells You About Custom Fields in Jira

By Mary Roper on Mar 4, 2021 12:19:10 PM

Blogpost-display-image_Three Things No One Tells You About Custom FieldsCustom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

Response Times for Jira Data Sets

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

  1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
  2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
  3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

Topics: jira blog best-practices optimization standardize configuration bespoke health-check

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us