Don't go just yet!

Enter your email below and receive this free offer.

Courtney Pool

Courtney Pool


Recent posts by Courtney Pool

3 min read

Extending ESM: What is Problem Management and why do you need it?

By Courtney Pool on Apr 26, 2022 10:23:00 AM

2022 Q2 Blog - Extending ESM - Hero

If you've read our earlier blog, "Service Management is More Than an IT Service Desk," you're likely already aware that Enterprise Service Management (ESM) strategies often start (and stop) at the sharing of core IT service desk capabilities. Limiting the aspects of IT Service Management (ITSM) pulled into other business functions is a huge miss. Organizations that do so are restricting the potential benefits of their ESM strategies. We don't want you to risk the same. 

Instead, we encourage you to reach beyond the service desk and incorporate other valuable ITSM capabilities into your ESM strategies. One of the first capabilities we'd recommend starting with is Problem Management. After all, every team will encounter at least some problems, right? 

Now, let's talk about what this means for you.

What's Problem Management?

ITSM's – and ESM's – use of the terms "problem" and "problem management" can be, well, 'problematic.'

While most English speakers might use the word "problem" to represent any and every issue that arises, Service Management takes a narrower view of it. What could be called a "problem" in casual conversation might instead be an "incident" in Service Management, as the term "problem" is reserved for:

"A cause, or potential cause, of one or more incidents." Source: ITIL Foundation: ITIL 4 Edition

An easy way to understand this is to think of it in terms of the common cold. Sneezing (an incident) could have any number of underlying causes, as could its friends, Sniffling, Headache, and General Malaise. These symptoms all let you know that something is wrong, but addressing them at their source – the rhinovirus, in this case – is what ultimately resolves the symptoms and keeps additional from arising.

Problems in Service Management operate similarly. Addressing only a "symptom" is unlikely to remove the underlying cause – meaning that the incident will probably continue in the same place or even sprout up elsewhere. More importantly, multiple incidents can occur from a single root cause and could continue until addressed.

Problem Management seeks to solve this with approaches toward identifying and mitigating the causes and preventing the symptoms from recurring.

Why Should I Care?

In an IT context, problems can crop up anywhere and everywhere. We've seen problems crop up in just about every scenario imaginable. Even those who don't work in IT can likely immediately call out a few common IT problems because that rapid connection already exists in the minds of most. Once you get past the idea that "Problem" equals "Technology," though, you'll see that the need to address problems is also evident in all other business functions. This is especially true for any department with a person or team acting as the frontline of support.

To best answer why you should care, first ask yourself: does your department's support team deal with many of the same issues day in and day out? 

If yes, that's reason enough as to why you should care about problem management. Because yes, while you might be able to address all problems as they come in or point users to where they can go to help themselves, wouldn't it be better if those affected customers didn't experience issues at all? Why not fix the leak instead rather than continually bailing the water out of a flooding boat?

But if you're not convinced yet, here are some examples that might help.

Examples of Problems in Other Departments

The potential problems currently hidden within your departments might include:

  • Inadequate instructions on how to do things.
    • Do visitors get lost navigating your hallways? Are customers repeatedly calling or emailing for assistance with the same simple tasks? Are callers frequently ending up at the wrong end of the phone tree? If so, these are problems.
  • Critical safety issues.
    • Are all employees using their keycards to enter the building, or are they coming in behind others? Is there a particular door that always sticks and needs force to open? Is your talent team carefully identifying all callers before sharing PII? These could all be problems too.
  • Inconsistencies with company "messaging."
    • Are you sending out emails laden with typos? Do your blogs not read like they're intended for a specific audience? Is branding not being applied consistently on everything supplied to customers? Yep, you guessed it – these are problems too.

And these are just a few of the problems that may be plaguing all of your departments now. Therefore, it is essential to look past the constant stream of issues hitting your frontline support and identify those that are frequently repeated. Once you've identified those repeat visitors, problem management can help you understand and address their root causes.

If you want to learn more about how enterprise service management and problem management can help your teams, let's get in touch.

Topics: problem enterprise service management
4 min read

What Exactly is Agile Methodology?

By Courtney Pool on Aug 17, 2021 12:22:47 PM

2021-q4-blogpost-What is Agile Methodology?

Any person who's worked in or around software for any length of time has likely heard of Agile. Since the release of the Agile Manifesto in 2001, Agile has quickly spread through the industry, and even companies who aren't fully Agile sometimes claim to be, if only to check the box. Still, despite this popularity, we regularly receive confessions from people who admit that they don't fully "get" what Agile is, often from teams outside of software developers who want to know if Agile can help them too.

The Elevator Pitch

"Getting" Agile is a multi-step process, but knowing the elevator pitch is a great place to start. Agile is an iterative approach to software development and project management, with iterative being the keyword. Its primary focus is on delivering value incrementally, with those increments being faster, more frequent, and with fewer strings attached than some traditional approaches. Agile also acknowledges, accepts, and even encourages that risk and change are likely to pop up and need mole-whacking along the way, allowing for real-time course-correcting as needed.

