Eight pitfalls to avoid in your IFS ERP project

Successful IFS ERP projects have three key ingredients: business change, project delivery, and internal resourcing and support.

But even with the most careful planning, it’s crucial to be vigilant to avoid your IFS implementation or upgrade going off track, running into trouble or even failing.

And the earlier you know about a potential issue, the better, so you can deal with it before it has a serious impact on your project delivery, and on your business.

Adrian Radue is a transformation leader, strategist and project manager, who is experienced at bringing about business change. His greenfield IFS ERP projects are seen as textbook by industry leaders, and he’s the go-to expert for realigning and reviving projects that are already in flight and in difficulty.

In this blog, Adrian reveals the eight early warning signs to look out for, so you can steer your enterprise software project away from trouble and back on track. Plus, he offers three best practices for IFS ERP implementations and upgrades.

Eight pitfalls to avoid in your IFS ERP project

1. Treating the IFS ERP implementation as an IT project

ERP implementations transform the way people work across departments. They’re not IT projects, they’re business change projects. You need leadership around the business change and effective change management to make it work. If the business thinks it’s an IT project happening ‘over there’ you’re going to hit a wall when you need business decisions about how the finance, HR, production etc. modules need to work. And an even bigger wall when people try to derail the new system and stick to their old ways of working.

2. Presenting rose-coloured views to management

Project sponsors take their perspective from project managers and don’t generally talk directly to people in the project teams on business change, technical delivery, and internal resource and support. Those three teams should be on the same page. It’s a very good indicator of the ill-health of the project when everyone has a different idea of how things are going.

Rose-coloured views being presented to leadership can be the first solid indicator something isn’t going right. And this comes down to culture. Open communication thrives in high-trust environments where people focus on solving problems. Communication suffers in low-trust environments focused on whose fault it is. Levels of trust directly affect speed and costs in business. When trust is high everything happens faster, to a higher quality and lower cost.

3. Being unclear about who’s doing what, when and where

Does everyone on the implementation have clarity around who’s responsible for which part of the overall implementation? Do you have the right technical resources? Do the workstream leaders understand what their role is, or are they cherry-picking what they would like to do?

Your workstream leader may have a very good understanding of IFS and projects, but are they reaching out to the business and bringing them on the journey? If that doesn’t happen there’s a disconnect.

A clear and common understanding around role, responsibility, team resource and capabilities is essential to a successful IFS ERP implementation. Everyone on the project should be accountable for acting in the best interest of your business, not carrying out their tasks in isolation.

4. Allowing business decisions to pile up

The project plan shows progress but there’s a stack of outstanding business decisions that are either being made by the workstream lead or otherwise haven’t been clarified with the business team.

The workstream lead is responsible for preparing the business for process change, and a symptom of unpreparedness is usually unclear business decisions.

Stage gate reviews and sign-offs are where you review the delivery of a particular milestone in a 360-degree context and decisions are made about taking a step back and fixing things in order to move forward. Without these formal reviews by the programme board and its business representatives, individuals kick cans down the road. By cans I mean major outstanding business decisions, and this just compounds towards the later part of the project.

5. Focusing on time, scope and cost, but not quality

In every project I’ve been called in to help there have been testing gaps, and a reluctance to stop, evaluate and fix issues as they arise. Major testing events on the project will highlight a set of exit criteria that need to be green or ticked before people move on. But when everyone is fixated on project delivery, the drive to meet time, scope and cost is so great that the qualitative review isn’t taken into account. This comes back to the triad of business change, project delivery, and internal resourcing and support. All the elements need to be balanced.

When everyone is fixated on the project, the drive to deliver in time comes at the expense of quality. The qualitative review isn’t taken into account.

6. Putting too much energy into being agile

The project methodology can be one of your earliest indicators there’s trouble ahead. Everyone wants to be on the bandwagon of agile, scrum, wagile, because it’s the best thing since sliced bread and no-one gets fired for being agile. In fact, the best way to run an IFS ERP project is to understand the mix of project methodologies and utilise all of them.

Good old waterfall, done properly, is an important component of establishing solutions through to test. Agile by its nature is great for solving some problems but having an entire team only doing agile can mean you only hit issues as you hit issues. Whereas with waterfall you are forced to predetermine all the components, which sets you up for proper testing and proper acceptance throughout the project. In waterfall you’re forced to think about change, you’re forced to document your solution.

Every time I’m pulled in to help a project, I take them back to the beginning of the waterfall; a business decision plus IFS, functionality plus customisations, plus access, plus data is equal to signing off. A single-minded focus on agile can be an early sign the project’s doomed.

7. Not considering the future IT support

Every project I’ve been brought in to help has had a considerable lack of resource and focus around the IT support element. For example, if you want to do a test, you’ll need a new environment and you’ll need it copied. You’ll need access and to do that you’ll need database administration. You’ll need technical people and if you have too little of them, they’ll all be focused on data migration and permission set construction. So, your environment management and evolution lags behind the rest of the project. Uncoordinated activity around how your IT support resources are intertwined with the project, and the change now and how they inform the change of the future, is a red flag.

8. Downplaying the importance of the finance team

Finance permeates almost every area of functionality within IFS ERP systems, so if the finance team aren’t involved enough then you’ve got a project with a problem. Because then you’ve got non-finance people setting up elements of the system without taking into account financial rules and regulations.

3 best practices for IFS ERP projects

1. Manage the business change, the project delivery, and the internal resourcing and support

Businesses use enterprise resource planning (ERP) systems to manage and integrate essential functions like finance, HR, services, production, manufacturing and supply chain. IFS is a leading enterprise software solution provider for companies in manufacturing, construction, engineering, energy and service industries.

IFS ERP implementations are company-wide projects that change the way people work and introduce new business processes. There are three key elements: the business change, the project delivery, and the internal resourcing and support. All three need to be brought together and managed as a continuum.

Your essential project team will include key business users or subject matter experts, business change management and service transition management, as well as technical and functional IFS consultants.

2. Understand everyone’s responsibilities

You’ll likely have an IFS partner, functional and technical consultants, project managers and a business team on the project. It’s vital you understand the impact of your people’s responsibilities, the limits of your partner’s responsibilities, and you’re realistic about the resources and capabilities in your own team.

3. Put your best people on the project and backfill their positions

There are 10 roles to fill on any IFS ERP project, and these can be a mix of your team and a trusted partner. One person can transition between roles, but if you’re expecting your finance manager to lead on business change, represent the finance team on the project and do their day job then you’re heading for trouble.