Confluence Databases for Project Tracking
Databases offer a number of features that help project managers stay on top of tasks in Confluence
Keeping track of all the pieces of a project can be challenging. Fortunately, there are a ton of different tools out there to get the job done. Recently, however, I’ve been using Confluence Databases to see how this feature can help me track project work, and I’ve found it to be pretty good at handling small to mid sized projects.
What is it?
Confluence Databases sit somewhere between a table/spreadsheet and Jira. They live in the content tree of a Confluence space, and look similar to a table. That is where the similarity ends though, as they have a number of functions that are very useful in tracking project statuses. This includes things like tracking specific users, linking to Jira tickets or Confluence pages, and even linking to other tables.
Features that help project managers
There’s a few specific features that I’ve found make a database very useful to project managers.
Saving (and easily sharing) filter views is incredibly useful. This allows me to create a view once, then share it with specific groups. I could, for example, share a list of new tasks with analysts so they can build out specs, or a list of blocked items to bring up at the start of our calls. Since the filter is saved in the URL this is as easy as copying/pasting, and can be bookmarked.
The native integration with Jira is another great feature as it’s highly likely I’ll be using Jira if I’m in Confluence. Being able to link a line in my database with 1 (or more) Jira tickets lets me keep my developers in Jira while still giving me easy access to what’s going on in there. This allows me to easily give my stakeholders a view of the project that isn’t too “technical” while preserving direct links to more information in case they want it.
Finally, configurations can be copied into a new database. This lets me easily make a clean copy of the database for a new project and preserve all of the columns and other settings I have. This means that once I have a good structure in place I can make as many copies as I need to, slot them into the proper place of Confluence, and not have to worry about deleting anything.
Database Setup
I’ve been using Databases to track relatively simple projects, so I added in a number of basic fields:
Task Name - A text field containing the name of the task
Status - A Tag field indicating the status (To Do, Blocked, etc) of the task
Owner - A User field with the task owner
Due Date - A Date field with when the task is due
Jira Ticket - If the task has a jira ticket it’s linked here
Jira Ticket Details - The assignee of the linked Jira ticket
Documentation - A link to any Confluence pages with more information
Why not just use Jira ?
There is an interesting question of why wouldn’t I just have used Jira to track my project work. There’s a few reasons:
Trying something new - I find it’s really important to expose myself to new ideas, tools and methodologies. Not only will this give me more options for managing projects, but I might find something useful that can be applied elsewhere.
Light weight - Setting up a Jira project takes time and sometimes requires a Jira admin to help with setup and changes. Both of these things may be in short supply, so having an option that is more robust than a spreadsheet (which may be flexible, but lacking features), but less heavy than a full-on Jira project is very attractive.
Presentable - I’ve found that many stakeholders don’t like going into Jira to get information on how things are going. Having another option, like an easily-accessible page in Confluence, has been great as people actually use them.
Flexible - The ability to easily add new columns, save filter-views and share information quickly makes databases very attractive. It hardly takes any time to add or adjust data, making it easy for my team to keep things up to date.
Integrations - Being able to instantly connect Confluence pages and Jira tickets makes Database more data-rich. For example teams can easily see any related Jira tickets, and stakeholders can easily access documents from one spot.
Why not just use a spreadsheet?
Spreadsheets are a great tool for many things, and they’re incredibly flexible. This makes them the go-to for many project trackers, especially if they don’t need specific features or integrations. That said, use a Database has a number of advantages:
Everything in one spot - If you’re already using Confluence you’re likely storing other project documentation in there as well. Having a database to track your progress puts everything in one spot, in the same system. This reduces the administrative overhead needed to track, maintain and manage things, and also leads to
Integrations - Aside from the built-in integrations with Jira, having your plan in Confluence makes it a lot easier to reference on other pages, integrate with other information and make more easily available.
Presentable - Similar to #3 above, I’ve found a database is easier to share with others, and easier for them to interpret. While a spreadsheet may have all the info in there, it’s easy for someone to go to the wrong tab, workbook, etc. and get frustrated.
Re-use - The configuration of a database can be copied into a new database in a few clicks. This makes it incredibly easy to spin up new projects with the same setup as an old one. A spreadsheet would require copying, then deleting everything to start over.
Final Thoughts
Databases are a great mid-weight way to track projects. The biggest hurdle for me was just figuring out what fields to include and after that I found them easy to update and use. Will they entirely replace spreadsheets? No, however, they do give project managers another great option to keep things on track.
Are system evaluations important? (Yes, definitely!)
I learned a valuable lesson early on - never, ever, pick a system randomly.
I worked at a company once where we used a particular software tool to manage our projects. It wasn’t a bad tool…. But it didn’t quite fit our needs. My team spent a LOT of time figuring out how to make it work, which not only distracted us from work it made us more than a bit frustrated. We didn’t have a choice though, so we suffered through using it, and finally, after about a year of pounding a square peg into a round hole we asked why we used that particular piece of software.
The answer… was a bit shocking.
Basically an executive was asked what we should use, and they pointed at the one we had and said “that one”. That was it. No further discussion. No questions asked. No requirements gathered. Nothing.
I had a feeling back then, and have since learned, that that is NOT a good way to pick a system!
Positives and Negatives
The positive aspects of randomly picking an option is it’s quick. You’ll get to the end of your “selection” process faster than you could otherwise. This can be an attractive prospect as system evaluations can take a lengthy amount of time and resources to complete.
In some extreme situations there can be an argument for speed, but I have never encountered one where every other aspect of the evaluation was thrown out the window. Needing to move quickly isn’t an excuse to not conduct due-diligence.
That positive aside, there’s a TON of negatives… things like:
Price - other options may do the same things (or do them “well enough”) more cheaply, or can be implemented more quickly. If you don’t evaluate those systems you won’t even realize you’re paying more for something.
Features - The one you pick may not do what you need, or may do it in a way that makes it challenging or onerous for your teams to adopt. Critical features can fall into this bucket, making a quick selection incredibly painful for teams when they realize their new system doesn’t do something they need to be successful.
Compatibility - The one you pick may not integrate or be compatible with other systems or processes you have. This can result in your teams having to do additional manual work to transfer information or get what they need. At best you may need to build custom integrations between systems, which introduces greater cost and risk, and in some cases may not even be possible if you don’t have the resources to integrate (either money or people).
Duplicative systems - You may already have a system that meets your team’s needs. Failing to recognize this could result in you ending up with two, VERY similar systems. This increases the administrative and budget overhead and adds unnecessary complexity to your tech stack.
Any one of these on its own should be enough to not randomly pick an option… all of them together make it a painful, and costly experience.
Doing it right
Instead of pointing randomly, groups should go through a more formal evaluation of their requirements and their options. This doesn’t have to be a months long, in depth endeavor, but it should at least involve some thought about what is needed, and how the options meet those needs.
Typically this process includes things like:
Identifying stakeholders - who will be using the system, or be impacted by it? Depending on their level of involvement stakeholders should be involved in the selection process to help ensure their needs are met. This list should include direct users, but also teams who would have to support or build the system (e.g. IT, engineering, etc).
Determine requirements - what challenge or issue needs to be solved and how should the system do that? The stakeholders identified in #1 can help pull this list together, but this is a critical step (one that the company I worked at definitely skipped!). By the end you’ll have a list of things you need to be successful, and while you may not get all of them, understanding what is needed will help you make a better choice.
Get options - After you know what’s needed, go and find potential options. This could be as simple as some quick googling, or an in-depth examination of what’s out there. Personally I find this to be an interesting step as I get to learn about what’s available.
Eliminate some - Compare your options against the requirements. Do any clearly NOT meet your needs? Sometimes you can figure this out just by looking at their website, other times you may need to send an email and ask for more info. Doing this helps weed out options that are clearly not a good fit, and saves time later.
Get more information - Once you’ve got a shorter list, dig in and really compare the rest to your requirements. Get a formal demo. Talk to other customers. Figure out how it really works. While it’s uncommon to find a system that really does everything you need, this will help you find the best possible fit. Have a core group of your stakeholders (especially from the group who will use the platform) get involved in this step as they’re the ones who will be stuck with the final outcome!
User Acceptance - If you decide to go forward with a new system make sure your stakeholders have a formal acceptance. Let them use the system and determine if it meets your needs… if not, work with the vendor to update or change things, but don’t just blindly accept that it works as expected!
All of this does take time and effort… however, it’s always cheaper to go through this process than to end up with a system that doesn’t meet your needs. Not only will you have to replace it, you’ll have to retrain everyone, find a new system, and rebuild credibility.
A great side effect of this process is it also gives you a great opportunity to build buy-in for the new system, to update processes and policies, and further enhance how your team operates.
Does it take time and effort? Yes.
Is it worth it? Definitely.
Boolean Basics - Parenthesis
Does anyone out there remember PEMDAS? I remember learning it back in grade school as a way to remember order of operations… but I never thought it would be helpful as an adult!
If I’m being honest I never thought it would be useful, ever, since I wasn’t into math… that said - I do NOW find it helpful!
Specifically the “P”, which stands for Parenthesis, is the part we’ll dig into today.
As a quick reminder, PEMDAS details the order in which specific mathamatical operations occur in an equation or statement. The letters stand for :
P - Parenthesis
E - Exponents
M - Multiplication
D - Divison
A - Addition
S - Subtraction
So if I remember 5th grade math correctly, any time I see multiplication in a math problem, I do that BEFORE I do any addition. Any time I see exponents, I should figure those out BEFORE I multiply anything… and so on.
Parenthesis, being the first letter, are done before annnnything else. In practice this means you take anything found inside a parenthesis and do it ALL before anything else. For example if we have
3 * ( 5 + 2 )
Then we first do the bit in the parenthesis like this:
3 * ( 5 +2) → 3 * 7
Then the rest
3 * 7 → 21
That’s a simple one… it gets gnarlier if the parenthesis are nested - that is parenthesis inside parenthesis… for example:
(3 * (5 + 2) ) * 3 + ( 2 + 1)
First we would find the “inner most” parenthesis -
(3 * (5 + 2) ) * 3 + ( 2 + 1) → (3 * 7 ) * 3 + ( 2 + 1)
And then the next layer
(3 * 7 ) * 3 + ( 2 + 1) → 21 * 3 + 3
And then the next operation (multiplication)
21 * 3 +3 → 63 + 3
And then addition
63 + 3 → 66
This means we need to be REALLY careful when parenthesis are involved, since if we don’t do those things FIRST, we’ll get a different answer. For most queries this isn’t too complex, as MOST queries only have none, or one, layer of parenthesis.
For the more complex ones, however, it can be beneficial to break them down (similarly to what I did above) to understand how they work.
A general rule I follow is that if I see ANY parenthesis, I take a moment to understand what they’re doing, even if things seem simple. Taking just a moment to unpack what they’re doing will save you a LOT of headache later!
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.
"Its broken"
Having a solid relationship in place before something goes wrong is incredibly important to helping folks navigate challenges.
Many times I’ve received a report that a specific system or integration is broken, only to go investigate and realize that nothing is actually wrong. Instead the root cause is a knowledge gap; the person reporting the problem doesn’t understand enough about how the system works so assumes it’s broken. This is a common challenge that takes up a lot of time, and fortunately one that can be mitigated quite easily.
Ensure new hires get basic training
As new team members join up they have a lot on their plate. They have a new team to meet, processes to learn and a job to do. Part of their onboarding, however, should include a basic outline of how the systems they use are intended to work. This basic knowledge will help reduce the risk they report something that turns out to be nothing.
Exposing new hires to systems will also begin building a partnership with them as early as possible. This will lay the groundwork for a positive relationship as they learn about you almost immediately. Having more touch points throughout a relationship will make it easier for them to reach out for help, and for you to help them.
Document everything (well, a lot)
Documentation is your protection against future questions and problems. You certainly don’t have to document everything, but taking time to write down and share out documentation on common challenges or basic information about your systems will help prevent users from reporting non-issues. Training users to go check documentation before they come to you will also help deflect tickets and up-skill your team. Frequently when someone comes to me for help the first thing I ask (assuming it’s not an emergency) is “What documentation did you check?”. This is both a (not so) subtle reminder that they should do that, but also clues me into what they’ve already tried.
Build solid partnerships
Getting to know, and understand, your end users is always a good idea. Strong partnerships make it easier for users to approach you with challenges or questions, and ensure they know who to go to for help. When an end user doesn’t have, or doesn’t feel like they have, a strong partnerships they’re much more likely to escalate issues or not report them. This can easily be mitigated by taking the time to get to know your end users.
While a large part of systems is working on tech, it is important to remember the importance of partnerships. The strength of these partnerships will help us get through challenging situations and can be a huge help in bridging knowledge gaps.
Knowing when to go "quick and dirty"
Sometimes there isn’t time or bandwidth or energy to do everything you “should” do. Knowing when, and how, to do something quick and dirty is critical to successfully pulling it off.
We’ve all been in situations where we know the “correct” or “best” way to do something, but not had the time/money/energy to go that route. Instead, we look for something that will still get the job done, but may not be as clean…. The “quick and dirty” method.
While we generally want to avoid going quick and dirty (it is, after all, both quick… and dirty) there is an argument for it being useful. Our standards and best practices certainly exist for a reason; experience (ours or others) tells us the best way to move forward. There are, however, times when we are unable to follow best practice, or when following it would result in negative consequences. These are the times when using a quick and dirty solution can be beneficial.
Making a decision to essentially ignore best practice and go this route shouldn’t be taken lightly. You, and everyone you interact with, needs to understand the tradeoffs. Generally there’s a higher risk of error and the end product may not be as robust as it would be had you followed the proper channels. Getting buy in, or at least ensuring everyone knows what the tradeoffs are, is absolutely critical to this route. You could go it solo, however, eventually others will notice that it wasn’t quite done “right” and will start asking questions.
Generally the quick and dirty approaches also necessitate additional testing or oversight to ensure something critical wasn’t missed. This degree of oversight may not be required with the best practices route, but is here since you’re basically cutting corners (hopefully the right ones!). You’ll need to ensure you’ve got extra bandwidth or support to help minimize the risk of problems showing up.
This approach can definitely help get things done… at least if you keep a close eye on things and know what you’re doing. My best advice when choosing to go this route is to ensure everyone on the team is aware that you’re choosing it. This has a few advantages, including getting more eyes watching out for issues and helping explain any odd side effects.
The biggest takeaway is to ensure you’re making the “quick and dirty” decision for the right reasons and that everyone is aware of your choice. Ideally you’ll never need to use it, but if you do a bit of planning can help save the day.
Order Pushing
Non-technical partners need to be careful to partner with their tech teams… many times they end up just sending orders to their technical partners. This not only results in a weaker relationship, but many times results in a weaker end product.
I picked up a great bit of advice from a recruiter - “Recruiters aren’t order takers, they’re partners”. The intention behind this is you shouldn’t go to a recruiter and say “find me a lawyer” then walk away. Instead, you should sit down with your recruiter and talk with them about what you need. What problems are you trying to solve? Why are those problems, well, problems?
This discussion helps the recruiter figure out what you REALLY need… not what you *think* you need. The difference between the two can be finding a great candidate, and not finding anyone. By partnering with the recruiter, instead of just putting in an order for something, you raise your chance of actually solving that challenge.
The same paradigm exists with technical teams (and I would imagine with ANY relationship). Many times we’re just told to install some system or make some modification by a partner team. The thinking is that the technical partner is there to take care of the technical stuff… which is obviously to install that new system. This approach, however, drives us nuts.
Instead of just telling, or even politely asking, your technical partner for XYZ solution, it’s a much better idea to start a discussion with them. Let them know more about what pain you’re experiencing, what solutions you’ve identified, and then ask what the best path forward is. At the very least this will build your relationship with your technical partner; they’ll see you more as an active partner in the relationship and less of a burden. At best, this will enable your technical partners to find better solutions… in many cases solutions you didn’t even knew existed.
Changing from order pushing to partnering can be challenging, but, like many things, it gets easier with practice. The next time you have something you need from your technical partner, schedule a quick meeting with them. Let them know you’ve got a challenge you need their help on and provide some background before the meeting. This will likely intrigue them, especially if they’re used to being order takers, and give them a chance to understand what you need.
Instead of approaching the meeting in a “Here’s what I need” mindset, approach it in a “I need your help on X” mindset. This will shift your perspective a bit, but more importantly it will show your technical partners you’re seriously about partnering. Instead of phrasing things as a definitive - “we need X solution by Y date”, phrase it as a question “So we’ve heard X solution would be a good idea, what do you think?”. This opens the door for your technical partners to provide their ideas.
Most importantly this approach will demonstrate that you value your technical partners’ experience in their area. This goes a LONG way to building a positive relationship that will pay off in the future.
Being better at technical communication
Communication is a challenging skill to learn that is only made more complex when attempting to communicate about technical topics. Making time to understand how to better technically communicate is a critical skill, especially as more and more folks end up in these fields.
I’m sure you can think of a discussion or email thread that you couldn’t really follow due to its content. Maybe it was with a software engineer describing their code, or a lawyer explaining the complexities of labor law. Regardless of the topic, parts flew over your head and you had to spend a good amount of effort going back to understand what happened. This confusion is a breakdown in communication; specifically technical communication.
Technical communication is just communication around specialized or technical topics. In addition to all the rules and guidelines around normal communication, it has the added complexity of needing to convey specialized knowledge. This is particularly challenging when the audience doesn’t share the same background concepts or ideas (such as when you’re trying to explain how your system works to someone who’s never used it). This is further compounded by the specific terms and acronyms that are used in different fields.
I see many individuals running into challenges when they either don’t know how to apply technical communication skills, they apply them at the time or in the wrong way. When this happens one, or both, parties, will miss important details of the message (at best) all the way up to damaging their relationship with that team. More frequently this results in poor communication that requires additional followup to clarify what is meant. I can think of many email threads that simply. Wouldn’t. End. because one or multiple individuals on it were not able to effectively translate their technical concepts.
In addition to needing to apply technical communication during synchronous communication - phone calls, zoom calls and the like - technical communication also needs to be applied to asynchronous communication - emails, documentation and bulletin boards. Asynchronous can be more challenging since the reader only has the text that’s in front of them and there’s no chance to clarify questions. In general the approach I take is to write my documentation so someone with NO background would be able to follow along. Assuming that my audience has no clue what I’m talking about helps me avoid assuming they’ll know background ideas and makes it a lot easier to include the right level of information.
Some other things that help with technical communication
Define acronyms immediately - The first time you use an acronym, either spell it out and put the acronym in parenthesis “Three Letter Acronym (TLA)”, or do the opposite “TLA (Three Letter Acronym)”. This gives the reader a good reference.
Identify and define specialized terms - Depending on the format this could take the form of a glossary, an appendix or just some lines at the top of an email. For example “Active Directory is a system we use to manage access and data about our users”.
Include Reference Material - Depending on the audience and format I also like to include links, attachments, photos etc. to help provide more context. This could be a general systems diagram so everyone knows how the systems interconnect, a vendors documentation, or anything else to help your audience understand what you’re talking about.
Domain Expertise
Knowing the system is absolutely necessary to supporting it. Know the domain it exists in, however, vastly improves our ability to manipulate and design the best way to use that system. Take time to learn that domain, meet the experts in it and if you can, become one.
In the tech world we tend to focus on learning the tech. Those of us working on any given system or tool want to drill into how it operates, what features it has and when they should be used. This is true for NetSuite, or AWS, or InfoSec. And there’s nothing wrong with making technical skills a focus of our job; after all we ARE the systems folks!
Learning technical skills, however, shouldn’t (can’t!) be all we focus on. We also need to stretch ourselves to understand the domain our systems exists in. For SalesForce this would involve learning how sales teams operate. What does any given Sales rep need to do or know on a monthly/week/daily/hourly basis? Why do they (dis)like any particular aspect of SalesForce? What policies does the Sales team have to follow?
While certainly not directly related to the system, questions like this help inform WHY and HOW the system can be used. We don’t need to know as much as our customers about their process, but the more we know, the better we’ll be able to support them (personally I became a license health care broker to help accomplish this).
Gaining Domain Experience
There’s many ways to help expand our domain expertise. The simplest is simply through osmosis. As we work on any given system, we’ll naturally learn a bit about the domain it exists in. Working in NetSuite, for example, will expose us to charts of accounts. SalesForce will expose us to a closing process. Workday will expose us to hiring. This is a natural first step for many folks since it’s basically impossible to miss; you can’t learn the system without picking up SOMETHING. That said, this is only the beginning.
Getting to know your customers is another way to improve your domain knowledge. Get them involved in testing, or have them show you how they use any particular screen. Sit in on their team meetings and get a feel for how the team behaves. This first-hand experience has several advantages, including giving you more domain expertise, but also helps build connections and puts a face to everyone. Knowing Jimmy in sales is much more impactful than knowing some random user has problems.
Training like your customer-base takes this a step further. Go and get whatever certification or accreditation they need (like my example of becoming a certified benefits broker). This will not only extend your baseline knowledge of that particular area, it will help you see things the way they do. In the care of a credential or training you’re also rounding out your own experience and possible exposing you to new concepts. This has the added benefit of (generally) getting you some street-cred with your customers.
Going even deeper you could even BECOME your customer. I very rarely see folks taking this path since it is very intense and time consuming… but it does offer the most in-depth way to gain experience. For example a software engineer might choose to implement a live customer, or a Salesforce rep may take some inbound calls. While this does crank up the intensity a bit, it will really help show you what’s important, or annoying, or impactful for your customer base.
While there’s nothing wrong with not taking these steps, I find they help individuals make better informed decisions and allows them to develop better solutions to challenges. Flexing ourselves this way also has the side-effect of helping us build better relationships, and learn something new about our tool.
On Negative Examples
Finding examples of things you want to mimic is great… but looking for examples of things you’d like to avoid (good and bad) is also important.
To preface this piece - negative examples are about finding attributes, outcomes, etc. that you choose to avoid, not necessarily things that have failed.
Frequently we look around a good example of what we want to do. We find some project, or team, or event that was insanely successful and point at it as a model to follow. This is a great approach since we can learn from that things success, and then build on it. It is, however, also important to find negative examples - things that didn’t go the way you want, or things you don’t want to do - to learn from. These both teach you what can go wrong, but also help provide a better definition to the shape of what you want.
Filling in the edges
Just like how negative space in artwork can define interesting shapes (or even the artwork itself), negative examples at work help us define our outcome. They allow us to look at another project/outcome/team/whatever and make more informed decisions on how we want to operate. As noted above, this doesn’t necessarily mean those projects/outcomes/teams are not effective or working properly… just that you choose a different route. Some examples:
Methodologies - Agile project management makes a lot of sense…. In certain circumstances. Many projects, however, will not benefit to the same degree, and some may even suffer. Watching another project struggle with the wrong methodology can serve as an example for your work, and what to avoid.
Team structure - How teams are setup differs widely, both between and within organizations. Looking at other orgs will help you determine the shape of yours. Maybe the People team has a great structure that’s super successful for them, but for some reason wouldn’t work in Engineering. Noting that difference, and being able to point out why it wouldn’t be good for your team, will help avoid
Documentation - While there are some more standardized ways to document material, at some point it comes down to specifically how a team operates, and choices they make in cataloging information. Understanding why another group’s decisions wouldn’t be the best for your needs will help you better shape what would be best for you.
When finding negative examples it is important to keep any judgement of good/bad or any blame out of your assessment. The intention is to help identify what the best solution for your particular need, not to pass judgement on how someone else operates (which may be best for them).
Data Analysts - Know Thy System
Understanding both how a system creates/stores data and how it is used is critical to being a good data analyst. Knowing these things makes it easier to interpret information and to tell a good story about any potential results. Failing to Know Thy System at best results in wasted in… and catastrophic decisions at worst.
“Know Thyself” is certainly an important concept to being a human. “Know Thy System” is an equally important concept to being a data analyst.
In addition to knowing data analytics concepts (not making misleading graphics, for example), a good data analyst also understands how data moves through the system(s) they analyze. This knowledge goes beyond basics and extends into how specific metrics are collected, how users behave and how data is stored. This background knowledge not only makes it easier for them to find the numbers they need, it allows them to draw better conclusions on that data.
Some examples I’ve run into include:
Knowing when tickets are assigned - Many reports on ticketing systems relate to who’s been working on tickets. Knowing when/how users are assigned tickets will impact the report. For example, if someone triages a ticket THEN assigns it, we can expect tickets to remain unassigned throughout the triage process.
When data is added to something - Some data fields are populated when a record is created (Employee ID, for example). Other data, however, may remain defaulted or even null. These defaulted values will appear in reporting, and may throw off results.
Where data comes from - End-user reports sometimes contain data from multiple sources/systems/etc. While this makes for easier story telling it can make troubleshooting or updating things more complicated. Being aware of how your reporting system pulls information reduces time to update things and makes it easier to explain how things were determined.
The problem with NOT knowing thy system
Understanding the UI and the users perspective isn’t enough to really know how the system operates. Many systems, for example, combine multiple metrics when displaying values such as Service Level Agreements (SLA), total compensation and others. Looking at the back end database tables can be incredibly confusing if you don’t realize that “SLA” really feeds 5 different dimensions.
As data analysts it is our job to know about these concepts. Failing to understand them will, at best, result in a LOT of wasted time as we dig through tables or configuration settings, and at worst, result in bad decisions being made about the data. Something as simple as not realizing your underlying data doesn’t include any data from January can be catastrophic; your customers will make business decisions on the lack of results from January… which aren’t real.
Helping others to Know Thy System
I’ve run into MANY situations where someone doesn’t have any background on the underlying systems and tries to make determinations on something. At best, this results in confusion as folks come to you, the Data Analyst with more questions. At worst, this results in conclusions being drawn from information that folks don’t truly understand.
In many cases we cannot expect our customers (folks reading our reports) to fully understand all the underlying concepts. This isn’t to say there shouldn’t be SOME expectation that they understand things, just that we cannot expect them to know anything close to what we do. To help bridge that gap, I’ve been following a few guidelines:
Always put comments in reports - Many reporting systems have a comment or text field. I’ve started always putting notes in there that relate to that specific report. These include a brief description of what the report is intended to show, and any call outs to specifics that may not be 100% obvious (e.g. a specific field showing a null/none until a specific time period, etc).
Proper Naming - Definitely another easy win - just name things more accurately. I try to keep a specific convention that briefly describes the report. This both makes it easier for me to organize, but also helps my customers find the right report more quickly.
Basic Documentation - In addition to cranking out reports and dashboards, I’ve found providing basic documentation on where data comes from is incredibly helpful. This doesn’t have to be (nor should it be!) a full data dictionary. This wouldn’t only drown your customer in too much info. Rather it’s a quick guide on what common metrics mean and how they’re pulled. Think of this as proactive defense against common questions.
Case Study - Learning a New System
Learning a new system, especially under time pressure, takes a LOT of energy. Just remember to get hands on, make some friends, and do your homework, and you’ll be fine!
One of my first jobs had me in the role of a project management module expert for a new system we were installing. This was a big step for me since it got me out of being an IT Helpdesk Tech and into business systems analysis (something I find a lot more interesting). This project would impact how 2,000+ people did their jobs across 6 locations, but the challenge I had was that I didn’t know much about project management, or this new system….
The Setup
This turned out to be a great opportunity to learn both by experience and by training. Since we were already using a version of this system we had environments available for me to play in, and, even better, we had other folks on my team who were familiar with the system and underlying concepts. Having both of these isn’t always the case, so I got lucky (sometimes system implementations involve a team entirely new to the system, which makes for one rather steep learning curve) . It was still a lot of work to make time in the system and to get to know everyone, but it really helped improve my learning curve.
First Things First
The first thing I did was get access to a sandbox version of the new system so I could play around. This helped me build up the basics, e.g. where buttons were, what they did, what our current setup looked like. The other thing I did was get my hands on the manual (a digital copy anyways). This helped inform my wanderings by giving me some underlying context into what those buttons were intended for, as well as background on the architecture and setup of the system.
Manuals can be a great resource, but many systems are incredibly complex, resulting in incredibly large manuals. My recommendation here would be to focus on specific areas to investigate (e.g. whatever area you’re responsible for) to build up familiarity with them. Sometimes it is fun to randomly explore, but I find this can lead to areas that you may never use, or end up being more confusing than useful.
In short, hands on gave me the “how do I do X”, while the manual gave me the “what this does and how to do it”. The last piece, the “why are we doing this?” came later.
Baby Steps
Going from zero experience in the system to something more than zero was a bit painful. Not only did I not know what it COULD do, I didn’t even have the basics. So I put in time (to use a gaming term, I did a lot of grinding). I tried adding simple things over and over. I read the same page of the manual multiple times and then tried doing those things to see if it really did that (a great way to check your own documentation!). Eventually I got to a point where I felt like I could open the system without hurting myself, which was good. At this stage, however, I was almost effectively useless to the team. Sure, I knew there were some buttons, and what some screens looked like, but I couldn’t translate that into helping the business solve anything.
This was by far the most challenging aspect of it all. Why did finance care how the GL is setup? Was it important that we used a specific numerical sequence for project numbers? Which data field was used to identify the project owner? The questions were endless, and each time I found one answer, more questions popped up.
Not only was I very new with the system, I was almost entirely new with the business and with project management as well. I needed help.
Help!
Luckily for me, my project team contained a representative from most areas of the business (Accounting, Accounts Receivable, Project Management, Purchasing, etc). This made it fairly easy to find someone to help me understand the basics, and even better, they were on the same project, which made it incredibly easy to connect and get some of their time. In addition to getting formal background on what everyone did (I have zero background with Finance, for example), I also got to see how they were planning on using the system. This helped me better understand how my area would interact with theirs (e.g. if a purchase order is placed on a project how does that impact inventory? What about the general ledger? Hours worked?). These learnings helped me further round out my understanding of the system, and more importantly, the “why” behind how it operates.
I also got help from other employees who happened to use the system. This was another bit of luck as not every implementation I work on has this setup (although you can generally get help from the system vendor). These folks were able to provide me more background on historic use, which is honestly a bit of a double edged sword. Implementing (or re-implementing) a system is intended to improve operations, not simply continue with the status quo. Understanding how something works is critical to improving it, however, you must be careful to not simply copy/paste that into the next iteration.
Connecting with other technical folks helped as well. For example, I originally believed reporting was a built-in module of our system. After a lot of (poor) guess work, I found out it was mainly handled using MS SQL. Data was loaded into our data warehouse by (what I eventually learned) were CRON jobs, after which it could be used by our data analysts. Being able to sit down and talk with our data engineer and analysts made this process both much shorter and more enjoyable.
Leveling Up
Having hands-on access to the system, formalized training (in the form of the manual) and access to experts on the underlying process was immensely helpful. While each area was incredibly informative on their own, when combined they played off each other giving me more depth of insight than otherwise possible. For example, understanding that the project number for any given project was added to the general ledger code string shed a lot of light on why Finance was involved in the structure of project numbers (don’t worry if that doesn’t really make sense out of context!).
On the more technical side this combination of knowledge helped explain why our project managers were so adamant about knowing when data was available in their reports. If, for example, we loaded data from the system to our data warehouse at 1am that morning, their reports that day would be a day old. Once I explained this to them they got much less concerned when the number in their report didn’t match the live number in the system.
Learning a New System - Lessons Learned
Despite the specifics being unique to the situation, there are a number of lessons that can be pulled out of this experience and generalized to others. Indeed, I’ve repeated this general pattern many times so far (hands on, make friends, do your homework) since then.
Get hands on - learn by doing. Any time you have the opportunity to get hands-on with the thing you’re expected to learn, take it. It doesn’t matter if it’s a new programming language, new vehicle or new system, the more time you have poking around and seeing what is where the better.
Make friends - know your end users. Get time (face to face if possible) with folks who already use the system, or who understand the underlying concepts that will impact it. These folks will, at the very least, give you pointers on what to look into next. At best, they’ll be able to walk you through specific scenarios and help answer your questions.
Do your homework - understand the business applications. Underlying concepts or ideas are incredibly important to how systems, programs, processes etc. operate. Take time to read up on your field to get a better grasp of these. While they may be very abstract or seem unimportant they almost always will have an impact on what you do.
Defects - What to do with them
While collecting defects is a great first step, there’s a lot more that can be done, including retroactive investigations and proactive avoidance.
Having determined our goal of zero defects, and determined what a defect is, the $10,000 question is what do you do with them. After all, it’s one thing to identify what a problem is, it’s entirely another thing to solve for it.
The easiest approach
Every company will accumulate defects as time goes on (or at least I hope they do… if you know someone who’s proactively solved every possible problem please let me know!). The type and quantity will differ, and may change over time, but at the end of the day there’s always a pile of things that need solving. The important thing is what is done with those defects.
The simplest approach is to collect them, which at its most minimal approach tends to be some kind of shared email inbox. This is a very common approach for smaller groups, or groups bootstrapping the process with no previous experience or resources. After all, it’s really easy to spin up a new email inbox and share out the alias with everyone.
This approach, however, gets out of hand incredibly quickly. The inbox will either get flooded by all the incoming requests, or trying to keep track of everything becomes incredibly complicated and convoluted. Having more than one agent (someone who responds to the emails) makes this even more challenging to keep track of (imagine 10 people monitoring a single inbox that gets 100’s of emails per day… how do you control who gets which email? How about metrics tracking? Followups?).
The next step
Another more advanced, but still very common approach is to collect these requests in some form of a ticketing system. Having a ticketing system adds some level of complexity to the process (it needs to be setup, administered, paid for, etc.), but this complexity provides a better foundation to provide support to customers. Equally importantly it provides a framework to draw data and insights from (e.g. when tickets were created, who made them, what they’re about, etc). These data dimensions make the more advanced work much easier.
Requests can come into the system directly, or be piped in from an email alias, but regardless of entry point those requests are monitored by a support team. This team is (hopefully) focused entirely on answering those requests. While it is possible to have part-time teams, breaking their focus onto other responsibilities will reduce both the number of requests responded to, and the quality of those responses. You are also preventing yourself from learning more about patterns in your requests since any given agent won’t have complete exposure to everything. It is also incredibly important to support these agents with whatever training or knowledge base information is necessary to handle the majority of those challenges. This is an ongoing goal, but something that must be started sooner rather than later.
A shared inbox or ticketing system is a necessary step, but it doesn’t do much, if anything, to prevent the defects from occurring in the first place (our actual goal). While the challenges/pain the defects cause must be addressed, simply collecting them doesn’t help stop the next defect from occurring.
Reactive analysis
To actually help reduce the number of defects, someone (or a team of someones) is needed to and analyze the incoming defects. Their goal is to better understand the defects that come in, and look for ways to help plug the leaks. What this team can learn from the defects is largely dependent on the quality of the incoming defects. This is partially reliant on the collection method (e.g. email vs. a sophisticated ticketing solution), but is also impacted by the teams ability to understand what the defects are and routing them appropriately.
By critically examining known defects, this team can then make recommendations to the business on how to prevent future defects. These recommendations may be the result of identifying patterns in defects (e.g. every tuesday we get a lot of tickets about entering time), or observations about improvements (e.g. update a button placement so users see it more easily). Since every business and group is different, the recommendations will vary, but the end goal is to provide guidance on how to stop the defects from recurring. This team should be formally and informally connected to the business units they advise.
Proactive avoidance
Reactively examining defects can provide guidance for changes to stop future defects, it would be much better to prevent those defects from ever occurring. To me, this goes beyond standard QA since some things cannot be easily QAed (for instance an onboarding program or policy). This is where proactive assessments come in. Think of these as pen-tests for other areas of the business; a complex examination of existing systems or processes that attempts to uncover faults before your customers (or fellow employees) find them for you.
This is further complicated since the business is constantly changing. It requires the totality of the process being examined any time a change is made to a process, a new policy is rolled out, or a new patch is released. This is no small ask, and requires a team that is equipped to go in and try to break everything in any way they can imagine. Say a payroll system is updated to provide more employee self-service (a recommendation from your defect analysis team). Your proactive team would need to think through a number of things, including:
What readily available documentation is available to employees?
Can it be easily found?
Are managers aware of the change?
What formal communications are going out to employees to let them know?
What information is made available during onboarding and retraining?
What other information sources should be updated (bulletin boards, etc)?
What downstream systems might be impacted? (change management)
The specific questions would differ depending on the changes and environment. This team may also opt to only focus on specific areas (e.g. payroll related items) to provide a more focused impact in higher-risk areas.
At the end of it all, it’s not a question of will there be defects, just when they will occur and where. While handling defects after they occur is necessary, groups need to better understand the weaknesses of their current processes and proactively plug them up. While it does take energy and time, it results in significantly happier customers.
Zero Defects - What is it?
Despite our best efforts every process or system produces some unwanted or unexpected behavior - defects. Many times our customers are the ones letting us know about them, which is less than good.
Somewhere along the line I picked up the idea that any problem (a ticket in my world) represents a failure somewhere in the overall process. This isn’t intended to point blame, or make us think like we’re failing horrifically when we gaze upon or vast collection of tickets, but rather to help us frame every one as an opportunity to improve. This failure could be in training employees, training managers, a technical glitch, or how an interaction with HR is handled. Regardless of WHY it occurred, it is still a defect that needs to be examined, understood, and never repeated.
What is a defect?
In general, however, a defect is any adverse or unintended behavior in a system or process. This may be further refined based on who you’re talking to and/or what industry your in. For example it could be the QA team finding a flaw before the production run in completed, or could be a piece of code that generates an incorrect result. “Zero defect” also implies that the defect is reported, that someone out there in the “wild” (not your team or testing) has found the flaw and is bringing it to your attention. This could be represented by a help desk ticket (common), and email (also common), a sticky note on your desk (less common) or a brick through your window with a note tied to it (hopefully least common). Regardless of how the message is sent, you are now in possession of a bright, shiny new defect.
In my world a defect is anything that results in the customer (fellow employees) having to reach out to a support team for help (this includes the HR, tech and IT teams). This outreach could be a complaint about someone’s behavior, confusion over a policy, or help finding a payslip. Note that this does not include any time someone has figured out something on their own (e.g. restarting their computer fixed the problem), or being able to look it up somewhere (e.g. HR policy information). The focus is on the group of individuals who have some problem and then have to reach out to one of our support teams for help. This makes things a bit challenging to totally control since it’s entirely possible an employee reaches out to a co-worker, manager, etc. and gets an answer without needing to reach out to support. Personally I’m not sure if this is truly a defect since they were able to figure it out without reaching out, but it’s a bit of a grey area for me. Regardless, there’s no easy way to measure those, so I stick with whatever happens to get into our ticketing system.
Rating Defects
Ideally 100% of defects are examined, understood, and never happen again. Unfortunately we don’t live in this version of reality, so some yardstick is needed to understand and rank them. It’s important for the teams that look at defects to sit down and determine what dimensions they want to use to sort these (such as impact to the bottom line, type of system impacted etc.) and then to share those definitions with stakeholders to help improve trust and transparency. When in doubt I tend to start with two simple dimensions, complexity and urgency since they are relatively easy to understand and allow for quick sorting of defects.
Defects range from the simple (where do I find my payslip) to insanely complex or in-depth (employees in a specific area cannot not log into to one part of a certain system) An important note that “simple” does not mean it isn’t important to whomever raises it. “Simple” instead refers to the likely response/solution (e.g. “Click this link to access our payroll system”). Defects are never “simple” from the “Well, your thing doesn’t really matter” perspective (especially when related to HR issues), and always have a real-world consequence to someone. This is part of an overall tech mindset that’s a bit beyond this post, but definitely something I’ll dig into later.
In addition to falling somewhere on a complexity scale, they also fall into an urgency scale. This scale can range from “I need my medical insurance confirmed so I can get my cancer drugs” to “Just wondering what our policy on XYZ is” for HR matters to “Our payment processing system is offline and we’re losing millions every minute” to “the icon on some little-used internal page is broken”. Similarly to how “simple” doesn’t mean it’s not important to the reporter, the seemingly non-urgent items are still important. The icon on that site is the Priority Zero for someone and should not be dismissed simply because it’s “not urgent to me”.
Having these dimensions on defects help make it easier to prioritize both how they are resolved and how they are investigated. An ultra-critical, ultra-complex item will likely be immediately addressed, but an in depth investigation will take time, while a low-criticality, highly complex item will likely wait to be addressed. Exactly what dimensions are used to sort tickets can be up to any given team, but SOME yardstick should be used to help the followup work on determining how to avoid the defect in the future. All that said, regardless of the metrics being used, it is still a defect, which represents a failure.
Next up are responses to defects, something I’ll take a look at a bit down the line.
On Entering Tickets
We’ve all had to put a ticket into something SOMEWHERE. Despite our collective practice, many tickets do not provide enough info for folks to get the help they need. Here are some tips.
Ticketing systems are everywhere, airlines, apartments, work. Everyone's reached out to one (sometimes not knowing it's a ticketing system!) at some time before, but despite the ubiquity of them many of us aren't the best at putting in good tickets.
Good tickets contain enough info for the person at the other end to understand what the problem is and determine a course of action. These tickets tend to include things like screenshots, error codes and descriptions of what was going on at the time. They not only provide the WHAT, but also the HOW and the WHY behind the ticket.
The bad
Before we look at what makes a good ticket, we need to understand what makes a less than good ticket. Consider the following (let's also assume the ticketing system knows who you are, what time it is, etc):
“Help! I can’t log into system ABC.”
This does tell us some information, that you cannot log into ABC, but the information provided is very limited. If I'm a very good tech I would first check to see if you have access to ABC, or if you're even supposed to be able to (its surprising how many times people try to log into systems they shouldn’t!). More likely, a tech will look at this, roll their eyes, and respond with something like:
“Ok, tell me what happens when you try to log in.”
While this response is typical, it doesn’t do much to get more information from the customer, and it doesn’t help establish positive rapport (not the scope of this discussion, but also very important!). Ideally the tech should do something more like :
“I understand you’re having trouble with ABC. I see you do have an active account in ABC. Could you please got to this link, try to log in with you username and password and send me a screenshot of your entire screen with what happens?”
I won't get too deep into how to properly answer tickets (a fascinating topic worthy of it's own discussion!), but this approach provides clear next steps for the customer. It also clarifies some assumptions, such as the user knowing where or how to log in, or them forgetting their credentials.
A Good Ticket
Short of just getting “Help!” (which does happen!) the example above is basically a worst case. A good ticket is one step up by providing more specifics, such as an error or screenshots. Thankfully more often than not customers fall into this bucket, mostly due to previous experience and/or training. It looks something like:
“When I try to log into ABC I get a ‘account not found’ error, help.”
This clearly states the problem, and provides some technical info to look into. It's better than the bad example since we get that error message, but even here more info would be really useful. For example a link to where they logged in, or telling us it worked yesterday.
Really Good Ticket
Rarely, oh so rarely, I see an exemplar. A ticket worthy of being printed off, framed, and hung on the wall as a shining beacon to direct people to. Something like :
“I tried logging into ABC at this link, but got a ‘account not found’ error (see attached). I could log in with my username last week, and don’t think anything’s changed. I need to get in to pay everyone. Help.”
This one gives us everything:
What - they can't get in, and am error plus screenshot
How - at a specific website, with info on it working before
Why - a business reason which helps determine priority
This information removes a lot of the guesswork for the tech. They should still double check, but now they know what to look for, and when to look (sometime in the past week). It’s also possible this info will trigger an immediate answer (e.g. system maintenance is ongoing and locking folks out), or otherwise clue-in the technician to something that may be impacting them.
While I concede our users won't do this all the time, we need to set the expectation on them to give us good tickets. Folks should be regularly reminded how to put in tickets, and that putting them in properly is beneficial for everyone. Not only does it make our techs lives easier, it decreases back and forth, shortens response time and makes everyone happier.
Afterthought of an afterthought
HRIS tends to be the forgotten cousin of IT - it’s frequently brought in at the last minute (if at all). Building better partnerships with HRIS helps both sides, as the business gets better results, and the tech team gets less grey hair.
Very frequently businesses need to make decisions about the business. These may be big or small decisions, but they all have one thing in common - tech/systems partners should be included in them sooner rather than later. This is doubly so for HR Information Systems (HRIS) since many highly sensitive things (like payroll) will be impacted, and very frequently the complexity of those systems isn’t fully appreciated by the business.
Oh, right.. we need that.
I frequently joke that IT is an afterthought. After all, no one starts a company to fix their own computers. Eventually, though, someone realizes that yes, you do need someone to manage your IT resources. Once this happens, things tend to get better for IT. The business fully (or at least mostly) realizes the need for IT resources, but this generally doesn’t flow over to HR. This results in HRIT becoming an afterthought of an afterthought - after all, we have HR Generalists / Coordinators / Business Partners to handle running HR, why do they need systems experts?
This is also compounded as HRIT and IT are only cost centers (would love to hear if anyone’s found a way to change that!). Since we don’t obviously increase profits it’s harder to justify why they exist. It’s also hard in some cases to prove their actions save money (how many dollars does a good knowledge base page save?). While it is possible to break down ticket cost etc. that also takes time and money, resulting in a nasty spiral of not wanting to do the work to prove it’s worthwhile since you don’t know it’s worthwhile.
Being a double afterthought results in problems ranging from processes being done manually that can/should be automated (manually emailing new hires vs. automating with free add-ons), to catastrophic problems resulting from the lack of understanding / planning (for example paying groups of terminated employees well after they’re gone). In my experience these problems are brought to the HRIS teams attention… but only AFTER the impact has been felt by the company.
The problem is this is the same as ignoring leaky pipes in a submarine, eventually the “savings” of not pumping up HRIS will result in a massive problem.
Leaky Pipes
Since HRIS is usually the last player to the party (or at least the last invited), we tend to only get looped in at the last possible second (“We need this live tomorrow” is a common request…). What kills me about this is many times I hear that planning for that initiative had been in the works for weeks, of not months, before hand. I very frequently find myself wondering how we can have so many smart and talented folks around, but constantly fail to include critical elements early enough in the process.
Some common things I hear about why HRIS isn’t included earlier, my thoughts, and possible solutions:
This project is highly confidential/legal/sensitive, so we have to limit the people involved
One of my favorite reasons (especially the confidential part). I completely understand the need to keep information contained, but every company I’ve ever worked with has had me sign some type of NDA. In addition, HRIS teams tend to deal with highly sensitive information as a matter of course (SSN, pay scales, home addresses, etc). It is expected that we are good data stewards, so your list of terminations is just like any other spreadsheet to us.
Solution - One of the simplest things to do is select one individual from the HRIS team (e.g. the manager) to get advanced warning that things are coming down the pike. They don’t have to get specific details, but a general outline of what is required is enough so they can think through possible fixes. Ideally this person understands both the system and the business ask well enough to make it generic so the team can plan.
We didn’t realize the impact on our systems
Any time I hear this one I scratch my head. I find it hard to believe that no one on the project team realized your plan to change compensation for 1,000 people wouldn’t, in some way, impact HRIS.
Solution - Involve your HRIS or IT teams in EVERY major change you consider. You wouldn’t leave Finance out of a discussion where you didn’t know with 100% certainty they’d be needed. At the very least include them in the “I” of your RACI charts (or whichever flavor your company prefers). This way your HRIT teams will at least be aware of whats going on and will speak up as needed.
We spoke to so-and-so and they didn’t think we needed to do anything
This generally results from someone on the project team (or their managers) making assumptions about how HRIS operates (similar to “This other place I worked at did it this way…”). The outcome tends to be dramatically skewed expectations from the project team that, at best, will alienate your HRIS teams (e.g. a change should . “only take two hours” but instead takes 4 days and 2 employees to fix).
Solution - This is all about proactive partnerships. Special project teams should regularly meet with HRIS teams to understand basics of the systems such as estimations on standard requests, downstream impacts, etc. Not only will this help alleviate #1 and #2, it will foster better collaboration and build trust.
Plugging the leaks
The best way to get over being an after thought is to build proactive relationships with HRIT and partner teams. This can take the form of a monthly lunch and learn where systems basics are shared, or specific meetings to go over features, or formalized partnerships where team members regularly sit down and go over challenges. At the very least this will help give partner teams a better understanding of just how complex the plumbing is.
I tend to prefer in-person sessions where I walk through specific processes, or demonstrate how specific features work. While I tend to have a plan in mind when we begin, the discussion frequently veers off into different areas based on comments or questions from my partners. Personally this is some of the most interesting discussions to be had about systems. Getting a systems expert and a business expert in the same room is bound to come up with some good topics.
To help avoid last-minute “gotchas” related to HRIS, we all need to remember that every aspect of what we do is complex; often more so than we think. Taking time to help the business understand our complexities, and appreciate the effort required to make “simple” changes, more than pays off. It not only helps strengthen relationships, but will pay dividends in future projects as partners are better equipped to help address challenges before they come up; hopefully bringing HRIS out from the shadows of being an afterthought.
"This other place I worked at did it this way…" ~ Some Executive
Tech teams need to be brought problems to solve, not solutions to implement. Frequently business partners only present their ideas for solutions, which, at best, will steal time from actual problem solving, and at worst cause problems down the road.
This is one of the phrases I dread hearing the most, mainly because it usually ends in “... so I’ve already told everyone we can do it this way” (or something scarily similar). This phrase definitely falls into the bucket of “partners telling us solutions” (which has it own dangers), however, for me this one is a little bit more insidious…
A Game of Telephone
Generally I don’t hear this phrase first hand. Instead, I’m (un)fortunate enough to hear it second, third or fourth hand. It tends to originate from someone higher-up in the org chart, generally a VP, Senior Director or the like. It also tends to originate from a place with good intentions. After all, this person and their team is faced with a big challenge, so why not use something they KNOW has worked before?
How it plays out (in Robs super-oversimplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, I’ll tell Rob to do it that way too”
Why it’s scary
This is scary since where ever we are now, we ARE NOT at the same place this worked for them in the past. We’ve also entirely skipped the part where we identify the problem. Even if the business is identical and we make the same product/service, the way our systems are setup will differ in some fashion. Generally we’re not in the exact same industry, making the differences even greater. Further, the individual who puts this idea forward likely does not understand the specifics of what was done, only the end product (it’s seldom a Director or higher I meet who truely cares to learn the technical specifics). So even if the solution worked exactly as remembered, they do not fully understand the pretzels their tech teams had to wrap themselves into in order to deliver.
How it should play out (in Robs super over-simplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, let me tell our Tech Experts about Way X, but we’ll also go over the problem and explore other solutions”
Getting from scary to supportive
Technical teams (whether it be IT, legal, communications, etc) are the experts in solving problems, so we get very concerned when instead we’re fed solutions. The best way to improve this relationship is, well, to improve the relationship. I personally spend a great deal of time working with my partner teams and sharing the basic concepts / patterns/ processes that my team uses. This helps demystify tech (that said a lot of it is still magic to me) for my partners, and, more importantly, helps build trust. This is needed for those times I have to tell them that what their VP said may have worked somewhere else, but it may not work here.
In the end it all boils down to the strength of relationships with partner teams. These scary phrases will continue to come up, but, they should become less and less scary as time goes on and more and more folks know to trust their tech.
On bringing solutions
I always appreciate when my partners think through challenges before coming to my team. It does get a bit dicey when they bring us solutions they think will be best…
One of the most common challenges I’ve run into is having a partner come to me with a solution to a problem they’ve run into. This might take the form of “Have Workday do XYZ”, or “Build me this type of report”, or “Use this tool to do X”. Part of me really appreciates my partners taking the time to figure out what they want to happen… but a much larger part of me has a blood pressure spike and a few more grey hairs pop up.
Why the grey hair?
I really do appreciate my partners taking a stab at figuring out what’s going on. I get the grey hair for a few reasons:
Generally partners don’t have the full picture - Partners usually are only aware of the aspects of systems they interact with (which is all we can expect or ask of them!). This means they frequently are unaware of other solutions, or of interactions with other systems.
Partners are usually not technical experts - Nor should they be! I frequently tell mine I’m not an HR expert and I’m glad they’re around to do that. That acknowledgment also means I don’t go tell them how to fix HR challenges though.
Their focus is only on their stuff - One of my favorite phrases is “This is my P0 (priority 0)”.(more on that in another post!). Everyone (me included!) has a personal list of what’s important, and nothing else comes close. This makes things problematic as partners get tunnel vision on just their own items.
When a partner brings me a solution they’re generally already stuck on one (or more!) of those items. This means I have to take time to talk them down (all that de-escalation training at the help desk REALLY comes in handy!) and explain why their solution may not be the best idea.
Why it’s challenging
While I find it great that my partners put thought into a solution before they come to me or my team, it tends to set us up for failure in a few ways:
They put energy into it - Once someone puts time/energy into something it’s MUCH harder to change their mind
They’re “stuck” on their idea - Everyone likes their own ideas, and it gets particularly challenging to try to change their thinking.
The clocks (usually) ticking - Since my partner’s already taken time to come up with an idea we now have less time to build one together. This can be particularly troublesome with highly sensitive asks.
These generally occur in some combination, which makes the initial talk mostly focused on talking my partner down or trying to find ways to reshape their thinking.
Just come back off the ledge…
This is where I find connections with my partners to be particularly important. When I first work with someone I don’t have any credibility (other than being the “IT” guy), so I have to build it on the fly. Once I have an established work relationship that process is a LOT quicker, allowing us to get to the source of the problem much more quickly.
I use a number of tools/tricks to help with this, but some of my favorite:
What are you trying to solve with this? - This question helps my partner focus on the problem and gives me an “in” to have them demonstrate it. This makes it easier to change their thinking about a solution.
Why do you want to do this? - Similar to the above it makes my partner explain how they got to their solution, which helps me figure out WHY they (think they) want it.
Who else have you spoke to about this? - This is a great question to help determine where their solution idea came from. This can then help me figure out how they came up with their idea.
Getting to a good endpoint
Usually this boils down to spending an hour with my partner to go backwards through their solution. This can be a painful process, but helps us uncover why they wanted that particular thing and, more importantly, better understand the underlying problem. There are some times when their solution ends up being the one we go with, but many times we land on a different approach (usually based on information my partner didn’t have, e.g. how a system operates).
The most important aspect of this approach is the time spent with my partner. This helps build a positive relationship with them, which will only help me out in the future. As the relationship progresses both my partners and I get better and presenting challenges, and developing solutions.
"Generic" and "Specific" Basics
I’ve found there’s two types of basic skills - generic and specific. Understanding which one needs to be addressed helps folks better address underlying problems.
One of the great things about life these days is technology. It (mostly) makes are lives easier, especially when it comes to work. I cannot imagine having to keep track of employee data on paper, having to run payroll by hand, or generating reports manually.
The downside of tech is that it requires at least a baseline understanding of how it works in order to get any benefit. These basics may be more “generic” (applied across multiple systems or scenarios), for example knowing the magnifying glass allows you to search, to a more “specific” basic, such as knowing how your underlying data is sourced.
“Generic” Basics
“Generic” basics are things that can be applied across multiple systems or areas. Save icons fall into this bucket since they’re almost always a floppy disk (something that dates back as far as I can remember!), which is especially amusing since physical media of almost any type is quickly disappearing. The search icon is another example that appears almost everywhere.
Despite the prevalence of these items, unless you understand what they mean you’re in for a very frustrating time. I once watching a steelworker manually scrolling through a list of 5,000 files despite the search icon being displayed at the top of his screen. I stopped him after a few minutes and showed him what the magnifying glass did, the told him to call me if he ever looked around for files again (I’ve always wondered how much time is spent globally manually looking for things….).
Digital natives have a massive leg up with the generic basics since they grow up with it all (I’ve heard apocryphal stories of young children getting upset that the TV isn’t a touch screen). Since their training begins so young they’re able to easily translate those basics to work.
“Specific” Basics
While generic basics may apply across systems, concepts or ideas, specific basics are, well, specific. Some examples I run into include:
Workdays security architecture - Knowing how this works doesn’t really help you understand other systems security
Using a video game controller - I see this one a lot at home with my family. Knowing how to use a TV remote does’t help you turn on the Xbox to watch Netflix.
Perform data analysis - How data is collected, transformed, and stored has massive impacts on your analysis, but those changes differ based on the data source.
All of those examples are only really in the sphere they’re used in. Due to this Specific basics are generally only known by individuals in those areas.
Where Problems Crop Up
Things get dicey when someone :
Doesn’t know a generic basic
Incorrectly applies a Specific basic
Does’t know a Specific basic
The first tends to result from missing training. An employee is a physical trade skill (e.g. carpentry) may not be aware of the search icon, for example. This type is relatively straightforward to correct via training, but can be incredibly frustrating to that individual. It’s always a mark of a good
The second and third are where things get dicey. Not knowing Specific basics results in looking bad (example below) to catastrophic errors (inadvertently exposing social security numbers). Frequently I see these crop up when folks begin doing data analysis or presentation. Most recently I spotted this gem in a hospital:
97% isn’t a third of something!
In this specific instance the error wasn’t too catastrophic, but I always imagine what would happen if something like that was presented to the C-Suite.
Minimizing Errors
I’ve found the best way to help avoid both Generic and Specific errors is to work on connections with folks, and try to break down the “I only go to IT when something breaks” mentality. Having a solid (or developing) relationships makes it easier both for partners to ask questions, and for you to point out possible errors.
It’s also REALLY helped me to remember we all commit errors. Everyone has forgotten to save a file, or copy a formula, or how to correctly update something. Keeping our humility, and remembering we’re all in this together, will go a long way to keeping things running smoothly.