This short description can help people navigate through many of the superficial conversations around Agile. If you want to impress though, knowing the details is the next step.

The Details

To really understand what Agile is, it helps to first understand why Agile is. Agile's origin is in software development, and its inception was a direct response to the rigidity of existing development methods like Waterfall. Despite this, its existence is not at all meant to be a critique of Waterfall, which is a valid methodology that still has uses in several scenarios; rather it's an answer to the "But what if...?" questions that plague so many projects, such as: 

  • What if I discover more requirements after development has started?
  • What if we don't catch a big problem because we waited too long to test?
  • What if we need to ship to market faster or more frequently?

Answering these questions is difficult in a Waterfall environment, and failure to answer them can be costly. This can be especially true in software, where conditions and criteria frequently change, and rapidity and innovation are critical factors in winning over users. Enter Agile, whose principles allow teams the flexibility needed to answer these questions as they arise while still meeting product and stakeholder needs.

While some interpret this flexibility as Agile having no rules, this could not be further from the truth! The Agile Manifesto itself includes both key pillars and guiding principles, which every organization purporting to be Agile should follow. Amongst the guiding principles are those that are arguably more nebulous, like "Working software is the primary measure of progress." Still, many are undeniably rules and not suggestions, such as the principle requiring the increments mentioned above: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. "

Beyond that, there are also rules associated with each particular Agile framework to adhere to as well.

You see, while "Agile" is the overarching methodology (or philosophy, some argue, an ongoing debate), the actual "doing" is often guided by the numerous frameworks within Agile, with more popular frameworks like Scrum, Kanban, eXtreme Programming, and the Crystal Method leading the charge. Of course, that's not to say that one can't simply follow the principles of Agile without needing a specific framework -- you absolutely can! -- but development teams may find it easier to work within a framework. Aiding this ease is that each framework has taken the Agile principles and hammered them into specific actions, ceremonies, and practices for teams to follow, reducing the need for teams to develop their own.

Knowing the pitch and the details is essential to understanding Agile, but "getting" Agile requires that you take it one step further and apply it outside the business.

The Real World Example

As mentioned, Agile is an iterative process that seeks to frequently deliver value while still allowing for the winds of change. One of the reasons Agile can work so well is, if you think about it in the simplest of terms, because most people do Agile every day.

No, seriously!

I recently moved and learned again how ever-present Agile is. I prepared for the move with a soft plan and a general goal in mind: get everything packed and ready by X date. I even took an incremental approach to it, regularly moving smaller and more manageable items over to the new house in the weeks leading up to the move. As is frequently the case, though, life had different plans, and I found myself scrambling to finish hours before the movers' arrival (see: winds of change). I could have chosen to stubbornly stick to my original plan, risking either an incomplete project or a financial blow from having to delay, but I instead chose the Agile approach. I reprioritized and adjusted my goal, focusing on readying the most vital components and shifting lower priority items to my next increment. 

And just like that, you're Agile!

So now you can quickly explain Agile to someone any time it comes up, dazzle them with a few specific details, and even deliver an analogy or two to help set it in. The final step? Contact us to find out how Praecipio Consulting can help you make it work for your teams.

Topics: kanban process tips agile software-development waterfall
2 min read

Best Practices for Using Labels in Jira

By Courtney Pool on May 21, 2021 8:15:00 AM

Jira has a multitude of ways to group and categorize similar issues, such as through projects, requests types, or components. Many of these are aimed at issues that exist within one project, though, making it a bit more difficult to track items across your entire Jira instance. This is where labels can shine.

Labels are basically tags on issues. If you have 4 different projects that may all see tickets related to the same customer, then a label for that customer would give you a great way to quickly gather an overarching view of everything that exists for them. You can also have multiple labels on an issue, allowing you to easily catch it in any number of buckets.

Like with many things in life, though, a watchful eye and steady hand are needed to really use labels effectively. With that in mind, we’ve identified a few best practices to help.

1. Labels should be used for informal grouping.

In other words, don’t count on just labels to be the driving factor of important reports or anything else you need to be accurate 100% of the time. Because new labels can be created by users from the issue screen directly, they are not and should not be viewed as a source of truth. They’re great at what they do, but be careful to limit the importance placed on them.

2. Try to limit the number of labels you have.

Labels are shared globally, which means the list can get very long, very quickly. To make them more effective, try to come to a consensus internally on the whens and whys of new labels.

3. Set up clear naming guidelines.

Limit the number of labels by making sure you have clear naming guidelines. This will be different from organization to organization, but we encourage you to discuss and decide on these guidelines early and to then check in periodically to make sure they're being adhered to. If you’re looking to label issues from ABC Law Firm, for example, you could quickly end up with labels for abc, abclaw, abc-law, etc. Without naming standards, you will dramatically decrease the efficacy of the labels as an informal(*) grouping tool.

