The Difference Between Uncertainty and Risk - Practical Project tips
A common mistake made by decision makers and practitioners alike is confusing the notions of uncertainty and risk, especially as they apply to enterprise projects. Uncertainty is a property of nature that resists quantification, and therefore cannot be effectively reduced to probabilities and scenarios. Risk is by definition quantifiable and manageable.
A project risk is an uncertain factor, managing an ERP or enterprise project is unlike any other effort because of the huge number of variables, people and risks involved. The complete replacement of an organization's information systems has a tremendous impact on the people in the organization, the company, its suppliers and even its customers. An ERP project manager must possess an intimate understanding of the business and how it will change when the ERP system is rolled out, and must also have a solid technical foundation. One common mistake, I usually see in enterprise projects is groupthink I call it the danger of compromise.
Enterprise projects is about making hard choices, not ducking the issues. Groupthink makes it harder for us to choose properly; it is a delusional process that exploits the members of a group and costs organizations dearly.You have probably experienced groupthink during meetings and may have fallen into its clutches occasionally; perhaps despite fairly strong feelings or personal reservations about the fairness and sensibility of some of the decisions you have supported while groupthinking.The valid opinions and due concerns of members are always at risk of being steam-rolled by groupthinking groups.
Once groupthink takes a grip, the affected group members are at risk of being gulled into unthinking acquiescence and a consequent, downward spiral of individual and collective weakness. For sure, groupthink is a powerful force and it can be hard to resist.But it’s all about compromising principles and individual responsibility, in the mistaken belief that the short-term advantage of group harmony will provide long-term satisfaction through the avoidance of proper consideration.
The consequences of groupthinking are invariably poor decision-making and damaged integrity. (In my years of experience, I think this is the number 1 reason why projects are delayed)
On a side note when a project plan is slipping before you announce that the go-live date is in jeopardy make sure you look at these points below:
Everyone hates it, but one logical place to start is with overtime. If people work more hours, they can get more work done in the same amount of calendar time. Overtime may be the best option if you’re close to the end of the project and just need a final push to get everything done on schedule.
Crash the schedule
Crashing the schedule means applying additional resources to the critical path, the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. It’s always possible to just throw more resources on the critical path, but crashing also means you try to get the biggest schedule gain for the least amount of incremental costs.
Scale back the scope of workOne option that is usually available is to look at the work remaining and negotiate with the client to remove some of these deliverables from the project. Example: non-core reports, some interfaces or extensions that can be pushed after go-live, manual conversion instead of automated, training material, etc. If you think some of the remaining work is not core to the project, you should discuss eliminating it quickly, to re-focus on the core areas.
Last tip, this has worked for me on all my enterprise project, do consider internal employees in addition to consulting help. Projects are more successful when the internal staff owns the project and the consultants are there to support, advise and teach.