What are the key challenges of implementing a new software system?

User buy is the key, in my experience whenever we implemented a new software the user community always went back to their past experience with the old software or methods and compared it with the new platform. Unlearning is the important aspect and it is equally important that user community / influencers are walked through the new platform before the actual journey begins. Repetitive communication especially on "Why the change?" will fortify the need

80% of IT projects fail because they don’t meet expectations. Clarifying and confirming what is expected (the WHAT) and HOW it will be delivered IS the difference between success and failure. Tenders and RFP’s (except for Military use) are too expensive to define both the WHAT and the HOW so they come fully loaded with expectation gaps. Closing this gap is the art of Project Management and Systems Integration.

Stakeholders from all levels of the organisation should be involved from the get go to ensure that end users receive a system that is compliant, fit for purpose and easy to use. When key decisions about design, functionality and end use are made by people with little or no operational input this can lead to resistance and misuse from go live as end users feel the new system is forced upon them with no input. The best projects I have worked on when implementing new control of work systems involve detailed discussions with Management as well as Operations and Maintenance personnel. Listen to end user feedback and build in a mechanism that allows to system to evolve.

In my experience, very few organizations go into the selection, purchase, and implementation of a new software solution with a clear plan for success. Often an executive is impressed by a demo, or at a conference, or by a peer. This begins the process without first documenting the problem being solved, the need, and how success will be measured. This also prevents the opportunity for buy-in from the 1st and 2nd line staff who will ultimately use and manage the solution. This breeds resistance to change.

Culture, culture and culture. The success of the implementation depends significantly on the existing culture. the impact of any tech tool depends directly on the willingness of the people to implement and use it. If the culture is not fit for implementation, the impact will be minor. People need to understand the relevance of the new software to their roles and responsibilities. Consequently, communication is key.

Understanding the differences between the ‘as is’ and ‘to be’ processes is a good first step to mitigate risk of fail. Identifying the differences early in a project smooths the testing process by providing testers with scripts that denote the potential glitches or incompatibility upfront.

When implementing highly customized solutions especially like ERP, the internal team has no choice but to trust the external/vendor technical team. A major red flag is frequent turnover of resources of your vendor technical resources. Don't bother about management changes, technical resources especially from mostly outsourced centers like India are crucial. Sometimes, what larger companies do is hire these resources themselves especially when they discover that the resource is leaving the organization.

Agile approach can 100% help to solve this. Delivering system in small deliverables and run UATs to assure the software is working properly. You will also gather feedback in sprint reviews and reflect on lesson learned in retrospectives. This continuous improvement approach will reduce these errors and technical issues over time

Enabling support and other relevant staff to access and use the new software, will aid their understanding of the potential challenges the new software may bring. Utilising a pre-production infrastructure can be significantly beneficial in this case. It would also help to produce any operational and user related guidance and associated material to aid the transition. Including operational maintenance/ resilience details, etc., to aid resolution of any major issues.

Help everyday users develop a sense of uppercase vs lowercase issues. Upper are big, lower are small. Most organizations bleed out from hundreds of lowercase issues... so start with those.

Beyond aligning the new software to the organizational goals, objectives and vision, the software/system must either solve a lingering business problem or provide new opportunities that could define a niche/competitive advantage for the organisation. Hence the software must be built around value delivery. It is this value that would then be aligned with the Organizational goals, objectives or vision and not the software/system itself.

Shame will kill tech all day long. Leaders are ashamed of low digital maturity. Directors are ashamed of the data quality. Staff are ashamed of their low adoption.

You should review and, if necessary, redesign existing business processes to align with the capabilities of the new software. This may involve reevaluating workflows, roles, and responsibilities to maximize efficiency and effectiveness.

This challenge can be overcome using the Strategic Alignment Model (SAM), the framework defined in the ITIL methodology and it can be ensured that the tools that are used are well aligned with the processes and the business goals. Nowadays, we live in a rapidly changing environment, where technological advancements are being done quite often and due to time pressure, there isn’t enough emphasis on testing how the updates of the new tool interferes with other processes. Any alignment gap between IT and business is a critical issue for organizations, the biggest challenge remains to identify how it can be achieved strategic alignment between IT and business objectives in general.

Alignment is essential to selling the ‘why’ to the business. Why are we implementing this software? What business benefits will it bring? How will it change the way we work? These are all questions that will be asked and answers for which the business leadership and management need to be aligned upon.

This should be 1st on the list. Kotter’s model is where I always start - Before people can be open to change, they have to believe that Not Changing will be WORSE than all the pain and effort required To Change. If you’ve made it this far in your change decision but haven’t implemented a management system, you are now playing defense instead of offense. Rumors have likely started, and the fear and doubt is building resistance to the change you’ve barely started announcing.

The main misses of change management are blindly following one methodology rather than incorporating the best of each when needed. For example ADKAR is the most used, but that does not mean that every project that uses it will automatically be successful (although it will be better than not considering change management at all which is still surprisingly prevalent). For tech change specifically, consider using the adoption curve, go slow to go fast, start small and iterate, and for all communications consider the power dynamics of who is sending it - authority, expertise, peer.

