Consequences of focusing too much on technology
As you’re launching a new project, ask yourself a tough question: Can you justify what you’re doing for solid business reasons, or are you simply captivated by a cool technology?
Over my career, I’ve seen a lot of projects make a lot of mistakes. One of the most insidious mistakes is when a project gets focused on the technology being implemented and not on the business. There might be a lot of valid reasons for emphasizing the technology, but when technology gets more important than the business, there will be some serious consequences. There’s just no way around it, there can be lots of consequences of running a project that’s focused on the technology and not the needs of the business.
Identifying those technology infatuation projects is simple. You will find that if you are really objective, it will be very difficult, if not impossible, to identify the payback and justify the investment if the project turns out to be all about the technology. If there’s no focus on the business then it’s almost impossible to show that the project is providing value to the business or meeting some other corporate objective.
A typical result of running a project focused on a technology and not on the business means that there will be some costly redesign efforts. Systems and functions might be duplicated, business requirements are completely missed, solutions that are already in place might be ignored, the real needs of the business are not taken into account, and so on. It means that when it all settles out, there will have to be some serious changes because the technology doesn’t do what the business needs it to do.
This kind of problem surfaces frequently when dealing with large, often rigid software applications. A project can successfully implement a software package that works extremely well, has been fully and completely deployed and integrated, has lots of fancy bells and whistles, and yet does not achieve one valuable result for the business. This is all too common when the software is implemented in a vacuum and the project only focuses on the software and not the business.
Another facet of these projects can be both a result and a cause. If there’s limited buy-in from the stakeholders outside of the project team and outside of the technology people, then the project is probably already in trouble. When the implementation is well underway and operations and other non-technology people start distancing themselves from the project, that’s a serious indicator because they see the problems coming and want no part of it. If the project starts without support and buy-in from the stakeholders, it’s a recipe for disaster because there’s no involvement from the business and no support from the stakeholders.
Likewise, when the project is focused on a technology and not on the business then things such as change management, training, and support all get short-changed. Nobody will understand the impact it has on the affected people and their jobs. That usually means that the importance of change management is not fully understood and can be left out of the project all together.
Training becomes confused because it’s all about how to use the features of the software with little or no connection to the actual business task to be performed or to the people and their specific jobs and job activities. Training is often nothing more than how to use this screen, how to enter this transaction, and so on, with no connection to the business, business processes, and business tasks.
Finally, maybe the worst consequence of all is the emphasis of the project when the work is done but before the true nature of its failure is obvious. Typically, in these kinds of technology projects, the emphasis is all about getting the software implemented and once it’s implemented there’s a big party, the team celebrates, and the project is over. But, at that point, there’s not really much to celebrate. There have been no improvements to the business. No new capabilities have been added, nor have there been any cost reductions. The only real accomplishment is a bunch of technology people working in a back room somewhere on some software. The celebrating is over, but from the perspective of the business, the real project can now get started. The more serious and difficult work will be finding a way to use the new software in a way that adds value to the business, meets the needs of the business, reduces costs, adds capabilities, and so on. But, in most cases, with technology projects like this, those people have already moved on to the next thing leaving the business to figure out how to make sense of this wonderful new software. Who is going to take up that task?
Well, I think I’ve made my point. You get the picture. When you’re doing a project, any project, it should always be about the business and not the technology. Just getting that simple concept right will go a long way toward ensuring a successful project. Until next time, good luck!
This post was written by John Clemons. John is the Director of Manufacturing IT at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
Annual Salary Survey
After almost a decade of uncertainty, the confidence of plant floor managers is soaring. Even with a number of challenges and while implementing new technologies, there is a renewed sense of optimism among plant managers about their business and their future.
The respondents to the 2014 Plant Engineering Salary Survey come from throughout the U.S. and serve a variety of industries, but they are uniform in their optimism about manufacturing. This year’s survey found 79% consider manufacturing a secure career. That’s up from 75% in 2013 and significantly higher than the 63% figure when Plant Engineering first started asking that question a decade ago.