THE PLM STATE

The PLM State TBT: Closing the Communication Gap between IT and Executives

Welcome to this week’s TBT post, originally published in 2010.

On September 8, 1974 Evel Knievel attempted to jump the Snake River Canyon in a steam-powered rocket cycle aptly named Skycycle. Between the parachute deploying early and the unanticipated headwinds the attempt failed miserably. The Skycycle failed to even reach the water below which was probably a good thing for Evel. Watching IT resources and Executives interact around technology and process initiatives often reminds me of this futile attempt at defying gravity. The gap between these two groups is often as wide as the Snake River Canyon and often IT seems as ill-equipped as Evel was that day he attempted his jump. This issue can also apply to other personnel within a company that are attempting to justify improvement initiatives to management. The main barrier to communication between Executives and the rest of their organization is that they are looking at these projects from a different perspective and often know or care very little about the technology itself. This blog will discuss how to blend the interests of IT and Engineering with Executive teams to facilitate adoption of beneficial technology and process solutions.

Recently I was involved in a discussion where an IT resource was trying to convey the value of virtualization to a manager. The IT resource was very knowledgeable about the technology but failed to grasp what key pieces of information were important to the manager. While he dwelt on the capabilities that would be gained by adopting this technology the manager was more concerned about the cost of acquiring this technology and what resource level was going to be needed to sustain it. While I am sure not every IT or engineering resource is oblivious to management's perspective, I think it might be worthwhile to discuss the idea of framing process improvement initiatives in a way that resonates with upper level management. I have discussed quantifying value in other blog post during the "Measuring This" series. This is more about understanding the perspective of management and engaging in a dialogue and process that will result in mutual satisfaction for both engineers and managers. Obviously, management is cost driven while IT and engineering are more concerned about capabilities.

It can be difficult to quantify value sometimes but it is very important to have this information ready when attempting to promote a process improvement initiative. I was recently scanning back through an excellent book on this topic called Let's Get Real by Mahan Khalsa. lets get real.jpgI consider this book a must read for any salesperson or consultant involved in process improvement technologies. I also think that those who are on the company side could also benefit from this book. It gives great insight into the pressures applied to both sellers and buyers and how to ensure a positive outcome when purchasing process improvement technology. Khalsa writes about the thoughts a manager might have when presented with a new idea. If the manager is smart he might ask the question, "before we write a check for this, could someone please tell me how this is money well spent?" This seems obvious but I have been involved in many projects where this question was not asked at all or very late in the project. While I think this is a best practice for a sales and/or consulting company to promote, many organizations view this as extra work and don't really push it unless the customer insists or the sales cycle stalls. It is incumbent on the client to drive this process and most likely a manager will raise this issue so it is important for engineering and IT to be ready with strong justification to address this question.

The real question becomes how you justify these initiatives to management. Talking about the functionality that will be gained is probably not going to resonate at that level. Notice the question, "how is this money well spent?". It could be argued that gaining certain capabilities justify the expenditure but if you make this argument you need to go a step further and quantify the impact either of not having these capabilities or gaining these capabilities. In the example I used above about virtualization, it might be that not having a virtualized environment for your Agile PLM system means you must spend money on extra hardware for test systems and that the backup only covers the data stored in the system but not the system itself. That alone is a pretty good argument but you could take it further by explaining that the amount of time it takes to perform and verify backups and maintain multiple hardware platforms consumes 5 hours a week and that over a twelve-month period using a burden rate of $100 per hour this adds up to over twenty thousand dollars in extra money spent. This doesn't even factor in the cost of the extra hardware and the time lost if the system must be reinstalled. Managers can understand this type of justification. You are spending extra money on IT resources (this is especially compelling if the IT resources are contract), hardware, and I am exposed from a backup perspective. VMWare actually has a spreadsheet for calculating extra hardware cost and it even goes into power consumption but I find these types of tools are only useful for very large companies. A management justification for this type of initiative needs to be based on cost savings and added security not reducing your carbon footprint.

There is a good set of questions you should ask yourself before you even think about approaching management with an idea. This is straight from the book.

  • How do you know there is a problem?
  • What lets you know there is a problem?
  • Where specifically does the problem show up?
  • Which measures prove there is a problem?
  • Who is specifically most affected by the problem?
  • When does this problem most occur?

These questions establish evidence that there is a problem but you need to take it a step further and determine if this is a problem worth solving. These questions address results.

  • How specifically would you measure success?
  • What would let you know you were successful?
  • Where would the success of this project show up?
  • Which performance indicators will increase or decrease if we are successful?
  • Who specifically would be affected by these issues?
  • When do you need these results in place?

Some of these questions are redundant but I wanted to keep them identical to the book; sometimes if you ask the same question a different way you get a different answer so it probably doesn't hurt. The bottom line is to go through some significant analysis of the issue prior to approaching management. If you are management you should expect this level of analysis from your resources or vendors before you go too far down the road with a project. Evidence must be gathered prior to beginning a process improvement project or its value may be obscured. Once you have gathered this information you will need to quantify the impact like I did in the virtualization example. The book goes into methods for doing this but keep in mind that there are no magic wands for this activity.

knievel-snake-river-parachute-deploys-early.jpgIf Evel had stopped and taken the time to better analyze his attempt to jump the Snake River Canyon we might have been deprived of the spectacle of him plummeting to the ground in the red, white and blue Skycycle. I suspect his main calculations that day were for the likelihood of his survival and in that regard, everything worked out. Before you decide to jump off a canyon like purchasing PLM or adding functionality, you might want to ask a few questions and come up with a plan that will ensure a safe landing on the other side.

[Edit: repost from 2010]

 

Request Recording 

Subscribe to the ZWS Blog

Recent Posts

Request