I spent a day with our Delivery manager last week, developing the second phase of our project management system as we recognised we need to keep improving our systems and processes. It got me thinking about the whole continuous improvement conundrum. Let’s face it, change is hard and getting users to change even harder, so it’s no wonder we put off projects which need the mobilising of others.
What came out of my day with Ian, was an exciting move forward, we recognised there were new possibilities for improving how we manage projects for our clients, giving them more visibility of deadlines, project timelines and documentation. It was a big step forward for us as a business. What I learnt was that improvement doesn’t have to be big to be transforming, but small bite sized changes can pay big dividends in time, effort and added value.
We are in the business of delivering financial planning improvement to companies. In the great scheme of things our projects are on the smaller side of 'automation and transformation' projects that FP&A are involved with, but the benefits can be significant; savings like 50%+ less time on budgeting cycles or reports updated in minutes, is a big deal for a tightly resourced finance team.
So, there's immediate benefits, but as with all change projects are they worth the pain? So I wanted to explore how to quantify change projects, ease the pain in delivery and ensure you realise the benefits. So we've brainstormed all the things that impact project success, so you can avoid costly mistakes and make change happen.
We also look at evaluating change beyond pure process and time savings to reflect payback which can impact team motivation, retention, attraction and broader business change.
Guide to project delivery
Decisions on buying solutions are usually made at a senior level, and usually the person signing off the spend.
This is also where the scope of the project is shaped. Priorities are set and phases agreed. The issues start when this scope is not explained to the in-house project team tasked with day to day build and implementation.
We certainly reflect that everyone needs to be clear on what the main objectives of the project are. Not everyone will agree on the views of the CFO / buyer or on what should be improved first, but projects very quickly get delayed if additional elements are suddenly added to the scope, or the team doesn't understand the objectives.
Changing the scope, may affect the time it takes to build, costs, additional consulting days and delays and may not deliver benefits as quickly. Critically, lack of scoping clarity can also divert focus from key deliverables identified at the outset, watering down the whole project.
The answer - ensure the scoping isn't just a 'buying exercise'. Ensure the scoping document covers the key elements which solve the critical pain points you identified. For many of our clients these are the same, the need for faster budgeting cycles, a more robust forecasting solution moving away from hefty Excel spreadsheets, and better reporting.
Then make sure the scope which is agreed between CFO / procurement is then communicated to the team who are involved in the project. As a consultancy it's amazing how many times at the initial workshop the internal team have a very different view of what the software will deliver and that gap can be very damaging to a project from the outset.
2. Manage the Project
Projects unfortunately don't manage themselves. That's why we always have a Delivery manager to drive our builds. Everyone needs to know what is going on, what they're responsibilities are and when tasks needs to be completed. That's why we've beefed up our project management system to provide more visibility on where the project has got to, slip and documentation.
We know in many companies there isn't enough resource to provide a dedicated PM and we certainly don't expect it. The next best thing is that someone becomes the super user who drives the build, and, critically, that the senior stakeholder - usually the CFO, must stay in the loop and drive the project forward, when needed.
The most common mistake is that energy goes into buying software and then there is a lack of resource to implement. In a typical forecasting system key decisions and data need to be owned by the client. As a consultancy we can't reconcile your data or determine key business processes, SO, whilst you may not have a PM, you will need to allocate some resource to liaise and provide information. Without it everything can quickly come to a standstill.
3. Set expectations
No-one likes surprises. We know finance teams are always pushed for time. Additional work is never welcome. SO setting expectations early on is essential to get everyone on board with a project. Understanding the work impact on individuals, such as uploading or reconciling data, committing to training, or just engaging with learning the system, will mean less delay later in the delivery cycle.
People tend to accept more work if they know there is a win for them at the end. So when setting expectations remember to highlight the plus points.
Our projects mean less repetitive number crunching work, and cutting the number of late nights in the office. Feedback from our customers is that teams love the freedom that cloud planning gives them, with ability to provide better analysis. Re-enforcing the message that good analysis is valued over juggling spreadsheets, will help drive adoption and change.
It is all too easy to accept that a deadline isn't real, and no-one really expects to hit it. If you start with that mindset, then the reality will be project slip. A short, sharp delivery can be easier to motivate than a long drawn out one. We find the beauty of implementing Adaptive Insights for example, is that it is short and sweet. However clients believe it won't be and are often surprised just how fast they can get up and running. The problem comes when the team and the business aren't ready for the change. When you buy your licence subscription, you want it to work hard for you.
Don't waste valuable days not getting value from your system. Commit resources, energy and backing with a clear deadline and the project will gain momentum, and get there fast. This approach means the drag of a long drawn out transformation project is avoided.
5. Step by Step - bite-sized project delivery
Formulate use our custom built Agile for Adaptive methodology Its not a pure agile approach, but it is a phased iterative method for delivery which gets a working solution built fast. This helps users see and learn in a hands on way, how the system works. They get to add value by providing feedback along the way and shape the final build.
Small phased projects are far easier to handle and you can prioritise elements to ensure you get quick wins. This also helps gain buy-in from the team. It may mean short periods of more work but there will be visible payback. Don't be tempted to think you can squeeze it all into a tight time period with a hard deadline. Your team won't thank you for it.
The key is to break change projects down. Then timetable phase 2,3 and beyond so that your software purchase keeps paying back.
Want to learn more about projects and planning, why not join our webinar 21st May at 12 noon