Today’s avalanche of technology promises to make everything better, especially in business and government, where the work gets done. From the digital workplace to the customer experience to artificial intelligence and beyond, automated nirvana, we are told, is just around the corner.
But while we’re basking in the glow of that burgeoning technology, we’d best not forget that we aren’t doing a very good job of using all this new power: Reliable studies tell us that while things are improving, a significant percentage of technology-based projects still fail or fall short of the their stated goals. The actual failure stats may be even higher, given the reluctance of project owners to admit defeat.
If technology is to save us from our antiquated ways of doing things, we must improve this percentage, and the first step toward that improvement is understanding why things are as they are: You can’t fix what you don’t know is broken.
When Answers Aren’t Really Answers
There’s plenty of research and analysis available. Do a web search for the phrase “IT project failures” and you get nearly 24 million hits, but much of that analysis may itself be part of the problem. Discussions of technology project failures tend to be highly structured, breaking failures down into logical components, discussed individually in almost technical terms.
While this may make for good reading, it fails to deal with the fact that workplace technology succeeds only if it is embraced by its target environment, and that workplaces are collections of human workers and humans aren’t logical behavior units but individuals, each with strengths and weaknesses, fears, even prejudices and pecking orders, all affecting the operation of any new technology placed among them.
Consider the Whole Foods “empty shelves” disaster brought on by a new, pre-Amazon acquisition, automated inventory and ordering system that seemed so powerful before it was implemented but failed to take staff, vendors and customers into account.
To understand the role employees play, sit in on the first meeting where the IT folks disclose their planned new technology and you will see just how human most workplaces are. Along with the early adopters who can’t wait to get started, there are those who fear change of any kind. And then there are people who have taken ownership of — and take pride in — their current processes, others who fear losing their jobs — and status — to computers, and some who just don’t trust anything IT comes up with and are convinced they are just guinea pigs for the IT group’s aggrandizement.
If you want a successful implementation of new technology, you must convince all of these folks to work with you, to accept the changes you are planning, and to upgrade their skills where it is needed. None of this will be easy, and the leaders of too many technology efforts don’t even realize that they need it. But need it they do, and getting the people on board is crucial to any hope of success.
Team Building ... in the Real World
First, you must accept that your greatest challenges will likely be human and organizational. While descriptions of the workplaces and employees of the future can be found most everywhere, workforce evolution is a slow, often ragged, process, and just writing new job descriptions doesn’t mean you can create employees able or willing to fill those new jobs on demand.
That reality may appear to go without saying, but taking it into account can be incredibly difficult in practice, so difficult that it is often deliberately ignored (“out of scope” in technospeak) by IT groups anxious to implement something — anything!
Next, you must realize that there are few actual digital workplaces but many human ones that can be improved by the intelligent application of digital technology, and the two are not the same. Chances are, if you are contemplating a technology-based project, you are dealing with the latter.
Once you understand this, you can plan for a meeting of human and technological factors that enables a better workplace using technology where and how it makes sense. The road to successful technology projects has one sign with one word on it: ownership.
Learning Opportunities
Ownership? What’s That and How Do I Get It?
If a project is to succeed, it must be an effort to which everyone subscribes, in which everyone feels a degree of ownership and from which everyone derives some sense of accomplishment.
Ownership is also the only way to avoid the “us vs. them” atmosphere that permeates so many projects — and organizations — and is sure to make everything difficult if not impossible. It also mitigates the fact that user organization management often outranks technology management, making the imposition of unpopular technology a risky endeavor often cancelled out by those for whom — and to whom — it is being done.
There is no magic bullet, but several things that will help:
First: Make user groups part of the effort from the outset. No one wants to hear your decisions about their future if they haven’t been part of the decision-making process — and they will let you know it. One good way to do this is to establish “cross-functional teams” (from the Concurrent Engineering methodology) organized by functional area and made up of representatives from each, including IT. If you do this early and make each team part of the problem definition and design process, you are more likely to make people feel like team members, not victims.
Next: Develop an overall functional strategy aimed at improving the working environment of the organization and its people. Don’t base the strategy on technology, except as a tool to achieve strategic and functional goals. This also appears to go without saying, but that approach is lacking from many if not most projects. And, of course, involve your cross-functional teams in every phase of this process, and don’t finalize your strategy unless every participant at least understands it — and (hopefully) supports it.
Next: Organize every phase of your effort along the functional lines your teams have developed. This is your road map to a better workplace, and it will keep IT from imposing its own goals. It will also position you to deal with the technology vendor community in functional terms: “What can you do for my needs?” rather than “What does your technology do well?” In fact, when the time comes to contact potential technology vendors — and weed out those who aren’t responsive — your detailed functional specification is probably the best way to engage.
Finally: Once you have set up this kind of shared, function-based environment, measure your progress by it. You must hold on to your functional strategy, especially as things get technical and complex at some point during implementation. Evaluate every technical decision and every vendor offering against its support of your functional goals.
And, of course, give yourself and your organization enough time to do things correctly and completely: Meeting an arbitrary schedule by doing things poorly is usually worse, and vastly more expensive in terms of dollars and workplace tranquility, than not doing them at all.
Learn how you can join our contributor community.