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.
Heads up!
No one likes surprises - especially in big meetings. Taking a few minutes to prep folks with an email / slack / call ahead of time can save a LOT of pain down the road.
No one likes being surprised. Ok, that’s not entirely true, instead I’ll say like no one likes getting handed big news in meetings. I’ve seen many meetings devolve into reactive damage control when some big announcement is shared that rocks the boat. Maybe it’s a project update that folks weren’t expecting, or maybe it’s some change in The Plan. Regardless, this information is new to at least some of the individuals involved, and they don’t take it well.
This results in most of the meeting taken up by explanations, of how we got to where we’re at, of why we made that decision etc. The time that should have been spent planning on next steps is instead focused on explaining what happened, resulting in a loss of time and potentially some credibility.
I’ve started to take a different approach. Instead of waiting for a meeting or gathering to pronounce something, instead I’ll give everyone a preview, a heads up, before the call. I’ll break down some of the ways I do this below, but in general they all have one thing in common - they eliminate the surprise factor.
Group Email
Sending a preparatory email to the entire group (or sub sets) is one great way to prepare everyone. Since email can be very asynchronous and is easily missed I tend to use this approach when the update will be less impactful. Email does, however, offer the advantage of being rather information rich - it’s easy to include links, documents, etc. to help bolster your message
Individual instant messages
If the topic is a bit more contentious/sensitive/etc, or if the stakeholder has more influence I’ll reach out directly with an instant message. GIven the prevalence of tools like Slack, this can be seen as a more personalized approach. It is also, at least in my experience, less likely to be ignored until later (like Email) and tends to get a quicker response.
Pre-Meetings / Calls
If it’s a VERY sensitive topic or highly influential stakeholder I’ll reach out to them via call/virtual meeting for a face-to-face update. This is the most time consuming and hardest to do with larger groups, but can help you get the message across in the most effective way. It also demonstrates that you take this seriously which can help further blunt any impact.
Stay on Target
Keeping meetings on track is challenging. Ensuring there’s a solid agenda, and deflecting other topics to a future call are two tricks I find are helpful to keep everyone on target.
Meetings are (generally) useful things. They allow groups of individuals to get together and figure out a solution to some challenge. It could be a small thing, like what to get for lunch, or a big thing, like how to send someone to Mars. Regardless of size, however, it’s incredibly important for them to stay on target.
Humans are, by nature, a bit chaotic. Many things demand our attention, so it’s no wonder that meetings can wander all over the place as different folks bring up different topics. This can quickly turn a potentially short productive meeting into a complete waste of time that leaves everyone wondering why they came. I’ve found a two things that have helped me keep my team on track:
Share a clear agenda - This seems like a no brainer but I constantly find myself with invites to vaguely worded meetings without an agenda. (As an aside I tend to decline these and ask for an agenda before I accept). At best this leaves the invitee’s confused as to what is for and wondering why they should attend. At worst, individuals will simply ignore the invite.
The Fix : Take a few moments to add bullet points to your meeting invites. Something as brief as the following can be enough to keep folks on track:
Review project status from yesterday
Update risk catalog
Determine schedule for testing
Keep everyone focused - A (generally) positive thing about meetings is new ideas will come up. Someone will remember some item, or bring up a related topic that could benefit the group. The problem is these ideas distract from the purpose of that particular meeting. Yes, those ideas are important and should be addressed - just not right now. If unchecked this can easily drag a group down.
The Fix : Don’t be afraid to ask folks to continue a specific discussion later. This could take the form of a quick meeting after the current one, an instant message, an email, whatever, just get them to have the chat later. Clearly acknowledge their idea and it’s importance, but get back to the topic of the call.
Keeping up awareness
Ensuring all parts of a project are up to date on whats going on is hard. There are a number of tricks that can help this though.
Projects tend to do a great job at the start by letting everyone know what's going on. Stakeholders are given demos, requirements are gathered and everyone is on the same page. Then things begin to drift. The project team may know what's going on, and updates may be sent out... But many are likely to lose track of what the project is for, and what the benefit is. Keeping all those moving pieces up to date and, and ensuring everyone is aware of the various changes can feel like an impossible task.
The folks working on the project are the most likely to know what's happening... After all, they're doing the world. That said, project teams can be big, and some individuals may not be as up to date as others. This is only amplified when multiple teams are involved as each one will have its own perspective on everything. When outside groups, like consultants, are brought in, this can only add to the challenge of keeping everyone updated.
The further any given person is from the project work, the less they'll likely follow up on it themselves. This raises a significant risk that stakeholders will forget what they're getting. At best this requires a realignment... At worst it kills a project.
There's a number of ways to counteract this knowledge drift:
Regular updates - emails and reports are the easiest, and should be sent out anyways. Ensuring they're easily understood is important, so asking for feedback is critical. Having the right audience is also important as different stakeholders will need different info. Your VP isn't as likely to care about minute bug details as your developers.
Recorded demos - recording updates and sharing with the team is one way to visually share updates. This doesn't have to be a long demo, just enough for folks to see what has been accomplished. One big advantage of this approach is being able to compare updates over time.
Live reviews - Agile's sprint reviews are a great tool to borrow for any project. These meetings are specifically to update stakeholders and to solicit feedback. These live calls also help build rapport between customers and the project team.
You work, I work
Teams are people working together. This includes those times we have to work over time, on holidays or into weekends. I’ve made this into a rule; if any member of my team is working, so am I.
I’ve spent a lot of my career on various project teams. I’ve been on large, multi-national deployments, handled startups getting their medical benefits for the first time, run projects entirely on my own and been part of much much larger teams. While they were all very different, to me they all had one thing in common; the project team.
Teams were obviously composed of different people at different times and places, but all projects have some kind of team. How that team functions is critical to the success of the project; a dysfunctioning team increases the risk of the project going poorly. This isn’t to say a perfect team will always have a successful project, but a dysfunctional one will be at a much higher risk of failure.
As the project manager (or really any non-SME / technical role) I tended to be close to the work, but not close enough to do a lot of it. At times, I also have to be the one to decide if the team needs to work late or work over a weekend or a holiday. Over time I’ve always followed a very important rule when I make those decisions ; if anyone on my team has to work extra hours, I will be right there with them.
Essentially this means that if any of my team is working a weekend (or over time) so am I. At the very least I’m in the office with them (or online and on slack) to simply be around them. This is incredibly important because it shifts the dynamic from “I’m telling you to give up spare time to work” to “we’re in this together to get it done”. I’ve found this not only helps break down push-back to working extra, but it can help inspire others to volunteer to pitch in as well.
I also find this a great way to build space for myself to take on tasks I “don’t have time to do” otherwise. This time is focused on the project my team is doing, but can be used to catch up on other aspects like improving documenting, reviewing lessons learned and updating plans. For me, it all boils down to the team aspect of a project team. We’re all in this together.
Let others do their jobs
Transitioning roles can be exciting… but one thing we have to remember is to let go of the old one. Staying too involved cheats our replacement out of valuable experience, and holds us back.
I’ve had many transitions in my career; points in time where my job shifts a bit and I now get to do something new. Doing something new also generally means no longer doing something old though, and this can be tough. Tough, because you’re used to doing it. Tough, because everyone knows YOU do it. Tough, because you don’t think someone else can.
Letting go of those things is hard, but it’s also important to our own development, and maybe more importantly, for others to develop. If we never let go of the things we used to do, the things that we’ve grown out of, we’re essentially cheating others out of the same opportunity we had to learn those skills. If we step in and keep doing the same work we used to do, not only are we spending our time in an area that won’t help us grow, we deny others their chance to grow.
I’m not saying we don’t help someone who’s taken over an old role. We certainly need to help set them up for success by giving them support, teaching them the ropes etc. What we want to be careful of, however, is continuing to do that job even after we’ve moved on. In addition to preventing them from learning, we also distract ourselves from our new role. There’s only so much time, and any minute spent on the old role is one less spent on the new one.
I see this frequently happen when a new ticketing system and team comes online. The group that used to do the work doesn’t want to let go. They’re concerned the new system won’t track everything, or that the new team won’t be up to snuff. There’s almost always SOME amount of disconnect as the new team comes online, but those aren’t just negative experiences. They’re also opportunities for the new team to learn how to improve. Making mistakes is one of the best ways to learn, and allowing others to make them is beneficial in the long term.
I’ve found that focusing on the new work, and checking in regularly with my replacement, is a great balance between the two. This allows me to excel in my new area, but also keeps a communication channel open in case something is needed. This helps build a strong relationship that makes the transfer more seamless, and easier, than if I stayed entirely involved.
Ownership
Ownership is critical to the success of a project or initiative, but it can be frustrating if someone doesn’t share that view. Sharing your own experience with it can help spark them to join in.
I’ve always felt some degree of ownership of the work I do… after all, it’s a direct reflection of who I am and what I do. Ownership to me is very similar to accountability. Both ownership and accountability involve being invested in something and helping drive it forward. They both involve having to understand as much as possible about that thing as you can, and they both involve being bound to the outcome. Where they differ, however, is in where they originate.
Accountability, I find, is generally external. We're told by our boss/teacher/partner that we're accountable for the project/assignment/chore. Accountability is something that someone else puts on us to complete a task. This isn’t a bad thing, as it helps us find our target and drive the project forward. It provides excellent external guidance on what we should be doing, which helps us shape our approach.
Being external, however, has its downside. External drive is harder to sustain as it requires someone else to push us along. Generally this can kickstart internal motivation, but sometimes it doesn’t, and suddenly it requires two people to do the task. External forces can also push us in a direct we maybe don’t like. Perhaps it’s a project or task we just don’t want to do. This makes it harder to get motivated and follow through with completing the task.
Ownership, I find, is generally internal. We tell ourselves we're responsible for that thing, and it is up to us to beg/borrow/steal to make it happen. Personally I find that once I understand what is needed I tend to assume ownership of projects and the like quite easily. I take a look at what is being asked of me and I make myself responsible for the outcome. If it doesn't happen it's not because of some external force (something being unavailable, someone missing etc, it's because I didn't get the resource I needed, or I didn't ask for help.
The plus side of ownership is the feeling of having a stake in the game. I’m part of that thing, so I’ll do whatever I can to make it happen. The downside of ownership is it can be hard to feel. Sometimes I just don’t feel like I’m an owner. Personally, I find it the most frustrating when others on my team have different levels of ownership; some are all in, some part way and others couldn’t be bothered.
I find the best way to help others invest in ownership is to speak to my own experience with it. Letting my team know that I stay up late working on the project, or showing them how I go the extra mile(s) to get something done helps spark that feeling in them. From there, it’s just a matter of encouraging them to continue to invest in their ownership.
Metrics Storytelling
Sometimes we don’t get the progress metrics we want. In these cases we need to see how we can tell a story around what we DO have.
A large part of project management is collecting and sharing metrics on how things are going. This could be the number of test cases completed, amount of code developed, or any other quantifiable aspect of a project. Sometimes the numbers tell an obvious story - we completed everything, all the code is done… but sometimes the numbers tell a more subtle story. To me this is much more interesting because instead of just sharing numbers, it requires me to dig in and find a story to tell about those numbers.
Sometimes the story isn’t “we were able to complete all our objectives this week”. This message can be hard to pass along since it isn’t the best outcome; actually completing the work. Instead, we have to dig in and see what other positives may be going on. Here’s two additional things I look at for reporting:
Momentum
Depending on the task that has to be accomplished it can take some time for things to get started. Test cases, for example, may have a delay between “started” and “completed”. This can result in completion metrics being relatively low in the first parts of the testing cycle, with them eventually catching up as cases are closed.
In these instances, I remind everyone to not only focus on the percent complete, but to take into account the “in progress” numbers as well. Generally these will begin converting to “passed” and will result in success.
Error Resolution
Despite the best setup possible, errors also pop up in testing. While these do represent more work and need to be dealt with, they do represent another source of positive metrics that can be shared. While initially reporting on the number of new errors can be stressful (after all it’s MORE work), reporting on how quickly the team triages and resolves them is a positive.
I see it as a positive in two ways, first the team is actively improving the process by IDing errors, and two, the team is fixing them (hopefully quickly!). Both of these can be presented as a value add vs. a distraction.
Both momentum and error resolution rates provide a lot of great stories. The secret is just to keep your eyes on and be able to point out positive aspects that help keep things moving.
On taking notes
Taking notes, especially during meetings, is a VERY easy way to create value, and help save your future self from potential challenges.
I've found myself to be a compulsive note taker. Every meeting I'm I. I'm constantly writing down the topics, what was said and follow ups. If I'm being honest this started when I almost fell asleep in a VERY exciting meeting about the chart of accounts... Regardless of how it started though, it's been a very handy compulsion.
It keeps me engaged
This compulsion started as a way to keep me engaged in the discussion. In order to write down what was going on I had to pay attention. Paying attention meant I had opportunities to be involved in the discussion.
Over time this engagement helped me pick up a lot of new ideas and skills. Simply by being involved in the meetings I learned more about the topics being discussed. Over time, this has helped me understand complex deployments, foreign concepts and new areas of the business. At the very least it demonstrated to my team that I was present and involved.
It provides instant value
Recording notes is an incredibly easy way to show you're creating value. Suddenly you go from being just another person in the meeting, to the person in the meeting who actually knows what happened. After joining a new team I constantly hear I'm providing value quickly.... Just by taking notes. Honestly I find this a bit funny since all I'm doing is writing things down, but it's a real easy win.
It covers your (you get the idea)
Having a stockpile of notes is a great way to cover yourself if you need to. Being able to go back and determine when a decision was made, or when a topic first came up is very powerful. Personally I've used this many many times to remind folks of what we had discussed... And in a few places averted major escalations by proving a point.
Sometimes it's not a stakeholder I need cover from... by myself. Sometimes (ok, many times) my memory feels like swiss cheese... I'm constantly going back to review what we went over, if only to ensure I make the best decision. Having my stockpile of notes gives me an incredible resource to rely on to help me make better decisions.
Frameworks
Having a framework for how things should be done is important… but equally important is ensuring your whole team shares that same framework. Nothing is worse than part of your team assuming things are done one way, when they’re really done another.
Frameworks
Projects are a funny thing. Everyone’s been on one at some point in their lives (even if it’s as “simple” as planning a trip), which means everyone kind of knows what to expect. This is good, because it means we all have some general idea of what the next steps are… but this is also not good because we all have our own assumptions / pre-conceived notions of what to do when.
Why This is good
All projects follow some version of ideation, planning, execution and completion. Exactly how that’s done differs, (for example Agile iterations over that execution and tinkers with planning while Waterfall sets it in stone), but all of that happens in one form or another. This makes it (relatively) easy(er) to translate our experience from one project to another, even if the exact topic or domain differs.
This is a good thing since we all have at least SOME shared experience. We’ve all had that moment of terror when we forget a detail and have to scramble to fix it. We’ve all had that moment of satisfaction when the project or milestone is done and we can check something big off the list. This makes joining a new project a little bit easier; we’ve seen how it’s done.
Why this is really not good
This familiarity, however, has a downside. It makes us complacent. It allows us to “safely” assume that one project will be anything like another, or that how one project is run will be how future projects are run. While this may lead to minor annoyances in smaller projects, it can lead to catastrophic problems for larger ones.
How to avoid the not good
There is a way to both capitalize on prior experience and avoid the pitfall of assumptions, and that solution is a framework. Frameworks give the team a shared understanding of what is expected. They take work to develop, teach and maintain, but the effort is worth it.
Building a framework is as simple as laying out steps to follow. Answering questions like 'how will we prioritize new work' or 'how will we run testing meetings' will help clear up confusion and avoid problems before the occur.
Just making a framework isn't enough though. We also need to gain buy in from the team, ensure they understand how to use it, and then actually use it. The payoff, though, is worth the effort.
No Update Updates
Sometimes we don’t have anything to report on how things are going… this, however, is (oddly) important to report! Letting folks know you’re still on it is just as important as having progress for them.
Communicating with stakeholders is important (citation needed). These updates frequently take the form of status updates, alerts, progress reports and more. All of these things are very important to share and ensure everyone has. That said, sometimes there simply isn’t an update share… maybe nothing major happened, or maybe stakeholders already know what’s going on. The exact reason doesn’t matter… what does matter is sending an update.
Sending an update like this sounds weird since there may not be any change or anything to update people about. Sending an update feels a bit ingenuous, or like a waste of time. In scenarios where updates are regular and expected, continuing to send one is important since it keeps up the schedule. These updates let stakeholders know you’re still there and keeps them engaged. It gives them that regular touchpoint they’re used to and reassures them you still care.
The trick is what to put in this update… after all, there may not be a big change going live, or any fun metrics to share. Frequently I’ll simply say something like “No specific progress was made this week, but we’re still tracking towards our plan”. Updates like this let the stakeholders know we’re on track, and allows them to spend their mental energy elsewhere. It also takes the important step of letting them know you’re still aware of their request. After all, nothing is worse than a stakeholder wondering if you still care about the work.
This trick is very useful on bigger updates, but I also frequently use it on tickets…. Especially when nothing’s changed. I might be waiting for someone else to take some action (e.g. a third party vendor or teammate), or I may just not have been able to get around to working on that ticket. Regardless of the background, this strategy helps the reporter know you’re still there and can prevent nasty escalations. Instead of them complaining to your manager that you’re not paying attention, they know you’re on it, even if nothing is going on.
The Importance of Triage
Triage is an important part of ticketing. Sure, it takes some time and effort, but it helps ensure basic information is available and the best resource is assigned to the task.
Every process has a point of entry, the point or place at which new work is considered and brought onboard. In the ticketing world, whether it’s for a benefits team, IT team or anyone else, this point of entry also represents a challenge; frequently requests come in that are missing information. As these move through the process they start to gum up the works as downstream folks may be missing critical information and have to go find it. At best this slows things down, at worst it results in a catastrophic failure.
This is where triage comes in. I think of this as a sub-process that runs as soon as new work enters the queue. Exactly what is performed here can vary, however, there are some standard questions that should be asked and actions that should be taken regardless of specifics.
Is the request clear?
Many times a request comes in and it’s hard to tell what it’s for. Maybe the name is poor, something like “New report request”. New report request for what?... for who?... when is it needed? Or maybe they’re asking for something sensitive but don’t provide any reason why. Regardless, we should always ask ourselves “Do I understand what this request is for?”. If I cannot answer “yes”, I follow up with the customer and ask for more information.
Is any information missing?
Similar to understanding the request, we need to ask if there’s enough information to take action. Asking for a change to report, for example, is useless without knowing what the change should be. Asking for access to a system without providing what type of access is similarly useless. Taking a moment to ask yourself if there is sufficient information to take action (or for the next person who gets the ticket to take action) is the next critical step. If you think any is missing, just reach out to the customer and ask for clarification.
Who should work on this?
Once we’ve got enough info on the request, we need to then determine who should work on it. Sometimes this is REALLY simple; there’s only one person to give the ticket to. Other times, this can be very complex if there’s multiple available agents to help out. In these circumstances figuring out who can/should work on the ticket can take a bit of thought since we have to take into mind things like workload and experience. In these scenarios I find it most helpful to have a list of who is trained/experienced in specific areas, and have access to everyone’s workload. These two pieces of info can make it easier to figure out who to assign the ticket to.
While triage does take time, it does streamline things quite a bit. By ensuring the ticket has sufficient information and is assigned to the most appropriate resource we set ourselves up for success. Even better, it helps build trust-based relationships with our customers by demonstrating we care about their needs.
Rolling out an intake process
Rolling out a new intake process can be tricky.. you need to ensure you’ve got buy in from the business and that everyone is aligned. Be sure to connect with their leadership, and invite them to collaborate to help make a strong process.
There's tons of ideas for work and projects floating around, and there's certainly no argument that there's tons of work to do, or that a lot of that is important and should get done. That said, this doesn’t mean that it ALL should be done. Frequently teams end up getting bombarded with different requests from multiple angles. Individuals will approach random team members and ask for some work, or executives will plan something out and assume it'll get done.
The challenge in the tech team is to figure out how to setup an intake process to streamline, filter and accept work. This process should include a way to evaluate the value of the work (e.g. what the business gets out of it), as well as the relative effort of the work (is it possible to accomplish with current resources). A good intake process results in several changes in how work is sourced, how it's accepted and how a team decides what to accept.
While there certainly is a lot to it, one of the biggest impacts I've seen is for the business side; they now have to follow a process instead of just flinging ideas at you. This makes getting buy-in from the business critical to any intake process. Not only are you changing things up for them, but you're adding process, which means things take longer. There's a few things I've found that help reduce this impact;
Start early
Once you've determined a basic I take process start socializing it with your business partners. This means letting them know what the plan is, and more importantly, how it helps them. Giving the team loads of time to get used to the change will help blunt the surprise when it goes online. You can start early be constantly bringing it up in meetings, reminding folks when it’s going to go online, and providing documentation on how it works.
Talk to the top
Like any process change, be sure you're getting buy-in from the leadership of your business partners. Ensuring the VP or Director is onboard will both get you an ally who will spread the word, but also give you a backstop. This makes it much harder for someone to not follow the process since their leadership is onboard. It also helps demonstrate you want to collaborate with the entire team instead of just pushing new processes onto specific individuals.
Be consistent
Once the process is in place ALWAYS use it. Nothing will undo it more quickly than one person or project getting to skip the line. This isn’t to say the process can’t or won’t be changed, just that it should be consistently applied across all requests / projects.
Collaborate
Once you've created your basic process, share it with the business. Explain to them why you started here, but ask them for their input. At the very least this gets more buy in, but it's also likely you'll get some good ideas from it. As the process matures, feedback from your business partners will also be a great source of ideas. After all, they’re the ones who have to deal with it on a regular basis.