Category: Digitalisation tools and tips

Procurement activities vary greatly from one organization to another, depending on “how mature the organization” is. The more mature it is, the more strategic their actions are and the least they operate admin tasks. The journey to procurement maturity doesn’t happen just because the team grow “older” – it is the result of a culture of value creation, a culture where everyone is critical of their own- work and ask themselves: Am I adding the most value while performing this? How can I do better?

When I first started to work as a procurement practitioner, I was amazed to see that the team was still operating plenty of admin tasks: cutting the PO, sending them out to each supplier, chasing delivery issues and eventually solving invoice on-hold issues. The amount of time spent by me and the team was considerable, and eventually, we had to fall short on the projects that mattered and added real value. Our stakeholders were not convinced by our procurement value (sometimes referring to us as the “pen buyers”) when they had all those “important purchases” they had to make themselves.

Fortunately, our manager at the time understood this challenge very well and had us started on a hunt for low-value add, repetitive tasks**. She first asked us to identify these tasks and quantify the time it was taking.** With the groundwork analysis done, it was then easier to find solutions to the most time-consuming processes and build the business case to make the changes happen. And surely enough, we identified massive time wasters, such as creating and sending the daily POs manually, supporting low-value and non-recurring buys, and resolving invoicing issues. We then had for objective to either Eliminate, streamline or outsource them.

Find a way to eliminate these three processes alone, would let us save nearly one headcount (20% of the team at that time!) that could then be reallocated to more strategic actions such as tenders, risk management, improving the user experience etc… and gain the business trust!

To do this, we went through the three ways that a process adding little value can be dealt with :

• Eliminate : Sometimes, organisations are doing things because of historical reasons and no longer have any true use. Think of that report that nobody’s reading anymore but still takes you hours to come up with. A good way to eliminate processes is by completely automating them, learning RPA or just Excel VBA can be a wonderful asset for procurement to automate (eliminate) tasks.
• Streamline: If a process is important and cannot be eliminated, then the next best solution is to streamline it by removing unnecessary steps or part. Think of your process to buy tail spend (low value, non-recurring), can that process be simplified in terms of need identification, supplier identification and setup, PR to PO process? The best course of action here is to map out the current processes and work with your stakeholders to identify the best alternative. For instance, by working with my legal POC, I was able to streamline my contract approval process from 14 to 1 day by aligning expectations between legal, the business and my suppliers through a standard addendum. The gain in efficiency was massive.
• Outsource: Last but not least, ask yourself if you or your team is the best positioned to perform the task and if not, try to find a way to outsource it :
  • Internally: In the case of invoicing issues, it is fairly clear that this task should be handle by account payable who has the tools and access to resolve this easily but often, procurement remains owner of the resolution. More generally, there are often tasks that should be reallocated to their legitimate owner to make them more efficient; find them and work with the business to transfer ownership. Document and work collaboratively, as these teams may well oppose this newly found ownership !
  • Externally: Sometimes, the best solution is to outsource the task to a third party: whether a digital solution provider or consultancy that will handle it for you, or an incumbent suppliers that will go the extra mile to adapt their process to yours. These third parties can be a great source of value for you as they may have the tools and experience to deal with these tasks more efficiently than you. However, make sure that you don’t outsource a mess! Understanding and streamlining the process before is key to ensure the outsourcing will be successful. If you don’t know what and how you want it, there are little chances a third party will do it well for you.

After having eliminated, streamlined and outsourced our low-value tasks, the team was now able to focus on more strategic activities with more time and focus. The team went on to support their first European tenders and gain recognition from the business stakeholders who actually enjoyed working with to make their process more efficient!

And you, where are you in your procurement efficiency journey? Have you identified your top time waster or are you already moving on to streamlining them?

Deploying technology successfully is a hard task, and the pilot phase is a critical step to assess whether the solution will be adopted and bring the expected benefits. Running a pilot and flying a plane are quite similar: the first (take-off) and last (landing) moments are the most critical and the ones that require the most attention. In between, the crew can usually relax a little bit more and rely on autopilot.

After sharing the 5 steps for running effective technology pilots last week, I will now deep-dive into the take-off, or the hyper care phase and what to do in the immediate weeks after the pilot go-live to ensure that your project does get off the ground and reach cruise speed.

