1. KNOW WHERE YOU ARE GOING

Start with the most important step: define where you are going and create an overall vision for performance management. This vision needs to be as detailed as possible – and shouldn’t just be a plan for replacing your Microsoft Excel or other outdated tools with a new version of the same type of system. (Trust me, I’ve seen those plans).

Sit down and think about what business changes the new system needs to make and include strategic modeling and planning, budgeting and forecasting, and reporting and analytics. We also encourage you to think long-term as you don’t want to have to re-implement system changes when other departments “make the switch.” Create the roadmap and then redesign your close and consolidation process with an integrated vision for performance management. Remember: Start with the end in mind!

2. GET EVERYONE INVOLVED

My team and I cannot stress this enough. Other departments (FP&A dislikes using Excel just as much as you do!) may also want to make the switch, so engage business units and all the key stakeholders, both at corporate and in the field. Involve the business users from the beginning by having them help to establish the vision and roadmap, define requirements, as well as design and build the technology. Because these users know the system, they can also test and deploy it too. If any group makes changes, it’s early enough in the process to get those changes on the roadmap.

The worst thing your organization can do is to allow your project to turn into a “turnkey” consulting project. Imagine describing your requirements and then months later the consulting team hands you a manual and says, “Call us if you need us.” Without knowing the ins and outs, it will be hard for your organization to understand how they arrived at these new processes. Likewise, don’t let the project become an IT-only project. They may get the software installed and turned on, but you may spend years tweaking it to your real requirements.  Our best client success stories are the ones that included the client as part of our implementation team.

3. DEFINE YOUR REQUIREMENTS

Document your existing processes, benchmarking business units with each other. Look for:

• best unit/department practices in your organization

• waste and variation

• best practices from similar companies, focusing on those in your industry with similar size and complexity

These are all great avenues for exploring things others are doing that may be adaptable to your business processes. Once you understand the current processes, you can start thinking about the future state processes.

4. DEVELOP A FUNCTIONAL REQUIREMENTS DOCUMENT

When you develop a functional requirements document, it should include the system’s technical design, implementation cost, training plan and cost and rollout/go-live strategy. The document should also provide additional detail to the overall functional scope of the project, the goals of the project, as well as the key stakeholders, project assumptions and project in/out of scope items. Design architects should perform the functional and technical design (even if the application is in the cloud) of the new system and produce the design document, which will include the detailed models of the system, such as:

• the application and infrastructure components

• metadata descriptions

• dimensionality

• data flows

• the details of each component of the software

The functional requirements document is critical to outlining what’s required in a new system. Other important items to define are key features of the software related to the functional data components. Non-functional focus includes:

• the usability requirements

• performance and operational requirements

• user documentation

• security requirements

• future training plans

• future maintenance best practices

5. CREATE A PROJECT PLAN

After the requirements are complete, create a project plan that lays out key dates, dependencies, and tasks. When your steering committee signs off on all the documents you prepared (functional requirements, design document, and project plan), the exciting journey to implement the technology can begin. In the end, the amount of effort and time you put in before you start touching the software will determine the success of your CPM project and will provide an excellent example to your stakeholders of what you are proposing and what they can expect as the result.

Following these best practices will go a long way toward a successful CPM implementation that is both on time and on budget, with the final product being one that is not only accepted by the stakeholders but also sustainable and adaptable as your company grows.