{"id":1140,"date":"2015-05-19T23:43:57","date_gmt":"2015-05-19T21:43:57","guid":{"rendered":"http:\/\/peterbj.com\/?p=1140"},"modified":"2017-12-09T21:12:12","modified_gmt":"2017-12-09T20:12:12","slug":"known-and-unknowns-in-the-erp-quest-for-success","status":"publish","type":"post","link":"https:\/\/peterbj.com\/?p=1140","title":{"rendered":"Known and Unknowns in the Quest for Predictable ERP Projects"},"content":{"rendered":"

\u201cThere 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.\u201d 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. <\/span><\/p>\n

However, careful examination of the <\/span>statement<\/span> 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 <\/span>assessment,<\/span> and as the illustration below shows, it fits perfect to classify four types of ERP\u00a0projects.<\/span><\/p>\n

\"\"<\/a><\/p>\n

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.\u00a0<\/span><\/p>\n

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\u00a0the 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.<\/span><\/p>\n

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 \u2013 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.<\/span><\/p>\n

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