As a consultancy we have had the pleasure of working with many different customers to implement IBM software. In this blog, Bronyck Stokes Horrigan takes us through the seven golden rules to follow to make sure a project is successful.
1. Support your team
Some customers dedicate time and resources to the project while others must work around their day job. In some cases, the latter approach can work if the project is a small one, and it is a quiet period. The greatest successes come from those organisations who put a team together to complete the project, clearly define the roles, and made sure that people support each other, and their managers support them. Trying to juggle a whole set of new tasks as well as day-to-day responsibility, can lead to long hours, frustration, and a tarnished experience. Of course, for smaller organisations, it is usually not feasible to drop the day job for two weeks.
Instead, customers have spread the project over a more extended period, at, perhaps, two days a week, or when there is a quieter period in the year.
It is essential to give people the time they need to do their day job and be part of the project. Budgeting, planning and forecasting activities are very time-consuming and stressful for a team, adding the implementation of new budgeting, planning and forecasting solution at the same time, can cause people even more stress. Improving the process for the future also needs investment in resources now.
2. Break it down
There is a temptation to add too much to the first phase of a project, which can see people become overwhelmed and not see any deliverables quickly enough, often, 80% of the benefit can come from doing just 20% of the work. Our advice is, and always has been, to break the project down into achievable deliverables along the way, realistic first steps. Create a phased approach to help achieve those deliverables – in short, do not bite off more than you can chew straight away. Aim to achieve something where you know you will see a quick win, which is more likely to get the buy-in of other stakeholders and be realistic about what the benefits will be, and make sure there is clarity about what you are trying to achieve.
We have found that the biggest causes of project overruns are managing project scope and handling additional requests. So, before you do anything agree on the range of the project. Agree what’s in and, more importantly, what’s out. Then decide on a process that, will allow you to add things in and, perhaps, take somethings out.
Often, risk factors get missed. Nobody wants to be negative, but things will go wrong, and we have found that it makes much sense to tabulate these potential issues into two categories, namely, how likely is something to go wrong and what will be the impact of it going wrong. In our experience data quality is the most likely thing to go wrong and often has the highest impact.
3. Make time for learning
Give your team the best chance of long-term success by making sure that they have the skills to understand the tool and empower them to take ownership of it going forwards. You don’t need everyone to be super users, so make sure there is at least one person who can be the ‘champion’ of the software or the data. The more users can engage with and understand the tool, the more likely they are to be positive and adopt the software, and the organisation will reap the productivity benefit.
4. Engage all stakeholders
Who is this project for and what do they expect to get from it? It might be more accurate data quicker, less fraught planning rounds, or not having to work long evenings and weekends to get the job done. Identify and deliver a ‘quick win’ to get people on board and demonstrate progress. It would be best if you were careful to manage any out of scope requests because trying to deliver everything may mean providing nothing.
5. Test, test and test some more
It is a good idea to consider a testing plan at the very beginning of the project, so you can factor in the extra time that you will need to fully complete the project. Your testing plan doesn’t need to be ground-breaking, a good way to test is to carry out your normal tasks in the new software, so you can be sure that you understand the new software, and that it works. As with all testing, it is best to test this across a range of users and a range of scenarios to be thorough.
6. Debrief
Once the project is live, it will become the centre of the working world. Then once it’s over, everyone moves on to the next thing, and we spend no time getting feedback on what went well and what went not so well, what you wanted to achieve and what you achieved. Both customers and Aramar find it beneficial. For us, it improves our future services and better supports our customers. It is always worth asking the following four questions:
- Did you achieve everything you wanted?
- How did the project go versus your expectations?
- How will you review the software in the future?
- Is there additional support you need for your team?
We also see it as an excellent opportunity to feedback to team members, check that they got the support, and have the support in the future, that they need. This step can help your team grow. A debrief also ‘closes off’ that initial phase of the project so that you can sign off on your achievements.
7. Document
Successful projects have good documentation. Like thorough testing, it can get pushed aside at the end of a project when people are beginning to think about the next big thing. People move around. They get promoted, or they get jobs in different organisations, and they don’t leave a record of how things work. People no longer know when tasks should happen, and in what order. A skills gap can develop. The solution deteriorates. Documentation means that users (and new colleagues) can understand and use the software. Do this during the project. Once the project finishes it rarely ever gets done.
Although Aramar specialises in IBM Business Analytics software, I believe what is in this blog can be applied to any organisation and any project. Customers who have wholeheartedly adopted the things I have written about have had a positive experience during the project and have built on their success to drive more and more value from the software. A great example of this is Melton Renewable Energy, and you can read more about them here.
I hope after reading this blog, you can identify some of the ways that you will be able to improve your projects and share in some of our learning over the years.