“There are known knowns. There are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. There are things we do not know we don’t know.” When Donald Rumsfeld, US Secretary of State for Defense in 2002, said this, he was almost universally lampooned as many people initially thought the statement was nonsense.

However, careful examination of the statement reveals that it does make sense. Moreover, the concept of Known/Unknowns existed long before Mr. Rumsfeld gave it a new audience. It has since long been used as a model for risk assessment, and as the illustration below shows, it fits perfect to classify four types of ERP projects.

Meeting the customer requirements well within the timeframe and budget is always the goal of professional implementers. In this endeavors, projects can take four archetype categories. In two dimensions, they tell us about the amount of clarity that the customer has of what s/he wants. 

On the Y-axis, we have capability requirements, what the application should be able to accomplish. On the X-axis we have ease of use issues, with which ease the application can be understood and used. Requirement Specifications is not enough because for each capability requirement are a variety of possible solutions, each solution involves making design decisions that affect usability.

This four-category classification helps us prepare for any new project and everything that goes with it (commitment, staffing, project management, change order procedures, and more). You may prefer an agile methodology; working iteratively and incrementally. That is fine. In most customer cases, however, you will never get the green light to start a project without a budget and schedule – which forces you to examine the scope of the project. To say something clever about time and money you need to know what the project is supposed to deliver.

Two Archetypes of ERP Application Projects
At each end of the spectrum, there are two different types of ERP application projects. One is vanilla (in information technology, vanilla is an adjective meaning plain or basic), the other is a pioneering project.

• The perfect example of a vanilla project is to adopt a cloud application as-is; go live without any modifications, additions, integration and installation activities.
• A pioneering project means developing an application that hitherto does not exists. That does not mean everything needs to be developed from scratch. You will for sure reuse many existing components. Nevertheless, to do something new means, as a starting point, that there are many unknowns that needs to be made knowns.

Why would an ordinary company involve in a pioneering application project? Of course, they should try to avoid it. If you can find an off-the-shelf application adequate for the job, that is the best solution. Notice the emphasis on the word ‘adequate’. Adopting an inadequate application can cost more and take longer time than developing a new one (using modern tools). Doing nothing may not be an option as we are in the midst of a transformation where everything goes digital on mobile devices.

I have seen firsthand how frustrating and painful application development can be. However, I have also experienced how development happens fast and simple toward delivering powerful applications driving significant business value.

The secret to successfully implementing new ERP applications (regardless of if it concerns a commodity, new application development or something in between) is to eliminate all unknowns. Simply, do not let them in before the project is completed. How realistic is that?

In the real world, you must allow exceptions to prove the rule, but that is what it is: exceptions. Most important to eliminate the unknowns is to specify the deliverables thoroughly and then have the users endorsing the new solution. The quality of this work depends on the ability to imagine the new solution – which in turn very much depends on the quality of the interactions and skills of the people involved and their ability to describe the new solution.

When the project have got the green light and is on the run, you still have to live with some unknowns – while you concentrate on delivering what we already know. You can do that, because you know that perfect is an illusion – so what you did not do perfect last time, you do better next time. That is how better can make you close to perfect. 

I know that this approach works, because I have used it many, many times. If you know where you are going, you eliminate the risk of ending up somewhere else.