The Impact of IT on Mechanical Engineering-Oriented Project Planning

What is it about the mechanical engineering (ME) industry that can cause smart people to make dumb decisions? In my international management consulting practices I see companies investing a lot of money on project initiatives that don't meet the minimum daily requirement for common sense. It's not that the project definitions are bad—in fact, most of them aren't. But they are not well thought out. They are simple needs assessments requiring a clear scope of work, methodology and many times a well defined implementation strategy. It sounds simplistic, but if you, as a mechanical engineer--or any other industry--can get the senior staff of your organization and the sponsors of the project to commit to delivering specific results on an IT project, you will have done most of the heavy lifting necessary to ensure success.

A few years ago I reviewed a strategic plan for a company in the U.S. providing thermal fatigue testing where an investment of $100 million in tools and labs were recommended over a three-year period. This plan was generated by a very large, very well-known IT consulting company at the request of the CIO. Nowhere in the document was there any discussion of the business payback for this investment.

Another instance occurred at a large machine design company in Costa Rica. At my client's request, I intervened on a strategy project in which the approach was not going to result in specific value commitments. When I raised my concerns with the consultant (from another very large, very well-known IT consulting company), I was informed that there was no way to calculate ROI for IT investments. Since he was missing the point, we spent the next two hours on "Business 101" and revised the approach accordingly. The sponsoring project manager specified value commitments and the project received $10 million in funding.

Both projects got funded, but only the second was fully implemented. The real difference in the two examples, however, lies in the quality of the up-front planning. With the first, unsuccessful project, a significant amount of work had to be spent redoing the financials. By the time this foundation work was complete, the senior executives were suffering from hangovers caused by a series of bad projects (usually the result of a lot of expenses and no discernable business benefit). In the end, they decided not to fund the rest of the project.

In the second successful example, the work focused on supporting front-line operations, with clear benefits to the machine design company. The sponsoring project manager made sure the organization stuck to the plan so that it could implement the business change and realize the benefits. Why is it so important to quantify the payback of IT projects? Because project managers will truly focus only on those things that will make them money.

No reasonable project manager is going to champion an IT project –especially if they don’t fully understand that environment-- that's poorly defined or not worth doing, especially if it runs into trouble. When times get tough—and there are always tough times on major projects—it's all too easy for executives to ax the initiatives where the project rationale is not broadly understood, as with the thermal fatigue testing example I mentioned.

It's a mystery to me why seasoned mechanical engineering executives follow the "build it and they will come" philosophy of technology investing. Many people believe the rapid pace of business dictates this fire-ready-aim behavior. After one of my talks at a PMI regional chapter in Massachusetts on this subject, yet another consultant from another major IT consultancy let me know that IT investment justification disciplines don't have any relevance in the mechanical engineering world. Tell this to the investors and project sponsors holding the bad note of a failed project!

Our current faith in the devil we don't know has given us permission to hold technology above the long-established business codes of conduct that require investment justification and accountability for results, especially in the mechanical engineering industry. Many CIO/CTOs give lip service to these disciplines. Although most of the mechanical engineering industry, in my experience, prepare formal project justifications, very few of the justifications include commitments by project managers for explicit results within a specified time frame. In fact, in most organizations, the IT department prepares the justification, which leads to the project being considered complete when the software is implemented rather than when the benefits have been realized.

As a result, the justification process becomes form over substance—simply a box to check off on the way to obtaining funding, which can be very dangerous for mechanical engineers, where the results of projects at times, will be evident only several months down the road. In letting project managers get away with not committing to projects, CIOs are putting their projects and careers at risk and ensuring that IT is kept in the back office, and not fully integrated with mechanical engineering projects.

If you want a seat at the boardroom and ensure greater chances of success for your project, here are some “rule for success” you need to adopt:

• Define the rules - Make it clear that your project definition and planning must demonstrate some type of business result for the IT investments. Make sure everybody knows that a big somebody will be watching. A CFO of a major petroleum company in Brazil not only reviews the business justifications when project plans are being drawn up but also remembers these commitments when budgets are reviewed.
• Use operational measures - It's admittedly difficult to draw a straight line between most investments and the financial impact. Fortunately, every business has operational measures such as customer service, cycle time and product quality that, over time, will result in financial impact. These measures can be identified by examining the underlying drivers of the financial results. For example, for a manufacturer of turbines in South Carolina, speedier production line affects peak time throughput and will increase sales (provided that there is excess demand for the product and customers are turned off by long backorder waiting period). IT improvements that increase speed of production are easier to commit to and measure than the resulting increase in sales.
• Be unreasonable - Effective leaders ask their organizations to deliver what is believed to be impossible. When I was a practicing CTO, I once asked my network administrator to prove that his request for a new file server cluster could pay back within six months. I thought I had killed the request. Imagine my surprise when he came back with a justification based on system payload reduction and less traffic on the network created by the system's more sophisticated data processing and network traffic capabilities. Even boring replacement projects can be made exciting if the team is challenged appropriately.
• Stage the funding - Most investments are a guess about the future. By staggering the funding in multiple stages, you motivate people to continuously prove the concept to gain more funding. Conducting pilot and proof-of-concept projects are the best ways to do technology projects, because they allow us to refine our knowledge and understand the risks and true scope.
• Invest in the front line - This is where your company or department interacts with its customers, supply chain and channel partners, and where small changes can lead to big dollars, because you can influence thousands of transactions, decisions and behaviors. For example, again in the turbine business, investing in IT at the manufacturing level is the only game in town. If you can save labor hours, millions fall to the bottom line. When you define an assembly process correctly, the average throughput of the assembly line increases, which has a huge effect over thousands of transactions.
• Evaluate the portfolio - Create specific measures for IT on ME projects, but allow some room for R&D, infrastructure and risky investments. Annually or more often, examine the impact over the entire capital budget. As with your personal financial portfolio, select a mix of sure things and fliers and evaluate your decision process based on the overall result.

If you are still wondering whether all this applies to you, ask yourself which part of ROI your organization manages most closely: the numerator (benefit) or the denominator (costs—mostly IT). If your company spends most of its time discussing the cost side of the equation, you don't have good investment management processes in place and IT is probably viewed as an expense to be minimized rather than an investment to be optimized. Without measurable results, IT will be considered a necessary evil rather than a strategic management lever and will be subjected to the tyranny of subjective performance assessments.

In contrast, the road to specific business commitments for ME projects leads to a hundred valuable discussions about the concept, the work required, the skills necessary, the barriers, the accountabilities and the measurements. If you haven't traveled down that path, then as a first step, pick two projects—a dog and a star—and work with the sponsoring business executives to define and commit to measurable business impact. My guess is that your dog will be redefined, reduced or eliminated, while the star will be recognized for the jewel that it is and be better funded and championed.

Cheers! (干杯)

MG