What do you think was the probable outcome of earlier example? Or which result has more probability?
Lesser the constraints easier to manage.Every org have constrainst. TOC states that take one constrainst at a time and restructure the methodology, project or org to solve that constraints.After that there may be new constrainsts. Repeat the same process. This way we improve the processes and bring more value for money. If we remove any one constraints, project execution becomes very simple. But unfortunately, we have to live within the intersection of these three constraints.More the overlap area, simpler it is to manage the projectThe goal is to make overlap area as big as possible.
End Results??<br />7/5/2010<br />Protorative Methodology<br />7<br />Only two possible outcome<br /> OR<br />SUCCESS<br />FAILURE<br />
Project Success Rate<br />7/5/2010<br />Protorative Methodology<br />8<br />“Studies by Standish Group and others for traditional project management methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion”.<br />“The success rate is even lower in case when companies are going for ERP system for the first time”.<br />
All open issues are closed before end of stabilization phase
Use & leverage the system as intended</li></ul>If we compare the meaning of success of both consulting partner and client, the only difference is using and leverage the system as intended. This is in fact the most ignored success criteria and deciding factor between success or failure of the project.<br />
Issue in Leveraging ERP System<br />7/5/2010<br />Protorative Methodology<br />11<br />Statistics shows that the top 2 reason behind companies not able to leverage or realize full potential of ERP is <br /><ul><li>Not all requirements were met during implementation of ERP.
Users are not comfortable running the system because not all desired functionalities are provided in system and lack of sufficient time spent on the system is hindering them to work as per management expectation.</li></li></ul><li>Project Success<br />7/5/2010<br />Protorative Methodology<br />12<br />With all the discussion and explanation of project’s success or failure, it is very easy to comprehend that on-time and in-budget go live are not the only of the criteria of successful implementation. <br />It is User’s adoptability of ERP system which will decide whether project is success or not.<br />
During Project Execution<br />7/5/2010<br />Protorative Methodology<br />15<br /><ul><li>How often requirements are captured inaccurately, insufficiently or missed to be captured at all?
How often changes in agreed business requirement/process are requested by client?
How often we run out of testing time when changes are requested during later phase of the project?
How often client feel inadequately trained at the end of the project?
How often client needs to have extended support to fix all outstanding issues?</li></ul>If most of the answers are in “Very Often” inspite of using ASAP methodology, blaming the poor planning and execution does not sound correct.<br />
Why Do Requirements Change?<br />7/5/2010<br />Protorative Methodology<br />16<br />When we write the initial specification we document the low hanging fruit. The specification will include the most obvious requirements, those that have been discussed before the project started, those which are already documented and those this people think of in the early stages. Yet as the project proceeds, everyone involved will get a more detailed understanding of what is happening both in the software and the company, potentially revealing even greater value in a system. Consequently, it is necessary to reprioritize our work as we go.<br />Requirements changes mainly due to one of the below factors: <br />External changes - changes required to meet some need from outside the organization, say a changed legal requirement. <br />Internal changes - changes required because of company changes such as new products or restructuring. <br />Technical changes - required to meet new technical demands.<br /> Learning - changes resulting from learning by individuals or groups.<br />
Drawback of ASAP Methodology<br />7/5/2010<br />Protorative Methodology<br />17<br />What is the main drawback of using ASAP methodology or for that matter any traditional project management methodology?<br />The answer is “it relies on completing all the activities of a particular phase in that phase itself”. It does not permit us to go back in phase and change something. If we try to go back to some phase and change something, basically we are eating up time of current phase. This often results in project delays.<br />
Theory of Constraints<br />7/5/2010<br />Protorative Methodology<br />18<br />
The five focusing steps in TOC<br />7/5/2010<br />Protorative Methodology<br />19<br /><ul><li>Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal) .
Decide how to exploit the constraint (make sure the constraint's time is not wasted doing things that it should not do)
Subordinate all other processes to above decision (align the whole system or organization to support the decision made above)
Elevate the constraint (if required or possible, permanently increase capacity of the constraint; "buy more")
If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint. </li></li></ul><li>7/5/2010<br />Protorative Methodology<br />20<br />3 Constraints of any Project<br />Scope<br />Schedule<br />Cost<br />
Differences<br />If most of the answers are in “Yes” inspite of using ASAP methodology, blaming the poor planning and execution does not sound correct.<br />7/5/2010<br />Protorative Methodology<br />24<br />
Assumptions<br />7/5/2010<br />Protorative Methodology<br />25<br /><ul><li>Client will ensure the dedicated users are available during complete life cycle of the project.
List of would be SAP users are finalized with their respective roles in Organization before project starts.
All the hardware (At least Dev and Quality servers) are procured and ready to be setup before project starts.
Consulting Project team is finalized and ready to be deployed.
Standard SAP user manuals are available to give it to the users.
Consulting team is experienced and ready to work extra hours from the day one of the project.
End users to have good excel knowledge. If not, a 5 day workshop will help the project in long run.</li></li></ul><li>Activity Schedule<br />7/5/2010<br />Protorative Methodology<br />26<br /><ul><li>Weekly Activity Schedule for Protorative Methodology</li></li></ul><li>Advantages<br />7/5/2010<br />Protorative Methodology<br />27<br /><ul><li>4-6 weeks of time saving (and cost) for both client and Implementation partner.
Testing of the system is done by user himself.
Both client and implementation partner become equally responsible for success of the system.
Consultants will be working more during initial phase of the project instead of later part. This way they can be more productive when it matters most.
Post Go Live issues will be very few as user has tested and approved the system.
Separate window for Training is not required as user get hands on training from week 2.
Data collection is almost error free and smooth.
User adopts & use the system as per management expectations.</li></li></ul><li>7/5/2010<br />Protorative Methodology<br />28<br />Thank you<br />Yashpal.v.Jain@gmail.com<br />