Although procurement technology is nothing new, there are first-time implementations going on all the time. Whether you are introducing the company’s first full end-to-end platform or adding a new area of functionality to an existing platform (i.e., contract management, supplier information management), preparing a solid business case will help win over decision makers and improve the selection process. Articulating your POV can be the difference between getting the green light to go ahead and more discussion and justification.
I hear and see questions about selecting procurement technology all the time: How do I get started? What should be included in a business case? The risk of moving forward without answers to these questions is that you may be shopping for the wrong thing.
In this series I will share some tips and strategies to take you from building a business case for technology, to the selection and implementation, and, finally, to demonstrating value from the investment. Because not all technology needs and purchases are the same, I’ll start by focusing on first-time technology purchases, including the opportunities as well as the pitfalls to avoid. In Part 2, I’ll address “upgrades” or situations where your organization has grown beyond the technology already in place.
Start by studying the status quo, focusing on people (procurement, distributed users, internal stakeholders, the IT team, suppliers) and process, to determine why the new technology is needed. Don’t forget to consider the potential risks or disruptions to in-flight procurement programs, and – most of all – projected costs. Since you won’t have already picked the exact solution you want to bring in house, the estimated cost doesn’t need to be a fixed number. Instead, be prepared to consider a qualified range based on research and a few prospective solutions.
The key is to do your homework. Be prepared to answer questions and indicate an intent to be responsible if you’re not already assigned with company resources.
Always focus on the business need the new technology will address. Are you highlighting a problem that can’t be addressed without a specific technology or focusing on current transactional work that’s prohibitively inefficient? Collect representative stories that serve as proof of the need, and document anything that has already been tried to resolve the issue. This will demonstrate that you’re not looking at technology as a “quick fix” to something that could be remedied with policies or workarounds.
While you prepare for the approval meeting, don’t go in as though you already have the answers. Executive teams exist to make decisions; tee them up with the information and options they need to be effective, but don’t deprive them of their decision-making role.
Outline what you see as the objectives, priorities, and associated change management requirements. Then you can either have your executive team add to/refine the project based on their point of view, or sign off on the project.
Pause Point: Be careful about asking “Will you approve the purchase of this new technology?” without having a sense of how each member will vote. Carefully consider the personality, priorities, and interests of all internal influencers in advance of the formal business case presentation. If appropriate, try to get them on board before the decision by requesting their input or feedback.
You can’t possibly vouch for the fit or effectiveness of technology if you haven’t seen it in action. Start broad to refine your needs and watch lots and LOTS of demos before finalizing a short list. Be an active participant in demos — not a passive viewer.
- Are they addressing my specific pain points?
- Can I envision how they would accommodate our unique needs?
- What will all of my company’s user groups think of the application?
The user interface is important, but it is just the beginning. The functionality will ultimately determine the success and adoption of the technology you select. After all, a successful deployment is useless unless all user groups actually use the technology.
Keep in mind that you are not just selecting technology for today. Does your team plan to expand, either in number or in approach? Will the organization grow? Does the technology have the flexibility and scope to scale with you?
Once the selection process and subsequent implementation begin, it is critical to deliver the promised results AND tell all interested parties that you have done so. Anyone who played a role in the process – even peripherally – should be kept informed. All updates should be focused on business drivers and outcomes rather than technical minutiae. Procurement often has a tendency to focus on the work at hand, causing us to forget to regularly communicate. Consider this the accountability part of the project: making sure the executive team has the information that proves the technology purchase was right.
The most difficult post-implementation questions procurement should address relate to ROI. Go back to the reasons you gave for requesting the technology in the first place (whether they were process roadblocks or transactional inefficiencies) and document improvements as different forms of return.
If your procurement team has been challenged to be more value-added, the ROI should reflect this. Identify what you can do now that was not possible before, or the new source of information/auditability that is now available to the company as a result of centralized automation.
Although the executive team is the key stakeholder through the approval and selection process, following implementation, procurement must focus on the rest of the organization. It’s one thing to secure the approval; ensuring adoption is another. Procurement must continue to invest the same energy in the launch of the project.
Here are a few tips to make sure your implementation delivers for the entire organization:
- Communication is only the beginning. To increase adoption, consider every user in the organization a key constituent, and provide a progress report.
- The best-crafted messaging in the world can’t fix poor alignment. If you wait until roll-out to consider how the technology works with existing process, it will be too late. The technology’s ability to conform to how your company works should be part of the selection process, not a downstream afterthought.
- That said, it is important to thoughtfully challenge how the organization works, given multiple departments may be involved in the process. If the technology provides an opportunity to improve it, consult the owners of those processes and secure their buy-in.
- Even the best laid plans can not anticipate all situations. Implementation will be the first test of your technology’s flexibility, but it will continue to face tests moving forward. Success over time will be closely tied to the breadth and agility of the solution you have selected — a decision that was hopefully supported by the business case development and requirements definition done up front.
If you already made the investment in a solution or suite in the past, your organization may have grown or diversified to where it’s no longer adequate. Plus, technology is constantly improving, so you may be at the point where an upgrade makes sense. In Part 2, I lay out the strategies for what to consider, and how to make the case for getting the resources that will put the right tools in place.