Anyone in the know about IFS ERP implementations will tell you these projects are just as much about the people as they are about the tech.

In this blog, independent ERP consultant Alan Price reveals his observations from his many years leading IFS project teams.

Alan, a project management specialist, explains:

• Why it’s important to recognise the different personalities in project teams
• How project managers can help people cope with uncertainty
• The benefits of psychometric testing and strategic analysis
• Why understanding an organisation’s structure is a key success factor in ERP implementations
• Plus, he shares his tips for successful IFS project management – and his advice for customers of the software

Recognising the different personalities in IFS project teams

The big thing I’ve noticed while working on IFS projects is that while people are very different, there are patterns you can spot. People who work in certain professions within an organisation tend to have similar personality traits.

I wasn’t aware of these patterns until I saw how people coped with the uncertainty that comes with IFS implementations. Because when you go through these projects, there’s uncertainty, especially at the beginning of the project. You’re bringing together people on a team who may never have worked together before. Some of them might not know what the different project phases are or what a good implementation looks like.

It’s the responsibility of the person leading the implementation – and that could be the project manager – to guide the IFS customer through that process.

If you’re a consultant leading the project, there are lots of supporting tools to help. But you should bear in mind there are certain parts of an organisation that are more used to dealing with uncertainty through their work – and other parts that aren’t.

Coping with uncertainty on ERP projects

Let’s look at the two extremes in a typical organisation:

• The people who work in sales tend to be absolutely comfortable with uncertainty. That’s because they never really know what they’ll face in their day-to-day work, when interacting with different customers and prospects.
• The other end of the scale tends to be the parts of the organisation that are very structured, so typically those who work in regulated areas and must have a really good attention to detail. They must conform to regulatory or legal requirements. So, from a personality point of view, they’re used to working in an environment that’s very much detail orientated.

As a consultant, you must engage with the customer to understand what their requirements are. In most cases they’ve bought a system but there’s uncertainty about what it’s capable of doing. The project might involve bringing into one system the capability that previously existed in several systems – or perhaps introducing new capabilities. And for people who can’t cope with uncertainty or find it difficult, that can be stressful.

How can the project manager guide the whole team through each phase?

I remember working on a project about 17 years ago and I noticed the finance team members were struggling with the uncertainty in the early phase. And that made me think: what can we do to support the team to get through this? Those team members don’t necessarily know how to engage and move forward effectively. And that can be another cause of stress, because normally in their jobs they’re in control and they know what they’re doing.

But as a team moves through a project, there’s a point in the middle I’d say is the team’s sweet spot. It’s where everyone starts to function well and produce what they need to.

Then, as you get towards the end of the project, the detail is much more of a requirement. So, the team must document processes and create test scripts. They must be very prescriptive in what they do to verify and validate the solution. And that’s when the people who struggled at the start begin to thrive. Meanwhile, the ones who were more comfortable at the beginning, such as the people in sales, now begin to struggle. It can be very difficult to get the guys in sales and commercial to do test scripts and all that good stuff to document it.

So, as the project manager, you must guide your team through the different phases of the project. Think about what countermeasures you can put in place to support those who struggle in a particular phase. And that isn’t in the standard methodology for software projects; it’s something that comes through practice and experience and having your own feedback loop to see how different strategies have worked.

Share worked examples

Each time you launch a new phase in the project, you can share worked examples of what the team must go through in that stage. What are the tools, the methods and the processes for completing the activity and documenting it? Reassure the internal team members that what they bring to the table is knowledge of their job and the company’s processes. Whereas what the consultants bring is their knowledge of the new system capability. As the project manager, you’re showing everyone how to get from the beginning to the end of that phase and what they should be producing at the end of it.

But there’s more to it than that because you then need to show, phase by phase, what the context is and how those deliverables will be used in subsequent phases.

How psychometric testing and strategic analysis can help

I was on a project where I had an opportunity to do some psychometric analysis on my project team. I was expecting the analysis of the personality types to reinforce my observation that the ‘completer finishers’ (those who focus on the fine details) would be more on the finance side, while those who are more creative would be on the sales side.

And that turned out to be true, because when the analysis came back, everyone recognised themselves and their colleagues.

You can use this analysis to develop strategies to positively engage team members based on their personality type, so you can get the best out of them and benefit the project. They’ll get a sense of success, rather than stress and failure.

Managing change

