“Insanity: doing the same thing over and over again and expecting different results.” –Albert Einstein
Here is the third post in a series of four that focuses on the adoption of Procurement technologies.
After looking at:
- statistics that demonstrate that, despite the relatively long existence of Procurement technology, low adoption is an old and recurrent story (part 1),
- some of the psychological reasons why change is difficult (part 2),
this post will cover some of the typical mistakes done in implementation projects and that can be easily prevented.
Some of the mistakes I will highlight find their origin in a fatal flaw: assumptions. Often, people leading a change assume without actually checking on the ground the validity of their opinions. From assuming that the change will be welcome to think that a limited change management will suffice, the curse of knowledge is at play.
Wrong approach and understanding of technology
In business, and especially in the community of domain experts, there is a tendency to look at technology as the solution to all problems and consider it as an end.
And, as Simona Pop says it:
“Technology is not the end goal. It was never the end goal and treating it as such will lead to failure. Technology is a tool to empower people. You cannot and should not forget it’s all about people and the effect you/what you do have on them.”
Also, another common misconception also hinders projects. Many organizations want to use a new technology by applying it to the current ways of doing things. Doing so, they miss the real value and transformative impact of technology.
“The usual methods for boosting performance — process rationalization and automation — haven’t yielded the dramatic improvements companies need. In particular, heavy investments in information technology have delivered disappointing results — largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.” — Harvard Business Review, Reengineering Work: Don’t Automate, Obliterate.
Technology can automate an existing process, true. But, it also enables organizations to do things that were previously impossible.
What will new technology let us do that was previously impossible?
Technology lets us rethink the very structure of how we do things. Consider, for example, the way that Uber and Lyft have transformed urban transportation. There were connected taxicabs long before Uber — but all they did was to recreate the old process. What we got for our connectivity was a credit card reader in the back, and a small screen showing us ads. What Garrett Camp and Travis Kalanick realized was that humans were now augmented by location-aware smartphones, and so you could completely rethink the way you summoned a car. It would be utter magic to someone from the past — that you can click on your phone, and summon a car to where-ever you are, and to know just how long it will take for a car to pick you up.” — Tim O’Reilly, Don’t Replace People. Augment Them.
Absence of (or weak) meaning
Not having a real business case detailing why (a.k.a. goal, purpose, vision) the change is important is a surprising, but very frequent, mistake. Many organizations decide to implement Procurement solutions without a clear picture of what the benefits will be. They have a high-level idea; nothing more.
Because of the lack of purpose, it is then impossible to create the conditions for change, to motivate people and to drive adoption.
”If you don’t know where you are going, any road will get you there.” — Lewis Carroll
Not knowing where you are going negatively impacts an organization’s ability to define the project scope (which categories, which suppliers, which geographies, which processes…) and roll-out (what, where, when, how).
This can lead to:
- missing benefits as some areas will be left out of the project; areas that should have been included in the scope…
- implementing the solution on the wrong scope or on “everything” (the one-size-fits-all approach). This will be very damaging as it will give opponents of the change good arguments against the project.
Together with the impact on scope, not knowing “why” also hinders the ability to define what the deliverables of the project are. This leads to the next major cause of failures: poor requirement management.
Poor requirement management
The fact that there is often a misunderstanding of what technology can do, and, if you add on top of that, a weak business case, then it is no wonder that buying the right technology is often difficult for organizations. And buying the right tool starts with developing the right requirements.
“47% of unsuccessful projects fail to meet goals due to poor requirements management. ” Source: Requirements Management, a Core Competency for Project and Program Success, The Project Management Institue, August 2014
Also, not having a proper requirement management process negatively impacts a project’s budget, schedule or quality. It can even kill a project. Often, requirements are developed or refined along the way. This leads to:
- consuming time and energy that should be allocated to other activities,
- making change management for requirements/gap analysis impossible as a reference or baseline does not exist,
- making development, testing, and acceptance challenging and strenuous as there is no source of truth of what the deliverable(s) should be.
Focus on deployment, adoption is left for later
”We’ve spent an awful lot of money on technology, but I still see people working in the old way,” complained the CFO of a large hospitality company. The result is often widely deployed internal applications that no one actually uses effectively.” Source: Convincing Employees to Use New Technology, Didier Bonnet, September 2014
When an organization launches a project to deploy a new solution, there is an implicit understanding that it also means that the system will be used. But, here again, this is a typical mistake to assume that, because a system is in place, people will use it.
To make a parallel with savings, the difference between a deployed solution and an adopted solution is like the difference between negotiated savings and realized savings.
Too fast into action, not enough planning
”Organizations need to resist the temptation to succumb to pressure from business leaders to get started before the enterprise is really ready […]. Business leaders must understand what it will take to ensure success.” Source: Gartner Says Through 2018, 90 Percent of Organizations Will Lack a Postmodern Application Integration Strategy, Gartner, March 2016
This quote from Gartner, although in the context of ERP implementation, is also applicable to Procurement solution projects.
Individuals have a natural tendency to want to “produce.” They go too fast into action mode and skip some planning/thinking steps. Organizations, because of various sources of pressure, also have the same eagerness to see things happen fast. It adds even more pressure on project teams to deliver.
It happens very often that, even before the planning phase is over, project sponsors, as an example, ask the project manager: when are we live? When is the first workshop?
Being too fast into action and not allocating enough time to planning is a frequent mistake. It is interesting to note that Procurement practitioners know that 90% of the success of a negotiation is in the preparation, but forget that same principle when the topic is the implementation of a Procurement solution.
So, all these common mistakes can easily be avoided by being aware of them and by understanding what actually happens during the introduction of new technology. The fourth and last post in this series will detail that.
If you missed the previous instalments, you can catch up here: Part 1, Part 2.
