Monday, February 16, 2009

The Maturity Curve of Product Development

Throughout my career I have had the privilege of visiting a great many different product development and manufacturing companies, from Ford, Boeing and other giants to the small mom-&-pop shops.  From high-tech to aerospace to automotive and machinery.  (I’m actually writing this while on another airplane coming home from more visits) I find it fascinating and enjoyable to take tours and talk to people about their responsibilities and how they fit into the greater process of product development.  Also of interest to me are the types of tools these people use to support their responsibility and the greater process.  Tools can be put into three simple categories; creators, managers and consumers.  Of course, most are some combination of all three, but will most likely focus on one more than another.  So how do the tools support the process and how well does the process deliver to the business objectives?

Throughout my visits I have seen the spectrum. From drafting boards (yes, they still exist) to the total absence of 2D drawings (although still very rare).  I’ve tried to capture this spectrum in what I call my product development maturity curve, or - whatever. There are certainly a thousand different ways to look at it, but this is mine, (so far):

There seems to be two basic factors that drive companies up the curve; #1: the business – basically the objectives and drivers associated with successfully competing in the business you are in, and, #2: the desire and willingness to excel.  #1 is something that every company has to deal with, but will not necessarily drive your processes up the curve.  #2 is also required to make the move, but unfortunately is often considered optional and is pushed back or neglected in favor of getting things done by the safe tried and true methods, i.e.; there is always a risk/cost associated with “change” and “new”.  There are many reasons for not moving up the curve.  The following are some of the reasons given to me by many of the companies that I have visited. “Our piece/parts are so simple we really don’t need to move up.”  “Our culture and personnel are just not ready; it would cause too much chaos.”  “We are in a highly regulated industry that keeps us where we are.”  “Our supply chain cannot support the move up.” “We are starting a new important project and just don’t have the time.”  These are all real and to some extent valid, although they are not inhibitors, as witnessed in several other companies.

The usual question to ask when considering a move up the curve is; what will be gained by making a move up and at what cost?

This question should quickly take you back to:

What are your business objectives and do your processes deliver to those objectives?  Is there any way to improve process to better deliver on business objectives?  Can process improvements be staged to minimize disruption?  What benefits can be gained – improvements, reductions, …?  What is the value?

Then:

Are the right toolsets in place to support the proposed process improvement?  What tools will need to be replaced?  What tools will need to be added? How will culture, practices and personnel need to change?  What is the cost?

And last, but not least; what is the ROI?  (There, I just put several months of work into a few simple sentences)

I can tell you that in just the last two months, three of the companies that I have visited are experiencing budget and schedule overruns in their PLM and/or xRP deployments.  And in every case the reason given, after asking a few probing questions, was that they too quickly jumped to the solution (tool) before looking in more detail at the business drivers, existing processes, process requirements, culture,  – and – the future.  In all three cases there was a desire, and a budget, to progress up the curve.  But unfortunately the cost will now far exceed the benefit, for the foreseeable future.

PLM is typically viewed as a “manager” toolset, like the name suggests, (of course there are also elements of creation and consumption in PLM).  As such it is obvious how it can impact process and if structured and deployed properly can support a move up the maturity curve, (as a matter of fact you cannot be successful in stage III without it).  The “creator” tools also have a huge impact on process and the ability to move up the curve.

The “creator” tools can be used to create massive amounts of data.  Can this data be managed properly so that it can be found, understood and extracted as needed throughout the process and its lifecycle? Is the data managed in such a way that it will support a move up the curve? Can the data be consumed as needed throughout the lifecycle to get the maximum value from it? Will it be consumable, of value, and support the future move up the curve?

In product development, one of your biggest “creators” is the CAD tool.  Besides geometry, there is a significant amount of data that is also created and associated with this geometry.  Stuff like history-trees, sketches, features, parameters, view sets, drawings, 3D dimensions/tolerances/notes, 2D dimensions/tolerances/notes, title blocks, FEA results, engineering calculations, tool paths, animations, images and so on.  Consider the data that is being created, the time that is invested to create it, the infrastructure needed to support and manage it and the various tools that can “consume” it and generate value from it.  What is the cost and what is the value?  Will it support/enable or inhibit the move up the curve?  Some of your data may be like the music on an old 8-track tape – the data is there, it may be good (probably not), and it is likely you will never be able to get any value from it again.

What I see to be much too common as I visit companies is the tendency for the selection of tools to be weighted heavily by the preference of the IT organization and/or the users.  These people are certainly very intelligent and most likely have the best interest of the company in mind as they make these decisions, but unfortunately as recognized by the three examples mentioned earlier, business drivers, process requirements and a clear vision for the future, are often weighted lower than other criteria in the selection process.  Shouldn’t these be at the top?

Where does your company fit on the curve? Where do you need to be to compete in your business today – next year, and the next?  Are you paving the way, or are you just trying to survive by tried and true methods?  Are you moving up the curve?  It’s a good bet that your competitors are.

Paul

4 comments:

Josh said...

Excellent Paul. This has been one of the most frustrating parts of being in an industry producing products that rely on the business' willingness to invest moderately in new technologies.

At first it was fine. new business. new tools. After that it seems that it's viewed as overhead with now verifiable ROI that is above and beyond current standards, even though it can be shown otherwise.

Hardware, in my view, and staying updated or on an upgrade schedule is going to have the biggest bang for the least learning curve. This one aspect could propel the company with proficient user past competition, not only from a company standpoint, but from a personnel standpoint.

Thanks for all the months (years I'm sure) of compiling this data.

Paul Hamilton said...

Thanks for the comments Josh.
I was just talking with another company. They are considering a potential layoff considering the economy. Layoffs seem to be one of those things close to the top of the list to consider when times get tough. I don't know if people realize how much it costs to lay people off - do they really understand the ROI. Are there other ways to spend that money that could yield a better return - and perhaps better prepare them for the future?

Paul

Gerd Schwaderer said...

Thats a great overview explaining the often strange decisions of companies selecting products and processes. One thing comes to my mind thinking of the development process and PLM. Does anybody have experience with scan data in PLM systems? Usually we are facing a pile of DVD's or a cluster of terrabyte carrying harddisks with scans of the design cycle of a set of iterations, lets say at an automotive design center. Nobody really knows which is what data, date, version. Maybe its hidden in the filename like "12.8.2009-leftside-full-serie4-4to10scale-LOD2". IS there any PLM system that can move, organise and handle hundreds of megabytes scandata or do they need to stick to a low level of detail or pictures?

Gerd Schwaderer

Paul Hamilton said...

Gerd,
Thanks for the comments.
Concerning your question about scan data and PLM. I know there are several PLM systems that can support your need. The amount of data is not the big issue - that is just a factor related to available disk space, and disk space is getting fairly cheap these days. What matters is how the data is packaged - this is usually a function of the tool that creates the data - hopefully it is packaged in a single file. Then it is a matter of submitting it to the PLM system and adding attributes (including version) to the added object to make it easy to find and access. In the case that the scan data is created in multiple files, the PLM system can relate these objects together so that you will know they belong together. I work at PTC, and they certainly have tools that can do this.
Paul