We all know the old saying about assumptions… “They make an ?!? out of you and me”. As a Project Manager, I think assumptions are actually good, and an important part of my job, especially when planning time and resources at the start of an ERP implementation.
They key point to remember is that assumptions must be written down and reviewed with key stakeholders.
Tips for Effective ERP Project Management
In the early stages of projects there are many unknowns. For example, when putting together a preliminary budget for an ERP implementation, we may not know the number or the complexity of custom reports the client will need. So, we make an educated guess based on our experience on other ERP projects.
We would then add the following to the assumptions section of our Statement of Work: “Reporting estimate assumes the design, development and testing of 10 medium complex custom reports.”
A Few Questions May Come to Mind When You Read This:
- So what happens if you find during the implementation that the client really needs 15 complex reports? In this case we would review the original assumption with the client, review the analysis that discovered the actual number and complexity of the reports, and help them decide if the increase in budget was worth the value of the extra reports. If yes, then a change order would be proposed to increase the budget. If not, we would prioritize the reports to decide which could be created within the existing budget.
- So what happens if you find you only need to create 5 simple reports? This depends on the type of project (e.g. Fixed cost versus time and materials), but in general, the discrepancy would be reviewed with the client. The client and partner PM’s would decide if the extra budget was needed somewhere else, or if the budget would be reduced.
As you can see, the assumption built into the estimate let the project team “draw a line in the sand”. It allowed the team to agree on a budget; everyone understood that it could change, but if it did change, it would be by an amount that could be compared back to that base line.
We have had a few cases where we made an assumption, didn’t write it down, and it came back to haunt us. Catapult specializes in implementing software and providing long-term support. When it comes to the hardware needed to run the software, however, we can provide advice, but we don’t implement the hardware itself. Because we know what we do, we didn’t specifically state the assumption that we wouldn’t be implementing the needed hardware for a client’s new ERP system. Unfortunately our client assumed we would. This obviously lead to confusion, and wasted time. We’ve resolved the mix-up to the client’s satisfaction (and will definitely state the assumption in the future!), but this confusion and wasted time could have been avoided if we had clearly stated our assumptions up front.
A PM mentor of mine once told me that the only time in a project where there is no uncertainty is after the project is over – a frustrating, but very accurate statement. The only way to work in this uncertainty is to make assumptions, but remember that they’re dangerous unless they’re communicated!
