Service Level Agreements
Expectations are a tricky thing. Everyone’s got one, and they don’t always align with what other people think. This is especially true working on a help desk or providing customer support. A customer calls in expecting an answer or a resolution in a specific timeframe… and many times the agent answering the call or ticket is stuck having to reset that expectation.
Folks get expectations from a LOT of place - but there’s one that can help make everyone’s life a bit easier and set those expectations out of the gate - the Service Level Agreement, or SLA). An SLA is basically an agreement between the service provider and the customer on how long something will take or how something will be done.
Essentially it’s a promise by the customer to have a specific expectation and in return the provider will meet that pre-set expectation.
Having worked on a help desk and helped agents working on them I find them to be both really great and a bit not so great.
Why they’re great!
SLA’s are great because they set a clear expectation that everyone can see. Generally they’re posted on a website and shared with customer groups so everyone has visibility into what they are. Customers go into a call knowing what to expect in terms of service. and agents know how long they have to complete any given request.
Why they’re not so great…
SLA’s aren’t so great for much the same reasons. Customer can now see how long something should take, meaning they can end up watching the clock and getting more anxious as it gets close to ticking down. They can also cause stress for agents since watching multiple tickets near their SLA is a bit stressful.
Some Terms
Breaching - When an SLA is exceeded. For example if you have 1 hour to do something and you take 2 hours, you’ve breached that SLA.
Paused - SLAs can be paused under certain conditions. This can be done when the agent is waiting for information from a customer or something is blocking the ticket. Generally this is utilized to ensure agents aren’t penalized for things they can’t control.
Active - SLA’s are active when their clock is ticket. Generally open tickets have an active SLA.
How to manage them
Folks who have SLAs setup should be on the lookout for the following:
Tickets nearing the SLA - Tickets within an hour or two of exceeding (breaching) their SLA should be closely monitored, and if needed additional resources should be added.
Tickets breaching SLA - These ticket should be examined to determine WHY the SLA was breached. This information is helpful to improve your processes and prevent it from happening again.
Tickets with a paused SLA - Tickets that have a paused SLA should be monitored to ensure they’re paused legitimately. It’s not uncommon for tickets to be paused and then forgotten about.
SLA’s in Jira Service Management
If you’re using Jira Service Management you can easily setup and track SLAs. Be default, you’ll have two
Time to first response (TTFR) - This begins ticking when a ticket is opened and stops once an agent responds. This helps ensure tickets get a quick response indicating they’ve been received.
Time to resolving (TTR) - Begins ticking when a ticket is opened and stops once a tickets is resolved. This is what most people think of when they think of SLA’s as it enforces a timeline to solve an issue.
You should consider when SLA’s are paused, commonly done when:
Tickets are waiting for customer - If a ticket is pending the customer to respond to take some action pausing the SLA lets the agent work on other issues.
Pending - If a ticket is stuck due to a third party it frequently pauses the SLA.
Function Help
I’ve been using Google Sheets for so long I actually can’t remember when I started… It must have been after my first job, since we used Excel, but other than that it’s lost in the years. Over that time I’ve gotten fairly comfortable with various functions in Google. Things like vLookup, or Index/Match, or Unique. I’ve got many of them memorized, which is a great place to be in since I can just pull those tools out and apply them to different situations.
Even though I’m (fairly) comfortable with many functions, I still use a feature Google has called Function Help. This displays information about the function I’m using on the screen so I can easily reference it.
Why?
There’s a few reasons I use function help, but mainly it’s to learn more. Having on-screen examples and guidance makes exploring new functions a breeze, and having a reference showing me where I”m at in the function helps avoid mistakes.
Habit - Over time I’ve just gotten used to having it up on my screen. Honestly it looks a bit weird not having it there!
Remember things… - Sometimes I know a function JUST enough to type it in and start filling it out… but I forget some key piece of info about it. This makes it incredibly frustrating since I”m close to getting it right. Having function help on the screen avoids that.
Learn new things - Many times I’ve had function help up and noticed something I didn’t know about a function I thought I knew, or I learned an entirely new function. Having the help right under my work makes it SUPER simple to learn
Where?
When you type in a function you may have noticed this little blue question mark. That’s telling you function help is hidden, and clicking on it will show it to you.
After you click on it Function Help will expand and give you the basic view.
Active Argument - The argument in a green box is the one you’re entering now. This makes it easy to see where in the function you are (especially helpful for nested functions).
Addition Arguments - Other arguments this function accepts
Optional Argument(s) - These always appear last and in brackets. These are optional, but the function will default them if they’re not entered.
Expand - Click to expand the function help and see more info, including examples
Close - Click to close function help (returns you to the blue question mark)
Clicking on the expand carrot will give you more information, including examples. This is a great way to learn more about functions.
See this live here:
What's better than "Status" in JQL? statusCategory
Searching for issues in Jira by status can be tricky. Every installation has a different slate of statuses, and that list can even vary within projects. While there are some more “standard” ones, like “Waiting for customer” sometimes a status like “Declined” will show up and throw your searches for a loop.
My old workaround was to keep a running list of statuses, especially those in the “Done” state, that I would add to queries. This looked a bit funny since I had to add “status in (“status 1”, “status 2”, “status x….”), but it got the job done. Unfortunately it made it hard to onboard new folks to the project and really frustrated users.
There’s a better way
Fortunately the nice people at Jira have a solution! Recently I’ve almost entirely stopped using “Status” for my day-to-day quering. There are specific cases where I need to use it, but generally it’s been replaced by statusCategory.
When an Admin adds a status to a project they have to select a category for it:
To Do - This status signals the ticket is pending work. Common examples include “Review”, “To Do” and “New”.
In Progress - This status signals the ticket is being worked on. Common examples include “In Progress”, “In Development” and “Waiting for Customer”.
Done - This status indicates work on the ticket is complete, or no further work is necessary. Common examples include “Cancelled”, “Completed”, “Finished”
How to use it
StatusCategory is similar to any other field in Jira : statusCategory = (value) - where the possible values are “To Do”, “In Progress” and “Done” (note they are case sensitive!.
I typically replace “Status” with “statusCategory”, so instead of using status = Completed I would use statusCategory = Done. This does make the query broader, but ensures I capture EVERY ticket that no long requires owrk.
Examples
Find all tickets in project ABC that are in the To Do category
statusCategory = “To Do” and project = ABC
Find all tickets in the ABC project that are in an open sprint and in progress
Project = ABC and sprint in openSprints() and statusCategory = “In Progress”
Check it out live:
The importance of Header Styles
I’ve (finally) figured out that formatting is an important part of a wiki. Shockingly folks don’t appreciate reading giant walls of text, so understanding how to break up a page in a way that improves it’s usefulness is important. One way we do this is with headers.
Headers are useful in breaking up the page into discrete sections. I think of them like chapters in a book - they signal to the reader what is coming up, and let folks skip around to more interesting sections if they like.
A VERY common way to do this is simply by changing the size of the text, or by bolding it.
While this DOES make the text bigger and bolder, it can rob you of some interesting features built into knowledge systems.
Header Styles
Instead, use header styles, NOT font sizing, to break up pages into sections. Header styles will also break up the page with clear headers, but have a major advantage over bolding and font sizing - they interact with the tool in different ways.
In Confluence
Using header styles in Confluence lets you do some pretty cool things like:
1️⃣ - Automatically generate a table of contents - The Table of Contents (TOC) macro will generate a TOC based on headers on the page. Easy!
2️⃣ - Send a hyperlink directly to that specific header - each Header will have it's own link, letting you send folks directly to it.
3️⃣ - Easily standardize look and feel - Using header styles will ensure your headers always look the same between pages.
Click the text size drop down & select your size
Type it in!
In Google Docs
Header styles in Google Docs let you easily create a table of contents and link to headers
Select the header size
Type it in
Google automagically makes a table of contents
Label Management in Confluence
Labels are a great way to help manage content, but tend to spiral out of control as anyone can add a new label to a page. This results in a large number of similar, or unneeded, labels, which clutter your system and make it harder to manage.
Why label management is important
Over time your system will collect more and more labels. Many of these will likely be legitimate labels used to help manager your knowledge base. Over time, however, you will start to collect typos, deprecated (un-needed) and duplicate labels.
Common examples include:
Plural vs Singular - “benefits” and “benefit”
Typos - “beneift” not “benefit”
Unneeded - “Excel” (but you no longer use or need this)
At best these labels clutter up the screen when selecting new labels - at worst users add them to documents which will confuse and break your search and other features.
A Solution
Setting up a regular label review (similar to a content review) will help you manage and update your labels. There are two macros that will help you
Labels List - Gives you all the labels in a specific space in alphabetical order
Popular Labels - Displays all labels in a specific space sized by use
Labels List
A-O
P-Z
0-9
This is useful for quickly seeing how many labels there are, and if there are any potential duplicates / un-needed labels. Click on the label to see a list of pages with that label.
Popular Labels
Generates either a list of labels or a heatmap. The list will display labels in descending order of use (most used at the top), while the heat-map displays them alphabetically and changes the size based on use (most used is bigger).
Don't be afraid of labels (or hashtags)
I recently spent some time browsing my company’s Confluence knowledge base and noticed that a LOT of articles didn’t have any labels. I’d bet this is because labels are mostly hidden when you’re writing pages - there’s no obvious spot to add labels during editing, and after you publish they’re waaaay down at the bottom. I imagine that many folks simply don’t know they’re a thing, or completely forget they’re there.
This is a bit of shame, since labels are a great way to help organize and drive content. They’re not even a foreign concept, since I’d bet many of us are already familiar with the concept of labels under a different name - hashtags. Platforms like twitter use hashtags to help folks find and organize content, much the same way Confluence uses labels. We’ve all seen tweets with a whole bunch of different hashtags related to the content - so why not do this with kb articles?
Labeling an article doesn’t take much time and has a lot of benefits. It helps the search function find things, but also drives gadgets like “content by label”, making dynamic page construction a lot easier. The few seconds an author takes to hit the “L” key and type in some keywords will definitely pay off, especially as your kb grows in size.
In addition to helping folks consume your content, it will make your life easier when you have to update things. For example if your onboarding process changes, you can just search for the onboarding label and know what to edit. You can even add a specific label to help you find content that might need to be updated regularly (I tend to add “monthly-review” to articles like this).
Depending on your needs, an article may end up having several labels (or more!) - and that’s ok! As long as each label is there for a reason and ties into the content, it doesn’t hurt anything, it just makes it easier to find and sort content.
This is a great feature that I think is really underutilized - be sure to check it out and see what you can do with them.
Onboarding New Team Members
Many times I get to work with existing teams. This generally means they have a shared relationship and know how to operate effectively. Many other times, however, I have to integrate someone new into the team. This is a great opportunity to add to the team’s culture and bring in some new ideas. The time spent onboarding is never wasted and helps the team as a whole improve.
Many times I get to kick off a project with a team that has worked together before. This certainly has its advantages…. Everyone generally knows how everyone else will act and work with the group.
Other times, though, I've had team members join mid-project. This could be due to someone leaving the company, being out of office or needing more resources to get the job done. Regardless of why, this new joiner can disrupt the team in several ways - they may communicate differently, they don't know the norms and they have to build relationships up from nothing.
Ensuring the new person feels welcome and meshes with the group is critical to its success. Frequently I see this process being ignored or sped up in the name of 'get the job done'. I find that while this approach may get them doing work more quickly, it doesn't result in an optimal outcome. Sure, they're working, but they’re also lacking connection with their team. They're less effective because they don't know where to go for some things, and because they don't know how to really work with everyone else.
I've found a few things can help get someone new onboarded and success :
Make sure they meet everyone - this sounds simple, but make sure your new team member has time to connect with everyone else on the team. I've found that prepping them beforehand with some background can also help guide the conversation (e.g. Sally has a background in coding, she's a great resource for X).
Get time with them early - don't wait until they've already finished their first week! Meet with them early and often, this both helps demonstrate that you care about them and their success, but also ensures they have time to get a feeling for how you operate.
Proper resourcing - make sure they have whatever access they need to do their job as soon as they join. Nothing saps morale faster then not being able to v successfully because your account isn't live.
Ask them how you can improve - this new member will bring in new experience and knowledge that can help your team. Asking them for their input on what the group can do better both shows you care about their thoughts, but also helps them buy into the group.
It does take time and effort to integrate new folks to the team. That time is more than well spent - not only will the team benefit from their skills and time, they'll benefit from being part of the team.
Tool Tip - Send Later
Somethings you’ve got a great message to send, but it’s not the right time… things like updates or questions sometimes should wait for a more opportune time (like on a Monday morning instead of Friday afternoon). Many systems offer the ability to “send" later” which helps better target communications.
While I try to only work during “working hours”, which are generally 8-5 Monday to Friday, but can go all over the place, I typically find myself being inspired to do work at odd hours. I also frequently find myself writing emails that should be sent at a more opportune time (for example a project update shouldn’t go out at 5 PM on a Friday… no one will read it anyways, PLUS it will get buried in their inbox by Monday).
In the past I’ve drafted those emails and then manually sent them later. This both allowed me to funnel my inspiration when it struck, but also to get information out at the best time. It did, however, require me to remember to actually send them. That’s when I discovered the “send later” feature of gMail and Slack.
This does exactly what it says… it will send your message at some later time. It completely removes the delay between writing an email and sending it later. I’ve found it particularly useful in scenarios like:
Sending emails when folks are more likely to read them - especially useful if you’re writing updates on a Friday or late at night. Having it send early the next morning brings it to the top of their inbox.
Queuing up messages for people in other time zones - for example scheduling it to drop into a coworkers inbox at 8 AM their time, even if it’s midnight my time)
Sending myself reminders to do something - I’m constantly sending things to myself in the future so I don’t forget something
Continual Improvements (Retrospectives)
We’re constantly working on improving where we work… but we rarely take time to improve how WE work. Making time to do a retrospective and actively work on continuous improvement is critical to improving.
One of the things I like most about Agile project management are the retrospectives. I do understand that they can sometimes feel onerous, or frequently have folks complaining about yet another meeting, but they allow us to do something to ourselves that we’re doing for our systems - continually improve.
Many of us are constantly focused on questions like “how do I make salesforce easier to use?” or “how do I ensure new hires can get their equipment faster?”. These questions are all basically a variation of “how do I continuously improve where I work?”. Many of us keep grinding away answering that question without taking (or making) time to step back. Retrospectives are our chance to change that question to “how do I continuously improve how I work?”.
Continual improvement is something we can do on our own, but I find it takes a LOT of willpower and energy. Critically examining my own work, habits, etc. is hard! Having a safe group to help me with this makes this a lot easier. There are, however, some ground rules that have to be followed:
Honest collaboration - everyone on the team has to have a mindset of helping the group improve. This isn’t an opportunity to blame Sally for that fire she caused, or Sam for forgetting to push an update. It’s an opportunity to identify ways to prevent the next fire from happening.
Everyone contributes - These meetings can easily be dominated by one or two voices. While they may have good points or ideas, there’s the rest of the team that doesn’t have a chance to share their insight. Everyone on the team has expertise and experience they can bring to the table if we just let them.
Document it - Once you’ve got the time set aside and the ideas flowing it needs to be documented… after all, it doesn’t help anyone if you take that time and then forget what you learned.
Make it regular - This isn’t a one time thing. Time should be taken for continual improvement on a regular basis. Making this habit part of your working cycle will help everyone get involved and begin moving towards better versions of themselves.
Exactly what these retrospectives looks like can differ, but the end goal is the same… making time to ensure the team is able to both improve the product, but also to improve themselves.
Ticketing system transition grace periods
Switching to a new ticketing system means new expectations on process and policy. Giving your team (and customers) a grace period to figure things out is a great way to introduce the new system without making things too heavy.
Moving to a new ticketing system (or starting one for the first time) can be jarring for everyone. Customers won't know how to ask for help, agents won't know how to update things and process managers will be scrambling for metrics. These challenges are common to all system changes, after all change is hard (citation needed).
To help combat this I find having a brief 'grace period' after deployment to be very helpful. During this period agents won't be too harsh on folks putting in tickets improperly, managers won't be expected to have a complete grasp of everything and agents can be forgiven for missing new SLAs or mis-tagging tickets. The length of this period can vary, but in general at least a few weeks is needed to help with the transition.
This grace period doesn't mean I'm not paying close attention to how things are going. Instead it's the exact opposite. With all the new changes and process I'm paying more attention to possible challenges. The grace period isn’t just for the team, it’s also for me to figure out what adjustments are needed to further improve how things operate. Taking extra time and energy to identify, and correct, defects at this stage will pay off later since it's all new.
Implementing a new ticketing system (or really any systems) presents an opportunity to set expectations on how folks interact with it. Once everyone has had time to learn bad habits it will be MUCH harder to reshape behaviors. This makes having a set window where everyone acknowledges they’re still learning, and ensuring folks are actively aware they need to change, very important in this shift.
I also find that treating this grace period like a retrospective and regularly review everything with the team (and customers!) is beneficial. I find calling attention to mistakes, and using them as learning opportunities, is a great way to help the team improve during this time and helps provide the best transition possible.
Misalignment within stakeholders
All the stakeholder and Project team alignment in the world doesn’t help if your stakeholders aren’t aligned with other stakeholders. Take time to ensure stakeholders at all levels understand what is being prioritized to help avoid some painful outcomes later.
Alignment with stakeholders for things like expectations and priorities is incredibly important (citation needed). Indeed, it takes up most of my time as a project manager as a misunderstanding here can lead to poor outcome (at best). While this can be challenging, at least project managers have some control over it; we can communicate with those stakeholders to ID and set those expectations. The harder challenges come from misalignment within stakeholders.
Imagine a scenario where you agree on a set of priorities with your main stakeholder. Your team executes on that, and then provides the final deliverables on time. And then things go sideways. It turns out what you delivered wasn't what was really needed.. despite being what was agreed on with your stakeholder. You and your team might rightfully be confused as to what happened… after all, everything was agreed on and delivered on time.
Despite that agreement, it turns out you weren't working on what was really needed because your stakeholders weren't aligned. This misalignment could be because stakeholders at the same level didn't align with each other (for example two managers on the same team), or it could be because management above whomever you worked with had a different set of priorities (a manager and their director). Regardless, you and your team have delivered the wrong thing and may take a reputation hit because of it.
At the surface level this seems to be a problem for your stakeholder to solve. After all, THEY weren't aligned. At its core, however, this relates to not properly engaging your stakeholder group. It's possible you didn't properly ID who you should speak with, or maybe you did, but then didn't share enough information.
This risk can be mitigated by ensuring your RACI is as complete as possible (especially the Inform group), and ensuring you communicate out priorities for your next Sprint / project / etc. Personally I tend to share this with my stakeholders leadership as an FYI on a regular basis (monthly or quarterly depending on the group), just to ensure they've at least received this information. At worst it's adding an extra email address, at best, it saves a TON of headache.
Expectations with transitioning to a ticketing system
Setting clear expectations for how a new ticketing system should be used is critical to its success. After all, nothing aggravates a customer more than not knowing how to get help so they can do their job.
The move to a ticketing system is a necessary step in a company's growth. It can be an exciting shift (especially for the support teams using it!), but it can also be cause for some heartache, especially for the end users expected to use it. The root cause tends to be change… those individuals are going from simply emailing or talking to someone to now having to use a System.
Generally it doesn’t matter what system is used, there’s now a process to follow. That process could be as simple as using a new email or more complex like having to go to a website and fill out specific fields in a form. This change results in friction, especially when expectations for what those users should do aren't clearly set.
Exactly what is expected can differ, but regardless of specifics, what an end user is expected to do should be considered during the deployment process. Taking time to think through what they’ll need to do, speaking with some directly, and adjusting your system to help make things easier does take time, but it will pay off in the end.
Failing to think this aspect through can lead to a lot of friction as your new process and system is rolled out. Customers, after all, are the ones who are coming to you asking for assistance. They’re the ones who may not be able to get their own work done, and now knowing how to reach out for help, or not knowing when help will be provided, can make their lives a lot more miserable.
Below are a few questions I ask myself to help figure out what those expectations are. By no means a complete list, but a good starting point that will help you get into the head of the folks expected to use your shiny new system:
Who will be putting in tickets? I prefer that the person experiencing the issue report it, but will it be OK for someone else to submit it? What about agents submitting on behalf of a user?
What is the expected response time? Knowing how long to wait for a reply or resolution is critical, but to protect your team and also to keep users comfortable with timelines. Having this clearly set and shared is important.
Where/how should tickets be entered? Ensuring everyone knows where, and how, to enter tickets reduces frustration, especially if it changes. You should also consider what happens if someone puts in a ticket the 'wrong' way.
Basic Ticketing Systems Data Points
Ticketing systems are great... or at least they're necessary to provide some semblance of order to the chaos.. Having one is a big step in helping better understand what your users need, where errors originate, and how to improve your process. Just collecting a ticket, however, isn't enough, it also needs to collect useful data points.
Exactly what those data points are will differ based on your needs. A library, for example, will likely need different data than a startup or a big company. Regardless of size.or industry, however, there are se basics that everyone should be collecting. Many of these are done automatically, but others may require setup or configuration depending on your system. The fields you choose to collect may also change over time… this is fine! As organizations change and grow their needs for data collecting will also change and grow. At the start though, it’s very useful to collect the following:
Reporter - this is the person who enters the ticket. This is needed to get more information, share updates and understand where tickets come from. This can also generally be used to gather more info, such as location, department and other data points related to the reporter that are useful in analysis.
Assignee - this is the person working on the ticket. This is necessary both to ensure one individual is actually doing the work, buy also useful in tracking utilization and bandwidth with your team.
Time entered - the time the ticket was created is useful for several reasons, including tracking response times and SLAs and routing tickets.
Time completed - similar to time entered this is useful in tracking your SLAs and how quickly your team can close specific ticket types.
Type of ticket - this can go by different names such as issue type, case type, etc. Regardless of its name this field tracks what 'bucket' your ticket falls into. Exact values vary depending on need, but examples include things like 'access request' 'training' and 'bug report'. This data is very useful identifying trends in your tickets.
Ticketing for the Small Things
Ideally our ticketing systems capture EVERYTHING… this can be annoying for the very small asks though (e.g. password resets). Having a quick way for your agents to enter and close a ticket makes this MUCH easier.
Ticketing systems are incredibly important to ensuring users are supported. Not only do they allow us to track any given issue, they give us the ability to look for trends and changes in what’s happening by digging into data. Ideally, every single contact gets a ticket. This includes the simple requests, like reset my password, and the complex ones, like install a new system.
I find it easier to sell the idea that tickets are needed for the bigger asks. After all, they tend to have more moving pieces, require more documentation and are generally more complex. Getting buy-in for those simple requests, however, can be challenging. After all, sometimes it takes less time to just do the Thing that it does to put in the ticket. Ticketing always increases friction since someone needs to fill out a form, but it’s completely understandable that it shouldn’t take more effort to do that than fix the Thing.
What to do then?...
My personal approach is to setup my system so specific types of tickets just auto-close when they’re created. I’ll still have to enter the reporter’s name, but otherwise it’s a one-click process. The total number I have depends on the types of requests I’ve identified, but there’s really no limit. The biggest challenge is ensuring only items that don’t require additional information don’t end up here. I’ve dropped some examples below, but I’d encourage you to think through how your help desk can be sped up using these one-click submissions.
Some Ideas (all should collect the reporter’s name, and assuming no approvals/etc are required)
Password resets - ensure you capture the system
Basic hardware - e.g. getting a keyboard, power cable, etc
How do I? - referring someone to documentation
Is X system down? - refer them to a down detector / status site
On Logging Tickets
As company’s grow it isn’t possible to just walk up to IT and get help. This is where ticketing comes in. The shift can be hard, but the metrics and ability to track work is more than worth it.
On logging tickets
Technical support is an interesting place. It’s where everyone goes when a thing breaks, or they need help, or they’re stuck. In smaller companies (under, say, 500 folks) technical support can be fairly straight forward - just walk over to so-and-so’s desk and ask for help. In larger environments, however, this breaks down… dozens, or hundreds of people needing help in multiple physical locations makes walking up to a desk MUCH less impactful.
This is where ticketing comes in. Some type of ticket or case or contact or whatever you call it needs to be submitted to track the work and the request. I’m amazing at how much pushback this can generate, especially in environments making the shift from smaller, walk-up-to-the-desk approaches to more mature enterprise levels.
The biggest piece of pushback tends to be that tickets aren’t perceived as being “white glove” or “high touch” service. By requiring a ticket, we’re divorcing the user from the process and making it a colder, more mechanical, transaction. On the one hand, this is true - we are requiring the user to use a form or submission portal to enter information. That said, having a “white glove” service for 1000’s of users isn’t possible without a massive number of technical support agents involved.
The tradeoff is the ticket - an artifact that allows for tracking of each request. Not only does this allow any given technician to monitor how the request is going, tickets also give us data. This can be used to look for trends and patterns. Hard numbers also make it easier for a support organization to quantify what they do. Instead of “well it feels like we’re constantly busy answering tickets”, it becomes “last month we answered 1200 tickets”, or “we’ve got 120 open tickets, I need more agents”. The minor loss in “white glove” service is more than made up for in understanding the patterns and underlying flows of support at the organization.
Responsible
R is for Responsible. This is the individual or group who needs to Do The Thing… they may also be Accountable, but not necessarily!
The “R” in RACI stands for responsible. This one confused me for a bit, since it seemed to be very similar to “accountable”, but really this is the person who will do the Thing. You may even have multiple people Doing the Thing, but at least one person has to be clearly identified as the Thing Doer. The Responsible person may also be Accountable, but doesn’t have to be. For example, an Executive may be the Accountable party, while a developer is responsible.
When assigning someone to the R in the chart, remember to clarify what exactly that entails. Does this person have to commit code a certain way? Submit a form? Deploy a customization in a specific system? Knowing that someone is responsible doesn’t really help if they don’t understand what that means. I find this is true for all aspects of a RACI, but if the Responsible party doesn’t have clarity relating to what they’re supposed to do, nothing will get done.
Personally I try to keep the number of “R”’s small for any given task. While this isn’t always possible, I find it helps streamline things a bit since there’s less parties involved. It also ties in to “Everyone thought Someone would do it, but Nobody did”.
For me, the Responsible party should also be providing updates on how they’re doing (and is something I clarify when I assign an “R” in my chart). This may take the form of updating a ticket, or sending a quick email out with some bullet points. Generally I use this input to develop my own reporting, but having the R resource send it proactively helps to keep information flowing more easily (and I don’t have to go chase anyone down).
RACI
There’s a LOT of project management tools out there (citation needed). Many times we don’t need them all, but I find a RACI is something that is ALWAYS useful.
Ensuring projects go well is a challenging task. There’s tasks to sequence, resources to line up and stakeholders to keep updated. Even on smaller projects this can easily become overwhelming, and failing to follow through properly can lead to some terrible results. This is where a RACI - Responsible, Accountable, Consult and Inform - chart comes in.
In short, a RACI helps you determine who is involved in a project, and to what degree. It does take some effort to set up, but once you’ve got it done, it becomes a lot easier to know who is doing what, or who should be involved in specific items. Let’s take a quick example - updating a data warehouse - to see how each of these fits into the puzzle. I’ll be digging into each of the letters in followup posts, but in general:
Responsible - This individual or group is the one doing the work. In our data warehouse example this might involve writing new code for a data pipeline, or optimizing data structures.
Accountable - Generally the person or group who ensures the work gets done (and whose neck is on the line if it fails). In our example this may be an Engineering leader, or a project manager who is overseeing the work.
Consult - People or groups who may have input, or need to share their needs and point of view. For our example project this could be downstream groups that use the data warehouse to run reports, or it could be upstream systems that feed data into the warehouse.
Inform - Anyone who needs to get updates on what is going on. Generally executives who may be involved, or stakeholders who will indirectly be impacted. Personally I include these folks on a weekly update just to ensure they know what’s going on.
Ideally a RACI defines each aspect, major task or milestone of a project. This helps ensure that everyone knows who is doing which part. Not only does this make planning easier, but if something does go sideways it’s much easier to track down who should be contacted.
Personally I find the time spent building a RACI to be more than worth it. Not only does this exercise help demonstrate you take the project seriously, but it gives you a valuable tool to use later in planning.
Implementing Structure
Early on companies may not need much structure… but as they grow it is vital to their success. Not only does it help set expectations, it ensures that the right folks get the right info. The trick, is building just the right amount.
Companies start out to do something (citation needed) - create a product, provide a service or invent. At the start companies are smaller, and can move very quickly to adjust or change their plans. This agility works well with smaller groups since there’s a smaller number of individuals who need to be involved. These smaller numbers make communication and expectation setting relatively easy. As the group becomes larger, however, this becomes more difficult to maintain.
This is where structure comes in. You can’t exist without any, and you can’t ONLY have structure… but without structure larger groups become inefficient. As the group expands it becomes harder for information to reach the right folks at the right time and expectations become muddled. The solution to these challenges is to find the right balance of structure for the group.
Structure can be something of a dirty word.. After all, it means we can no longer run and do what we want to… we have to follow rules and do things that aren’t building/moving forward. These are valid points - structure does require us to follow some set of rules. Structure does take some time away from other, seemingly productive, activities. Structure does make us stop and “play by the rules”.
At its extreme (or if I’m being honest this tends to happen more often than not) structure becomes enshrined and is either blindly followed, or pushed to an extreme. At this point it transitions from a useful tool to help guide us to something that is toxic. This is the type of structure that makes someone skeptical that any structure can be useful.
Structure, however, helps us improve how we operate at size. Structure gives us a universal expectation of what should happen when. This makes it easier for new team members to join in, and helps ensure existing team members know what to expect. These expectations can range from how releases occur to what is communicated when to how resources are assigned and utilized.
Exactly what structure looks like and how it is implemented will vary based on the needs and the organization, but there are some basic building blocks that tend to show up everywhere around things like communication and planning. The thing to keep in mind is that the form it takes should be tailored to the environment it’s in… there is no “one size fits all”.
Ownership
Having a project team is one thing, but having everyone feel ownership of the work is something else.
Lots of work is done in projects to determine things like who is accountable or responsible for various items. This is a great necessary step, but I find many times we stop there. We write down our RACI, all agree on it and then move on. Agreeing on these things is important, but it doesn’t necessarily translate to anyone feeling ownership of the project (or pieces of it).
Ownership extends beyond taking on some work. It extends deeper, into feeling that you truly own it. It’s yours, and how you handle it is a direct representation of yourself. Frequently this feeling of ownership is lacking in projects, which leads to some less than desirable outcomes:
Lack of “push” - When someone doesn’t feel ownership of a particular item, they won’t push to complete it the same was as if they do feel ownership. They won’t go that extra mile, as that extra question, or do that extra test to really make it work.
General lack of interest - If someone doesn’t feel like they own a task or item, they won’t be as interested in it. This shows up as individuals not being as curious about their work and not understanding it as well as if they did feel ownership.
The good news is that ownership is something that can be cultivated. Some individuals will have more or less levels of it, but it can always be improved. There’s a few things that can help an individual build a sense of ownership, including:
Demonstrating ownership - It can be hard to feel ownership if you don’t see others practicing it. In order to help others build their sense of ownership, YOU have to actively demonstrate it. Showing your interest in the topic, constantly knowing what’s going on with it and generally moving it forward will help others cultivate their sense of ownership.
Getting to the core - Individuals may have some reason they don’t demonstrate ownership, one they may not even be fully aware of. Having a direct conversation with them about ownership, and why they aren’t demonstrating it, can help them flip the script.
Staying on them - A more intense/extreme tactic is to constantly ask them how their task is doing. Do they know the status? Why it’s important? Who’s impacted? Consistently pushing them for info and being present will force them to internalize a sense of ownership, if only to be ready for you.
Testing Test Cases
Getting test cases done can be a bit like pulling teeth, especially if everyone isn’t working on them together. I’ve found several ways to make it easier, but definitely prefer working on them in real time.
Getting test cases completed can be a big challenge. You need to identify what should be tested, how those tests will be run, who will run them and how you'll track it all. Each step is important, but ensuring it's actually done can be the hardest part.
There's a number of ways to do this, and each had it's own pros and cons.
Testing on your own
This is a very common approach. Just send out the test cases with some instructions and ask folks to run the test. The big advantage is this is entirely asynchronous. Testers can do their testing on their own time. A big trade off, however, is that since it's asynchronous it's hard to track and plan… you never know when someone will get it done.
Regular syncs, independent testing
This approach blends in regular meetings with testers while still allowing them test on their own. These regular syncs are useful as they give the y am a touch point for help, and let you more easily see progress. The check-ins help mitigate the risks Of asynchronous testing, but allowing testers to choose their own time to test still presents a risk that things won't get done in a timely fashion.
Scheduled testing sessions
The next step up is the schedule specific times for the entire team to connect and test together. This involves getting the testers, and the technical team, in a conference room (virtual or otherwise) and running tests together. This presents the best opportunity to solve challenges and get updates since everyone's in it together. Depending on the size of your group it can be challenging to find time/space for everyone.
One on one testing
This option involves scheduling one on one time for testers to connect with the technical team and test together. This provides the highest touch experience as each tester gets personalized support. This is a good option if specific users are new to testing or if they have a need for elevated support. It doesn't, however, scale well if the group is big as each tester needs their own session(s). It can also be very taxing on the project team as they'll have to sit on all those calls.