Why is Hypercare important?

In the ideal world, we wouldn’t need Hypercare – and perhaps that is why a lot of organizations are just launching their digital solution, and waiting until the end of the agreed period to see if there has been adoption and results. In the ideal world, the solution has been connected perfectly, all data flows correctly, and the users can do exactly what they want/need without any training and experience errors.

The reality? There ALWAYS are some errors, things that weren’t considered and those will lead to dissatisfaction or issues. And think how important the first experience is: if there are problems, or issues that aren’t addressed immediately, your project will die down by lack of adoption. Think about this marketing saying that one dissatisfied user will tell 6 people. Any bad experience with the tool will snowball and may give the solution you are trying to get adopted a bad reputation.

To avoid these critical early mistakes, or at least minimize their impact on adoption, best-in-class organizations set up an Hypercare phase. The Hypercare is a phase in the pilot, typically the first few weeks after the GO-live, where the project team will function with an elevated level of support and resources. During this phase, every aspect of the solution will be scrutinized, issues identified, tracked, and resolved to ensure a successful first contact with the tool.

Running an hypercare phase will therefore aim at having a complete view of the functional and technical performance of the solution, from end to end (including actual user feedback). It should also be used to start iterating on the KPIs, weekly flashes, and other information you are going to produce and use to evaluate the solution. You may realize that some important evaluation points were missed while others may actually be less relevant than you imagined. Either way, it is important to remain open-minded and flexible during this period: be ready to try, change, and experiment with a lot of things during that limited time.

A big part of the success of your digitalization project will rely on these few weeks of hypercare, make it count!

How to run Hypercare

The hypercare should start the very day the solution is pushed to the end-users and should run for a defined period of time: ideally up until the first pilot review.

The goal of an hypercare phase is to make sure that there are no blind spots. the project team’s attention will be focused on the pilot metrics all the way down to the most operational aspects, all the way to the number of clicks users are taking if that’s relevant! Each transaction should be looked at and understood from end to end. – there probably won’t be that many, the big bang deployment doesn’t exist in digital transformation.

Set up an agile team and experiment

The project team – with the suppliers! – will have to dedicate time and resources to produce and analyze the data, track user feedback, and ensure speedy resolution of any issue arising. The hypercare should be led by the project manager and the core project team, but it is also desirable to have other functions stepping up in the process. Good practice in some cases is to ask suppliers to assign a dedicated Customer Service (CS) person, preferably one of the best in the CS organization, who could then act as the focal point, track and resolve any issue that was arising. This really is important as in most cases, the customer service will be done through a general alias/phone number and the information gets lost, the dots aren’t connected. Make sure you understand how your supplier CS is organized; if there are different levels of supports and what are the main workflows, etc… When engaged correctly, the supplier’s CS can truly turn into a key enabler for success.

During this time, the entire goal is to understand what is happening and PILOTING it. Understanding and tracking the KPI isn’t enough, the goal of a hypercare phase is also to try as many things as possible. These piloting activities can be technical (changing a setup), communicational (sending more, or different documentation…) or a change in scope (Extending or restricting the scope, experimenting with additional functionalities that were deemed less relevant, etc…). When making these decisions, make sure you are tracking the effects week on week so you can roll back quickly anything that wouldn’t make sense. Organizations that launch tech pilots and wait until the end of the pilot period to see if it works are very likely to face disappointment. Instead, the successful ones will experiment with all sorts of things and be bold, after all, this limited scope of users means the risks are very low, and trying anything later will become more complex and risky!

Eventually, those tasks require a level of attention that is not sustainable and that’s why it should only last for a few weeks. If you need to maintain a high level of control and follow up after, this probably means that you have a deeper problem: either the solution does not work or it doesn’t answer the needs of your stakeholders.

And put the user at the center of it all

A successful hypercare will look at the technicals (is the solution working as expected), measure benefits (is the solution delivering what it is expected to) but most importantly, will focus on the users and their experience.

