Successful Deployments Require Good Decisions Plus Consistent Follow-Up
Successful deployments of technology begin with a thorough understanding of what is good and bad about the current way of doing things. This understanding needs to be developed through the eyes of the people who are doing the work today, filtered through the tools and work process they are using to do that work.
Most technology projects do not do this well. Who hasn't seen a great solution proposed and deployed, only to find that it is at best moderately successful? Nobody gets fired, nobody gets promoted and everybody agrees that maybe their processes are a little too unique to be successfully adapted in a technology solution. The usual result is that the new system is used for most basic functions, but small portions of the work remain manual, or at least not integrated with the rest of the automated process.
Which should I tackle first - work flow or automation?
There are two main ways to approach the deployment of technology. One is to identify and fix the workflow associated with the process to be automated before attempting new technology. This has the advantage of making sure that the process which is automated is tailored to the present and future objectives of the management team. It has the disadvantage of being harder to implement, because it is much more disruptive, both to the staff involved with the work and to others inside and outside the organization who interact with them. When doing this kind of deployment, firms are well-advised to allot extra time in order to allow the user community to learn both the new processes and the technology.
Another deployment method is to implement technology to automate the current flow of work and then use or customize the technology to address specific areas of concern. This method has the advantage of being easier to get user buy-in and quicker to get up to speed with the new technology. It has the disadvantage of the risk that it could perpetuate inefficient processes and work flows without addressing the underlying shortcomings inherent in them.
The choice of which method to use can be complex. When making that decision, management should consider the existing workflows, the staff involved, the available time for deployment and the likely impact on external stakeholders (especially customers).
The importance of staff buy-in before the system is put in use
Sometimes the people who use a new system take a variation on the first approach. They tell the bosses and the vendor (or the IT department if it's a home-grown solution) that it's a great system but it doesn't fit their work. They then go on to follow the same process described above (using the system for simple tasks with little or no change to the overall workflow). It has a lot to do with our resistance to change. We need users and management to clearly understand the goals associated with these projects, especially how they will help the users themselves.
At other times the end result is more combative. Users in these situations either say that the system doesn't work, that it's too complicated or that it needs to be modified - but they can never quite say exactly how it needs to be modified. This usually happens when a system is forced on a user community with little or no user input at the outset of the project. Even if the user comments and suggestions add little or no value to the final result from the project, the fact that they had their say works wonders in preventing this type of sabotage.
Only rarely does a system get deployed and used as intended, with happy users, smiling (and responsive vendors) and pleased management teams who are reaping justly earned rewards from the substantial increases in productivity that a successful new system deployment brings. Our purpose here is to describe how we help customers put their projects in the rarified atmosphere of successful and measurable use - on a regular basis. How do we do that?
Choices to offer employees
Sometimes getting user buy-in works best when the new technology is presented as a solution from the outset, addressing user concerns that management has heard for years. Other times, it is more effective to ask open-ended questions and let users present their own suggestions. Which of these methods to use depends on several factors: how motivated the users are, how well they identify with the goals of the organization (as articulated by management), how familiar they are with technology and their overall knowledge of their business. As the learning process unfolds, there are often more questions which flow naturally from the answers to the previous questions.
Technology deployments: valuable lessons learned
We have helped dozens of organizations with deployments over the years. The purpose of this document is to introduce a few of the decision points that we can help you address in order to ensure a more successful deployment of technology, whether it is home-grown or purchased from a vendor.
The first step in a successful deployment is to earn the support of the user community. This is never easy, but it is absolutely critical. Tactics vary, but there are some common factors:
1. Understand the work people are doing today - what they are doing, how they do it, why they do it, what inputs they use, how they get those inputs, what outputs they produce, what they do with those outputs (where they send them and how):
- Learn why they think it is important (everybody feels that their job is important, even if they are reluctant to admit it)
- Learn more about things that are being done, or people who are in the process for no obvious gain of the process of the process in the first place.
- Learn why their management thinks it is important
- Learn who uses the product of their work, as well as how they use it and what it does for them
- Understand what tools people use today - how they use them, how and why the tools were chosen, who made those choices and how the users feel about them
- Learn what is good and not good about every tool they use
- Learn how the users would improve them (and what they would keep)
- Learn why they specified those improvements and why they kept the things that they retained
How to learn this presents another decision point for management in the deployment process. A few user communities work best with surveys they can complete in their own time, while many others would never touch the survey forms. Some groups respond better to bringing a larger group together a seminar format, while others work better with individual interviews. Some learning processes work best when done in one session while others work better when the learning phase of the project is spread out over several days or weeks. Sometimes the approach needs to be very task-specific (possibly even limiting user input to a set of binary choices), while other groups respond better to a looser, more open-ended approach.
Which approach is best to use? That is usually determined by the amount of time available, the urgency of making change, the size (scope and cost) of the problems being addressed, the nature of the organization and the budget available. Whatever approach is used, management needs to be aware that there will be more changes as users and project teams learn more about one another during the course of the project and its deployment. Time and money should be allocated at the outset to deal with this inevitability.
2. Next, we need to learn what management wants to accomplish with the new solution:
- Learn what real or perceived problems are in play, how long the problems have existed, who is affected by these problems (and how)
- Learn what real or perceived opportunities are available as a result or goal of the project
- Understand what the other (downstream) consequences of those problems are and what the costs are - to the people and to the organization
This is usually done before the project is funded, but many management teams see that they have a problem, decide it's worth a technology solution and throw some money at it with little or no exploration of implications. Failure to look at secondary and tertiary issues has derailed many projects, leading to inadequate solutions and a need to tackle those secondary issues in another project, costing time and money which could have been handled in the original project.
It also helps to know what (if anything) has been tried before to deal with this problem - and how it worked out. If the previous solution was successful, what happened to make the problem reappear? If it was not successful, how and why did it fail? Again, this is usually done before a project is approved - it is just important to keep it in mind throughout the entire project. Losing sight of this knowledge can lead to a repetition of previous mistakes.
The benefit of moving forward vs. the cost of not
Whichever it is, an understanding of what management wants is important. That knowledge will make it possible to present that to the entire organization in terms that resonate with everyone. This involves planning - before communicating. To do that, it is necessary to put all that has been learned into perspective, forming a picture of the organization, where it is today, where it is heading (both with and without the new solution) and what consequences can be expected from each path. In other words, we need to understand the cost of failing to implement the technology solution. Gathering a clear understanding of this enables management and the project team to make a solid case for the goals.
Only then are you ready to talk both management and users about actual solutions. Whatever solution is planned, it probably will not have all the functionality desired by the users. Part of the project necessarily involves customizing the solution to the organization. Another part needs to involve reconciling the user community to forsaking the elements of their wish list that are impossible (or too expensive for management's tastes) to provide. Even harder is reconciling management to admitting the truth to the users when it is cost and not possibility that prevents giving users something they perceive as necessary.
The iterative design process
One reason people tend to be unhappy with a new solution is due to incremental learning, an unavoidable consequence of the way our minds work. Often people in the process do not know what is possible to change. When they see part of the process unfold, they think of other, newer things that they want to see in the solution. And, they are impatient to see these new features incorporated quickly.
To deal with this, we recommend an approach that we call iterative design. With this approach, solutions are proposed at the outset and then reviewed on a regular basis throughout the project. With each review comes an opportunity to incorporate "new possibilities" based on what the users have learned from the solution as of that point.
It is hard for most users to accept the fact that the first delivery will not magically solve everything on Day One. Nonetheless, it is very important to understand that the first delivery is just that: the first step, and not necessarily the ideal solution. The candid disclosure of the decision process earns a great deal of credibility with users. Without that, it is more difficult to gain acceptance among the various stakeholders. With that credibility, the users begin to feel that they have a stake in the success of the solution. That feeling is critical to success.
This is the first phase of the successful project. It will often play out over several weeks, and sometimes it will take months. In a few situations (usually involving large organizations and complex solutions), it will be years. It is much better to do this part right at the outset. The cost is real, but it is much less than the cost of trying to fix problems afterwards.
Even worse, some problems that result from failing to get the initial buy-in can never be fixed. Users can become embittered and dismissive of the solution, concluding that it makes things worse than before. If this happens, it can become a cancer in the organization. That such a cancer is avoidable makes it all the more tragic.
Get as much consensus as possible from the outset
The next phase is to outline what is planned and to negotiate each step with the users, the system suppliers (internal, external or both) and management. This can also be tricky, but at least it is relatively straightforward. A key element of this process is to get hidden agendas on the table so everyone can be assured that everyone else is being honest with them. When there is a consensus (or even better, unanimous agreement) on the path forward, the project team can begin executing the plan to follow that path.
There should be broad participation in deciding how to go about building the new solution, but at the end of the day it is a management decision. Some firms choose to build the entire solution at once. Others roll out a prototype to a small test group and then they continuously improve (actually re-build) the solution over a period of months. At the end of that process (which may or may not have specific time targets), they have something that they are ready to introduce to a larger audience.
It is important to have frequent reality checks with users and management while the solution is being customized. It is much easier to correct misunderstandings at that point than later in the process (there are always misunderstandings - they come with the territory). This will also provide many opportunities for the kind of negotiation described in the initial phase (brokering the possibility/plausibility decisions between users, providers and management).
Deciding how to roll out your solution
Once the solution is built, everyone should decide how to go about implementing the new process. Do we use the Big Bang approach or one that sees little bits come in rapid succession? Do we have a pre-determined schedule or do we adapt to the users' learning curve? These decisions require an understanding of the potential users, the degree of change involved and the complexity of the solution.
Most organizations opt for some kind of incremental approach. Some organizations roll out to a set of one or more pilot users first, assessing their experience to inform how to deploy the solution for a larger audience. After that, they roll out the solution to the full user community.
Others take an even more gradual approach. They begin with pilot group (as described above) and then deploy to successive groups. These groups may be segmented by location, by functional department, randomly, by some other method or by some combination of those. They may also be increasingly large groups as the roll-out experience becomes more mature for this particular solution.
Regardless of which deployment style is chosen, it is necessary to have some kind of structured training and testing process. Training should include all users and stakeholders, although the implementation sequence will determine whether they are all trained at the same time.
Following the training, the organization needs to identify a test group. This group will include users, management and external players to ensure that the test is both realistic and comprehensive. It needs to test not only the system but the processes in order to be sure that the results are as intended and that the costs are less than the value of the benefits offered by the new solution. For that reason, the test group needs to be larger than a single individual - it needs to include at least one representative from each department in the work process being automated.
After that is done, it's time for a full-scale rollout. This is not a time to scrimp - making a big deal of it ensures that everybody involved is proud of their involvement. That engenders an emotional stake in the success of the solution.
It is also critical to make sure that there is good solid support for users in the crucial first two weeks of the new process. Users need to be able to quickly reduce their frustration in adapting to a new work flow. To provide this support, most successful deployments involve one or more teams that consist of an expert from the user business group and an expert on the system being deployed. This helps ensure that no matter what question or problem a user has, there will be someone on hand who can help them right away. Frustration that festers is a very avoidable problem for both the organization and for the individual.
Be smart in setting performance targets
Management goal-setting provides another opportunity for tailored decision making. Some firms prefer to set achievable goals for the initial period in order to be sure everyone can exceed their goals. Their feeling is that there will be ample time for ramping up to unprecedented levels of output in the future.
Other organizations opt for aggressive goals at once. Managers who do so generally feel that their staff will not be discouraged by missing goals for a short period at the outset. Often, these managers also believe that their employees will be more likely to see the aggressive goals as a personal challenge to be met and exceeded.
The factors guiding this decision include the maturity of the user community, the expected speed of the learning curve (informed by the experience of the pilot group) and the urgency of getting the system in place. Every organization is different, so there is not one right answer.
When the deployment process is successful, final-stage productivity will exceed initial expectations. This is because users will find more and better ways to deliver superior performance. At the end of the day, that is always the key to successful projects: tapping the hidden reservoir of creativity and productivity that exists within the ranks of every organization.