Avoid lying to yourself

Why should you spend time understanding the dynamics of a complex digital project? And why should you increase your readiness and flexibility as an organisation before choosing an ERP system? Find out in this blog post.

Either you've already read my first blog post, "Why nobody really cares about an ERP project" and have naturally come to this post, or you've clicked in via a post directly. If you are in the former category - thank you very much. You haven't given up after reading my subjective outpourings! If you've clicked in directly here, welcome and hold your horses: I'd recommend you start by reading my first post via the link above, as that is where I talk into why preparation is so important before launching larger and more complex ERP projects (and digital transformations for that matter). Should you already belong to the 'true faith' and very well know that good and proper preparation is important, go on from here.

This post is going to be relatively 'analysis nerdy' so if you don't want to bother reading all the intermediate calculations, have a look at the figures and skip to the last paragraph, where I reiterate why preparation is essential and how a target vision is an important catalyst for a successful ERP project.

As mentioned earlier, an ERP target picture is "a fundamentally structured and managed process that drives a collection of data, facilitates a series of key decisions, and provides a series of artifacts for the decision-making process required in an ERP project".

OK. Thanks for the management consulting definition, you might be thinking. So what does it really mean?

Basically, it means establishing a knowledge base within the company that makes you clear about what you want to achieve through the ERP project and a realistic assessment of how mature you actually are on a number of key parameters before you get started.

As I have described earlier, I do not believe that the typical ERP software selection process can deliver the maturity of business readiness required to succeed with an ERP project (unless you incorporate the target picture process as a component of it).

Furthermore, I believe that the success of an ERP project depends more on how you manage assumptions and risks than on which system you choose (tough claim). Most modern ERP systems can do pretty much the same thing, so unless you are a very large and complex company, with very unique requirements, the 5-6 most widely used platforms will be able to do the job 90% of the time. 

Above in figure 1 I show where I see the 'target picture' fitting into a typical ERP project process. It is thus in the middle between a recognized need and the actual practical selection process - and thus enriches both the choice of system vendor and system, but also the whole parallel mobilization and ongoing project management, as well as the benefit-expectation and realization the project should bring about. 

You can skip these steps and take them in a 'light-version' as part of a system selection process. Especially for smaller projects, this can make a lot of sense. However, for larger complex projects I would not recommend it. Most literature points to the same challenges with large and complex (digital) projects and can typically be summarized in some of the following challenges:

1. Poor management buy-in
2. Poor target management
3. Poor risk management
4. Poor requirements management
5. Over-optimistic estimation
6. Too long process
7. Poor choice of supplier
8. Poor management of change
9. …

And so on, and so on.

If you ask the professional literature, you can see that deep in the belly of failed projects lies a fundamental challenge of continuous misinformation based on bias. Bent Flyvbjerg, professor at ITU and Oxford University and acclaimed author and editor of some of the most thorough analyses of the nature and causes of project failure, calls this phenomenon 'Survival of the Unfittest', because the projects that exaggerate benefits and underplay complexity, risks and costs are the ones that get the green light.

This starts right at the planning stage, where over-optimistic benefits and estimates are carried into a project execution, and as a result objectives and frameworks that were completely skewed from the start have to be continuously defended. The root cause of this pattern is thus not a lack of implementation, estimation or risk management models, but much more a reward system and a 'psychology' that encourages this type of misinformation to thrive.

If you want a much better and more thorough review, you can find more information in Bent Flyvbjerg's publications and a good summary in Morten Münster's post here.

My contention is that one of the simplest ways to counter misinformation and misrepresentation is to create a common, transparent knowledge base based on a thorough factual representation of the company's objectives, its starting point for the project, and what it will realistically take to achieve those objectives. Couple this with available statistics ('base-rates', as Flyvbjerg calls it) of similar projects' data, as well as a conscious and clear recognition of all types of bias, and we're in business!

Sure. And good, experienced project managers are essential to the success of ERP projects. There are also many vendors [and consultants, ed.] who can promise you that their experience should mitigate all the challenges I've listed.

But that doesn't shift responsibility for doing your homework as a business. All my experience with digital transformation projects shows that as a senior executive, middle manager, project manager, sponsor or participant in an ERP project, you need to ask yourself the following 3 questions:

1. why do you need a new ERP system,
2. what is your current organizational maturity and ambition for the future and
3. how do you expect to implement the project?

If you do this job thoroughly and properly, it is much harder to artificially inflate gains, hide biases and immaturity, and ignore risks, thus lying to yourself.

That process, of course, needs to be supported by focused change management that ensures learning, course correction and transparent reporting are de facto. And read that sentence again: Learning. Course correction. Transparent reporting. In other words, you should be allowed to think again. You should be allowed to make mistakes and correct them. And risks and progress must be reported honestly and transparently. 

Ah yes, the promised land. An agile ERP project. Immediately, this process is really difficult because the ERP system is relatively pre-defined as a framework and a too agile approach can result in too many development hours and delays.

I feel a bit like good planning always pays off. The 'just get started' thing and then build the system based on a traditional agile approach with a product backlog ('thin requirements specification') and then run stand-ups with business and development, can work fine if you as business are relatively clear on objectives and requirements.

But most suppliers today will claim to work partially agile in the development phase - but this requires that the customer both understands and is well trained in the agile collaboration and development process and that they are really well prepared in terms of requirements and success criteria, and that the management and board are OK with not knowing the exact framework for deliverables and costs.

Let me quote Bent Flyvbjerg again, here from his article in Harvard Business Review about super-architect Frank Gehry's ability to always deliver his gigantic construction projects on time and on budget:

”Gehry’s process asks much of everyone involved. It also consumes a great deal of time. For project proponents eager to have something to show for their efforts—and get to the finish line—extended planning can be frustrating, even unnerving. For them, planning is pushing paper, something to get over with. Only digging and building are progress. If you want to get things done, they think, get going.

This sentiment is easy to understand. But it is wrong. When projects are launched without detailed and rigorous plans, issues are left unresolved that will resurface during delivery, causing delays, cost overruns, and breakdowns. A scramble for more time and more money follows, along with efforts to manage the inevitable bad press. With leaders distracted in this manner, the probability of further breakdowns—more scrambling, more delays, more cost overruns—grows. Eventually, a project that started at a sprint becomes a long slog through quicksand “

Think slow. Act fast. OK?

Then I think the point is hammered home. We need to move on in the process of getting a detailed ERP target picture.

In the next blog post I will go into detail about the content of the 3 questions above 'why', 'what' and 'how' , and the approach to get the answer. If you haven't given up yet, carry on reading!