Implementing Technology? Five Things You'll Need Besides Software

People

We have heard the adage "People, Process, Technology" for decades, and for good reason, but which people? The obvious choice in most cases are people early in their careers, as it is common knowledge that younger generations have had technology as a part of most of their lives. The danger here is that employees that should be using features or modules within the platform may offload work onto others that have learned the tools more quickly. This can lead to anxiety, role overload, and morale issues beyond a failed tech implementation.

To avoid this, divide tasks for the new tech into smaller, more distributed chunks. Obviously, this depends on which tech it is and how it applies to the work, but identifying more reasons and more individuals to interact with the technology will help avoid having only a handful of individuals saddled using the platform for the entire company.

Different types of end users will learn in different ways. The implementation team will need to have a variety of delivery formats of the material to be ready if the initial training program is not yielding effective results. If they are in situ, tactics such as vendor videos, help files, or blog searches will not provide feedback at the pace they work. Focus on techniques that more directly provide the support they are looking for. These may include creating something as simple as curating text groups.

Processes

Most leaders within a firm would agree that their high performers can execute work and keep the company profitable, but ask these high performers specifically how they succeed at what they do. In most cases, you will get a shoulder shrug. To find success, both the low and high performers need to be able to accomplish their work at whatever level they are capable. A standard operating procedure maps out what needs to be done and how the new tech supports the work stream, but you cannot improve a standard that doesn't exist.

Whether through shadowing, role swaps, or focus groups, a collection of the steps involved in completing activities needs to be documented. The process should be as agnostic of specific technologies as possible, but for some processes, this may be unavoidable. The format of this documentation should be as aligned with the current company culture as possible (more on this later). If the staff or project teams live in an environment that is highly autonomous, then perhaps just illustrating the inputs, tasks, and deliverables, leaving the order to them, may work best. If the culture is siloed, showing the current responsibilities of each functional group along with the interdependencies among each may resonate better.

Funding

After years of being responsible for seeing investments in technology return value for the company, what never ceases to be true is that unfunded mandates have very short lifespans. Unfortunately, many technologies do not provide a value this directly. Most support indirect values or manage soft costs (e.g., preventing costly accidents, streamlining communication, or visualizing data in a more compelling way). No believable dollar value can be calculated to quantify these advantages, but the technology vendor is expecting to be paid in real money.

After the initial activities have been successfully completed, how will future licenses, training, and continuous improvement be covered? This could evolve into a "project tax" where a line item is included as a standard in the general conditions of all projects. If the value that end users experience is well documented and well publicized, this can work well.

Another approach can be to put plans in place to decommission legacy systems and solutions. If a new enterprise resource planning system is rolled out but is run concurrently with legacy processes that involve third-party consultants, try tracking the uptake over a predetermined period. The spend on consultants could be dialed back proportionately. Then, the case for continuing the technology spend at the next budget cycle should be less arduous.

Understanding of "Business as Usual"

If the company has grown to a point where resources are available to innovate, learn how it got there. Many of the answers will be embedded in the culture. If the technology implementation is not at a scale that includes a culture change, then the current culture will need to be factored into the rollout. Most importantly, do not break something else that is working well in the push to finalize this implementation.

As mentioned, whether the culture at the firm values autonomy or has a command-and-control structure, everything from the training program to the roles and responsibilities should fit within the culture. If certain activities are typically purchased or delegated to a subcontractor, then design a way for subcontractors to be onboarded to the tool so they can complete the work they normally do. However, this is easier said than done. It may involve custom permissions or access be developed to allow this to happen with the technology in question. If the tech is replacing a legacy paper-based system (some electronic version of a "paper trail") mimicking the sign-offs, checks, and balances, approvals need to be developed or the new technology will fail in such an environment.

Adequate Time

Even team members who consider themselves enthusiastic, willing participants are limited to the rate at which they absorb new, technical information. It is well accepted in professional circles that, on average, it takes an adult seven exposures to a concept before it is truly remembered, understood, and can be applied. The hour-long introduction employees will be made to sit through on the new platform could only be considered one.

Devise plans that will allow the implementation team access to previously trained users after periods of time where they have either attempted to utilize the new tool or have completed a project with it. Plan on different formats to accomplish this. If the initial training had users coming into the office, is it feasible to send members of the implementation team to the field for follow-up consultations?

Conclusion

If your team has honestly done the due diligence to find what is truly the best-in-class solution for the problem you are trying to solve, do not let the following "missing ingredients" tank your efforts.

• People. They are the key to any amount of success in the business world. Treat them like the vital resource they are, and consider concepts that prevent them from suffering any "techno stress" or role overload. Divide and conquer!
• Processes. Take any steps necessary to learn as much as possible about how high performers work. The technology you have invested so much into only succeeds as part of processes that are working best.
• Funding. An unfunded mandate, also known as a memory in most cases, cannot be how your implementation is described. Make plans that not only maintain the platform but do so in a way that is not a drain on the company.
• Business as usual. You will need to understand what drove your company's success. If the company had a jolt in growth years ago, what allowed that to happen? The new technology needs to support these facts and leverage them to drive progress, not throw them out the window for the sake of change.
• Time. We all have people we answer to and often give them the answer they want to hear. The truth is people absorb new information at a finite rate and this singular technology rollout is not going to change that.

With masterful execution of these five crucial ingredients, you will find this technology rollout on that "fun" side of the 84 percent mentioned earlier. You can feel confident you can give your team high fives all around and enjoy your ride home.