The proceeding article invites senior business, IT, and procurement leaders to rethink the way that they look at, and approach, the purchase of technology.
Procurement is generally viewed as an impediment to innovation. But its limitations are from such. In fact, a well thought and executed procurement together with the business and IT, can be a strategic tool for the organization’s ultimate benefit. When coordinated well, organizations greatly increase their likelihood of identifying the best solution and a ready provider. Their negotiating power also strengthens.Organizations that achieve these outcomes follow 11 practices when preparing to purchase new technology:
- Be Clear on What You Are Trying to Achieve
- Leverage the RFP to its Potential
- Go Beyond High-Level Evaluation Criteria
- Be Certain on How You Will Score Providers
- Do Not Inadvertently Undermine Innovation
- Focus Attention on Where You are Unique
- Do Not Assume That Integration is a Given
- Quantify Expectations
- Tell Providers What Is on the Horizon
- Put Your Cards on the Table
- Do Not Go After Unicorns
And they follow 6 practices when selecting:
- Do Not Surprise the Market
- Do Not Rush the Market
- See It to Believe It
- Do Not Rush the Selection
- Stick to the Schedule
- Staff for the Long Run
While the number of practices may seem daunting, none are complicated to execute. In fact, seasoned IT professionals will know that they pale in comparison with the direct and indirect costs that otherwise stem from a poorly executed technology purchase. And when followed, these practices also protect organizations from post-award objections and litigation.
Embracing technology is the only way for organizations to thrive in today’s world of business. And those that do not will struggle, if not perish.
Remember Blockbuster, Kodak, or Tower Records? Their failures continue to serve as cautionary tales to modern organizations who do not want to be left behind by ignoring the benefits of implementing new technologies.To that end, organizations continue to work aggressively to adopt new business technologies. Whether it be solutions that optimize decisions, transform the customer journey, or streamline administrative processes, priorities are endless. Yet ‘success’ is proving far from easy. In fact, it is a never-ending challenge for most to achieve. And for some, it has been elusive.As at any airport, there are a myriad of security needs and issues to be addressed, such as defending against unauthorized intruders with malicious intent. In addition to traditional threats to aircraft, there are also rapidly evolving tactics to defend against. Airports also face threats from insiders, drones, cyber-attacks, and laser strikes, to name just a few. Public spaces at airports are also increasingly seen as targets and need to be provided adequate security coverage.Since 2006, the Project Management Institute (PMI) has been tracking an array of trends within the world of projects. PMI compiles these trends through collecting firsthand insights from thousands of project professionals, directors, and executives worldwide. Consistent with most other reports published on the performance rates of projects, PMI’s respondents convey sobering realities. Approximately 33% of projects are still not meeting their goals, 43% are going over budget, 49% are being delivered late, and 16% are simply failing.There is no other way to put it. Something is not right! And considering that most projects are technology centric , the push for organizations to embrace and implement new technology is at real risk. But noteworthy to the executives surveyed was a consistent view that their organizations’ choices in solution and provider may be their biggest cause for trouble. From our experience, their suspicion is valid.The truth is that most organizations, public and private, struggle in procuring new technology. Whether it be determining what is to be pursued, selecting the right procurement strategy, selecting the right provider, or agreeing on a fair contract, the hurdles are many. And the implications are real.
The Challenges Encountered When Purchasing Technology
Most organizations must follow strict procurement rules and procedures in order to buy products and services. Such policies exist in the hope that the best possible price and terms will be secured in return for the appropriate product or service. Unfortunately, these policies are often applied in the same fashion regardless of the product or service that is to be purchased. For example, many companies apply the same methodologies whether they are acquiring pencils or selecting an advanced IT system. As a result, there is a never-ending set of challenges being encountered by the company’s selection committees.
Organization Cannot Tell Who’s Best
Organizations regularly struggle to compare and contrast the proposals that they receive from the market. For example, one provider may score relatively high on some requirements while another provider does so on other requirements. Who wins? Organizations are consequently frustrated with the complexity and time required to select the appropriate solution or provider; or the risk of being incomplete, inaccurate, or inconsistent in their reviews.
Ultimately, organizations lack confidence in the selection process or begin second guessing why they made the choice to begin with. As a result, many purchases end up being driven solely by price (i.e., it was the cheapest proposal).
Selected Solution is not Actually a Fit
A second trend rests around organizations not knowing which providers truly have an adequate, and viable, solution.
For example, it is not uncommon for providers to try and ‘fake’ compliance with the hope that the organization does not check their word. Alternatively, the provider may be honest about their solution’s shortcomings but promise to develop all missing features during the project. Are such development plans a guarantee? Many organizations do not carry out adequate due diligence of the preferred solution(s). As a result, many later find themselves encountering delays, costly change orders, and sometimes overall failure.
Provider is not Ready to Deliver
A last trend rests around organizations not knowing, or at least considering, which providers are ready to deliver their solution into the organization. For example, most providers put forward impressive portfolios of client references, polished approaches, and stellar resumes of team members. Yet by the time the work starts, key team members are no longer available. Or referenced clients are later found not to have been comparable in the first place.As many organizations do not carry out an adequate due diligence of the proposed teams (and references), many later find themselves without any real options once the provider attempts to exchange the proposed candidates. Accepting the provider’s requested staffing change results in certain delays and possibly overall failure. New team members are often not familiar with the provider’s tried and proven approaches. And canceling the award requires a repeat of the time and effort intensive procurement.
What Organizations Should Do When Preparing to Purchase New Technology
Technology continues to advance at exponential rates. Consequently, an organization’s targets generally keep moving. And this certainly does not make purchasing a solution any easier. But that is only part of the story on why organizations struggle to purchase solutions. Most organizations set themselves up for failure. Fortunately, there are practical steps that organizations can take to overcome these challenges.
Be Clear on What You Are Trying to Achieve
There is a saying “if you do not know where you are going, any path will take you there’. To get better proposals, and outcomes, from solutions and providers, organizations need to provide adequate context to their solicitations. That is, what the organization is trying to achieve by bringing on a new solution and any constraints that should be respected by the provider. For example, a new solution may potentially be sought for increasing revenue, decreasing costs, increasing convenience, increasing security, or something else. But if an organization’s RFP only states detailed requirements, providers can only guess on what the bigger picture might be. The urgency or deadlines of key features also yield key context for providers as they craft the best delivery strategy. Providers cannot succeed if they are in the dark on overall goals and priorities. That said, attempts at providing adequate clarity can be difficult. That is because the organization itself has not definitively concluded what it is, or perhaps forgotten what it was, trying to ultimately achieve. If that is the case, stakeholders should be brought together to rethink the problem, solution, and priorities.
Leverage the RFP to its Potential
Many see an RFP as a means for an organization to communicate to the market every last need and want of a solution. Others see an RFP as the basis of a contract’s eventual terms and conditions. But an RFP’s potential is so much more. An RFP, when designed correctly, provides organizations the best chance to make the right selection and to negotiate the best contract, in the least time and with the least effort. Organizations achieve this when they write their RFP from the frame of mind in which evaluations will actually take place. That is, they focus the RFP’s development on the aspects that are of most concern to the organization and how those criteria will be later evaluated and scored. While such an approach to RFP development may seem obvious, few organizations manage to execute in practice. One large public sector organization who recently applied this mindset found both their RFP preparation and proposal evaluation times to be cut in half as compared to past purchases. By thinking through their evaluation plan before putting pen to paper, their RFPs became a tool for value rather than just an inconvenience imposed on them by their procurement department.
Go Beyond High-Level Evaluation Criteria
Most organization do well to identify and weight the high-level criteria in which proposals will be evaluated. However, more is needed than high-level. With solutions increasingly comprising multiple software modules and hardware components, each’s importance to achieving the project’s overall goals needs to be determined and reflected before attempting to evaluate proposals. The same holds true for the detailed requirements specified by the organization. For one organization, the impact of applying a more granular and structured evaluation system translated to only needing a third of the workshops and meetings typically held for discussing and agreeing provider pros and cons. Through having a more granular and structured evaluation system in place prior receipt of proposals, the selection committee was able to direct its attention to the big-ticket differences that mattered while avoiding their traditional tendency to dwell over less significant details. As a further benefit, subjectivity by selection committees in their scoring proposals was also reduced.
Be Certain on How You Will Score Providers
Scoring a provider’s level of compliance is seldom binary; that is ‘yes’ or ‘no’. Each evaluation criterion is also different and comprising multiple layers to be considered. For organizations that value references in their consideration of experience, they must decide what type and how many references are enough, or not enough. Similarly, each provider’s proposed speed of delivery, reliance on the organization, and impact on the business, all require a clear and consistent scoring approach. Such considerations are especially important as each contribute to the true total cost of ownership (TCO) to the organization for the project.
Do Not Inadvertently Undermine Innovation
Most organizations are generally seeking new and innovative technology to purchase. And in such cases, there is naturally little deployment experience to be had by start-ups but also established providers. Yet, organizations all so often place experience as a top criterion to be evaluated and scored. Respecting experience can help mitigate the likelihood of a solution not working, not being successfully delivered, and/or not being adequately maintained, organizations must be careful not to overweight the importance of experience. If the organization prefers to consider experience and references, it should do so only as a sub-criterion in evaluating the viability of the provider’s plan; not as an overarching criterion.
Focus Attention on Where You Are Unique
Organizations have more in common with one another than they might think. But no organization is exactly the same as another. To that end, attention needs to be placed most on specifying the unique requirements that an organization has of a solution and less on those that are industry standard. That is, focus is needed more on features that will support a competitive advantage, or significant business constraint, of the organization. If it proves difficult to identify where the organization is unique in its needs, design thinking is one tool that can be leveraged. By looking beyond the organization and considering end-customer needs, and considering how the organization differentiates itself, unique solution needs often become more apparent. This is because an organization’s ability to differentiate in the market is ultimately determined by its core internal systems and processes.
Do Not Assume That Integration Is a Given
Much has been achieved by solution providers the last years in making their solutions more ‘open’ to connecting with solutions from their peers. That is, ready to exchange data and commands through application programming interfaces (API). However, that does not mean any provider’s API will address all of an organization’s integration needs. For starters, APIs only cover part of the integration that ultimately needs to be created between the new and existing pieces of software and/or hardware. APIs also only generally cover integration requirements previously requested by clients; such APIs may not cover any newer expectations on data and commands to be exchanged. To have assurances over integrations to be delivered, requirements need to be clearer on their purpose as well as associated data objects, points of creation, system ownership, access types, service types, and refresh rates.
Organizations must recognize that the purchase of technology is not only about a system. Buying technology is ultimately about buying business value which will be realized in how the technology is applied and works. To that end, ‘best in class’ is only an expectation. It is not a metric for measuring a solution’s expected processing speeds, infrastructure requirements, or output quality. Respecting solution providers do not generally publish all of this detailed information broadly, they can be identified by organizations through various forms of market research prior writing the RFP. Requests-for-information (RFI) are one useful source while benchmarking with peers is sometimes another. But considering each organization operates against different variables, proof-of-concepts (POCs) often prove most useful. By incorporating a POC into the purchase plan and budget, organizations obtain the opportunity to test, evaluate, and consider key metrics for their eventual RFP. Similar to RFIs, POCs go a step further in helping the organization confirm that their ideas will work for them while informing expected timelines, efforts, and costs. POCs ultimately help in an organization’s attempt to employ best value procurement (BVP) rather than focusing solely on price come the RFP stage.
Tell Providers What is on the Horizon
An organization’s plans beyond the current project’s scope often provide important context for providers. For providers to propose a ‘future proof’ solution, they need to understand where the organization intends to go; the organization’s vision and outcomes that it expects to pursue after, and around, the initiative are key. Respecting organizations may not prefer to disclose strategy-indicating details in an RFP, these and other organizationally sensitive details can be protected by requiring providers to sign nondisclosure agreements.
Put Your Cards on the Table
It is just as important for providers to know where the organization is coming from as where it is trying to go. As such, organizations need to thoroughly describe their current business and IT environments in RFPs. In this manner, organizations need to provide context about their current business operations such as processes, priorities, and operating constraints. Current performance levels are also key given a bottom-line impact is, or should be, expected from implementing a new solution.
Details about current software and versions in use, current hardware and models in use, infrastructure, available documentation, and relevant agreements such as for the operation and maintenance of existing systems are also key. As a new solution must be integrated into the organization’s IT environment, with certainty, these details are vital to providers. Providers need to know if they have established connectors or that the interfacing systems are adequately supported by their respective providers.
Do Not Go after Unicorns
RFPs only work if they target solution features and capabilities that can and will be covered by at least one solution; or group of solution providers that agree to partner on the project. While a seemingly obvious mistake to be avoided, all too many organizations build their RFPs for a solution, provider, or provider team that does not exist. Instead, the organization’s wish list takes control of the RFP. And with internal expectations and business cases built on the assumption that all target features and capabilities will be fulfilled by one provider, a winner does not arise come selection time. Or custom development is pushed on the best choice in turn increasing, often unknowingly, the risk level of the project. The situation can be corrected though. By cataloging the different features and capabilities available from providers (via desktop research or RFI) and mapping them against the organization’s ‘must have’ requirements, the RFP’s viability becomes clear. Where one or more providers cover the ‘must have’ requirements, the RFP is safe to proceed. Where they do not, ‘must haves’ need to be rethought.
What Organizations Should Do When Selecting
A strong RFP is the foundation for a successful technology procurement. However, certain practices are vital for organizations working through the subsequent selection.
Do Not Surprise the Market
Unless the right solution and provider are clear from the outset and the procurement is only a formality, organizations should do all that they can to solicit the maximum number of qualified and optimized proposals from the market. To that end, organizations should not drop RFPs onto the market with little to no notice given. Considering the amount of time and effort required for providers to coordinate a compliant and competitive proposal, providers should be given as much notice as possible, and expected timing, of a forthcoming RFP. Whether through electronic announcement or an in-person provider day, any notice can do wonders for market but especially for the organization.
Do Not Rush the Market
Organizations should respect certain realities when building their proposal submission schedules. First, providers need time to digest an RFP before deciding whether they are qualified to submit a compliant and competitive proposal. Second, it takes providers time to develop and submit appropriate questions. Third, it takes organizations even more time to adequately address and communicate useful answers back to providers. Finally, providers need to process an organization’s answers before pulling together and submitting a compliant, and competitive, proposal. Respecting almost every RFP schedule gets extended per request of the market, short turnaround periods is neither warranted nor conducive to receiving as many qualified and optimized proposals as possible.
See It to Believe It
Most salespeople strive to say “yes” to every requirement put forth in an organization’s RFP. Despite the custom development efforts and resulting risk that will arise for their delivery team, salespeople more fear that a “no” on even just one requirement will lead to their proposals being dismissed. Consequently, the organization receives multiple proposals citing “full compliance”. And the ability to differentiate solution quality amongst providers disappears. To overcome these issues and avoid an undesired focus on solely price, requirement evaluation should be concentrated on providers demoing specific use cases for the organization and demonstrating quantifiable outcomes. Written assurances are nice but seeing is believing.
Do Not Rush the Selection
Organizations should respect certain realities when building their proposal review and selection schedules. First, selection committee members need time to read and consider all, ideally pre-qualified, proposals. Second, it takes time to collect, refine, and coordinate smart questions to be answered by providers either in writing or in an interview. Finally, it can take significant time to perform a robust due diligence on shortlisted solutions and providers through their demonstration of key use cases.
Besides the fact that solutions and their selection are becoming increasingly complex, organizations must respect that selection committee members generally do not have much experience procuring solutions. Selection committee members also normally have other obligations fighting for their time. As such, selection committee members should be given adequate time and resources so not to overlook and misjudge crucial aspects of their review and evaluation.
Stick to the Schedule
Letting the procurement schedule slip, as is frequently the case, needlessly increases the costs for providers. More problematic, it increases the likelihood that the technology being purchased becomes obsolete by go-live, if not earlier. By incorporating earlier mentioned realities into the schedule, the project is more likely to maintain momentum. Consequently, the interest of both the organization and the provider also have a higher chance of being maintained through to the end.
Staff for the Long Run
While there are many ways for organizations to better their technology RFPs and selections, continuity of the team remains a vital factor for the organization’s overall project success. Whereas an organization’s RFP team often finishes its job following selection, or negotiation, the organization favors better when they keep core team members on for and through implementation. Besides the fact that the RFP team collected an abundance of institutional knowledge valuable to the project, promises made internally and/or with the selected provider during the procurement best not be forgotten during implementation. To this end, the RFP’s project manager, business analyst, and technical analyst are most important to keep on for the implementation.
All leaders have something to gain from their organizations being more effective and efficient in acquiring technology from the market. For organizations that embrace the steps outlined in this article, everyone stands to win. Procurement leaders can still be assured that the best price has been secured. IT leaders can rest assured that they are obtaining the right solutions and providers. And business leaders can rest assured that they have the technology that they need to thrive in today’s world of constant change.