When to use Confluence or Jira
Confluence and Jira are complimentary, but different!
Almost every company I’ve worked at has provided access to both Confluence and Jira. These two tools offer a ton of functionality and features that can help make our lives easier, but many times I find myself asking myself “which one should I use?”.
On the surface this should be an easy question - after all Confluence is a knowledge base and Jira is for ticketing. This distinction, however, can easily break down - Confluence supports task tracking and can be used to manage work, and Jira can easily be used to house information about things in the form of task descriptions, fields and more.
So let’s take a deeper look at these two systems, their differences, and why we may choose one of the other in some cases.
Confluence
Confluence is intended to serve as a collaborative platform for sharing, maintaining and creating information. It excels at allowing individuals to work on content together, manage and store that information and easily add more as it is created or discovered. Personally I find myself using it mainly to keep track of what I’ve been up to in the form of meeting notes, product updates and other notes.
Part of collaborating, however, includes tracking tasks or action items. For example, during a meeting I may record that Bob will update the server on Friday, or that Sally will connect with Procurement about an important contract. To support this, Confluence allows us to track tasks, which can have assignees, descriptions and due dates… which sound awfully similar to a Jira ticket.
Jira
Jira is intended to help teams manage work in the form of tickets. Tickets can have different types, for example bug, task, story, etc. Each type of ticket can also follow its own workflow, so tasks can have a different set of steps necessary for completion than bugs. Additionally tickets can have any number of data fields attached to them allowing teams to collect and track many kinds of metrics relative to their work.
Part of managing work, however, includes collecting information about what you’re doing. For example an HR team may build out policies using Jira tickets and include information about them in the description field. An engineering team may collect API documentation on a ticket as well… both of which sound awfully similar to a Confluence page.
How to choose
Given the number of similarities the systems share (tracking an item of work, collecting information, etc) it can sometimes be hard to know which one to use. For example, I could keep Jira open during meetings and add new tickets as action items are identified. I could also open up Confluence any time I learn something new about a task and add it to a page.
My general rule is to use whichever one requires the least amount of work. Typically this results in me using Confluence as it makes managing information easier, and also supports tasks. Only when I get to a point where Confluence tasks don’t support what I need (e.g. adding more information to a task, requiring a workflow or approval, etc) will I switch to Jira.
Fortunately both systems are tightly integrated, allowing Jira tickets to be posted directly on Confluence pages and Confluence pages to be easily linked to Jira tickets. This makes it very easy to span both systems when I need to.
Schedule Crashing
Crashing means putting more resources on a task to finish it… but not all tasks are crashable!
Planning a project is a lot of work. There's dependencies, resources risks, assumptions, competing stakeholders and more. You've got to juggle all of those thoughts and demands and somehow come up with a project plan that gets you from nothing to something.
And then you realize some task won't get completed on time... There's just too much work. Luckily there's a way to help speed that up - crashing. Crashing a task is basically throwing more people at it to get it done faster. Only have one person and have ten widgets to build? Get five people and go five times as fast.
It is a great option for o help speed things up, but has several limitations that need to be understood....
You need to right resources
Every task in a project has a specific set of skills needed to complete. For example building a website requires someone who knows HTML and CSS. This need should be accounted for in planning to ensure the task can be accomplished, however, it doesn't mean you'll have others with the skill available to crash a task.
Depending on your team you could get lucky and have multiple individuals who have the necessary skills available to crash something. You might even be able to get by having one resource quickly train others (although this introduces a risk that they'll do something incorrectly...).many times, however you simply may not have the correct resource available.
Crashability
Many tasks can benefit from crashing. Data entry is one example I frequently run into... Two people will update a spreadsheet twice as quickly as one. Some physical tasks, like moving materials or preparing a work site are also good examples as multiple people can work together to speed them up.
There are, however, tasks where that isn't true... The standard example is having a baby - there simply isn't a way to speed that process up. Some tasks require waiting - for example proofing bread - that cannot be sped up even with more resources.
The challenge is to understand the difference - which takes can you crash, and which can you not? There are some characteristics I look for when trying to figure out if a task is crashable:
Repeatability - Are aspects of the task repetitive? If they are then the task may be a good candidate for crashing. Since the action actions happen multiple times they’re easier to train up others on, and there are more opportunities for others to help. Data entry is a good example of this.
Complexity - Simpler tasks tend to be more crashable as the skills needed are more widely available. This makes it more likely that your team has the skills spread across multiple resources.
Resource Availability - Getting more resources to work on a single task is more expensive - either in time, money or opportunity. There may be times when you simply cannot afford to crash since your resources are tied up elsewhere.
Crashing can be a great way to get things done in time - but like any tool you need to know how it’s best used, and the tradeoffs!
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.
How to get into Project Management
Project management is a great field - but taking time to understand why you want to get into it, and understanding your skills, is really important.
A common question I hear frequently is “How do I get into project management?”. Typically it comes from individuals who are new to their career and are interested in becoming a project manager (PM), but folks looking to make a career change also consider it. After answering this question several times I figured I’d collect my thoughts on the answer and share them below. Hopefully they’re helpful!
Why are you interested?
The first thing I ask someone who expresses interest in becoming a PM (or anything else really) is why are you interested? There isn’t really a wrong answer to this, but understanding why someone wants to become a PM helps them figure out how to get there, or maybe helps them figure out it’s not for them. For example, wanting to become a PM to help improve the lives of under-priviledged people is different from wanting to be part of building something big.
Understanding their “Why” not only helps guide them in terms of where to apply their time and energy, but may also help determine which type of project management they should look into. For example if they want to be part of construction projects then Waterfall projects are likely a better fit. If they want to build the next Big App, Agile is likely a better fit.
One important thing to note is that while you contemplate your Why, you may determine Project Management isn’t for you - and that is OK! Discovering that about yourself is a very important thing, as it will let you focus on something else that you’ll get more excited about.
What project experience do you have already?
This question is a good way to baseline where someone is, and also helps figure out next steps. It’s also a bit misleading, as almost everyone has SOME kind of project experience.
Just out of university? I’m betting you’ve been part of a class or group project and had to navigate stakeholder management (e.g. your project team).
Ever done a home project? Many things we do at home are projects. Do you have a garden? Build Lego? Install your own gutters? All projects.
Never been part of an official project? I’d bet the team you were on had some projects going that you were aware of.
Been part of a project team, but not the PM? You’ve definitely picked up some bits and pieces of how projects work.
Knowing what experience you have is important as it helps you figure out where your knowledge gaps are. Personally I learned many of my PM skills by doing… which isn’t necessarily the best way. This gave me a deeper understanding of some of them (e.g. communication), but I was totally lacking in others (resource management). This required me to improve my general knowledge to first understand what I was missing, then targeted learning in those areas.
What options are available to you?
I’m still working on a way to instantly become a PM, so the next question I ask is what options are there? Some individuals are in a position where they can take extensive training courses at work to learn the skills, others have an intense job that limits their time, and others are between jobs for various reasons and have other restrictions.
There are certainly a LOT of different ways to learn PM skills, including, but not limited to:
School - Many universities / colleges offer certificates, or even degrees, in PM. I took a great community college course on PM, and it was also part of the masters program I was part of.
Paid online learning - There are a ton of online learning options for PM (instructing.com is a great one, and I have several Udemy courses on the topic). These can offer intensive courses, or packages to help improve skills. Some will also prepare you for certifications (more on those below).
Free online learning - There’s also a ton of free online learning (check out my youtube channel).
Books - Personally I learned a ton from various PM books (like this oneLINK NEEDED). For a relatively small investment (in dollars) and larger investment (in time) I picked up a lot of the basics.
Mentorship - Some company’s offer formal mentorship programs, and informal mentors are almost always available if you look around. I find these tend to be better if you’ve got a starting point, but can also help someone get into being a PM.
There may be more options out there, but taking time to understand what is available is crucial as it helps guide learning.
Entry level roles
Finding an entry-level job in Project management can be challenging, but there are a few titles or roles to look out for:
Project Coordinator - Coordinators tend to assist project managers by helping manage things like scheduling, documentation and more. This is a great way to get exposure to project management without being responsible for running the project.
Project Analyst- Analysts typically focus on specific areas, e.g. risk management, contracts, etc. This type of role may be easier to get into if you already have experience in that area, but it will expose you to project management in general.
One thing to keep in mind is that every company may call the job something different, so it’s important to read the job description.
Closing Thoughts
I thoroughly enjoy my time in project management. It’s helped me learn a ton of great skills, exposed me to some really interesting people and helped me grow as a person. It does, however, take some internal work to get into and to thrive in. That said, the time you spend considering this is more than worth it.
Onboarding New Team Members
Many times I get to work with existing teams. This generally means they have a shared relationship and know how to operate effectively. Many other times, however, I have to integrate someone new into the team. This is a great opportunity to add to the team’s culture and bring in some new ideas. The time spent onboarding is never wasted and helps the team as a whole improve.
Many times I get to kick off a project with a team that has worked together before. This certainly has its advantages…. Everyone generally knows how everyone else will act and work with the group.
Other times, though, I've had team members join mid-project. This could be due to someone leaving the company, being out of office or needing more resources to get the job done. Regardless of why, this new joiner can disrupt the team in several ways - they may communicate differently, they don't know the norms and they have to build relationships up from nothing.
Ensuring the new person feels welcome and meshes with the group is critical to its success. Frequently I see this process being ignored or sped up in the name of 'get the job done'. I find that while this approach may get them doing work more quickly, it doesn't result in an optimal outcome. Sure, they're working, but they’re also lacking connection with their team. They're less effective because they don't know where to go for some things, and because they don't know how to really work with everyone else.
I've found a few things can help get someone new onboarded and success :
Make sure they meet everyone - this sounds simple, but make sure your new team member has time to connect with everyone else on the team. I've found that prepping them beforehand with some background can also help guide the conversation (e.g. Sally has a background in coding, she's a great resource for X).
Get time with them early - don't wait until they've already finished their first week! Meet with them early and often, this both helps demonstrate that you care about them and their success, but also ensures they have time to get a feeling for how you operate.
Proper resourcing - make sure they have whatever access they need to do their job as soon as they join. Nothing saps morale faster then not being able to v successfully because your account isn't live.
Ask them how you can improve - this new member will bring in new experience and knowledge that can help your team. Asking them for their input on what the group can do better both shows you care about their thoughts, but also helps them buy into the group.
It does take time and effort to integrate new folks to the team. That time is more than well spent - not only will the team benefit from their skills and time, they'll benefit from being part of the team.
Tool Tip - Send Later
Somethings you’ve got a great message to send, but it’s not the right time… things like updates or questions sometimes should wait for a more opportune time (like on a Monday morning instead of Friday afternoon). Many systems offer the ability to “send" later” which helps better target communications.
While I try to only work during “working hours”, which are generally 8-5 Monday to Friday, but can go all over the place, I typically find myself being inspired to do work at odd hours. I also frequently find myself writing emails that should be sent at a more opportune time (for example a project update shouldn’t go out at 5 PM on a Friday… no one will read it anyways, PLUS it will get buried in their inbox by Monday).
In the past I’ve drafted those emails and then manually sent them later. This both allowed me to funnel my inspiration when it struck, but also to get information out at the best time. It did, however, require me to remember to actually send them. That’s when I discovered the “send later” feature of gMail and Slack.
This does exactly what it says… it will send your message at some later time. It completely removes the delay between writing an email and sending it later. I’ve found it particularly useful in scenarios like:
Sending emails when folks are more likely to read them - especially useful if you’re writing updates on a Friday or late at night. Having it send early the next morning brings it to the top of their inbox.
Queuing up messages for people in other time zones - for example scheduling it to drop into a coworkers inbox at 8 AM their time, even if it’s midnight my time)
Sending myself reminders to do something - I’m constantly sending things to myself in the future so I don’t forget something
Continual Improvements (Retrospectives)
We’re constantly working on improving where we work… but we rarely take time to improve how WE work. Making time to do a retrospective and actively work on continuous improvement is critical to improving.
One of the things I like most about Agile project management are the retrospectives. I do understand that they can sometimes feel onerous, or frequently have folks complaining about yet another meeting, but they allow us to do something to ourselves that we’re doing for our systems - continually improve.
Many of us are constantly focused on questions like “how do I make salesforce easier to use?” or “how do I ensure new hires can get their equipment faster?”. These questions are all basically a variation of “how do I continuously improve where I work?”. Many of us keep grinding away answering that question without taking (or making) time to step back. Retrospectives are our chance to change that question to “how do I continuously improve how I work?”.
Continual improvement is something we can do on our own, but I find it takes a LOT of willpower and energy. Critically examining my own work, habits, etc. is hard! Having a safe group to help me with this makes this a lot easier. There are, however, some ground rules that have to be followed:
Honest collaboration - everyone on the team has to have a mindset of helping the group improve. This isn’t an opportunity to blame Sally for that fire she caused, or Sam for forgetting to push an update. It’s an opportunity to identify ways to prevent the next fire from happening.
Everyone contributes - These meetings can easily be dominated by one or two voices. While they may have good points or ideas, there’s the rest of the team that doesn’t have a chance to share their insight. Everyone on the team has expertise and experience they can bring to the table if we just let them.
Document it - Once you’ve got the time set aside and the ideas flowing it needs to be documented… after all, it doesn’t help anyone if you take that time and then forget what you learned.
Make it regular - This isn’t a one time thing. Time should be taken for continual improvement on a regular basis. Making this habit part of your working cycle will help everyone get involved and begin moving towards better versions of themselves.
Exactly what these retrospectives looks like can differ, but the end goal is the same… making time to ensure the team is able to both improve the product, but also to improve themselves.
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.
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.
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.
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.
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.
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.
All hands on deck
Sometimes something happens that needs the whole team to respond. When possible plan these out and ensure everyone’s there and involved.
Most of the time our work fits into the (insert your normal working hours here). This means we may or may not see the whole team we work with at any given time, and we can reasonably expect to be unavailable when we go home to do things like not work. There are, however, times when we need everyone to be available outside those hours. These situations tend to be big deployments, massive outages and other (thankfully!) non-standard events. While everyone knows they come up, they do frequently cause a lot of friction… after all, who wants to be dragged into the (virtual) office on a Sunday?
I’ve found a number of things help at least easy the pain of these events:
Plan it out in advance
When possible these events should be planned out in advance. This is easier to do on bigger projects where you can predict when major events (like a go-live) occur, but to some extent this can also be performed through risk planning. For example if you know a holiday is coming up and your system may be stressed, have more folks placed on call.
Planning it in advance helps everyone plan for it; now they can not take holiday and they can move other personal things out of the way. Planning it out also helps everyone see it’s an important part of the project/etc. And sets an expectation that its a required action vs. an optional event.
EVERYONE shows up
I usually serve as the project manager, so I’m rarely the one actually performing the go-live. This means my presence isn’t as critical as the developers, but I still make a point of being in the room as things unfold. This extends beyond my own personal sense of ownership of the project and into a sense of camaraderie. If everyone knows that everyone else will be there during crunch time, it’s more likely they’ll show up. Experiencing this stressful event together will help the team bond, and make it feel more like, well, a team.
Loosen protocol
Depending on the office culture this may or may not be a good tip, but loosening protocol (e.g. dress codes, eating at your desk, whatever) during these events helps to ease folks into it. It also helps deflate arguments about people being available as they can be more comfortable… or at the very least makes it more palatable (well at least I can wear my jeans).
Clearly define what needs doing
This goes with the “plan it in advance”, but you should (ideally) have a plan in place for what needs to happen during crunch time. This helps reinforce the “this is important” aspect of things, but also signals to your team that they aren’t going to be wasting their time. It also gives you a finish line to point at and keep driving towards.
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.
Don't play telephone
Telephone is a great game to play as kids, but playing it at work presents a whole host of challenges. Cutting out the folks in the middle and finding the source of the request is critical, as is your followup.
Do you remember a game called “telephone”? You know, the one where a group stands in a circle and one person whispers a message into someones the next person’s ear, then they into the next until it gets back to the first person? The message changes… sometimes folks add in parts on purpose, and sometimes they just mis-understand what they were told. The end result, however, is the message changes in (hopefully funny!) way.
In the game, that’s the point! It’s fun to see what happens when multiple people are in the middle since you never really know what will come out the other side. When you’re at work, however, this communication drift causes a LOT of problems. This lesson will go over how to identify when you’re in a game of telephone and how to constructively resolve it.
There’s three things you want to do in these situations:
Get in direct contact with the person impacted
Let the reporter know you’re reaching out the impacted person
Educate both parties on what to do in the future
Step #1 - Connect
Getting in direct contact with the person impacted can be harder than it seems, as sometimes there is more than one person between you and them. Frequently I see 2, 3 or sometimes more people in the chain, all “helpfully” passing along a message to someone else. Unfortunately, as our game showed us, each node in communication introduces a chance for an error to be introduced, and the drift from the original message only increases each time it’s passed along. To help with this, the first question I ask myself when I get a new request, whether it’s an email, instant message or ticket, is “who is this REALLY coming from?”. For example, if one of my data analytics partners sends in a request to get a new team member setup with access, that new team member is really the person how needs help. In that case, I’d connect directly with them to understand their needs, versus the perceived needs that are being reported.
Frequently the folks in the middle also don’t fully understand the request; they are, after all, filtering it through their own experience and ideas. This can result in your understanding of what needs to be done being drastically different from what is needed. Identifying, and connecting directly with, the originator of the request helps mitigate this risk substantially.
Step #2 - Update
Once I think I’ve identified the person impacted, I’ll connect to them directly, and also let the reporter know what I”m up to. That second bit is critical; if they are unaware I’m helping they’ll keep coming after me. Some quick examples:
If it’s an email - I’ll move the reporter to CC or BCC and email the impacted person directly.
If it’s an instant message - I’ll either let the reporter know I’ll be in touch with the impacted person, or get both of them in a group message
If it’s in person - Similarly to an instant message I’ll let the reporter know what I’m up to, then connect with the impact person directly.
Step #3 - Educate
Keep in mind the reporter is just trying to help their colleague out, they’re not intentionally making things harder for you. This makes these situations great learning opportunities. As part of your communication, you can let the reporter know how these situations ideally should be handled. While the exact approach will differ by organization, I prefer for the person impact to be the one to report the issue. Sometimes this isn’t possible, maybe they’re on vacation or unavailable. That’s totally OK. In those situations someone else should report it, but clearly indicate they’re passing along a message and include the impacted person on the email, message or thread. This makes it significantly easier to follow up, and ensures everyone is aware of where they are.
Some examples of language I’ve used:
Example #1
“Hey Tim, thanks for letting me know Rebecca is having login issues. I’m going to connect with her directly. I appreciate you forwarding in her request, but please encourage folks to use our help desk (link here), it makes it a lot easier when they reach out directly”.
Example #2
“Hey Tim, Rebecca let me know you’re having problems running your TPS report. More than happy to help out, but it would be helpful if you report these directly in the future.”
Broken Comb Skillsets
Broken Combs have expertise in a few areas, in addition to general skills. This makes them a great addition to any team since they can fill multiple gaps. This can, however, result in them getting spread too thin…
A broken comb skill set refers to the shape a comb with missing teeth makes - some vertical lines and a horizontal one (and certainly doesn’t suggest the individual is broken!). They’re essentially an extension of the “T” skill shape, multiple in-depth areas with a (potentially) broad general base. This type of skillset is very interesting to work with, as they have multiple areas of expertise. While this is not without its challenges, broken combs can be very flexible and bring immense value to a team.
The upside of a Broken Comb
Broken comb skill sets offer the advantage of multiple focus disciplines. Due to these areas they can potentially reduce the need to bring in additional team members, or negate the need to bring in outside help. By excelling in multiple areas they provide a lot of flexibility and are able to make a big impact on projects. This is especially true if their areas are related (your tax and finance systems, for example) as they are able to easily support thos areas and understand the interconnections between them.
In addition to their areas of depth they are also similar to how a “T”-shaped skillset with a broad skillset of more general skills. This general knowledge helps them bridge gaps between areas (even their own), and allows them to get a better handle on the big picture. The mix of focus areas and general skills can make for some very versatile individuals, capable of not only handling technical areas, but also “softer” skill sets.
The downside of a Broken Comb
While not a rule, despite a Broken Comb shaped skill sets offer deeper expertise in multiple areas, it’s likely their depth isn’t as great as an “I”, or even a “T”. This is simply due to not having as much time to dedicate to each one as those other types. This may result in overconfidence, or stretching too far in those areas. Have multiple focus areas can also detract from their overall impact as they may get pulled in too many directions to be truely impactful.
Similarly, the breadth of general skills may be limited as a lot of energy is put onto the areas of focus. This leaves less capacity to developing general skills, or to developing them deeply enough to be at least minimally effective. This can result in broken combs having narrower general skillset than their “T” shaped counterparts.
Managing a Broken Comb
Understanding what any given Broken Comb’s focus areas are is important to fully using their talents. Take time to understand where their interests lie, and what areas they choose to focus on. This will not only allow you to be utilize them on projects, but also help the continue to improve their focus areas. Knowing how wide (or narrow) their general skillsets are is also important. Their wide range of skills can make it seem like they can handle anything, but knowing where the edges are is critical.
Broken Combs can also fit in incredibly well between teams, especially if there are folks with I-shaped sklil sets on either side. A Broken Combs multiple focus areas allows them to (relatively) easily translate between groups as they share an understanding with each side. This can also open opportunities to expand someone else’s skillsets and the Broken Comb can relate to them, and the new skill.
If you’re a Broken Comb
Take time to understand where the edges of your focus and general areas are. Knowing your areas of depth allows you to further exploit and build those skills, and knowing your general areas will make it easy to see how things connect. It will also help you better communicate to your team what you can do… and help avoid situations where you’re expected to be an expert but really don’t know.
Having multiple focus areas (plus generalized skills to round you out) will make you very popular. Be careful that you don’t get pulled into too many different directions. Take an active approach in shaping what work you take on to best maximize your interest and impacts.