If a customer is moving from a very old system to a modern ERP, their internal people might be used to a certain way of working. But the new system means they must learn a new way of working. Managing that change can be difficult for businesses.

Also, projects can be quite long; potentially about 12 to 18 months. So, internal team members might get out of touch with what’s going on in their department, which means uncertainty about what happens to them at the end of the project. They need to be reassured about what their role will be and where they’ll be in the company. And that involves some planning from the organisation’s management team.

Ideal IFS project team: mix of external specialists and internal representatives

I’m an outside specialist in ERP project management.

There are roles that are needed internally, such as a test lead. These don’t necessarily have to be full-time tasks, but the business should assign those roles and responsibilities to the right people from within the organisation.

There must be ownership of the solution by the business.

What are the different organisation structures?

The two organisation types I tend to see are:

• Command and control
• Collegial

With command and control, one person makes all the decisions and people just have to follow. There’s not much discussion. You tend to get this type of structure in the oil and gas industry, manufacturing, and other similar types of organisations.

Whereas in a collegial organisation, more people are involved in the decision-making process. You often find this structure in the professions, where people are members of a professional body.

How does an organisation’s structure affect a project?

When you’re trying to move forward as a project or programme manager, it’s important to know and understand the organisation’s structure. You need to know how quickly, and how well, the business makes decisions – and this is one of the issues that goes on my ‘risk register’ for IFS projects.

Command and control organisations tend to make timely decisions. However, they’re not always the right decisions because they’re not consulting everyone.

Meanwhile, collegial organisations usually take their time. They’re more likely to be right, but it can sometimes be frustrating when you’ve got a deadline and you want them to make a decision.

That pattern can also manifest itself culturally. For example, I worked as a project manager for a company in Norway. They are very much collegial in decision making. And even though the business was in the shipping industry, which you’d expect to be command and control, there was actually a lot of consultation and collaboration. In fact, I was told they wanted someone who wasn’t Norwegian on board because they wanted to be told what to do – to get the project done!

Use your knowledge of the organisation’s structure to help the project succeed

There are different ways to use this knowledge for the benefit of the team, project and customer.

Sometimes you might just need to continually give tighter deadlines to those who are collegial, knowing they’re going to take a bit longer to make decisions.

But there are other factors. For example, when I join a project, I always say, ‘We either all succeed together, or all fail together.’ So, I use metrics all the time in my reporting. Everyone is measured in the same way; nothing is hidden. The progress of performance is published weekly with targets and whether those targets have been met or not. And if they haven’t, what will they do to get back on track?

With the collegial organisations, the internal people perhaps don’t want to be seen to be the ones holding everyone up. And with the command-and-control companies, they don’t like to be seen to be making bad decisions, so rework for those guys is something they don’t want to see much.

Where does your interest in strategic analysis and organisation structures stem from?

It goes back to when I was an apprentice electrical and electronic engineer. I worked in the maintenance department of a company where my role was to fault-find. I developed a keen sense of observation and enquiry, so when I see a pattern, I want to know why it’s a pattern. I want to analyse and understand it.

How long have you been working with IFS software?

For about 25 years, and I’ve been an independent consultant since 2005. I’ve worked in pretty much most of Europe and in the Middle East, the U.S. and Korea.

What are some of the reasons for IFS projects getting into trouble?

I’ve been called in to recover programmes that are late or overrunning. The most common reason they get into trouble is because they’re not following the right methodology for an IFS implementation, and this goes back to that key issue: uncertainty.

For example, there are some ERP systems that have pre-canned security rules ready to go when you install the software. But IFS doesn’t. So, you can’t do the security part until you’ve developed the IFS solution.

If you don’t follow the right methodology for IFS, you’ll be trying to guide people to do things the system isn’t ready for. And that just causes more uncertainty.

Other tips for successful IFS project management

Don’t rush in. You should observe and ask questions. You need to understand how the organisation works, so you can use its strengths to get the implementation done.

Cultural change can take at least a year, and that’s driven from the top down. If you come in as a project manager on an ERP implementation and expect to change the culture of your team so it works in a certain way, that’s never going to happen. You must adapt to the capabilities and strengths of your team.

Advice for customers of IFS

If you’re a customer, you might not have a full appreciation of what’s involved in an IFS implementation. It’s important you don’t expect the IFS project to be run in the same way as a SAP or Oracle one, because there are key differences in the detail of the methodology.