4 Mistakes To Avoid When Deploying A New Technology In Your Business
There comes a time in every business when it is required to leave behind its existing technologies and replace them with new. This is as true of IT infrastructure and business systems as it is of other business disciplines. Often however, these decisions can be made for reasons other than conforming to a business plan. Perhaps they are made in haste, and don’t bring the business benefits that were expected from the investment. The IT landscape is littered with such failed and incomplete projects.
Here are four common mistakes that are made with new technology deployments.
-
Flavour of the month
Sometimes, rather than following the strategy laid out in the business plan, technology decisions are made on the basis of emotion, because everyone else is doing it, or a supplier actively persuades you that it needs to be done now.
Perhaps the Company Chairman read something in a magazine, or heard from a fellow Chairman about a stunning business success in a rival company brought about by the new technology. He wants to know why we aren’t doing it now.
Frequently such decisions are proof of the old adage, act in haste, repent at leisure.
It is difficult to avoid making this mistake, particularly when it is being forced on you. Perhaps delay, divert and resist is the only option open if it`s coming from above. If a personal decision, or pressure from a supplier have it reviewed.
-
Knee-Jerk response following a business event
This follows a serious business event and is sometimes known as the “Something must be done” response. The Board demand action and assurances that it will not happen again. Rather than a careful and complete review of why the event happened and what current remedial and future preventative actions need to be taken, the response is to deploy new technology to provide an immediate solution, however inappropriate and outside the business strategic plan that might be. “Something is being done”.
The only response to this mistake is to state that all efforts are being made in line with the business continuity plan, and that active steps are being taken to implement preventative measures.
-
Ignoring the users
Technologists are good at technology. By and large, they can select and implement a technology solution with great precision and success. That is what they do, and what they are paid for. However, they are technologists, not people persons, and they often forget or ignore that to be a success, users of the new technology must buy into the new technology and the process of change needed to deliver it.
People like their comfort zone, and bringing in new technology often takes them out of it. They need to understand why things are changing, what effects the changes will have on their workday, and what benefits will accrue to them. They are often wary of change, fearful that because of the change their jobs are now at risk.
Unless they are made part of the change process and kept fully involved and informed about how, why and when changes are to be made, they will be at best apathetic and at worst actively resistant to change. This is particularly true in environments with Trades Unions or Staff Associations.
A corollary to this is the problem of vested interests. When business systems or technologies have been in place for some time, unofficial lines of communication and practices will spring up, some benign, some not so benign. If the new systems challenge these arrangements, then there will be attempts to resist or sabotage the deployment of the new systems. They can be difficult to identify and remove or work around. Sometimes their removal is the main reason for the new technology deployment.
-
Scope Creep and Gold-Plating
Both Scope Creep and Gold Plating can seriously derail a deployment project from its original objectives.
Scope creep arises when the original objectives of the project are changed. This can be by not managing the change request process properly, or indeed at all, the client might interfere, or the original scope of the project might not have been properly understood and defined.
Another common reason is a breakdown in communications between members of the deployment team and the client.
Gold plating is the intentional adding of new features and functions that were not included in the original project scope. This can be done to impress the client, by a team member to impress the deployment manager, or to cover up deficiencies in the technology being deployed.
If properly managed though a change control body, scope creep and gold plating can be controlled, and any additional resources, time or budget authorised. If there is no control, the project will run out of resources, budget and time and fail to meet the original objectives. In extreme cases it could even be terminated.
Both are a mistake, and should be strongly resisted.13