The top 12 success factors for software implementation projects
Article by Gavin Halse
So, you invested in a software safety solution like IntelliPERMIT, great news! But you probably also know that many, if not most software projects fail to deliver the anticipated business benefits within the original budget and anticipated schedule. After purchasing a software licence, it is still necessary to tailor and apply the solution to solve a specific problem, and often this is where new problems are experienced. Successful software project implementations should be a matter of common sense, but sadly this is not always the case.
The good news is that some relatively simple and basic principles can be used to dramatically increase the chances of successfully implementing software. The IntelliPERMIT team at Adapt IT have highlighted our top 12 success factors below. These are the result of several software projects where our safety and operations management solutions were implemented at industrial customers.
This is a business, not an IT project
At the outset remember that every IT system should be implemented for a sound business reason. Technology might be introduced to support a business improvement process, or it might be a way to solve a problem that cannot be tackled in another way. But make no assumptions. Be careful to understand the business requirements carefully – and remember that there might be other approaches to solving the problem that do not require any software. Yes, you might have a good set of new tools and your new software might be very capable, but time spent researching and totally understanding the true business need will ultimately be rewarded with success. This understanding of the actual business problem is the responsibility of the whole project team and not just a few consultants. Spend enough time on this activity and make sure the whole team can clearly see the problem through the eyes of you as the customer before starting to implement.
IntelliPERMIT and FlexiLOG implementations can significantly improve operational risk and performance in a typical factory. They incorporate decades of learning and experience in the way the software is designed. But they are also highly configurable systems that can cater for nearly any situation. From the business perspective your situation will be unique and require you to define the business problem in a way that the project team can easily understand and act on.
Plan to plan, plan and then plan to update the plan
It is said that it is more important to plan carefully, and then execute poorly, than to perfectly execute a bad plan. Preparation is the key to success in most areas of business, and even more so when implementing software solutions.
Gathering clear requirements from all the stakeholders is very important. Upfront planning forces this to happen. Modern methodologies like Agile should not be an excuse for starting without a clear understanding of the business problem. Agile allows teams to iterate and reprioritise during the project, but it does not substitute for a clear understanding of the problem, nor does it mean that you do not need to plan ahead.
A suitable project planning tool is also important to communicate and get alignment on scope, timing and costs of the individual deliverables. Nothing is worse than trying to track a complex project using an assortment of spreadsheet lists and ad-hoc tools. If your project meetings feel disorganised, your tools might need to be improved. Your vendor should be able to recommend the right tools for your project needs.
Document the project charter carefully
The project charter sets out the business problem, the envisaged solution and the implementation approach. It serves as the starting point for the project and helps ensure there is alignment at the outset.
When developing your charter make sure that you involve all the relevant participants. Leave no-one out and ensure each stakeholder gets a chance to comment and contribute. This means that you need to identify all your stakeholders and you need to commit to keep each of them informed on progress.
A charter need not be developed from scratch every time. Feel free to build in learning and experience from previous projects. Work closely with the consultants – they can add enormous value at this stage. But be careful not to write up the charter in isolation from the business, you have to influence your internal stakeholders so that they take ownership, while at the same time helping to guide them as to what to expect.
The project charter might not resemble reality at the end of a project, and this is OK. There will often be many changes and compromises along the way as the business need is further unpacked. But a well thought out charter at the outset can help resolve conflicts and realign teams when it seems like the wheels might come off during the more intense project phases that follow.
Follow an established implementation methodology
A project implementation methodology is like a recipe, that when followed enhances the chance of success. While it is possible to develop your own methodology, using an industry standard is best because these incorporate best practices and learning, and third parties including contractors are probably already familiar with them.
A standard methodology is also important to help the team avoid assumptions and using confusing or ambiguous terminology.
If you want to enforce your own methodology work closely with the consultants at the beginning of the project to make sure that all aspects are covered and there is no confusion between the different approaches and terminology.
A typical project methodology will define several high-level phases and project activities. For example:
- Business case
- Solution architecture design
- Functional requirements
- Solution design
- Gap analysis and functional design for gaps
- Change request
- Technical design
- Test scripts
- User acceptance testing
- Training content
- Go-live strategy
- Roll out plan
- Support / SLA
Assemble the right team
Implementing business software is more than running “setup” on a server.. It is a multidisciplinary activity involving a team of experts. The different roles required in the team include business analysts, project managers, consultants, communications specialists, change management specialists, developers/engineers, technical support, trainers and IT specialists.
When putting together the project team keep it focused and simple – remember that individuals can take on multiple roles. A small focused team comprised of full-time members is often better than a large part-time team.
Because it will often be difficult to get full time participants out of the business owing to their other responsibilities, certain part-time roles are OK, provided they are clearly identified and have clear responsibility for their deliverables.
Identify the core project team which is a smaller group of people who will be involved from the outset of the project and also expected to support the system after handover. This team might include your “power-users” and some of the functional consultants from Adapt IT. Make sure these individuals will be fully available to the project because they will anchor the project as other members come and go during the different phases.
No team will be without internal conflict. Recognise that there will be different interests in each team that will need to be managed. For example, consultants that bill their time will often be accused of doing unnecessary work by other role-players who might be focused on cost containment.
Once the team has been assembled, it is critical to invest time in building the team’s understanding of the problem, their individual roles and the implementation plan. People will join the team over the life of the project. Never just assume that when people are later assigned to a team during subsequent project stages that they are automatically well informed. Continuous communication and team building is a necessary and important activity.
Document what is necessary, but hold back on documentation that adds little value
Together with the Adapt IT consultants, decide upfront on what documents are essential to the success of the project. Usually this will include the project definition (charter), the agreed scope and the plan. Many project documents are simply generated because it is assumed that they are needed and never read later.
The more documents that are created by the project the more maintenance is required and the higher the possibility of inconsistencies leading to errors. Remember that a picture or diagram is worth more than a thousand words. Strive for simplicity in documents rather than writing volumes.
The best software solutions like IntelliPERMIT and FlexiLOG are largely self-documented within the software itself. Critically evaluate the need for each document upfront.
Be careful of “it’s always been done like this”
Resistance to change is normal in any project. Often the most experienced stakeholders will object to change because of their previous experience, and they might feel threatened by a new automated solution. Learn to recognise the difference between simple resistance to change in your business and real concerns about the practicality of the solution. Respect and listen closely to the opinions of those who work every day with the problem and who are directly affected by the issues.
The goal of a software project is not to simply replicate and automate existing processes, it is to improve the processes themselves with technology. Your goal is to introduce these changes in a way that ensures commitment and buy in. There is a balance to be struck here.
The role of the project sponsor
Every project must have a sponsor who is a senior participant from your business. Most project sponsors are actually poorly informed as to what exactly is expected of them – it is important to have this role clarified and understood at the outset.
The sponsor is the main business stakeholder in the success of the project and will be ultimately accountable for its success.
Your project sponsor must have decision making power in the form of a mandate from the business. A sponsor who constantly has to go back for support or approval from another body is not adequately mandated – be sure to address this issue early on.
The sponsor must also be a leader and good communicator who can motivate and be able to simultaneously focus on both the task that needs to be done and ensure effective participation of the people involved.
As a leader, the sponsor needs to always be available to the project team. He/she should also participate in the relevant meetings, be they the steering committee meeting or weekly progress reviews. The sponsor needs to ensure that the business priorities are being met and that the project remains aligned to these. At the same time the sponsor needs to shield the project team from spurious issues from the business that could derail progress.
Appoint the right project manager
A project manager is expected to manage the project – in short this includes ensuring deliverables are met, there is full alignment in the team, that issues are addressed quickly and effectively, that obstacles to success are removed, that team members feel supported, that stakeholders are kept informed and that risks are understood and managed.
A good project manager needs to be able to make decisions and learn to (diplomatically) say “no” to both members of the team as well as external stakeholders from the business or third parties.
A good project manager will work closely with the sponsor and guide the sponsor in balancing the need to deliver the project against the changing business environment.
The project manager needs to set up progress reporting structures for the project team and these will involve regular review meetings. A fine balance is required between the need to regularly get together and align the team during project meetings and giving people the space to do their work and focus on the deliverables.
For larger projects, a project steering committee is also useful to consider change requests and ensure there is constant alignment between the business requirements and the project. The project sponsor and project manager are both necessary contributors into the steering committee.
A good project manager needs to recognise conflict, and together with the sponsor, act to protect the project team from external politics in the organisation and stay focussed on the agreed deliverables.
A formal PM methodology such as PMBOK or PRINCE is important – aligned with the implementation methodology. Most project managers are familiar with using one of these methodologies.
Remember that a project manager is not the same role as a project coordinator – the first is a leadership / management role, the latter is an important service function that assists with updating plans, securing resources and measuring/reporting on progress. We often see these roles conflated, leading to an ineffective and often overstretched project manager.
Control the scope carefully
During all projects there will be changes that affect the scope. It is important to have a process in place to evaluate each change and control the impact of the change on scope, cost, deliverable quality and schedule.
Not all change is bad. Changes can also improve the solution and/or reduce the costs. This type of innovative change on a project needs to be encouraged. However sometimes even the most innovative change needs to be put on hold, particularly later on in the project because it could require a lot of rework that might place the whole project at risk.
Remember that controlling “scope” refers to controlling the actual deliverables and not the activities themselves. If it takes twice as long to deliver something, it is a change to the budget and plan, not the scope.
User adoption needs to be nurtured
Business software involves users and they can make or break even the best software solution. It is therefore important to recognise the importance of user acceptance on the longer-term success of the new system.
Training is not the only tool for ensuring user adoption – in any case training is often too late in the process to be effective tool to get buy-in.
Incorporate user suggestions early on as far as possible to get buy in. User acceptance testing (UAT) should not only take place at the end, you might get some example mock-ups of parts of the solution built in order to get users feedback and input early on.
In all software projects following good change management principles is crucial. Good change management involves the following:
- Demonstrate your understanding of the problem and your commitment to the best solution;
- communicate the importance of the change;
- highlight the negative consequences of not doing anything;
- create a sense of urgency;
- empower people to act;
- reward positive contributions and
- constantly reinforce the benefits.
Strong support during go-live and handover
Remember that no software solution is static, it will continue to evolve after go-live. Constant improvements and enhancements are normal and to be expected going forward. This means that you should focus on the minimal viable solution as a priority in the project scope; and be prepared to defer “nice-to-haves” to later when they can compete with other priorities. Clarify this philosophy of a minimum solution and ongoing enhancements with the customer when developing the project charter.
A service level agreement (SLA) is a useful technique to ensuring elevated support by the project team after go-live to build in enhancements.
“Phase 2 items” should not be left unattended at the end of the initial project. It is good to have a list of these which can be prioritised after go-live and handover.
After go-live measure benefits and reinforce these successes with the users of the system. Encourage ongoing suggestions for improvements and set up a process with the customer through which these can be prioritised and acted on.
Having decided to invest in a software solution it is important to also understand the implementation process. IntelliPERMIT and FlexiLOG are powerful tools that can certainly deliver major improvements to safety and operations performance. The flexibility of these software solutions makes it that much more important to adapt the right implementation approach. Discuss this approach upfront with your Adapt IT consultant. Project implementation should demand as much attention as the initial software selection.
A successful implementation will also impact the ongoing support and maintenance costs.
The business benefits of a successful project will be enhanced, conversely a poor implementation can actually destroy value. It is therefore very important to consider the implementation carefully upfront and ensure you are aligned with the vendor on your expectations.
To learn more about IntelliPERMIT and FlexiLOG solutions please contact the IntelliPERMIT team at Adapt IT.
You might also enjoy
In this article we will take a look at the concept of a “Safe System of Work”, and how this relates to overall operational risk management and the permit to work.
Enterprise risk is often grouped into categories such as operational, financial, environmental and reputational risks. But there are many overlaps and dependencies between these categories.
Safety management systems rely on the control of formal safety documents that need to be easily and reliably accessed when it matters most, while planning and executing work in dangerous plant areas.