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

2021-q4-blogpost-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

2021-q4-blogpost-Does Jira do burndowns?_1

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

How to Implement an IT Modernization Strategy - Part 1 of 5

By Mary Roper on May 28, 2021 10:15:00 AM

2021-q4-blogpost--How to Implement an IT Modernization Strategy- Part 1 What is IT Modernization_1


When we initially set out to write a piece about how to implement an IT Modernization Strategy, we quickly realized there is not only a lot to consider when weighing the possibilities, but also a lot of context required to lay a meaningful foundation. We want to discuss what IT Modernization is and what it means for your individual business, as well as other terms and ideas to help define the overall picture. Join us as we unpack and discuss IT Modernization through this series of blog posts.

Part 1: What is IT Modernization

We'll begin by exploring the motive behind IT Modernization, and identifying the traits that make up the profile of an entity that is looking to implement IT Modernization in their enterprise.  Overarching themes include Digital Transformation, Capital Expenses vs Operational Expenses, Legacy Systems, how Cloud fits into the picture (because it's no longer a question of "if" cloud fits into the picture), as well as others.

There are several questions to ask when trying to nail down the motive- we'll be working through these questions in our series:

  • Why would you be interested in IT Modernization in the first place?
  • What are some of the apparent benefits of IT Modernization? 
  • What would IT Modernization look like in your organization and how?
  • What would a rollout plan look like?
  • When do you tackle certain things over others?

By the end of this series our goal is that you will have the foundational understanding of IT Modernization that will help you answer these questions.

The Basics

If you've worked with Praecipio Consulting before, you know we like to start simple - so let's begin with the basic question "What is IT Modernization?"  To oversimplify the concept, IT Modernization is a process of assessing an individual system or group of systems in your organization with the intent of establishing the best possible balance of cost and efficiency. One of the challenges we often call out is that this can look vastly different depending on the context of what it is being applied to.

As part of an IT Modernization strategy there can be some aspects of your business where it makes sense to move in a more digital direction, for example migrating on-prem resources to virtualization or the cloud. While the overarching goal may be to get to the cloud, there are different paths that you organization may take based on your specific context. In the case of moving  an application to the cloud, there are the branches hosting the application on a digital platform like AWS or moving completely to a more SaaS model and allow it to be maintained by a third party.  And of course, for some other aspects of your business it could make more sense to maintain an on-prem solution but update the infrastructure. The key thing to consider here is how you can balance the cost of maintaining whatever aspect of your business you're assessing with the amount of performance proficiency it is providing.

Another term you'll often hear mentioned in the same breath as IT Modernization is Digital Transformation.  It's true that these often go hand-in-hand, but the main difference to consider is that Digital Transformation gets into the explicit changes you have to make in order to keep pace with the digitization of aspects of your business, like products, assets, and processes. IT Modernization is more of a strategy for improving your business through cost savings, efficiency or improving on how agile your business can be. More often than not, Digital Transformation will be a key part of your IT Modernization plan, but they are not necessarily mutually exclusive.

The Breakdown

With that in mind, let's start to identify the motive a business might have for exploring IT Modernization and what attributes make up its profile. The first question you have to ask is "Why would you even be interested in IT Modernization?" The short answer is every business should be thinking about IT Modernization on some level. We exist in a world where the only true constant is change, and as time progresses the main thing that we're betting on is that our technology and business landscapes will continue to shift. The most successful businesses will adjust business practices to match - if you're not willing to embrace the change and make it work for you, your competitor will, and they'll be happy to take your market share off your hands. Additionally, IT Modernization benefits the business, either by lowering your operating costs, or empowering you to be more efficient managing resources and development. Thinking about ways you can Modernize aspects of your business is just good business.

So how do you this? What does it look like?  Well, we've touched on the two key factors associated with Modernization: Cost and Efficiency.  There are a couple schools of thought when it comes to the approach and how you can execute modernization, outlined below.

The first approach would be considered a more traditional approach. This approach involves making incremental changes made over time targeting the most costly or bottlenecked aspects of the business. From this you can attempt to figure out how you can make them more efficient or cost less, or maybe a combination of both. The main benefit of an approach like this pertains to risk: changing pieces incrementally allows you to carefully consider those changes and their impact on the business as a whole. Incremental changes can also be very good for the bottom line since it allows you to budget changes over time.  One of the potential downsides to an incremental approach is it can be limiting. Taking the time to make incremental changes can take.. well... time.

On the other end of the spectrum there's the end-to-end or holistic approach.  This is about what you'd expect: instead of incrementally making changes you're making a plan to implement broad changes across your organization as a whole. This requires careful planning and consideration of what elements need to change in what sequence, to truly understand the potential impact across the organization. One of the benefits of this approach is it keeps the organization from advancing in a siloed manner, which can lead to less efficiency as a whole. In one instance, that might mean two different business groups moving their application to two different cloud solutions that offer the same functionality. Whether your approach is more incremental or end-to-end, it's important to try to take into account the potential impact across the business and ensure groups coordinate the efforts.

Modernization  Mechanisms

When it comes to implementing IT Modernization, it's important to understand that it is much more than a simple update to your technologies. Rather, the approach should be thoughtful and well planned, with an eye to the future and a willingness to embrace the new and sunset the old. At a high level it is important for your teams to identify out of its legacy software or assets what can can be invested in - whether through legacy software modernization or replatforming- and what should be divested from. Reaching a decision on the best path forward for each application will take time - legacy modernization is not an all or nothing endeavor. We'll spend dedicated time in future posts discussing how you can best approach application modernization. 

It's Just the Beginning

As you consider what IT Modernization means for your organization, keep in mind that there is not a one size fits all solution. Our goal in this blog series is to provide helpful context to help you define what an IT Modernization approach could look like and what success would mean to your organization.

At Praecipio Consulting, we enjoy helping our clients reach their IT Modernization goals and bringing teams up to speed with digital demand. If you'd like to learn more about how we can help, please reach out to us!

Topics: aws optimization saas it digital-transformation
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

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us