The first goal and one that needs that need to be achieved as soon as possible is to train the pilot users to use the solution. The training should cover two parts: how to use the solution (where to click) and when to use it (what are the use cases where the solution is relevant). There are many ways to deliver training: live training and office hours are my favorites, but online classes, quizzes, and other learning tools can be effective as well. What is important is to give these training resources to the user, and make them available at any time through offline versions. These offline documents are often overlooked and consist of a few PDF uploaded on a drive somewhere. This is not right, these documents are what will help your users use the solution you want them to use, so they have to be well thought out: it can be very disheartening for a user who takes the time to seek information and only find uncoherent, half-complete documentation.

The second goal will be to establish a 2-way communication channel with the users and collect feedback. The project team should have several KPIs from the pilot to judge performance but qualitative feedback is at least as important and collecting it requires a different set of mechanisms. Setting up a system of ticketing, or a dedicated email address to send feedback onto can be a good way to collect feedback passively. The main issue with these methods is the bias they incur as people are more likely to give feedback when something went wrong rather than take time to give positive ones. Focus groups with 10 – 20 pilot users can help overcome this bias, they are a powerful tool to understand user perception and experience with the solution (or lack of as you should also invite people who didn’t use it!). These sessions will give you insights that hard data never will, positive or negative.

In summary, if you want to make sure your pilots do take off and don’t become one of these zombie projects, those that are moving but with such little vitality that it’s as good as dead. The first weeks are crucial to get your project take-off so don’t miss out your window. Running a structured hypercare does take time and resources, but it is worth it as it is the only way to really test and deploy new tech.

Internal communication and stakeholder engagement is key for any successful project, everyone can agree with that. Between the weekly, monthly meetings, the project updates, and steerco, the amount of time spent in various communication mechanisms can be huge -think 5 hours a week- with results often mitigated. When was the last time you ran a project and everyone felt consulted and considered enough? The last time someone shared a last minute feedback and you wished they expressed it earlier in the project?

One tool that I have found particularly interesting in the project communication toolbox is the office hours. The office hours are basically a time, usually an hour, set on a regular basis where you make yourself available on an open conference ID (or a actual room!) and let people come at their convenience during the hour to answer 1 to 1 questions.

I find office hours particularly interesting in business, for projects where reaching to everyone individually would be too difficult or time consuming because:

• It helps creating an atmosphere of transparency and openness: people know where to find you, and know that you will be open to discuss during this time.
• It saves time and removes friction as people can come, ask rapid questions, and get an answer without going through the trouble of sending emails, finding calendar slots etc.
• It helps you increase the number of 121 interactions, which may lead to hearing new perspectives on an issue you may be facing and increase stakeholder buy-in.

Best practices:

• Frame the office hours to get people to come and have specific topics to discuss with you. Make sure you have given them updates on where the project is, what are the lowlights, highlights etc. Office hours on their own aren’t enough.
• Make sure the time and location are known. It is nice to use the quiet time of an office hours to do some emails etc, but it shouldn’t be the point. Make sure you are advertising this time enough, send calendar invite and mention this designated time as often as possible.
• Educate your stakeholders. Instead of replying through emails to any question, tell them to come to your office hours to talk. This will improve your productivity and favorise face-to-face interactions.

Use this when training people to new tools or processes as well! In addition to the classic instructor-led training and user guides, setting up some office hours in the immediate weeks of such projects can help drive adoption as people may not be available for the planned training, and face-to-face interactions remain more effective than user guides.

Are you using office hours yourself ? Any other benefits or best practice to share ? Please do so in the comments below!

Deploying technology solutions successfully has become the biggest stake of businesses around the world. With over 70% of technology transformation failing, organization really have to reflect on how to launch technology solutions effectively. What drives that high level of failure? In nearly all cases, the reason for the failure isn’t technological (the technology does work as intended) but rather a problem of adoption of the solution.

For me, one key reason for low adoption and failed digitalization is a poor approach to project management and especially in the piloting phase.

Some organizations may skip piloting altogether because they expect people to adopt the new tech immediately and launching globally may seem like a good idea, but it never is. When pilots are run, the vast majority of organizations will underestimate the need for structure in their pilot and it will fail. In most cases, the transformation will fail because of piloting resulting in poor adoption and not the technology! A good pilot will serve the purpose of i) verifying the technology works as intended, ii) making sure that your organization will adopt this solution and iii) verifying that the expected benefits are delivered, with a limited investment in time and money.

