This article was originally authored by Locana, which is now part of TRC.
Success pillars of software implementation.
John spoke about the three key pillars applicable to project controls software implementation: People, Processes, and Products. Under these pillars, John identified the points that will make the difference between a mediocre project and a great one.
People
1. Sponsorship — Having the right support at the right levels in the organisation is crucial to enable business change activities. You need senior support. TRC Companies can deploy and configure software but if the senior organisation doesn’t enforce behavioural change there may be resistance which will inhibit adoption and frustrate the realisation of benefits.
2. Identify the best resources — Allocate a resource within the client organisation that understands the end goal, that has the capacity and ability to support the project within the customer. Whether this means hiring a new person for the project or using someone internal, the difference between success and failure can often be attributed to the presence or lack of a skilled resource to assist.
3. Organisation readiness — How capable is the rest of the organisation to receive the solution? Often, organisations think they can benefit from the change, but they are not ready for it. Readiness often has to do with the way that leaders communicate their vision and the measurable outcomes of the project – how it will impact users, teams, and the bottom line of the company.
Assessing readiness determines the level of support required. If the organisation is willing to accept and non-resistant it will be a different path to that which will be needed if the teams are unaware of the new solution. Projects will be implemented quicker when the customer is ready to receive the new solution and accepts it. Other factors can slow projects down, or even block them.
4. Training — In the last two steps we’ve identified a gap in knowledge. Customised training can be implemented to fulfil difference in learning styles. Some want to be taught, some want to game, some want to read. TRC can identify the appropriate methods to get the best outcome as not a one size fits all approach. Sometimes organisations have a dedicated internal training capability – TRC can implement a train the trainer approach. TRC can deliver the training ourselves with appropriate multimedia documentation and packaging. The TRC approach is to look at each situation differently and propose the appropriate methods and channels.
5. Support Model — TRC helps identify super users and support champions capable of handling first line support, answering frequently asked questions, or dealing with support tickets. Ensuring the appointed people are in their roles early in the project means they can be involved at critical stages and develop a sense of ownership around the new system. This also helps them to be able to answer the questions WHY something is done a certain way. This, in turn, enables end users to understand the reason for the change and associated benefits.
6. Partnership — TRC implements systems on a day-to-day basis. To use an analogy, when undergoing renovation, in the first instance without experience, costly mistakes are made, that in turn, delay completion. The shared knowledge base and experience of the TRC team can help avoid pitfalls, create an on time on cost implementation project and often provides a more efficient result.
7. Socialise — TRC encourages clients to get out and talk to other similar organisations who have achieved similar solutions. Clients can either find an existing group or create one. The value of shared experience can address the fear of being alone; as a community you are bigger when communicating back to your vendor for example regarding enhancements or roadmaps. You can share workarounds and understand whether a client is unique in their situation.
Processes
1. Start small and simple — Some clients ask to start with a big bang and huge cutover. They dive in with excitement and expect everything to work immediately. If the system doesn’t work with customer provided data sets, they can’t immediately tell whether it’s the system or the data that is causing the issue. When things don’t work the first time, confidence in the solution is lost. To avoid starting with a huge amount of bad data, it’s best practice to start with a small amount of good, simple data to build confidence. Keep the data to manageable sizes, and use data the team has confidence in. Once the team has the confidence that the system is working as it should, larger and more ‘real’ data can be utilised.
2. Know what your customer needs — Nearly everyone has a customer. Your stakeholders should know what information is of the most benefit and it will grow their confidence in the system if it can deliver what they need.
All too often, teams create a bottom-up approach to data which creates too much reporting that serves no senior purpose. By starting at the top and finding out the requirements of your key stakeholders you will likely create fewer data sets, fewer codes, and less irrelevant reports that won’t be used.
3. Identify projects for first release/pilot — Identify good and bad projects for first release. Good projects that you can celebrate the success of and build momentum, but you will not learn as much until you get to poor performing projects or bad data sets where you’ll learn more about the client and the environment. Guided mistakes can develop teams’ understanding of the approach to fixes later if things go wrong.
4. Test manually. Automate later — Scalable solutions are often developed manually. This is to fine tune processes and develop the best approach to a process or design system before automating it for scale. Testing manually with positive outcomes grows confidence that the other parts of the system are performing as planned. Once confidence is assured in the integrated state, automation as a subsequent phase will speed things up and address productivity concerns.
5. Plan rollout — Use momentum, confidence, and learnings to enable the successful deployment of the solution of the target state to the audience. Don’t pause, don’t let the team roll back onto other work because reclaiming lost resource will be nearly impossible after they have been deployed back to other projects.
Products
1. Support/knowledge base — It is a good approach for a team to get used to using all support tools the vendor offers. Make use of support available from the vendor including any knowledge base of known issues and fixes. If knowledgebase articles aren’t sufficient, users can use the feedback functionality to improve usefulness. Some vendors also have an ideas or feature request database where users can request new features, upvote other requests and see updates on the progress of requests.
The implementation partner has seen most product issues before, so they will be able to guide the client team towards the most useful support channels. The partner should be on hand during the critical stage after implementation to answer questions and offer guidance on potential issues & support channels.
2. Architecture options — TRC works with teams to find out what is best for them. As an example, before COVID when most people were office-based, systems were set up for that arrangement. During COVID teams were obliged to be working from home – and some teams are still not back to full office time. Now, it’s best practice to consider where the users will be working from, and whether the applications are configured in the best way for users to access from their locations.
3. Clean user interface — Where possible, remove the distraction of features and buttons that are not going to be used within the application. This will help user adoption by giving a cleaner, user-specific interface that only shows what is needed and is therefore less crowded. Often, applications can feel overwhelming when switched on for the first time. Avoid this by removing unnecessary features, making the first impression more pleasing and straightforward, and easier to learn.
4. Boundaries — Nowadays, nearly all applications can achieve multiple outcomes. Just because a product can do something, doesn’t mean it should! Understanding where there are overlaps and focusing on the core strengths of each product will produce more efficient workflows. Often the end goal is to remove spaghetti systems, so it is best practice to consolidate, but also to deploy the best applications for certain tasks.
5. Version roadmaps — The times when software could be installed and left for years without upgrades are long gone. World events, the increase of cyber-attacks and other concerns have prompted software vendors to update their software frequently, to address vulnerabilities. Out of date versions expose systems to unnecessary risk and do not result in a cost saving. Leaving software updates behind for too long makes upgrades more expensive, time consuming and prone to error.
6. Stage your changes — Do consider having at least one separate environment to develop and test changes, patches, and upgrades, before affecting the live environment. Learn there before affecting real users, systems, people, and data.
7. Take backups! — You’ll never regret taking backups, you’ll only regret not taking backups! Take as many backups as practical, as often as needed . . . and remember to check that the restore function works!
Conclusion
System vendors are conscious that it’s important that their customers use their applications in a constructive, secure manner. They are usually keen to ensure that systems evolve to make best use of emerging needs and technology.
Trust your implementation partner. They will have knowledge of the latest functionality and help you to ensure you make best use of it. At the same time, they will have installed similar systems many, many times and will often be continuing to provide post-implementation support. Let them use that experience to help you avoid pitfalls that could be in your path if doing such an implementation for the first time.
TRC’s culture of competence and transparency has built an enviable reputation in the UK over the past 30 years. Staffed mostly by permanent staff, the team’s knowledge base is robust because it is comprised of people dedicated to our clients’ success. With customers ranging from 1-2 users to 12,000 users, TRC has a track-record of accomplishment working with a range of software combinations and processes in teams of varying size, scale, and complexity. In addition, TRC is not solely aligned to any one vendor and is truly independent with multi-vendor expertise so is able to advise based on each individual situation depending on the requirements of the organisation.