Driver-Based Planning Step 8: Rolling out to users

Posted by  Michael Coveney

In this series of blogs I am providing a comprehensive approach to the design, construction, roll-out and maintenance of a modern driver-based planning solution.  In this blog I look at rolling out the model to users.

A system, no matter how useful on paper, is of no value if users can’t or won’t use it.  Similarly, if they choose to use the model just because ‘they have to’, it is unlikely to realise the potential that was envisaged at the start of the project.  Users can elevate or bring down the best of systems and so it’s vital to get their engagement right.

Rolling out a system is not just a case of sending someone a connection with a page of instructions - that is a sure way to failure.  Similarly, the system has to add value to the users’ existing role if they are to embrace it and get over any teething problems.

Preparation for rolling out any system starts right at the beginning of the project.  Here are the stages that I recommend.

1.    Cast the vision – but don’t overdo it.  The project was setup to solve a particular problem or set of issues.  These should be made clear to all users and the way in which the proposed system will solve them.  At this stage it is just a vision, so don’t over promise capabilities and transformations which could later be used as signs of failure, even though the end objective may be achieved.

2.    Involve them in specifications.  When it comes to individual users, discuss with them the specifications of the system as it will affect them.  You cannot meet their every need but you are more likely to carry some favour if they can see some part of their involvement.

3.    Employ cheer leaders.  All new systems will go through times of difficulty, when things won’t quite work as expected.  At these times, and when delays occur, it’s important to have cheerleaders who are not part of the project who can still talk about the eventual benefits being worthwhile.

4.    Keep them informed of progress.  This goes with the last point.  A period of silence where nothing is heard about the project can easily be mistaken as the project being no longer important.  Keep users up to date with the progress of development and remind them of the ultimate benefits.

5.    Better to have releases that are small and often than the big reveal.  As parts of the system become available then, if you can, release those parts rather than wait for the whole project to be completed.   These releases do have to add value though.  In doing so they will provide good feedback on what areas work well and those where there are user challenges.

6.    Ongoing, relevant training.  Training should be tailored to individual users and be available online. Some users may only need to know how to enter data, while others will need to know how to perform analyses.  Training should include face-to-face meetings backed up with good manuals, some form of helpline service and maybe a dedicated support desk.

All this may seem like a lot of work – in my experience, the rollout part of the project can be up to 40% of the development effort.  But it’s less costly than having a project fail through user indifference.

Michael Coveney

Michael Coveney spent 40+ years in the software analytic business with a focus on transforming the planning, budgeting, forecasting and reporting processes. He has considerable experience in the design and implementation of Business Analytic systems with major organisations throughout the world. He is a gifted conference speaker and author where his latest book ‘Budgeting, Forecasting and Planning In Uncertain Times’is published by J Wiley. His articles have also appeared on www.fpa-trends.com, that encourages innovation in FP&A departments.