Project Scope Creep (PSC): An ERP Implementation Pitfall!
Project Scope Creep (PSC), often times is a fallout of poor business requirement definition. It is a concept that if not properly managed can result in failed ERP implementation. PSC occurs as a result of new business requirements springing up from the end-users while system implementation is already started - ongoing. The end product of course is uncompleted ERP implementation. Also, project owner - client non readiness can be the cause. Unavailabity of infrastructures on client site can be responsible for PCS. These infrastructures can include, but not limited to hardware and remote connectivity.
However, is an ERP implementation ever completed? It is debatable topic and can represent a subject for another discussion. The emphasis here is that work - customization and configuration of the system must terminate (if temporarily) at a certain predefined time so that the system can be used for processing live transactions.
The cause of PCS is double-faced. The system owner(s) or the consultant can be responsible. It is understandable and of course pardonable when the system owners are the cause of PCS as opposed to the consultants. This is prevalent in an environment where users are not ERP system savvy. The more they get to know about the system offerings and capabilities, the more their demand for additional functionalities. I have learnt that additional system/business demands are made during process and task trainings.
Consultants too can be guilty. A number of consultants don't know where to put a full stop on a project. This might be as a result of not properly understanding the system to be configured or spending more time than necessary on customization or reconfiguration. It's not a matter of bowing out when the ovation is loudest but when due and timely.
The implication of this phenomenon, irrespective of the initiator is that it is expensive in terms of time, value, resources and ROI for both parties. Furthermore, the downside (if it has any upside at all) can be grave. This is because the more the end user keeps seeing the consultants on site more than expected, they tend to feel insecure, uncomfortable and lack confidence. The perception will then be "will the system work after all" or "there are still issues".
By and large, it is expedient to prudently manage PCS. The list of steps that can be taken to guide against PCS is inexhaustible, the following recommendation represents a few.
1. Have a clear cut project plan and implementation model.
2. Carry out and document comprehensive business process definition and requirements.
3. Carry out and document objective business process re-engineering.
4. Adopt a clear cut strategy for handling additional business process requirements, preferably a post go- live strategy.
5. Carry out process workshops for process owners prior to start of system implementation. Processes can include Quote to Cash, Procure to Pay, Plan to Produce, Goods in - Goods out and financial management
6. Identify system limitation and inform end users via project owner.
7. Objectively align your consultant's expertise with the business needs especially as it relates to complex customizations.
8. Develop a realistic timesheet to monitor progress of activities.
9.Ensure that all necessarily infrastructures are in place at client site before moving to site.
10. Be proactive to problem solving
However, is an ERP implementation ever completed? It is debatable topic and can represent a subject for another discussion. The emphasis here is that work - customization and configuration of the system must terminate (if temporarily) at a certain predefined time so that the system can be used for processing live transactions.
The cause of PCS is double-faced. The system owner(s) or the consultant can be responsible. It is understandable and of course pardonable when the system owners are the cause of PCS as opposed to the consultants. This is prevalent in an environment where users are not ERP system savvy. The more they get to know about the system offerings and capabilities, the more their demand for additional functionalities. I have learnt that additional system/business demands are made during process and task trainings.
Consultants too can be guilty. A number of consultants don't know where to put a full stop on a project. This might be as a result of not properly understanding the system to be configured or spending more time than necessary on customization or reconfiguration. It's not a matter of bowing out when the ovation is loudest but when due and timely.
The implication of this phenomenon, irrespective of the initiator is that it is expensive in terms of time, value, resources and ROI for both parties. Furthermore, the downside (if it has any upside at all) can be grave. This is because the more the end user keeps seeing the consultants on site more than expected, they tend to feel insecure, uncomfortable and lack confidence. The perception will then be "will the system work after all" or "there are still issues".
By and large, it is expedient to prudently manage PCS. The list of steps that can be taken to guide against PCS is inexhaustible, the following recommendation represents a few.
1. Have a clear cut project plan and implementation model.
2. Carry out and document comprehensive business process definition and requirements.
3. Carry out and document objective business process re-engineering.
4. Adopt a clear cut strategy for handling additional business process requirements, preferably a post go- live strategy.
5. Carry out process workshops for process owners prior to start of system implementation. Processes can include Quote to Cash, Procure to Pay, Plan to Produce, Goods in - Goods out and financial management
6. Identify system limitation and inform end users via project owner.
7. Objectively align your consultant's expertise with the business needs especially as it relates to complex customizations.
8. Develop a realistic timesheet to monitor progress of activities.
9.Ensure that all necessarily infrastructures are in place at client site before moving to site.
10. Be proactive to problem solving
posted by Kehinde Disu @ 1:56 AM
0 comments
