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.

MEYNARDO , GU, United States, 09/05/13 06:55 PM:

The point exactly hit the reality. This is an excellant discussion that is truly happening in most organizations where the utility plant staff who support the operation do not have the knowledge and field feedback (experience) on what was actually happening in the process and operation of the plant machineries and systems.
Consulting-Specifying Engineer's Product of the Year (POY) contest is the premier award for new products in the HVAC, fire, electrical, and...
Consulting-Specifying Engineer magazine is dedicated to encouraging and recognizing the most talented young individuals...
The MEP Giants program lists the top mechanical, electrical, plumbing, and fire protection engineering firms in the United States.
Control noise, vibration in building design: Tackling acoustics and design issues; High-performance building design; NFPA 99; Combined heat, power
40 Under 40; Stand-alone medical buildings; NFPA 92; Specialty fire suppression; Applying 90.1 in lighting design
2016 Product of the Year Finalists: Vote now; Data center Q&A; LED codes; Smart buildings
Putting COPS into context; Designing medium-voltage electrical systems; Planning and designing resilient, efficient data centers; The nine steps of designing generator fuel systems
Designing generator systems; Using online commissioning tools; Selective coordination best practices
Understanding transfer switch operation; Coordinating protective devices; Analyzing NEC 2014 changes; Cooling data centers
As brand protection manager for Eaton’s Electrical Sector, Tom Grace oversees counterfeit awareness...
Amara Rozgus is chief editor and content manager of Consulting-Specifier Engineer magazine.
IEEE power industry experts bring their combined experience in the electrical power industry...
Michael Heinsdorf, P.E., LEED AP, CDT is an Engineering Specification Writer at ARCOM MasterSpec.
click me