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.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
Annual Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.