Projects of all kinds fail for a myriad of reasons. Whether it is scope creep, failure to adhere to a Scope of Work (SOW), organizational dysfunction, personality conflicts or technical limitations, a project may end up not working out. Common risks have a tendency to doom any project if not recognized and mitigated early on. But what about software implementations specifically? What challenges do they face that might not be obvious to a skilled project manager?
Here are a few risks to consider when implementing AssetWorks EAM, or any software in your organization:
1. Failure to keep the end in mind
During a software implementation, you will be asked to not only learn about how a software works, but also tasked with doing research to enable decisions that will dictate how that software will be configured. At those critical moments, you should ask yourself: “What does success look like?” Every task that you complete as part of the implementation should reintroduce this question. You may be thinking to yourself if you are in the early stages of an implementation that “we won’t need to worry about forgetting our requirements! We will make sure that our requirements are well documented and often revisited.” Still, you will be surprised how easy (and how often) it will be to lose sight of your end goal as you enter the throes of an implementation.
Along with losing sight of the big picture, it is also critically important for the customer to know what they want to get out of the system when they are done. This usually manifests itself in the form of reports that need to be defined. While people often focus on the format, or ‘look and feel’ of a report, it is much more important that the purpose of that report to be well defined. Who will be accessing the report? For what reason? What decisions will that report inform? By answering these questions, instead of focusing on whether you want a pie chart or a line graph, you will be well on your way towards success.
An exercise that you can do early in the implementation to mitigate these kinds of risks is to pretend that you are 6-12 months in the future, and the software implementation has miserably failed. Now, what reasons have led to that failure? Was it a failure to properly train the end users? Were the reports too complicated? Are the processes configured in the tool too far removed from reality? Whatever those reasons are, they should be identified as risks to the implementation project and wherever possible, mitigated as well.
2. Focusing on the technology and not the people
Implementing software can feel like opening up a shiny new toy. It can be very easy to get mired in functionality and configurable options while losing sight of why the software was purchased in the first place. Configuration is where a considerable amount of time and expense will be spent when configuring and implementing software, so it may seem imperative to your success to get to this task early.
This is the wrong approach.
A successful software implementation hinges on whether the implementation team knows what success looks like. To do this, the needs of not only management need to be well defined, but also the needs of the users. Failure to consider users will likely result in the software not being used at all. Success as defined by management and users will likely be two different things. Both of those things need to be met to have success in a software implementation.
Meeting the needs of software users requires the implementation team to not only understand their perspective, but also to meet the end-user where they are at. If that user is not a regular computer user, then some type of additional support is needed to get that user to a place where they can use any software to assist in their daily job. If an end-user requires certain functionality outside of the normal documentation and training exercises, then that will need to be addressed as well.
3. “Configure it to work exactly like we work today”
All organizations have a process whether they realize it or not. While AssetWorks EAM is highly configurable, there will likely be decisions that you will need to make during the design process that will change how work needs to get done in the future in order to optimize that process as part of the AssetWorks workflow. It is important for implementation teams to know what elements or steps of the existing process are negotiable, and which are not. If compliance dictates that certain tasks be done a certain way, then EAM should be configured accordingly. If a process exists because of someone’s preference, then that process should be negotiable. The more processes you have that are negotiable, the easier it will be to implement. They key here is to know what the end goals of implementing the software are. This aligns well with “knowing what success looks like.”
Anytime someone asks why things need to be done a certain way and the response is “we have always done it this way,” this is generally a good indication that that process is (or should be) negotiable.
4. Who is your implementation champion?
AssetWorks EAM is not meant to be a turn-key solution. For continued success in using EAM, someone within your organization should be identified as the AssetWorks expert. This will allow a true knowledge-transfer to take place during the implementation, and allow you to quickly identify and fix problems throughout your usage of AssetWorks. Having a champion also allows your organization to easily make minor configuration changes as needed without re-engaging AssetWorks professional services. This will save you time and money. It will also allow you to expand the use of EAM across your organization which will reduce your reliance on integrations for disparate tools.
5. Failure to launch
There isn’t much in the world that is more useless than software that is not being utilized. The goal of any software implementation should ultimately be to get people to use it. With that said, no software is perfect. While a software implementation’s success is usually dependent on how well it is received by its users, it is important to realize that every organization’s struggles with implementation will vary due to the fact that every organization operates differently, has different challenges and has different personalities. We recommend that our customers deploy AssetWorks in phases to reduce the scope of the initial deployment and to track lessons-learned so that future phases will have a better risk mitigation plan.
It can also be tempting to think that you can mitigate the risk of low adoption by threatening users with various types of punishment. This can work but typically breeds resentment. Instead, a much more effective method is to reward users who excel in using the tool. AssetWorks can be a valuable instrument in communicating the productivity of your teams by allowing you to quantify how much work, and the value of that work, that has been done. By rewarding those users or teams with things like verbal praise or additional headcount, you will help those lower-performing teams to become more motivated to use AssetWorks.
People usually go into a software implementation without knowing exactly what they want. This is totally acceptable and understandable, however, it is very important that people know what a successful software implementation looks like. Do you need to be able to justify your department’s existence? Do you need to communicate to your city council why a capital improvement project will ultimately save taxpayer dollars? Do you need to demonstrate the value of the work you do to the citizens within your jurisdiction? These are all common problems that our customers bring to us to try and help them solve. Knowing your end goal will help you stay focused on what is important during your software implementation. Defining success is the first step towards achieving it.
AssetWorks Enterprise Asset Management’s (EAM) professional services team prides itself in its successful and well-received implementations. To read about a real customer example, you can click this link about Seattle Parks and Recreation.