So how can we run better pilots and make sure that adoption is high enough to make informed decision?

I. Define the scope:

Defining the perimeter of the project is the first important step in running a successful pilot. It is important to define a scope that is big enough to get representative data but small enough to keep some control over it. To define a scope, you will need to identify “who” and “what”.

Defining the people who are going to be part of the pilot is perhaps the most important consideration. The idea is to identify a pilot population that will be representative of the global population and avoid falling into the trap of piloting your solution with a cohort of your best performers. This will skew the results positively during the pilot and may translate into a failed rollout.

It’s also important to avoid two traps when defining your pilot population:

• Include detractors as well as supporters in the project. As Machiavelli wrote, “keep your friend close and your enemies closer”. Including the detractors in the projects is a great way to sway them over, or at least make sure that their arguments are well-founded rather than opposed in principles.
• Don’t create divisions between pilot users and non-pilot users. Try to keep your scope of users coherent with your business. It can create tensions when you designate pilot users and non-pilot users within a same office or division, especially if the tool does provide great value.

Finally, don’t neglect the other stakeholders, even if not directly using the solution, like the various finance controllers, operation leaders. Keep them at least informed with the periodic reviews (see last point).

The what, in procurement, would be to define clearly the categories of spend, or amounts from which the solution should or should not be used. A common failure at this stage is to launch a solution and expect that the users will figure out when or for what purchases they should use the solution. It should really work the other way around: you need to tell the users when they should be using it, otherwise they will just not use the solution.

II. Define the timeline:

Defining the timelines for the pilot is also an important step for success. That means that all steps, including before and after the pilot must be planned, but also that the pilot itself must have a clear start date and end date. How long is that pilot going to be? There is no clear and universal length to this, as the duration of the pilot should be dictated by how long do we need to get enough data to make an informed decision. This means that duration also depends on how many people you included in the pilot, the more people the shorter and vice versa.

A too-short pilot means you may not have enough data, or will be missing the peak of the adoption curve. All pilots (and technology changes) have a certain inertia, caused by the learning curve and change of habits so if you are cutting the project to early, you may miss that momentum and make wrong decision.

A too-long pilot means that you are either using resources for a project that should have been abandoned as not probing, or that you are delaying the benefits of the roll-out.

Once the ideal duration has been identified, it is important to schedule the Go/No Go call where the decision to roll out or abandon the pilot must be taken (see more on this in the section below).

A basic good practice to remind here is to have a project tracker with all milestones and ETA, and that is updated weekly by the project team and shared in the flash ( See periodic reviews section).

III. Set goals and KPIs:

Setting the goals and KPI of the project is also critical to do from the onset. The idea is to set a number of goals for the solutions: between 3 and 5 and use KPI to validate them. By identifying clearly what success looks like, you are facilitating the follow-up of the project (are we on the right track ?) and perhaps more importantly, the Go/ No Go decision (do we go to roll out?).h

I have seen a lot of organizations forget to set up these goals and KPI and arrive at the end of the pilote only to scramble to find some data supporting what they think is the right decision. This is just poor project management.

Another problem when timelines and goals haven’t be clearly defined is to get stuck into the “never-ending” pilot stage.

That’s why from the onset, you should define a Go/ No Go checklist, (included in you project plan!) so that you summarise all goals, KPIs, who is responsible for getting the underlying data etc.. and can update this list as the pilot goes.

When defining your goals, I recommend defining your methodology for savings calculation – that may save you some painful discussion later on.

Example : The solution must provide an improved experience compared with existing ways of buying.

• Improved time from order to delivery in days
• Time spend per order in minutes
• Reduction in errors and exception handling in %
• Ease of use (As per survey and focus group)

To add some Time-bound element to these SMART goals, you can set these goals to be attained at the end of the pilot, but can also add intermediary steps to make sure you are on track during your periodic reviews.

Also, while you should use quantitive KPI to suport your decision, don’t underestimate qualitative ones: run focus group, survey your users about adoption, satisfactions etc. . As adoption is the key factor, make sure that you are listening to your users in those sessions. A very common pitfall is for procurement to recommend what they think is best, but if it is not what users think is best, your solution won’t be adopted and the roll-out will fail.

