(Update as for year 2018: it is also valid for SAP Activate in terms of a Backlog means result of fit/gap analysis)
…especially the potential problems can bee seen here!
Remark: this article is mainly about the ERP scope means all integrated transnational components thus may be not valid for some not transaction components like BW or any BI solutions.
The blueprint is a very critical point of the ERP implementation project, building some kind of the fundamental for the project and deployment of ERP. That is why the blueprint has to be carefully prepared, good understood, considered and accepted by all responsible stakeholders.
However in practice often as the most important thing at the end of Blueprint phase is rather… the milestone deadline and unfortunately not blueprint quality. That’s clear – in fact this is the first project's phase and everybody likes to achieve the first success, celebrate and share congrats! This is also very important to create this kind of momentum.
The mood on the project is at this time being very good, often fraternal and nobody dares to raise any issues - especially project manager who as the first looks forward to enjoy. Usually the problems are still hanging in air so seem to be easy to resolve soon thus usually the problematic points in the blueprint are left for later. That may backfire later a lot!
I can understand it and must admin very often I am in such a situation. But there is a kind of red line which must not be crossed - these are some sorts of fundamental things and also scale of the potential change after the build-out has started. So change management in this sense of changing the scope and content of the project is something common and known in many methodologies like PRINCE2 but definitely there is always project manager responsible in person to accept and also apply regime to mitigate any risks and consequences under below described conditions.
In ERP there are many cross dependencies and many different teams working in the same time. If we left vital things open or/and change them in uncontrolled manner it will get as a snowball and eventually unstable. Besides this is very hard if not possible to foresee all the potential consequences.
All projects with troubles had something in common: weak blueprint means with open issues and controversial and frivolous project management. In fact all the potential troubles on projects are already to be seen and predicted by evaluation of the blueprint.
Again the problem is that bad results as consequences of dirty project execution are separated by long time from causes in form of weak blueprint - the weak blueprint at the beginning of the project can sometimes backfire at very end of it. Of course we have tests on the way but usually snow ball caused at the beginning draws to cutting up the time for test for the sake of next milestone and we are close to a collapse...
The problems occurring in later stages of the project are damaging the mood – nobody recalls then the good mood by the blueprint closing. Especially the customer is claiming the vendor is not competent and the vendor is claiming that the customer is changing specification and thus is breaking the rules. It is clear that the only one responsible is the implementation vendor – the management of the project is on the vendors side and if customer fails to deliver they have to raise the flag or even stop the project.
SAP ERP is, as of my strong belief based on experience, very tolerant in implementation. The embedded implementation tools and very good ASAP/ SAP Activate methodology are securing the implementation process. However if the project manager and/or other stakeholders are bypassing the steps and quality gates there is no “artificial intelligence” inside to mitigate them! In this circumstances it may produce a situation with the higher risk for the project and potential problems.
Please note that changes made after the respective phase closing are often made without the right consideration – in fact outside the quality gate. This especially is critical by ERP where the data stored and transactions using and changing the data are highly crossed through the whole scope and project teams are from various business units where the communication and integration between teams is a big issue for the implementation.
Changes in one area may influence many other areas. Project flow “orchestrated” by ASAP requires the right audience and right consideration on every step on the project. But in case some specification is changed already after the close of a blueprint phase it may be not considered right by all stakeholders. Especially in the situation of many changes in many areas – even not significant as it may be seen individually – can reach the critical mass and cause troubles.
EXAPLE: Implementing Retail functionality with change (extension) of characteristics of the goods (seeming not significant) may lead to significant grow of the data size that can be critical in both terms: transfer and storage. When not evaluated correctly may lead to disruption of the business – and sometimes as you may read about “ERP failures” is.
In fact the right remedy for above described problems is very simple and cheap:
1. To prepare the blueprint very carefully in order to ensure covering the full scope of the project and understanding and commitment by all responsible stakeholders;
2. Call an external (from outside of the project) project manager to make an audit / project review. Always somebody experienced with fresh look can see open issues or not solved problems better.
It is much more important to have the blueprint of best quality than to have it on time. In other words – some delay caused by blueprint preparation cost significantly less than the potential troubles caused by the wrong blueprint.
During my work by SAP the project audit by the end of blueprint phase was practiced with always very good result. Usually people involved – even project managers – are loosing a big picture view. That’s normal - and may occur especially in the rush time of closing the phase.
Read more about the use of AGILE on SAP ERP implementation:
http://scn.sap.com/community/asap-methodology/blog/2012/10/14/i-am-sure-agile-is-not-for-big-sap-erp...
With best Regards,
Waldemar Faliński
PS. Dear Readers of this article if you find it usable for you please award me wit “like” or even rank with stars!
