Planning, Budgeting & Forecasting Processes – Ensuring User Adoption
28th January 2008 The budget process is complete, and users are enthusiastic about the possibilities of their new planning application. The consultants pack up their laptops and the project team disbands after a celebratory lunch. But now the hard work starts – users have expectations of continued development to realise the full potential of the product, and will not be happy if the project ends here. In the final of a series of six articles, FSN contributing editor Steve Bows looks at some techniques to encourage continued user commitment and ensure healthy long term returns on the initial project investment.
The Importance of User Commitment
Why should we be so concerned about what our users think? This is business after all, and every dollar spent on development needs to be justified – if the solution meets the basic needs then surely that will be enough? There is a lot to be said for this point of view – it is often easy to get carried away with a grand vision and lose sight of the real business case, and for this reason (and others besides) many organisations never get beyond the first stage of development. However, there are even better reasons to listen to user feedback and continue the development process.
First and foremost, we should cast our minds back to the first article in this series and assess our progress against the roadmap for a Twenty-First Century planning process: we identified a faster planning process as the first step, or a “quick win”, on the path to a culture of collaboration and better driver-based modelling techniques. Having gained the trust of the user group through the success of the first deliverable, now is the perfect opportunity to start this dialogue of collaboration.
Secondly, once this empowerment process begins to gather momentum, the pressure will be released from the sponsor to provide all the solutions and be responsible for them – his role becomes more the chairman of a group that takes collective responsibility. This can be a much more comfortable, and indeed robust, management framework, although it requires a particular type of management style to succeed well.
Finally, it would be foolish not to recognise that, without the continued support of the user community, the shiny new tool could rapidly become a white elephant: if the users are forced into spreadsheet workarounds to get what they need, the change process will rapidly unravel and result in an even more complex and cumbersome beast than before the project began. Seeing the disarray, senior management could step in and demand a fresh start with a different solution, and all the hard work would be lost.
Creating Ownership of the Solution
At the outset of the project, the solution “belongs” to the consultants – they have designed and built it based on the prototyping rounds, and they are the ones to call if there are questions. During the testing, training & rollout phases, part of this ownership transfers to the sponsor and the user “champions” who are part of the project team, as they have to explain and justify the way in which the new process will operate to the wider user community. In most cases this how it remains ever after, a precarious balance between a limited number of internal and external individuals.
Ownership must be brought back wholly within the organisation, and then rolled out to the full user community, before the solution has a stable long-term future, and this requires a two-pronged approach;
A Typical Performance Management Development Team
Firstly, establish the framework of an internal development team (an example is illustrated above). The first person on board should be the development team manager, ideally an individual with prior experience of running a Performance Management (or at least Business Intelligence) systems development team. This will often be the project manager from the initial implementation. Try to keep the team ring-fenced as an independent unit as much as possible – clearly it is difficult to justify large numbers of dedicated headcount, but ten people each doing a couple of hours a week on top of their day-jobs will not work, so a sensible balance needs to be struck.
Carefully consider the skills development of the individuals involved in the team, and be prepared for a significant training investment: highly skilled planning model developers do not grow on trees, and it is likely that it will take a year or so for even a smart, dedicated individual to reach a level of sufficient competence. It is wise therefore to choose the team members carefully and not to expect too much of them at the outset – it can be frustrating to watch all that skills investment walk out the door due to overwork or unrealistic expectations.
Once the embryonic team is in place, ensure that it has an external mentor or mentors – members of the original consulting team assigned to transfer specific skills and knowledge. This often works well in practice by forming a joint internal/external development team for the second project stage, and this can happen for as long as necessary before the internal team is ready to fly solo.
Now let's turn to the end-users' training needs. A customised training course should have been given as part of the initial rollout, but it may have been cut back due to lack of time, and some users may have been on leave in any case and missed it. Short and frequent refresher training courses should be scheduled prior to each planning activity to keep users up to date – if continuous development is taking place, there will always be something new to talk about, and it is also a great opportunity to get feedback.
Make sure that this feedback is actioned, though – the only thing worse than not taking feedback is taking it and then sitting on it! A regular User Group meeting, perhaps once a month, or more regularly during periods of intense development, is the best forum, ideally chaired by the sponsor to guide it according to the high-level strategy.
Architecture Revisited
A Robust Framework for Continual Development
In the previous article we discussed the importance of separate development and production environments, now it is time to see how these environments will operate in practice. The diagram above shows three environments and a potential split of ownership responsibilities, illustrating how a structured flow of development work can pass in regular bite-sized pieces from development to production with minimal down-time for users. At each stage, the owner of the environment is responsible for the transition of models from the stage before in the process, and will expect to see user sign-off, as well as a checklist of other procedures, before actioning the change.
And Finally..
Over the six articles in this series we have seen how a vision of the future taken from management accounting textbooks can be realistically applied in practice, by laying the correct technical foundations with a small data mart , understanding the difference between planning models and Business Intelligence tools and how to get the best out of each. We have looked at how to structure the project team to create a positive dynamic, scoped the project to mitigate risks and ensure success, and finally discussed how to carry this momentum forward in to the full realisation of the Twenty-First Century planning process by building skills and ownership.
After all this, I hope you are feeling far more confident about engaging in a planning system implementation, and so you should be, because it can be a tremendously rewarding experience and one that will help unlock the true potential of your business. I wish you the best of luck!