4. Routinely clean them up.

Even with clear naming guidelines and a company decision to limit the number of total labels, you may still end up with some that are no longer relevant down the line. Set a regular time for somebody to go in, check them out, and determine if there’s any room for clean-up. Even better, cleaning up labels is as simple as entirely removing them from all issues, giving you the opportunity to swap them out for another if needed.

5. Don’t overuse them.

This one really echoes all of the points above, but it bears repeating: Don’t overuse your labels. If you’re looking for something to track issues for a very-important, super-vital, must-be-accurate report? Labels are likely not the answer. Have a certain issue type that can have 30 different permutations? Again, labels are likely not the answer.

Jira as a tool has many options for tracking related issues. And labels, in the right hands, can be a great means of doing just that — if they’re handled intentionally and in moderation. Don’t be scared to give them a try, but do keep these best practices handy to keep your labels as helpful as possible.

Contact us if you have any questions on labels, or in anything Jira: We are experts in all things Atlassian.

Topics: jira blog best-practices tips information-architecture
4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in Jira

Permissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

TYPES OF DELETE PERMISSIONS

To begin, it’s important to understand the delete permissions structure. Within Jira, there are four groups of delete permissions: 

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues


And then within those permissions, there are two types:

  • Delete Own
  • Delete All

DELETE OWN PERMISSIONS

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for most of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is an innocuous permission and can be assigned to any users with access to a project, unless you have strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This feature might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than a spreadsheet for the project. It’s fairly low impact as well and can likely be given out to any users within your project, especially if you’re following the Backup Rule of 3 or similar internally.

DELETE ALL PERMISSIONS

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All WorklogsDelete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a years’ worth of tickets. 

Remember: when something is deleted in Jira, it’s gone forever. This permanence can be a nightmare for many, especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  Explore more ways we can help your team succeed with our Consulting Services, or contact us with a question or request and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration
2 min read

Jira Service Management for HR

By Courtney Pool on Jan 13, 2021 12:58:15 PM

Blogpost-display-image_Jira Service Management for HRIn November of 2020, Atlassian rebranded Jira Service Desk to Jira Service Management. With this rebranding, Atlassian sought to make one thing clear: JSM isn’t just for IT. In fact, any team who receives requests from others, whether from external or internal customers, can utilize JSM.

Similarly, IT Service Management (ITSM) doesn’t have to be just for IT either. IT organizations around the world benefit daily from applying ITSM principles and processes to their own organizations. Enterprise Service Management (ESM) sees this success and seeks to take it a step further, contending that ITSM practices can be applied even outside of IT teams, which allows for similar successes in other departments. JSM agrees, and it even has quick-starts in Atlassian Cloud for some business teams, including HR.

By now, you may have already read about the ITSM capabilities that can be leveraged by your HR department. You may even already have a few use cases in mind. At Praecipio Consulting, one of the most frequent JSM use cases that we encounter for HR is onboarding and offboarding. 

To start, you’ll want to be sure that you have one request form for onboarding and another for offboarding. One of the things that makes JSM great for non-tech teams is the ability to change display names for fields and add help text to forms, making it even easier for people who aren’t familiar with Jira to submit requests.

As onboarding and offboarding are typically handled by multiple teams and individuals, you can also utilize an app to auto-generate subtasks for each Request or Issue Type on issue creation. This is also possible in Jira Core and Jira Software, of course, but having this driven by a request created through the portal means that a user can set it in motion with more ease than they would be able to otherwise.

Queues are another JSM feature that will be helpful for your HR team once a request is submitted. You could set queues up for just onboarding and offboarding, or you could even go deeper, having queues that differentiate between full-time employees, part-time employees, and contractors, as an example. Queues can be set to run on anything you’re collecting in your form.

Once a request comes in, you’ll benefit from the Service Level Agreements, or SLAs, that JSM can apply. SLAs can be set based on any number of criteria, so your HR team can easily track if they’re meeting expected targets, as well as have another way to prioritize their work. For example, a high-priority offboarding will need more attention than onboarding that’s more than a week out, so the SLAs can be set accordingly, with more time afforded to less pressing tasks.

Onboarding and offboarding are common needs in every HR department, but these same features can be applied to most HR tasks you can think of, like PTO requests, asking for assistance with benefits, or even recognizing a colleague.

The rebranding of JSM is a message to all teams, in all companies, that service tools are not just for IT. They can be a huge benefit to many teams, and HR is a great place to start. 

At Praecipio Consulting, we offer a wide range of services for HR teams (or any team, for that matter) looking to use best-in-class ITSM tools. Reach out today and let us know how we can help you make the most out of JSM

Topics: human-resource itsm jira-service-management

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