Users’ quotes taken from focus groups are a powerful way to support a Go/ No Go decision. Don’t underestimate them, after all, success stories is why you are deploying the solution in the first place.

IV. Define the project team:

The core project team is in my opinion the most important important thing to get right to be successful. A successful pilot needs great alignment between your internal stakeholders, but also with your supplier.

Internal team :

Assigning a project manager is a key step in organizing your pilot, and most organizations are now understanding that project management is a job by itself and should not be someone’s second hat. Your employees aren’t batman and cannot have two identities…

On top of the project manager, who is going to focus on the project deliverables, the most successful organizations I have seen also had a dedicated change manager (or communication manager). Successful deployment have a ‘social’ strategy, where communication will be planned strategically, with a deep understanding of the key influencers, and possible organizational blockers. A mistake most companies make is to neglect this, and suffer the consequences.

Also, if relevant, constitute a network of “power users” with whom you will be communicating more intensely than with other classic users. These people should be a mix of advocates but also detractors so that you collect more objective feedback and get a population of hyper-engaged people to spread your word internally.

Define an executive sponsor:

The decision to start a pilot should be top-down, but the decision to roll out must be bottom-up. Follow this rule and you increase your chances of success significantly.

The common mistake that many organizations make is to use leadership incorrectly, or not at all. it is so prevalent that I am actually using a separate section for this. Any project should have a senior leader sponsoring the project assigned from the very first day. This means that their name will be associated with the project, and its outcome: the Go/ No Go decision for roll-out. Sponsors should have the power to escalate and enforce policies when required, i.e. if resistance to change is too high, processes aren’t followed etc.

Equally important, make sure you have identified (and preferably met with) your account manager’s manager. This person should be the mirror of your executive sponsor and be present in the key milestones of the project like the intermediary and Go/ No Go meeting (see below part 5)

External:

Don’t underestimate or forget to clarify what you expect from the supplier in terms of data, reporting, and other resources. you should also have defined the contractual framework for your collaboration during and post-pilot. It is acceptable to leave certain points open to start a pilot, but the resolution of these points should be tracked and added to the “Go/ No Go checklist”, but ideally, try to align the success (i.e. the adoption) of the pilot with the remuneration.

Also, procurement tends to underestimate the role of the supplier’ account manager: Don’t. Great account managers are invaluable, they will be proactive in solving issues and proposing improvements, data and save a lot of time and issues. If you are worried about the performance of your supplier’ team, make sure to escalate and obtain the right resource.

V. Review periodically:

Set up reviews and communicate updates internally throughout the pilot phase, balancing weekly update, intermediary reviews and the final decision. Most organizations are launching new solutions and waiting until the end of the pilot to see whether it has been successful or not – the best organizations review progress weekly and establish corrective actions to make sure they are on track. Make sure you identified and planned all of these steps from the start of the pilot, this creates a certain accountability toward your stakeholders and establishes a real two-way dialogue.

Weekly:

“Weekly Flash” are a wonderful way to communicate on your project regularly, set them up and see how everything will change. By sending flashes that summarise the vital few of your project and the key updates of your project since the last update, you are creating a channel for engagement that is amazing for both the people in the pilot and the senior stakeholders:

• For the people in the pilot, they will want good news to be shared and are made even more accountable for meeting timelines.
• It is also an easy way for the project to get visibility during the months of the pilot and make sure it remains on the radar. If your leadership hasn’t heard of your project in the last 2 or 3 months, you have made your job of getting the roll out approved much harder.

I also recommend to use these weekly flash to invite people to give feedback by advertising the survey and other feedback mechanisms (like ticketing system or mailbox) available to them.

The intermediary reviews and the final Go/No Go call are key steps to take, and should be planned ahead. These meetings should contain the project team including executive sponsors from both sides so that these meetings really are top to top meetings. These meetings require a lot of preparation as you will need to produce all KPIs and provide a comprehensive view of where we are and agree on next steps.

Don’t underestimate the power of the mid-review too. With mid-reviews, you are giving a chance for the leaders, who ultimately approve the project, to weight in, give their recommandations and be aware of how your pilot is going. Waiting until the final meeting to update your leadership is one surest way to delay your roll out sign off.