The vision you have for your company probably involves, growth. Growth means change. The change we’re talking about today is implementation.
You built your sticks and bricks, and your website/store. That was implementation. You hired your team. Implementation. When we step back from thinking of implementations only around software, where granted, we mostly use the word; we can think of this invisible thing that has to happen, and start to see it more concretely.
im * ple * men * ta * tion: The process of putting a decision or plan into effect; execution.
Implementations are changes. Change can get heated in companies, and when you’re small, your team is important in many decisions that will impact the future of your company.
For over 18 years, I’ve been part of large and small implementations, from a small healthcare software company that lived in chaos (5 ceos in four years) to a global new business process training rollout after an acquisition in the oil and gas industry, and many implementation variations in between.
Some implementations were well thought out and able to pivot when needed to accommodate the inevitable changes that come up, others fell dormant, were abandoned or plain failed.
In my post To Subscribe Or To Buy. That Is A Question
, we talked about risks vs risks when it comes to figuring out the right DAM for your needs. Now that you’ve chosen your DAM, you’re still in that risks vs risks window when it comes to having your implementation be a wild success...or not.
Planning. Communication: Two words that can intimidate the strongest of teams because they are two of the most challenging skills almond humans.
People don’t speak up. People don’t know their role. People don’t think the same outcomes are the goal. They are two of the absolute necessities your project will need to have in order to be seen as a success once the implementation dust settles.
Let’s dive in to 5 of the top reasons implementations fail so you can be prepared to meet these challenges head on.
Hitting you in the gut right away, right? Lack of knowledge comes in many forms, what I’m talking about in an implementation is understanding each other’s roles in the project, including the vendor. This can bring up a lot of stress for everyone involved.
Moving from a familiar process to a new one is stressful no matter how poorly the old one serves your company. Learning a new tool when your day is already packed full is stressful. Figuring out how best to communicate with your vendor is stressful. There might be unexpressed concerns because of lack of knowledge - or team dynamic.
Avoid the pitfalls of lack of knowledge by involving team members who know your company well. They’ll have insight and be able to see where things might be getting off track. Their input could save everyone’s peace of mind and avoid scope creep, unnecessary pivots and wasted time.
2. Low Adoption (people don’t use it)
Think about the last time you tried to change something in your personal life that you decided needed changing. Exercise. Less coffee. Better eating. Reach out to someone you lost contact with. Finishing those never ending projects around the house.
These can be called pre launch planning - you signed up for the gym. You got out the one cup coffee press to use and put the 12 cup brewer away. You shopped and stocked up, maybe even meal prepped healthier food. You made that call and left a message telling someone it’d be nice to reconnect.
In other wordsyou set yourself up for success
As simple as it sounds, setting your whole team up for success increases how your team will adapt to using the DAM, how they perceive it, how they work together to help each other get up and running.
Low adoption can look like the whole thing was a failure (ie low ROI). And when you’re a small company you might not follow the classic technology adoption life cycle
(Innovators/Early Adopters/Early Majority/Late majority/Laggards or Phobics) because you simply don’t have each of the adopter personas.
With 1 to 5 people or even up to 50 people companies, this model falls short in helping you understand what happened because you might have individuals who encompass more than one of the personas. It is still important to recognize this type of DAM user on your team because unique to small teams, the trusted persona will impact the implementation positively or negatively.
Some won’t see the benefit of the DAM. Someone might be reluctant to make the switch from doing things the old way to disrupting their day to learn a new process for digital assets. Those two scenarios are solvable by having a trusted team member be your DAM advocate and help quality check the process until everyone is comfortably on board. Meaning, yes, your trusted team member will push back on the people who are either struggling with it or are stubborn about it.
Plan for training. In groups in person when possible. Have your vendor build training based on your specific implementation, then have them leave documentation/recordings/online training for you once they’re gone. Training is not an afterthought.
Lunch and learns, town hall style meetings, vendor user guides with amendments to highlight your specific processes. These are the signs your vendor understands more than make the sale, put the thing in, walk away. Also, Take into consideration the emotional maturity of your team.
3. Scale: the case for incrementalism
Are you taking on more than your teams can manage in a reasonable time? This one is tricky because you want long term impact from such a big disruption, and you want people to buy in and use the thing.
Implementing software will impact your team’s lives inside and out of work. I know a hospice nurse manager who, along with a core group of nurses, was tasked with adopting, learning, testing, suggesting changes to and influencing other hospice medical staff to use wholly new electronic medical record forms built by a vendor for their facility to use for patient records.
What was supposed to be a 9 or 10 month project dragged out over two years and eventually was partially abandoned. The toll it took on the nursing staff was immense because in this case, they were the direct users, directly impacted by the changes but both executive staff and the vendor were on their own course and pushed back on most of the feedback from the nursing staff. People quit over the implementation because it turned out to make their jobs harder not better.
When it comes to large millions of dollars implementations, you’re definitely looking at a long implementation. That could mean years. When you’re a micro, or small company you might decide to take your vendor’s advice and push every feature out in your initial implementation.
This is the case for incremental feature roll outs. To do something like this successfully you have to have a clear set of problems your new system will solve, and prioritize them by how often your team is faced with them.
Incremental feature roll out most often applies to the vendor side of things, software development and release. Think of beta programs you’ve been involved in. Incremental feature roll out helps identify and solve issues that could become complete business stoppers in the future.
It works in implementations too. You can bring on a DAM and roll out features to your teams, giving them time to adapt to the changes, learn them, live them. This concept is different than the vendor method of giving beta versions to users. It means the implementation is built in cycles and it increases learning, helps you stay focused and keep the implementation moving.
For example, if you have never had formal libraries and everyone throws assets into folders they know and use often only to lose track of them resulting in duplicating assets, you have a pain point the software will help with and a feature to put at the top of your list for teams to learn and adopt. Target the things your teams need to accomplish with this new change and let those drive your implementation.
It’s easy to want to get things put in place and move on to your next thing but people don’t function that way, especially when it comes to learning new things. Yes, business moves at a fast pace, really often. Setting your teams up for success when asking them to make large changes to their workflows will help you keep them in mind while riding the roller coaster that is your business growth.
4. Abandoned Requirements:
When you set out on your DAM implementation, you have a lot of people to consider. You have a lot of requirements you expect will improve your asset management processes. Sometimes in the interest of getting to the finish line a little sooner, you decide to drop a few of the requirements you set out to meet.
This is where the concept of incrementalism will help support your implementation. Putting your requirements into implementation phases will save frustration, especially when you decide to drop a requirement one team sees as crucial. Instead of dropping requirements, you have options to move them to other phases, keep them, or drop them.
Communicate these choices. Give your team the chance to give you some insight into why it may or may not be the best to completely drop some requirements. Persistent communication is your best friend when it comes to successful DAM implementation.
Cards on the table, change management is a huge elephant in every implementation and often gets left to the vendor to handle. This is where you put on your work gloves and get in the mix with your team to be the advocate for the DAM, the processes it will change in your company and to walk alongside your teams to assure the best possible outcome.
Don’t leave change management to a vendor who doesn’t know your company, your team or what is inside your head. No one knows your vision like you do.
Define success early. Identify the emotional maturity of your teams. Figure out if you’re on the same page (mit article). And most importantly, admit when things are not aligning.
I worked with a virtual assistant company where the CEO had built a significant client base. Her goal was to build a company where VAs had a good work environment, her clients were well cared for at a high level of expertise and she made money.
After a few years, she brought on two layers of management in a relatively short period of time. She moved a VA into the role of HR director, another VA into the role of IT director, and hired outside to bring on a Director of Operations.
Change. It is hard. It is inevitable.
After adding these layers to her company, she removed herself from the day to day and relied on the HR and Ops directors to run the business side of things. Her HR director did multiple things to sabotage the company, the VAs directly, while she presented a picture of people not cooperating to the CEO.
The Operations director took months to understand what was happening. After a large turnover, the Ops director caught on. Not because he listened to the exiting VAs, but because he found discrepancies in the HR director’s actions compared to the outcomes.
And as is the case in small companies (lots of big ones too), the HR and IT directors were related so their complicity with one another let the HR director’s actions go on for a full three years before her actions were discovered. The CEO’s approach was one of “my Ops and HR directors will figure this out”, and CEO continually came to the defense of HR director all the while being blind to how HR director was treating the company and the VAs.
Once everything came to light, both the IT and HR directors were let go, the executive team layers were restructured, processes set up to allow for more transparent communication and amazingly, the company grew immediately.
I bring this scenario up because it highlights how important - critically important - communication is at all levels of a small company. The VA company had 4 people in management, all at a peer level. Below them were all of the VAs, a team of close to 25 people.
The VAs did not feel valued since they were prevented by the HR director from expressing their opinions (one of the sabotages was HR director not conveying grievances to CEO). The CEO had an open door policy but would always back the HR director.
It was toxic to say the least. The CEO failed to take the time to understand her company and moved two people who were not suited to support he vision into roles they did not understand.
On time. On budget. On target are minimums. Listening to your teams throughout the whole implementation of your DAM and bringing it on in increments will help you have a successful DAM, one that people use for a long time and grow to value since they had a hand in bringing it to life.
Most people taking on a home improvement project understand that contractors, vendors, weather, pandemics - are not controlled factors and homeowners will often add in a few months, and many thousands of dollars to their project knowing it will go over on almost every aspect.
If on time, budget, target are the core - however minimal- requirements of a successful project it’s no mystery why a 2012 report showed 70% of implementations fail. Also that’s a 2012 report that gets cited relentlessly, even in 2021 because software implementations still go wonky. Often.
I prefer going in a the incremental implementation because it includes incorporating how human nature comes into play. I know, sacrilege. There is no human in AI…there should be. Everyone benefits when implementations consider every hand that will touch the software from every level of the company.