Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
How to Manage Scope Creep in Mid-Range ERP Implementations?
Introduction
Project Scope creep - A major challange we all face in the mid range ERP implementations.
- Who plays a major role in setting the right expections?
- How will you arrive at your SoW during the presales level?
- How the handing over takes place from Presales to the Project execution team
- What makes the customer unhappy? - your bills on the Change requests? Or your strict processes?
Let us discuss / talk about the above 4 important questions which leads the road to project success.
Analysis
Majority of mid range ERP implementations fail due to the scope creep. I am not putting up a argument that only mid-range ERP's fail due to the scope creep. There is a thick line between the mid-range and the tier I applications. Let me put out my views on the 4 major questions:
1) Who plays a major role in setting the right expections?
The whole process starts from the customer inquiry. Inquiry can be in any form like Tenders, RFP, IT providers sales team, presales, telemarketing etc., Once the customer engages himself with the team and start the discussions on product functionality, cost, time and the support process, the presales expertise plays a major role in bridging the gap between the sales team and the customer. The Presales consultants role becomes vital in setting up the right expections. Moreover, the sales team inclusive the presales should give the right commitments. One of the research says "Truth plays a vital role in ERP implementation success". Yes, this is pretty much true and the most critical success factor for a project success
In continuation with the above subject - I would strongly recommend, the presales team to get the Functional consultant's on board during the important discussions and mapping the business process and setting up the right expectation. Before we could engage the customer and sign up our legal contracts / agreements, the POC needs to be done and identify the potential risks which may cause damage to the project during the execution phase. POC and mapping plays a major role in your win.
2) How will you arrive at your SoW during the presales level?
Million $ question, the reason behind, the presales & the sales team would be under termendous pressure in closing the sales cycle. This is where, the stakeholders loyalty and the commitments comes in to picture. Agreed, that the pre award SoW can't be a elobrated SoW. However, during the kick off meetings and handing over from sales to projects team, the functional / presales team should be (mandate) involved and set the customer expectation right and define the SoW. This will really help the projects team to work within the boundary and arrive at the SoW.
3) How the handing over takes place from Presales to the Project execution team
The process of project kick off - both internal and external plays a major role. As discussed in my earlier question, the presales / functional team should be made available in the process of handing over and define the clear cut SoW and the boundaries set. The pre-award SoW needs to be attached in your legal / agremments and should be signed off by all the stake holders. Involving the projects team in all levels would be a ideal suggestion. Again, if your processes are clear and agreed by all the stake holders, project won't give you any surprises during the execution.
4) What makes the customer unhappy? Your bills on the change requests? Or your strict processes?
- Various reasons include:
- Your delivery commitments
- Quality of your delivery
- Time frame & working within your budgets
- Managing relationships
- Adhering processes
- Your bills for Change requests
- Support process and commitments
Yes, these are very few examples of why your customer is unhappy. Also, during the execution phase, if you find a GAP between the customer core business process and the mapping, you tend to create a Change request. As soon as, the customer hears the word Change request, he would immediately start thinking about the budget and the other constraints. I have personnly experienced the issue of Changes during the execution which makes the customer most unhappy. However, even though there is a change request during the execution, the customer should be aware that it is a core document which clearly state the functional consultants understanding of the process. It is not a rule that all the change requests would be charged. This should be explained very clearly in your kick offs and the review meetings.
Post implementation support is a major challenge for almost all the mid range ERP companies. In most of the cases, the support team is detached from the Projects team during the execution phase. While handing over the project to the customer, the support process and the team would be introduced. However, in back of the customers mind there would be a question whether the support consultant is aware of their business process and how would the Knowledge transfer would take place ?? Yes, before the handing over process, and at the warranty expiry period, the support team should also get involved. This would also give confidence to the customer and the relationship would be built between the support team and the customer.
Apart from this, keeping the customer informed about the status of their support call/bugs reported / issues reported is a key success to retain your customer and always remember ERP implementations are gifts, if you maintain well, it would always pays you back! ! !
Conclusion
My recommendations to a Successful ERP implementation:
- Strong ERP implementation methodology
- Set the expectations right
- Strong functional Knowledge
- Speak truth
- Build strong relationships
- Keep your commitments
- Involve users and make them to participate
Techrepublic white papers
Events
- Marketing Thought Leaders: A Conversation with Julie Fajgenbaum May 25 @ 11 am PT
- The Do’s and Don'ts of Small Business Marketing May 29 @ 11 am PT







2 Comments
I have been on most sides of this issue. Purchasing an ERP system for my company's use; Implementing systems for other companies; Integrating ERP systems into other software; Selling ERP software to others.
In all cases re-focusing on two questions kept the SoW on track and made decision making much simpler:
1) Do these features/changes reduce the company's limitations that prevent them from greater productivity and profits? (If it is not reducing a measurable limitation, it is probably not worthwhile.)
2) How does this software/change improve the company's bottom line? (If it does not, it probably cannot be justified.)
These are somewhat 'harsh' and software companies squirm when having to answer them. BUT... When they CAN justify them, then the customer is also accountable for them as well. So 'Scope Creep' is always contained by this justification.
Excellent article Sekhar. I think a key challenge is understanding how to clearly define both project scope and product scope. I would like to share an article that provides detail examples of building ERP scope statements.
http://gbeaubouef.wordpress.com/2011/02/13/defining-erp-product-scope/
Answer This Question