Project Management: The Planning Phase and Project Charter
The quote "you don't have to recover from a fast start" very much applies to an ERP implementation. As soon as the ink is dry on the Statement of Work, it's time to get down to business, and if you plan well, you stand a much better chance for success. I feel like the Planning Phase is the key to success on a project. That's when you figure out what you're doing, who's doing it, how you're doing it and when it needs to happen.
In the Sure Step methodology, the first phase of an implementation is called the Analysis Phase, but we feel strongly enough about the work that leads up to the Kickoff Meeting, that we've termed that the Planning Phase. The Planning Phase has a few output components:
- Project Plan
- Project Charter
- Kickoff Meeting
The Project Charter encompasses a high-level of the project plan and serves as the basis for the Kickoff Meeting, so that's the most important output. Let's delve into it a little further.
Project Charter
The Project Charter has 4 main sections, each with a lot of input that goes into it to pull it all together. In the next blog post, I'll talk about the questions that I like to ask to gather all the information to create this document. Once I've pulled it all together, I go over it with the internal team and review it with the customer decision maker.
Why? - Project Goals
The first section highlights the reasons for this project and the goals you hope to achieve. As a customer, you want to get your internal on-board with the idea of this project, and clearly stating the goals of the project provides the team the direction they need to put in the time necessary to complete this project. I break it into three sections:
- Project Key Objectives - this is a narrative around why you are doing this project and what goals you want to achieve at a high level. This may be that you are replacing an old, unsupported system; you may be needed a modern platform to serve as a hub for integrations; or you may need to have an updated system to support expansion or the desire to go public. Whatever the reason, it should be articulated here so it can be shared with the project team.
- Business Benefits and Metrics - here's where you want to cite any statistics and/or objective measures that you want to achieve with this project. Perhaps you want to close your books in 10 days instead of 30 or you want to track 99.5% of your inventory instead of 95%. Whatever the metrics that you want to measure, we should write those down and work to achieve them.
- Success Factors - these are the behaviors/actions that will allow us (collectively) to achieve a successful project. This would include factors such as "we will seek automation where we can see a great return on investment" or "we will train on team on the solution so we can support ourselves in the future", etc.
Both the internal and consulting teams should be able to read through this section and have a good grasp on why you are doing this ERP implementation.
What? - In and Out of Scope
The second section is pretty straight-forward - this is where you articulate what's in and out of scope. It seems easy, and in many cases, it seems like this has all been discussed pre-SoW, but it is very important to make sure this is written down and known by all parties when the project starts. The "out of scope" part of it is the most important. Here you want to save the project team a lot of time by crossing out potential solutions before they become a distraction on the project. It's pretty easy for a project team member to say "we need a solution for tracking skills and I see AX has that. Let's add that to the project." Great idea - bad timing. If that was listed as out of scope, we need to wait until we've completed the core implementation before addressing that need.
When? - Deliverables and Timelines
The third section identifies what documentation will be completed as part of this project. You articulate what the phases are, what deliverables are included in each phase and when they are expected to happen. The hardest part of putting this together is building that initial project plan timeline. I start the project with a more high-level project plan; we'll get down into the details when we get further into the project. In this, we lay out dates and activities that occur during the Analysis, Design, Development and Deployment phases so we can forecast a go-live date. At this point, I always say the go-live date is not firm until we've had a chance to complete the fit/gap and reassess the timelines and budget. No one listens despite me repeating this over and over - perhaps I need a suggestion there on how to make this more clear.
How? - Team and Governance
The final section is where you list who is serving in the various roles on the project - this includes everyone on the internal project team, the consulting team and any third party vendors or subcontractors who will be part of the project. On the customer side, you need to know the following roles:
- Executive Sponsor/Steering Committee
- Project Owner
- Project Manager
- Subject Matter Experts
- IT Resources
On the consulting side, you need the following roles:
- Executive Sponsor and Engagement Manager/Account Executive
- Project Manager
- Architect
- Functional Consultant(s)
- Technical Consultant
- Developer(s)
- 3rd party resources, if needed
Once you've identified who does what on the project, you need to talk about how you're going to run the project. First, you should discuss your organizational change management plan at a high level so you know what's going to be done to help the customer team understand the change, how to handle new processes and how the new technology will get into their hands. Next, you want to define your change control process flow. When a request for a requirement comes in after the fit/gap, what is the process to make a decision if it should be added to the project. Next, you cover the tool/technology that will be used to store all of the documentation generated on the project. We use a custom SharePoint site, which I'll get to in a later blog. The final two things that are covered are the identified risks and the communication plan for the project.
There's a lot here to go through so my next blog articles will go into detail in key areas to help you make sure the project is starting off on the right foot.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.