In my experience scope creep is another challenge and sometimes it is simply harmless. This might manifest as an extra deliverable or two, while cumbersome, don’t alter the project in any significant way. But notable scope creep can undermine your project’s success by taking attention away from your project and may impact the budget. Stay focused.

Having leadership support and sponsor involvement is a key in successful change management. Gain active support from top leadership, as their commitment to the change sends a strong message to the rest of the organization. Leaders should lead by example and champion the new system.

Change management is the navigator steering the ship. A well-crafted change management plan is essential. It involves assessing the impact, communicating effectively, and providing the necessary support. This comprehensive strategy ensures that the entire organization sails smoothly through the sea of change.

Hyper-care sessions, team champions and quarterly refreshers. Coaches and leaders also need to ensure users are implementing the changes effectively and consistently.

User adoption is a key measure that determining whether a project has been successfully delivered. It is therefore paramount to stay in close contact with the user community to quickly react to shortcomings or perceived delivery misses. Success for sure must be celebrated. Similarly, understanding failures and quickly remediating is also a time to acknowledge the value of the user community and celebrate the resolution.

Stop saying adoption and say accountability instead. Create "who does what" and make sure leaders recognize users when they demonstrate the right behaviors.

Isso só será possível se os usuários estiverem envolvidos em todas as etapas, desde a especificação do novo sistema. Informar apenas depois do processo todo pronto vai dificultar a adesão

I think this is often overlooked in the planning phase of a new software implementation. To get users adopt the new software and use it to its full potential this might help: 1. before deploy it, not just train the people how to use it, but "sell" them the advantages of using it, and build all communication around the value proposition 2. use some gamification to create engagement and make the experience more fun and engaging, at least on the on-boarding process if anything else not possible

In my opinion, to designate key users is a vital point to take in account during all the phases. Usually they are early adopters and help to break down barriers. Specially when the project team leave the software running, they support users to understand system and solve differents daily issues.

Every software is a work in progress since there is no one size fits all. So implementing any software should only take place IF the management has allocated the budget and resources for continuous improvement and customization to allow work efficiency and effectiveness. Otherwise the new software will be more of a disruptive factor than an enhancer to the system and work processes.

Feedback loops are your best friends. Establish mechanisms for collecting feedback from stakeholders. Regularly ask for input to identify issues, opportunities for enhancement, and areas for improvement. This assures you to proactively identify if there's any change in organization's needs

Continuous improvement is the lighthouse guiding future journeys. I instill a culture of ongoing evaluation and adaptation. Regular feedback, analysis of outcomes, and refining processes are key. This commitment to continuous improvement ensures that the organization not only adapts to the current software but is ready for future technological tides.

Implementing a new software system's sixth challenge involves maintaining and improving it continuously. Unlike a one-time project, the software system is a dynamic asset that needs regular updates to meet the evolving needs of the organization and stakeholders. Overcoming this challenge requires establishing a vital continuous improvement cycle, including data collection, analysis, issue identification, solution implementation, and result review.

According to McKinsey research, software projects run the highest risks of costs and schedule overruns. Successful implementation starts with a clearly defined plan: understand what the software can deliver, carefully select - and prepare - the project team, anticipate employee needs, define a timeline, and agree on a budget. Not only ask yourself why are we doing this at the beginning of an implementation project, but start every follow up meeting by asking the project team: “Why did we plan for this and is our current approach still the right one to deliver on those expectations?” This forces you to reflect on your implementation path and avoid expensive and time consuming (over) customization.

Human Centered Design A key challenge of implementing a software system, is not understanding the human element within the implementation. Without a focus on understanding ‘what is in it’ for the people undergoing the transformation and communicating that message frequently, there is usually a significant amount of change resistance which leads to a lack of efficiency in adopting the new ways of working. By putting people at the middle of a significant technology transformation, it is easier to take change champions along on a journey of the software implementation. It also makes it easier and more authentic for people to buy into a change when their user experience has been factored into the software system implementation.

Here is what I can say Identify power users of the existing system and recruit them as champions of the new system Ask the power users the most frequently executed tasks and quickly get them familiarized with those task steps in the new system As a PM/BA you also need to become a power user. You don’t want the users to contact the vendor for every little query. You build a reasonable level of expertise within the team and reduce the downtime for the end users. This means you have to get hands on experience and there is no way around it The last point I made is very important because for the end user it gives a perception that you care. The mindset helps leads to quick adoption

Implementing new system software is a complex process, and the most challenging part often comes after completion when management decides not to use it, resulting in wasted time and resources. This can have a demoralizing impact and raise questions about decision-making. To mitigate such risks, thorough planning, stakeholder engagement, and post-implementation evaluations are vital. Success lies in ongoing refinement and understanding the system's impact. It's a cyclical process focused on organizational goals. Fostering open communication and adaptability is key to maximizing the value of technological investments.

Embed user testimonials in your communication strategy. I personally favor video testimonials. Show your employees their peers use the software and are convinced of its benefits.