Getting Difficult People to Successfully Deploy Difficult Technology

Sometimes people and technology mix, and sometimes they do not. If you have been employed for any length of time, you no doubt have been involved directly or indirectly in the implementation of some form of information technology – whether a new telephone system, a new electronic mail system, or a new accounting system. On the surface, this change was proclaimed to be beneficial to both you (the employee) and the organization, but upon closer scrutiny, you may have found that it hasn’t really “lived up to the expectations” that were set at its inception. What had been touted as a solution that would boost productivity and provide ease of use, actually wound up being a “real chore.”

What is it that makes the implementation of large corporate information systems so difficult? Is it an innate desire to resist change of any type? Is the technology truly too difficult for us to comprehend and incorporate into our work routines? Let us begin by examining some of the more common ailments associated with large information system implementations.

Common Pitfalls of System Development
First, let me begin by saying that I am not an expert in system development. I simply have had the benefit of being on both sides of the issue (user vs. supplier) for the past 20 years. What follows is not intended to be an exhaustive list, but a compilation of my observed experiences.

User and Supplier expectations are mismatched
This is probably the most common pitfall. The user most often hears what they want to hear, and the supplier says what they believe the user wants to hear in an effort get the contract. Promises and commitments are made that both sides will quite likely be unable to meet, thus setting up future disagreements which erode any built up trust. The best way to sidestep this pitfall is for the user to educate themselves as to other installations of the same or similar technology. Industry trade shows and site visits are an excellent means to gain this knowledge.
User requirements are not clearly developed and documented to the Supplier
In most cases, the user has a general idea of what they want, but rely upon the supplier to “fill in the gaps”. This doesn’t rear its ugly head until the supplier delivers the first prototype and the user states, “That’s not quite how we envisioned it”. The burden is on the user to clearly understand exactly what business they are in, and exactly which business processes this new technology will impact. If the user is not clear on these items, then they will transfer that “lack of clarity” to the supplier. Having a clearly defined and documented set of requirements that are signed off by both the user and the supplier can aid in mitigating the effects of this pitfall.
User and Supplier fail to contain a previously agreed upon “scope” of effort
This pitfall is commonly referred to as “scope creep”. Invariably, as the business requirements become translated into software development, additional features and functionality will be desired. The challenge for both parties is to have a written document in place that, as clearly as possible, communicates the level of detail expected in the final solution. This allows decisions to be made which affect both budget and schedule in a nonemotional setting.
Supplier is not fully experienced in delivering what the user expects
At best, this can be viewed as “over representation” by a supplier who desires to enhance their chance of winning a contract. At worst, this is “false representation,” and both supplier and user will likely suffer. Once again, the burden is on the user to assure that the supplier is capable of performing the effort, and all suppliers’ client references have been checked and potentially visited. The best hedge against the effects of this pitfall is for the user to be fully educated as to the strengths and weaknesses of the supplier. Once the weaknesses of the supplier are identified, the user should have a risk-mitigation plan in place to address those weaknesses.
Supplier suffers from resource issues, thus impacting deliverable quality and schedule
No supplier is perfect, and since a company’s workload and resource allocation vary, what was not a problem during the supplier selection process, may become a problem during a multi-year project implementation. For example, some supplier skill sets are highly specialized. Thus, there is greater risk to the project when losing a $150/hour database architect, than when losing a $50/hour software coder. The best hedge against the effects of this pitfall would be for the user to require a “backup” or “transition” resource plan from the supplier in the event key resources leave the supplier’s organization.
User and Supplier lose trust in each other along the way
When looking back, it usually becomes clear that there were identifiable warning signs which, if they had been addressed in a timely manner, could have averted the effects of this pitfall. This is not unlike a partnership that has gone “sour.” It is very difficult to reverse, but a corrective measure quite often is to replace certain personnel that may have contributed to the trust erosion.

Some of the early warning signs and their potential solutions are as follows:
- WARNING SIGN: Problems which are allowed to smolder
  POSSIBLE SOLUTION: Known problems should be addressed immediately!
- WARNING SIGN: Ongoing personality conflicts
  POSSIBLE SOLUTION: Resolve by getting parties to “work it out” amongst themselves, or remove them from the project
- WARNING SIGN: Ongoing concerns over invoice details
  POSSIBLE SOLUTION: Bring these issues out into the open immediately and resolve
- WARNING SIGN: Meetings between user and supplier become increasingly tense or hostile
  POSSIBLE SOLUTION: Spend more time discussing achieved milestones and resultant celebrations, than project problems
Technology advances cause delivered solution to be “dated” upon delivery
This is a difficult pitfall to sidestep in many instances. Technology always develops and improves faster than organizations can implement it. This pitfall alone can act as a deterrent to successful multi-year projects. For example, a supplier may be originally contracted to deliver an application using Microsoft® Windows® 98. However, prior to completion and delivery, the organization has already decided to upgrade to Microsoft® Windows® 2000. The potential damage from this pitfall is the lack of user enthusiasm and acceptance of the delivered solution. If the best technological solution is implemented at the organization in record time, but the users fail to use it and receive the projected benefits from it, then the solution should be considered a failure. Managing the user’s expectations and the planned life of the solution will go a long way to minimizing the negative effects of this pitfall.