#8 – How to Control Technology Procurement Outcomes | Part 2
Part 2 – Establishing Your Specification
The first step in controlling your technology procurement outcomes is defining your needs: being able to clearly state what you are trying to accomplish for your organization, and having an agreement on which voice will represent the organization. With that clarity will come an understanding of what behaviors need to change, and by what degrees, to drive the necessary results. The next step in the process is defining the measurements for the future state of processes and technologies that will drive the correct behavior, more commonly known as “defining the spec.”
The most common mistake made when beginning to define specifications is to start by actually defining the specifications. If specs are the measurements for the end state, then we can’t define specs until we have defined the end state. To do that, we have to build a complete demand model. This includes taking stock of your operational requirements, and lifecycle deployment schedules, including growth and downturn projections. The goal is to build a “Year One Commitment” position. This will be key when it eventually becomes time to negotiate on contracts.
The second most common issue when defining specifications is to spend a lot of time carving out a “wish list,” or any other named collection of non-essential items. These lists only add unnecessary time and complexity to the process. Having unusual or custom requirements is perfectly fine, but define only absolute requirements at this stage. Doing so allows the upcoming and inevitable vendor comparisons to be standardized at the most essential layers.
The third most frequent pitfall has some overlap with the second. This occurs when you treat each component, be it an end-user, a process, or a technology, as being unique until every variable has been proven to already have been captured elsewhere. Instead, the focus should be on templatizing as much as possible. Start from a default assumption that all end users are the same, and break out sub-categories for features or permissions only when unavoidable. A highly templatized stack, be it a workflow or data stack, is not only easier to evaluate and shop for, but it’s also easier to deploy and maintain.
With the foresight of these common mistakes, it clearly behooves us all to take some time and clearly map out how the technology you are shopping for will interface with and change processes, people, and behaviors. Make sure you can clearly visualize how end users will interact with this system and how it will change the way they behave. Understand all of the actions and tasks that an end-user must be able to accomplish through this system. Also look at things from a higher perspective, and figure out how managers will use this technology on a day-to-day basis to improve business and measure the KPIs you’re looking to improve. If you can’t draw a connection from the use of or interaction with this technology directly to an improvement in your KPIs, then it’s time to reassess your objectives.
Beyond just using the technology, end users must also get used to the technology. It’s important that we clearly understand how we will introduce the new technology into the current environment, specifically the migration process but also including how we will maintain, expand, contract, and eventually replace the technology. Make sure you understand who will interface with this technology, both in operational use and maintenance/repair. How will they attempt to use the technology? How will they respond to its interface? How customizable is it? Make sure you’re clear on what systems need to integrate with this technology, and whether they are capable of that now, or if they need to be reconfigured/updated to support this change. Take time to consider what amount of customization, training, and ramp-up time this technology or system will require for it to drive the results you need. Are you equipped to support the additional workload to implement these services? If not, consider looking for an agent that can redirect your commission dollars into implementation services.
Next, make sure you understand what currently works and does not work with your current technology service, to the best of your ability to define. Are there features that users just never understood or picked up on? Are there features that everyone just absolutely loves? Can you quantify the things that don’t work? If bandwidth is an issue, can you identify that 300% more would solve the issue? If you need to improve up-time, what is the specific amount of downtime you can tolerate?
Once you have those, you can finally begin to define the specific outcomes that you are going to shop for. Some products, quantities or other details may make themselves apparent as you’re defining the outcomes, but at this stage we should only be defining the outcomes we need. Some examples are:
- Increase bandwidth so that users are not experiencing congestion (quantified increase amount, if possible)
- Introduce circuit-agnostic resiliency (quantified allowable downtime)
- Reduce current cost per license for productivity software
At this time it is imperative that you still focus only on what is absolutely necessary. That being said, you should still also have a clear vision of what will be absolutely necessary for the near future, so make sure you include the correct growth capacities in your requirements. Do you foresee growth or downturn in the next 12-24 months? You may have multiple locations that need this service, but will you really be rolling them all out within the first year? Is this a change you expect will last a while, or are you predicting another significant change in the next 12, 24, or 36 months? By the completion of this step, you should be able to clearly define the specific outcomes you are looking to achieve with a technology review or change, and each outcome clearly tied to driving the KPIs you have identified.
If at this point, you know the products, quantities, sizes, and other specific details of the solution you’re looking for, now is the time to validate they achieve the right outcomes, and then go ahead and document them in your list of requirements. If you’re not sure what technology will bring the solution you’re looking for, that’s okay. If you’ve got the support of an objective procurement expert, they’ll be able to assist you in defining the finest details of the specifications. However, if you’re still not sure of what you’re looking for, and you don’t have the advantage of an agent in your corner, then the next step from here will be to gather information on various solutions, define the last of your specifications, and ultimately request pricing.
