7 Top Failures Of Financial Transformation And Procure To Pay Projects

Lots of organisations are considering ways to reduce their costs and automate their operations, procure to pay projects are high on the list with organisations considering different technologies that can be used to drive these results. But in an environment where, according to reports, 25 percent of technology projects fail outright; 20 to 25 percent don’t show any return on investment; and as much as 50 percent need massive reworking by the time they’re finished. The likelihood of success can seem low.

We wanted to share the trending failures we’ve seen in fixing and re-aligning Financial Transformation, Procurement, Procure To Pay and Back Office automation projects globally. Most of these may be applicable for any technology transformation projects in mid to large sized corporates.

Achieving Procure to Pay success and getting to your transformation goals requires your teams’ support and commitment. If your team is not on board, this could lead you being blocked for getting into transformation targets you originally set out to achieve.

For a project sponsor, this would mean being unsuccessful in their leadership role and likely deviations on career plans.

Here are the most common reasons for pitfalls, primarily aimed at Project Sponsors, CFO’s, CPO’s and Shared Services directors, that can cast your project in negative light setting you up for failure.

#1 downplaying change management in procure to pay projects

With Change Management here I mean the process, not (necessarily) a role. Change Management should be seen as a process which ensures everyone within the project team thoroughly understand the people and process impact the project presents to their organisation. This is the journey people and culture of the organisation is required to take to have the solution designed, successfully implemented, deployed and adopted so that business case benefits can be realised. Remember that not everyone is and can be support in your initiative no matter how good job you are doing communicating the benefits so getting everyone in the organisation behind your initiative is not always not possible. Ultimately your success may be a threat of unemployment or retrenchment for many. Solid Change Management plan aims to identify the individuals lacking in support and more importantly, whether their support matters.

#2 trying to solve the world -syndrome

It’s easier to get funding when your project plan and business case promises to solve the problems of the world showing a rapid ROI, however is this the purpose of the case you are building? Don’t build a business case which is too much to digest, rather aim to break it down to bite size chunks and introduce the benefits gradually. Look for technology and process scope to deliver which can be deployed in phases and tested for assumptions. If you were on a quest to solve the problems of P2P for your organisation, why not start with AP or even a portion of your AP? This is great area for calculating tangible returns for your organisation and showing a solid ROI. Additionally, it is important to begin showing early success rather than take on too much.

It is a good idea to get something of high visibility delivered fast increasing your teams credibility and getting you on a path of further funding acceptance.

#3 the illusion of risk with smaller technology providers

There is plenty of great, modern technology out there but largest organisations tend to choose the safest, most reputable providers which withdraws from the innovation, savings realisation and process efficiencies they could otherwise realise. Technology driven innovation does not sit well with the largest players in the industry, in fact the largest failures of the industry come from the big players. Don’t fall for this trap of thinking this is your only option. Any modern technology out there allows you test the returns you get by building a proof of concept, or by conducting a low cost mini implementation of your solution. This is a great, low cost, risk free way of testing these assumptions and enables a much broader filter of technologies allowing you to tap to innovation of AI, RPA and the best (not the largest) providers of P2P tech in the market. Large technology and process transformation projects are always made of components which can be tested. If you hear otherwise, it is likely you asked a sales person. Avoid falling for this and test your commercial returns, process efficiencies and technology you are planning to sign up for otherwise you end up with an expensive technology with long, sometimes negative, return. You can implement modern, disruptive technology with very little risk, if you understand the and know how to structure you concept test to validate your assumptions. The benefits of this are adoption of risk free innovative new technology, great cost and process efficiency gains and ultimately greater advancements in the back office compared to your competition.

#4 making political compromises without understanding the impact on your procure to pay project

Navigating corporate politics is a hard skill to master. Decisions that are politically correct are sometimes justifiable and required, however there is a fine line between making a politically right call that adds to the success of your project vs. making one that withdraws from it. A wrong, politically correct but irrational call can be demoralising for the project team unless they thoroughly understand why the decision has been made. Communicate effectively the choices you make so that team is and stays on your side of the delivery. If you get mixed messages that are difficult to comprehend, get an unbiased advise to understand the impact of the decision to your business before making a call.

#5 “don’t give me problems, give me solutions” -mindset

We have seen many great sponsors falling for this trap by discouraging their team to bring problems to daylight. If you don’t want to hear about problems and let that show, the likelihood is soon you’ll stop hearing any and are literally waiting for the bomb to drop. Your team is not always ready with a solution as sometimes project delivery, scope or design issues can be complex. That does not mean these should not be tabled. In fact it is quite the opposite.

Hearing the bad news as soon as possible is crucial for the team and the sponsor to act on time and getting way ahead on solving it. The problems will not go away with an act of ignorance. Empower and build courage and confidence within your team to bring the problems out as early as possible. Once analysed and understood, they can always be solved. Do not try to avoid the difficult discussions. Openly communicating teams are proactive in problem resolution, whereas closed teams end up into a loop of reactiveness. Needing to jump on issues when they pop out is often too late. This is counterproductive and deviates the project from planned activities.

#6 concentrating on product rather than the solution

Organisations tend to spend a lot of time aiming to get the Procure To Pay product selection right. Product is important, however, in our experience is not the leading factor towards a success or a failure. Most of the organisations don’t choose a wrong product even if this is often is the blame point. Instead they fail on delivery and being able to merge the technology with the business processes of their organisation. Procure To Pay delivery requires a streamlined, simplified processes to be deployed, and an experienced team that has done it before and knows the pitfalls, has really good understanding of your business, and an efficient methods of communicate this knowledge back to the technology vendor tasked with technical delivery and often integration. The vendor is not an expert in your business but their product, and the best vendors admit that upfront. Your vendor should also be used as functional advisor on what does and does not make sense to be delivered on their product. This means the vendor should be confident enough to say NO. It is always the job of the project team to make the ultimate design decisions and most of the time, getting the processes right around Procure To Pay require a lot more work than the actual technical delivery. The technology almost never is the reason for the lack of success.

To succeed in Procure To Pay delivery, you need an expert team in P2P deployments that can be held accountable for the outcomes delivered and measured by the business case benefits realised. Only then you have reached the right level of ownership over the initiative.

#7 strong sponsorship

Once the business case is solid, signed off and initiative(s) move to delivery, very strong sponsors is required to take the noise away from the project team. At this point, the team really should be fully concentrating on delivery. The reality is that the project team should be working with teams in support, not against, of their initiative. If the internal selling is not done by the time of design and implementation you may find project teams engaged in hours, days of meeting aiming to convince their peers on why this is the right thing to do. A weak sponsor let’s the discussion of scope deviations and political matters de-escalate down to Project Teams, and what happens the project teams end up wasting their time on non-productive, scope, alignment seeking meetings rather than getting their hands dirty designing and delivering. This is largely unproductive and makes initiatives stall rather than progress, often leading to cancellation of projects.

This may make Procure To Pay delivery sound like its all doom and gloom, but a good preparation, realistic business case process and a knowledgeable, experienced team which not just plans but delivers the project can avoid all these pitfalls and help you get your returns.