Amanda Scigaj is the Head of Campaign Operations at Asana and is a master of problem solving, collaboration, and tech implementation. She shared her expert tech implementation insights with Stensul.
When it comes to implementing a new tool, everyone loves to talk about when things go wrong. The gory stories of derailments, depreciations and DDOS attacks are favorites — but rarely do we talk about when or why an implementation goes well. Tech implementations of any size that change the way a team works have trickle-down effects beyond expectations, and each comes with their own set of nuances.
What does a good implementation look like? As someone who has managed all sorts of technology transformations both as a consultant and in-house, I’ve compiled my top recommendations based on time-tested experience of what works, and what I wish I’d known when I started in this body of work.
Before You Begin
Whether you’ve been lucky enough to be a part of the exciting early steps of vendor selection or you’ve been ‘voluntold’ to implement a new tool, one of the most important questions you have to ask yourself is ‘Why?’. During a session at Adobe Summit a few years ago, Ops expert Kelly Jo Horton said one of the simplest yet most eye-opening things that has stuck with me ever since: When implementing new tech, ask ‘why’ five times. Some ‘why’ questions to consider are:
- Why are we implementing this now (is there a legal or compliance issue at stake like GDPR)?
- Why don’t we use another tool?
- Why can’t our current tech stack support this use case?
- Why is this important? Is there support from leadership, or is this a niche ask from a specific team?
- Why is this a priority? Is this a part of a larger project or supporting a large event? What happens if we do nothing?
Doing this exercise alleviates any doubts or assumptions (more on that later), and now you can give an elevator pitch on this project. Your colleagues are likely going to take time away from their current roles to participate in this endeavor – being able to quickly (and repeatedly) explain ‘why’ improves enablement down the line.
Even if you are not the project manager, make sure the group maps out the teams that need to be looped in or communicated with throughout the implementation. You can get sophisticated and use a RACI or DACI model, or just grab a series of post-its and sharpies and map out your organization. Likely, the new tech you’re implementing will impact teams in ways you’re not expecting and maybe haven’t considered. Once, during a large database migration, nearly six months passed before it occurred to the group that we needed to involve our web team, resulting in a lot of unnecessary last minute scrambling. Even if you assume that a change won’t affect a team, reach out — I doubt that you’ll ever hear negative feedback when a team is informed of a new change in your organization. You improve your relationship with other teams, and maybe even learn something new!
Streamlining Communication
Determine how you communicate, each team member’s area of responsibility, and your project plan.
Have you ever been in a large meeting that’s essentially just the 12th version of a meeting you already had last Tuesday? It’s the worst — nothing good comes from it, there are too many people present for anyone to make a clear decision, and if you’re like me, you spend most of that time thinking about what you could be doing with the time (and maybe what you’re having for lunch). Determining a dedicated resource for each department eliminates the dreaded all hands discovery meeting and decreases time spent hosting redundant brainstorming sessions.
When you put different teams together you get lots of opinions and tasks, and lots of ways of managing these opinions and tasks; your engineering team may use Jira while marketing uses Sheets, and sales ops uses something entirely homegrown. Clicking through each tool (and learning the tool, and getting/giving access to said tool in the first place) in order to track tasks and decisions becomes a nightmare, and what we at Asana call ‘work about work’. Utilizing one scalable tool that everyone can leverage removes these headaches and gives everyone valuable time back.
Consider major holidays or paid time off that will impact your project.
Did you know companies like Adobe take a full week off around July 4th? This is an amazing and well-deserved perk, but it can impact your go-live. Get key dates and PTO from everyone involved in a launch; the team, the vendors, consultants, and offshore team. During a major database migration, three coworkers and I got married, and because we planned ahead of time, our other exceptional team members were appointed to decision making. Each of us could focus on our personal tasks like making a wedding playlist and managing surprise plus ones, instead of what fields we needed to be on the lead object for routing.
Making Decisions
One of the best pieces of advice I got early in my career during a particularly tenuous project was simply, ‘don’t make assumptions.’ This is accurate in every part of the implementation process: don’t assume everyone speaks ‘marketing technology’, don’t assume that a solution in theory works in practice, and don’t assume a vendor’s suggestion is best. I dislike the term ‘best practice’. What was best practice for a small startup, for example, probably won’t work for Google.
It’s hard to make decisions in a large group, so leave the planning to a small group of focused people. Tighter teams work. I have spent hours of my life discussing partner accounts when those conversations should’ve been taken ‘offline’ and solved with a tighter team. This is especially true in *gestures wildly* all this. Zoom fatigue is very palpable.
There will be times where you cannot agree on a solution, or you feel strongly that the solution proposed is the wrong one. In these cases, make sure each of your solution options and the risks attached are well-documented, surfaced, and acknowledged, rather than buried in a deck that no one but yourself has seen.
QA/UAT
To reiterate on the ‘don’t make assumptions’ concept, make sure to prioritize testing, no matter what you’re implementing. If what you’re working on has a large volume (API calls, a lot of trigger logic, daisy-chained processes, leveraged by a large event, etc), stress test it wherever possible. Just like a bad implementation, people are more likely to talk about a bad experience (a failed Zoom meeting, an email with placeholder text, a site crashing) than a positive one.
Enablement
You must have a strong reason for implementing new technology. Crafting that elevator pitch means you can succinctly tell any team or individual in your organization why the change is needed. Personally, I could discuss at length that ‘x technology optimizes’ or it’s a ‘new ABM tool,’ but that doesn’t necessarily tell the ‘why’. What really matters to you and to your company is that the tech improves someone’s experience. Tell a story they’ll understand and relate to.
No new technology is going to be as bright and shiny as it is on the convention display. Set realistic expectations and communicate them clearly. For example, when implementing lead scoring, it’s not going to instantly be a game-changer, and some people may be eager to adjust the model, or they won’t trust it in the first place. In the past, I’ve communicated that there will be a ‘listening phase’ of a few weeks or months, after which we will ask for feedback and adjust lead scoring if needed. For a large technological implementation, maintain a clear space that tracks known issues, and let teams know the cadence of when those fixes will happen. Hold office hours to encourage team members to raise concerns and requests.
Keep in mind the fact that you are taking time away from someone’s day-to-day job, and if something doesn’t work as advertised, it will be met with derision.
Post Implementation
No technology is a monolith. I mean, I thought the Sony Minidisc player was the height of technology before I was old enough to vote. The same goes for the tools and workflows you build. Think about that technology like a consultant or vendor and perform regular reviews to make sure it still works for you, and how it continues to improve on your original problem statement.
Gratitude
One of the biggest implementation priorities isn’t integrating the tool itself, but clearly saying thank you to those involved. Thank you gifts that can be personalized and/or helpful (and not just another thing that lurks in their bag and is tossed in the next purge) distributed to the larger group shows appreciation, as does a meaningful, verbal message. Personally, being in a large group of my professional peers and getting a thank you for a specific thing I worked on is more valuable than a shoutout on Slack or commemorative laptop stickers. It shows that you pay attention to the individual contributor, and you know their name.
Implementations done well take a lot of investment from yourself, and from the teams involved. They rarely go as planned, and it is completely common for momentum to slow, or tasks to get derailed on account of ‘surprises’ or conflicting opinions. By communicating well, staying organized, setting expectations, getting people excited about this change, and showing appreciation along the way, you are on the right track for a successful project.
