If you are about to start a CPM (Corporate Performance Management) project, know that there are a number of tricks to consider mitigating the risk of a result that does not live up to your expectations.
Working in a consulting firm that has been implementing this type of project for more than 20 years and with more than 70 clients and 100 CPM projects in Italy and abroad, I have gathered some indispensable cautions to always keep in mind.
CPM: consider all the resources and teams needed before the project begins
Some clients tend to approach CPM (corporate performance management) projects hastily, risking losing key resources and commitment of part or the entire team along the way. This with considerable impact in terms of time, cost and quality of the end result.
How many times have I heard the phrase “Unfortunately, we are busy with other activities” or “We cannot provide you with the required specifications on time.” Some delay or unforeseen is of course part of any project, however, it is not so uncommon for this approach to become part of the “design methodology,” wrecking the project.
Another case are very large and extended projects over time, where there is a high risk of losing the commitment of resources belonging to key business units but different than the main project sponsor.
In your case, how high is the risk of getting lost along the way and not making it to the end?
Don’t get caught up in the rush to get started. Ask yourself whether you can achieve partial results in the short term to keep the interest and commitment of the stakeholders involved. Set priorities and make sure your team has the right amount of time available at the right stages of the project. Identify your critical issues and remember, the consulting firm you have chosen is also there to support you before the project begins.
Assess the skills of the partner you have chosen to implement your corporate performance management project.
I have noticed that some consulting companies tend to allocate different teams in the design phase than in the implementation phase. Thus, process experts (functional consultants who do not know the software solution being adopted) and product experts (system integrators who do not know the process and cannot guide the client) are identified. This approach, which probably makes more sense in different and more standard projects than in the corporate performance management arena, is very dangerous with CPM software.
Knowing the process to be implemented (consolidated, budgeting planning & forecasting, financial planning, closing, profitability analysis, …) without knowing what the best practices, critical issues and limitations of the adopted solution are, or vice versa, will likely lead to an inefficient and, in some cases, unusable result because it is too far removed from the chosen process or solution.
Choosing the right partner is no less complex than choosing the right software.
Think before saying “We’ve always done it this way.”
You are about to design a CPM process, the solution architect refutes your process model or suggests you follow a software best practice or a path already taken by other companies in the same industry but you prefer to go ahead and, perhaps, create something custom because “we are used to working this way” or “this is the way we have always done it and we are different from others.”
The “we’ve always done it this way” may be a distorted way of managing processes, flawed by a way of doing things that is years old and now inadequate to the business processes that have changed in the meantime.
It is very important to give proper consideration to the suggestions of the consulting firm you have chosen as a partner in this initiative. A partner that does not push you on process best practices or challenge your current way of operating does not add any value. Unfortunately, I have had experiences of clients wanting at all costs to implement inadequate models, perhaps with excessive complexity or detail without real benefit in terms of outcome, ultimately losing sight of the balance between the real needs of stakeholder analysis, maintenance costs, performance, and user experience of the solution.
The consulting firm should not only indicate how to implement a given phenomenon on a software, but it should also be able to explain why it is better to manage this and not another phenomenon.