I had a colleague ask me what are the key project management strategies for successful ERP/COTS implementations. I laughed and told my friend that I’m still learning! My friend is an experienced, certified project manager (PMP) so I spared him the foundational best practices (approved project charter, executive support, risk management, communications, etc). These core best practices are well known and documented. I wanted to go to extra mile and provide advice that may not be well known or understood. Following are the key strategies that drive my project management approach for ERP/COTS implementations:
(1) FOCUS
Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who is doing what. Just as important to scope definition is to define constraints and assumptions. Example: for packaged software implementations (like ERP) I create scope statements with the following sections:
i. Packaged software features in scope (product scope)
ii. Packaged software features out of scope (product scope)
iii. Implementation activities and party responsible (project scope)
iv. Assumptions
v. Constraints
A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.
(2) KNOW THE BUSINESS
How can you lead a project to generate value for a business if you do not understand the business? You may be able to perform project control/admin but you will not be able to lead a project team in their efforts. Analyzing whether your project is generating business value is difficult if you do not understand what results drive real value.
(3) ENABLEMENT OVER CONTROL
Would you rather have one person (PM) focused on project scope or the entire project team (including your customer) guarding project scope? It’s been my experience that undetected scope creep starts outside of project meetings – ex. water cooler discussions, off topic discussions. Addressing project scope changes in a change control process is reactive – you already wasted time/effort writing up the potential change. I educate the entire project team on the project management basics of scope, schedule, and resources. I also make the scope easy to understand so that every individual on the project team understands scope boundaries. Individual team members are your first line of defense – the project manager cannot be everywhere at once.
Governance by itself does guarantee business value – a project manager has to do more than just control.
(4) BE RESULTS-ORIENTED
Focus on the right results: On-time, On-Budget are good project metrics but it does not guarantee that business value is generated. Decisions drive projects forward – not action items. As your project evolves your meetings should start generating more decisions and less action items. Running software is a good beginning but is not the end of generating business value.
(5) CREATE AND PROMOTE TRUST
Like the old adage says “Trust but verify!” The only thing I would add to this is to build in an iterative approach so that verification is frequent versus a one-time event. Waiting to develop trust during the Testing phase (i.e. validation) is not a smart risk to take.
(6) BE ADAPTABLE
Do not confuse a plan with execution. A project plan is a simplified model of reality based upon many factors whose definition will further elaborate during the project. Change will occur – be flexible and adaptable to reach the desired goals. A process (methodology) supports achieving the desired results but the methodology is not more important than achieving the desired business results.
Effective project management must be more than coordination and control – it must include enablement and leadership. Always keep the end goal in sight and on the minds of your project team.
Join the community! 10k followers across 100 countries!
Leave a Reply