In this post, let’s dive into where bottlenecks normally occur in the delivery of an implementation or a project or what steps the project tends to get stuck at.
That is Step 1 and Step 2 in the implementation framework.
This is the costliest stage because this is where people spend most time pondering and discussing different requirements.
A lot of organisations get a group of stakeholders together - expensive stakeholders - leading to a never-ending discussion at the requirements stage. Because like your health and safety or quality team, each has their own requirements; and sometimes it is always easy to get down the rabbit hole and keep refining those requirements.
Remember the clear thing is to establish what your goals and objectives are of that transformation. Be very clear of the problem you're trying to solve; the value you're trying to get from the solution. If you can be as specific as possible that will be good to focus the team and not be distracted by the finer details.
What you are trying to do is to split up the end goal into multiple stages.
Sometimes a good enough solution is good enough.
And you don't really want to be spending this amount of time to get a perfect solution. Anything that you can get an agreement and move on with is always better than your current state, hopefully if you get your goals and objective aligned. That's probably a very important aspect of not getting stuck.
The other tips that probably I would like to share is to invest some time to map out your current process. Spend some time to have a flow chart if you do not already have them.
It is often very difficult and particularly important before you actually see a provider, because when you engage with the provider or even your internal development team, one of the first things they would ask is “What does your current process look like? How does it work?”.
If you've done the prep work and have drawn out those processes, it makes that knowledge transfer a lot easier.
Source: Lucid Chart
The other advantage of having your existing process mapped out is the fact that you can identify and challenge:
Why have I been doing a particular thing for so long? What is the value for that particular piece of process? Why do I need to do that activity?
You can question why things are being done, and in the digital world, what value it has. It may be that some of the requirements in those processes are limited by technology at the time - they may be here because you're running a paper-based process.
As an example, we have an approval engine on our platform. Most of our customers prior to using the digital platform would have a wet signature type of approval and by nature, there's an approval form people need to sign off; it needs to pass from one person to another, so you can't do the approval simultaneously simply because it's limited by the fact that you've got one piece of paper and that needs to pass from one end to another.
When we move into a digital space, that no longer applies. You can send it to multiple people at the same time, at the same level. That opens up a lot of opportunities to re-examine those processes and potentially decide if some of these processes are the point where people get stuck on. To question whether you need them or not helps simplify the overall solution and therefore simplify the implementation.
Another major risk to a project is around organisation change. In a lot of cases where in terms of transformation, this can easily be overlooked.
If your organisation change isn't done in a comprehensive manner, you will find that while the solution brings some benefits, you're not actually realising the full potential of what that solution could bring you. After all, you need a bigger team to all utilise the solution to gain maximum benefits.
What we sometimes observe is there will be a business unit that is extremely passionate about adopting the digital solution. They work really well because they were engaged early on and they're part of the project. They really see the value.
But as it rolls out to another part of the organisation, because of communication (or lack thereof), because of that change management piece, they are less aware of the solution. The engagement and the satisfaction level drop simply because of the gap between what the solution is designed or configured to do versus how they're doing it at that point in time, and the buy-in that they are having.
Organisation change is a very important piece, and that needs to be embedded in the organisation and across the organisation.
The other pitfall we see is sometimes the project is sponsor orientated. Thus, when there's a personnel change, and if the digital transformation is not embedded well enough within the organisation, you could lose momentum along the way. Again, you're not utilising the full potential of the of the solution being offered.
Now I want to introduce Kotter’s 8-Step Model as a change management framework.
This framework is proven to be working. It most famously helped Graham Henry transform the All Blacks from a team suffering a crushing 40 to 26 loss to South Africa in 2003 and to be the world champions that we see now.
To be successful in your transformation, you will really need to create the right environment and channel all the energy across the organisation to make it a success.
And for those who may be interested, the graphic below maps out how All Blacks did it.
One thing that the All Blacks can't be accused of is strong leadership and a culture of leadership.
Q: Like construction projects, we've often seen time and budget blowouts when you're implementing a piece of software. What advice can you impart to the listeners about how to best prepare in advance to have a smooth implementation? What are those critical success factors of a tech project?
A: Make sure that you have clear objectives and goals, what you're wanting to achieve with your project. Then manage the change.
Once you get those pieces in play, your partner in the form of your development team or a service provider should also be able to provide feedback to yourself and they should all bring value. For example, throughout the implementation, your internal team may learn new things to come back and improve on. Likewise, your service provider will be able to bring additional value from a consultancy basis as they interact with multiple organisations and have varied experience.
I mentioned in the previous post that richer feedback is essential, and it could make a big difference because someone who may be having an issue may solve a problem in one particular way today using a solution that you may not have, that could be something that you will see in the future and there is already a lesson learned that someone’s already solved it. It makes the entire process so efficient.
To sum up, the key thing is make sure you understand your own objectives, what you're trying to do, the impact you're trying to get from the solution. Make sure the changes are done right. Select a competent partner or competent team if you're doing it internally to run through the process.
Q: Have you got any examples and what have been the most successful projects in your experience and why?
A: I think the most successful project - and that is in plural - is always where we work with our customers as partners and the customer shows genuine interest to drive the project.
This can be really observed by the priority they place on implementing the solution, the efforts of due diligence; the investment in change management and the motivation and excitement from the team members and also from Felix throughout the entire implementation process.
I think this is a winning formula and we can see this pattern repeating in some recent projects where all of these clients have invested a lot throughout the implementation process and worked with us as equal partners.
If you want to be successful, remember one thing. A piece of software or technology solution can solve some problems, but it's not the silver bullet. You still need to invest time and channel your energy and make sure that the equipment that you have chosen is operating in maximum efficiency.
Watch the full webinar Tips for Successful Procurement Tech Implementation.
Vendor risk management in subcontractor-dependent industries such as construction has re-entered the scene as a hot topic. The increasing burden of compliance requirements, cost pressure and project magnitude have pushed some to be “building in the dark”.
Big data, small data, lots of data. What are we supposed to do with all this data? It can get overwhelming quickly. Many construction companies miss out on critical insights because they're managing procurement manually with excel and email.
Get the monthly dose of supply chain, procurement and technology insights with the Felix newsletter.