Product Development Archives

Why bother with the Internet of Things (IoT)?

Great question! Maybe to understand your product, make a deeper connection with customers, create a new business model, increase revenue or even build a new revenue stream. Perhaps you’d like to find out what your products are doing after you sell them and figure out which features to include or remove from your next iteration. There are piles of ideas and ways to make the IoT work for you. In short, however, it depends on your initiatives — and the IoT could be just the thing you need to move your initiatives from “How are we gonna do that?” to “This is gonna be awesome!”

When considering your corporate initiatives and the IoT, I’d encourage you to integrate them rather than looking at them as separate things. At EAC, our Connect Services (the way we help customers achieve their IoT objectives) starts with strategy. You’ve got to make a connection between the motivation to have smart and connected products and your initiatives. In other words, your approach to the IoT could be the central catalyst of your initiatives. Otherwise, it’s just a fun and techy science project without clear direction.

Let’s say you’re a forward thinking company and you call yourself innovative while having a goal of improving dealer service capabilities and increasing end-customer engagement. Perhaps you could build a whole new business unit that collects data from your product in the field and distributes use and service information back to your dealers as they provide service. It could increase revenue (data/subscription sales to dealers), increase your ‘innovative edge’ as perceived by your end customers (through apps and product information) and feeds feature and performance data back into your design cycle. You could aggregate the data from your products in the field to your ERP and MRP systems and have truly integrated (connected) PLM into your business. Just for the sake of argument, this could include role-specific mobile device apps for dealers, DIY repair, data junkies and regional usage maps. We could even weave this into production and procurement roles and have data actually ‘flowing’ in several directions. Who knows where it could lead.

Ok, now back to avoiding the ‘science project.’ The key is to have a strategy — figure out why you want to be part of the IoT and then go do it. Our goal at EAC is to help companies transform the way they design, manufacture, connect to and service their products. As a part of that, we’d like to help you build your strategy, devise ‘connected things,’ and implement a facilitating platform easing the access, sharing and use of the information. This 3-legged stool is what we place our IoT strategy on — next time I’ll talk more about the ‘things’ or the ‘platform.’ For now, how can we help you build your IoT strategy? Let us know…

When is PDSA season?
We all know when it’s cold and flu season and what precautions to take to get back to health or at least dial down the symptoms. However, do we recognize when it’s time to conduct a Product Development System Assessment (PDSA) to get our organization back to health?

To analogize a real life situation, if someone is sick and goes to the doctor, the doctor would want to treat the immediate sickness and then propose a physical to determine what else is going on within the patient’s body. The doctor then sets a diagnosis for continuous improvement of health. A PDSA lends itself to something close to this from a product development standpoint.

An organization must first acknowledge a problem from a department stakeholder (i.e: Vice President, Director, Manager). They must obtain an understanding of how this problem effects downstream departments and create a sense of urgency that this one problem, is only one problem, and more problems are likely to be a major inhibitor to reaching goals.

Sure, organizations can operate with these inefficiencies and still make products, but we want them to know that they could make even more products or run more projects by taking part in a PDSA, which is when we come in to align an organization’s goals and measure achievement recognition through a secure and obtainable continuous improvement plan. PDSA’s are our way of measuring an organizations pain in their processes and providing a long-term solution to provide continuous improvement and maintain a healthy organization.

PDSA’s are the only way for EAC to truly understand the heartbeat of a company and the only way a customer or prospect can become a partner. Their goals become our goals for that organization.

Why would you want a PDSA?

PDSA’s are valuable for two reasons. First we, EAC, help clients to see their product development operation as a system which is a critical first step in making the operation better (i.e. more systematic). Secondly, we provide, as the output of the assessment, a set of high leverage improvement initiatives that will directly lead to increased productivity of their product development system.

Organizations may know something is not right with their product development operation – maybe for instance due to the number of recurring fires they fight – but they don’t know where to focus their improvement initiatives until they learn to see their operation as a system as opposed to a process.

The PDSA aligns a company’s business strategies and objectives to product development initiatives to determine areas of improvement. This is so valuable to be able to motivate a company or the internal champion to see how an improvement to a product development system would be tied to or contribute to a portion of the company’s objectives.

For example, an organizations objective or value opportunity is to reduce product development cost. Then we would streamline the product development system by making sure the people, process, and technology within a product development process are all working together without disrupting another part of the product development process thus taking waste out of the system enables reduction in cost.

During a PDSA, we engage with multifunctional groups within a company to extract process information and where waste is. Over and above that, a continuous improvement strategy will be set in place for the company to achieve the desired state or desired maturity level. Without an investment in continuous improvement, a one-time fix to a process or system will not sustain in the long term.

What’s so great about PDSA’s?

PDSA’s are learning events and EAC consultants learn something new with every PDSA because of the uniqueness of each client we work with. Beyond spreading our understanding of seeing operations as systems, it is exciting to be able to learn the details of the client’s operations and then provide critical improvement information.

The ability to tell an internal champion or the economic buyer that their organization is “leaking oil” or specifically being able to quantify to them the dollars being wasted, and that we, EAC are here to help reduce that and get them in a better state excites me. The ability to whiteboard the organizations processes and ask them why they would perform a certain task in that fashion. The ability to ask the tough questions, like “what is the biggest headache or challenge they have right now?” and “what is working well for you?” The ability to help the champion to present to their executive board is what is rewarding in the end.

We live and breathe to make a difference for our customers. PDSA’s are a mental marathon that test every part of a person’s attention to detail, savvy, note taking, and overall listening abilities. The challenge is what we get revved up for. We never know what we are going to find.

Today we talk about the fifth and final system archetype we’ll cover in this series — The Tragedy of the Commons. It is a system that starts with independent and rational behavior, but it leads to a disaster. It starts with a shared resource with a number of individuals sharing this same resource. Each individual tries to optimize the use of the resource to his or her best advantage. That is to say, to grow their use of the resource. The individual that grows the use of their resource captures 100% of the benefit of the resource, but the cost of the resource is shared amongst all of the people that use the resource. That 100% of the gain and only a small portion of the cost drives increasing use of the resource and sometimes leads to the resource being overused.

Here is a related example – if you go to a restaurant with three of your friends and, to make things easier, you decide ahead of time that you’re just going to split the tab 4 ways. When this happens you’re likely to consume more food and drink than if you were picking up your own tab because you want to make sure you’re not being cheated. So this use of a common shared resource drives increasing utilization.

The growth of every individual’s use of a common resource ends up abusing the resource and the resource, if it’s a renewable resource, the resource can be destroyed. It’s the problem of overgrazing, overfishing of the oceans, the behavior that lead to the elimination of all the trees on Easter Island.

In non-renewable resource situations you have overburdening of the shared resource. This overburdening, as we learn from Don Reinertsen in queuing theory, can lead to a decrease in efficiency and availability of the resource.

In product development, if we look to engineering as a shared resource, we see that we have a lot of people using this resource somewhat independently. You have marketing making requirements, you have the executive team, you have manufacturing that has needs that are brought to engineering, and customer support also gives input to engineering addressing market issues. Each of these resources looks to optimize the use of the resource and this drives the system archetype of the Tragedy of the Commons where engineering ends up being overburdened and as queuing theory says it’s efficiency drops off dramatically.

The antidote for the Tragedy of the Commons system is simply management of the resource. Instead of letting everyone operate it independently it’s to put a management system in place that doles out access to the resource. In product development or engineering this management takes the form of a single queue for engineering requests, clearly defining engineering requirements and requests, and prioritization of all the requests that come engineering sot he most important tasks are getting the available resources and the resources are not taxed or overburdened. The interesting thing to me is that these three management antidotes to the problem of the shared resource of engineering are the three practices — engineering requests, requirements management, and prioritization — are core to an Agile product development system that EAC promotes that is finding increased usage and utilization even in hardware and systems engineering organizations.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive. Follow us at http://www.twitter.com/systhinking

Today we continue our discussion about System Archetypes with an archetype known as “Accidental Adversaries.” This system starts with two partners working to cooperate, but it leads to a negative outcome. The cooperation comes from each partner filling a need of the other. But, once the cooperation or system is put in place, each of them looks to individually optimize their part of the operation — a local optimization. This local optimization has unintended negative consequences for the partner. As each partner feels the negative consequence of what the other is doing, feelings erode, the partnership dissolves, and both sides feel the other side is inconsiderate and taking advantage of them.

The classic example used to highlight Accidental Adversaries is that of Walmart and Proctor & Gamble. Walmart needed product for their shelves and P&G needed distribution for their products. So the two companies cooperated. Once the cooperation was in place P&G tried to improve their position by running a lot of specials and sales. This created extra work and costs for Walmart. Walmart tried to recover those costs by buying extra quantities of the discounted product, stockpiling, and then burning through their inventory after the prices went up — selling them at full price to make extra profit and recover the burden put on them by the sales themselves. Proctor & Gamble then started running more sales to move more product and make up for the loss, and this turned into a cycle. Both sides felt the other side was operating against their interest and this cooperative venture became an adversarial relationship.

We see something similar happening in our organizations. Let’s use the relationship between marketing and engineering as an example. Marketing needs some organization to realize their vision and design. Engineering needs someone to come up with a vision and awareness of what the market needs in order to execute and do their work. As marketing learns, deep into a development project, some new information, they will try feeding it into a project. This is often called scope creep. Engineering will try their best to fulfill the new requirement. However, it may cause a problem for engineering. It may cause a project to be late. So, engineering puts in place some rigid rule like a spec freeze. Marketing, losing the flexibility of the process, will amp up its early requirements and put in stretch goals instead real goals. The idea being that if engineering can meet the stretch goals, then the product will still be strongly competitive in the market place. This cycle repeats itself and marketing and engineering find them selves in an adversarial relationship.

The antidote for this archetype is dialogue — continuing dialogue about the cooperation throughout the entire life of the system. Dialogue can’t end once the initial system in place. There needs to be ongoing dialogue between marketing and engineering. This is part of the design of the interface between the two groups. To come full circle, design of the interface is one of the key elements of systems and systems thinking…the topic that we’re heavily focused on in this series.

We’ve been talking about System Archetypes. These are the types of systems that recur in a number of environments and are easily recognizable. The system archetype we’re going to talk about today is called Eroding Goals. Eroding goals are caused by a delay in the results of the actions we take to improve something. If you recall, systems operate on feedback — positive and negative feedback — and delays in the cause and effect cycles between elements of the system.

So in eroding goals you start with some condition and an ambition to improve it. There is some gap between your condition and the goal. This gap causes a dynamic tension. Senge represents it well in his book, The Fifth Discipline, by showing a hand stretching a rubber band. The tension of that rubber band pulls up on the condition, but with the same force it puts pressure to pull down the goal. You have two possible results. You can either take action that will move the condition towards the goal or you can soften the goal and pull it down closer to your condition.

What happens in eroding goals is you start by taking positive action, doing the right thing, but there is a time delay between the activity you take and seeing the positive results of the action you take. This time delay, this lack of positive reinforcement of your action, causes a loss of commitment to the work you’re doing. To relieve the pressure you lower your goals to reduce the dynamic tension that’s in play.

An example of this might be if your company releases three new products each year and there’s a goal to increase this number to six. This goal drives increased investment as the company moves towards increasing the capacity and capability to release six new products. But there is a delay in the positive results from the actions taken to increase capacity. This lack of results causes those making the investment to lose confidence and commitment to the initiative. So, to avoid making increased investments — in their minds eye perhaps throwing good money after bad — they lower their goals from six to four; an incremental increase instead of a dramatic increase.

The antidote to eroding goals is simply setting good goals. The setting of good goals comes from a process called learning first. Study your situation; study the distance between your condition and your goal. Then make goals that are achievable. This ties directly to learning first, learning cycles, and the EAC promoted LAMDA learning tool. If you’re not familiar with the LAMDA learning tool, I suggest you look into it. One way of doing so is to contact EAC.

We’ve been talking about system archetypes and will focus on that topic again in this post. We’re going to look at the system archetype called “Shifting the Burden.” First, a little review. A system archetype is a system that recurs over and over in many different settings and industries.

Shifting the Burden centers around shifting the burden from solving a problem to solving a symptom. It starts with the awareness of a problem. The awareness comes from the observation of some symptom of that problem. At the point of observation you have a choice. You can either choose to put out the fire and resolve the symptom, or you can do a more protracted problem solving exercise and get to the root-cause and solve the problem. Under the time constraints of modern business we oftentimes choose the former and put out the fire. We measure success using the fact that the symptom goes away and we can get back to our urgent regular work.

Shifting the burden from solving a problem to solving a symptom results in an addiction cycle. We treat the symptom and, because we haven’t solved the problem, the problem recurs as a fire. As we rely more on solving symptoms instead of problems, more and more fires recur and we find ourselves in perpetual firefighting. As we are perpetually firefighting we have less time to spend on solving problems so we’re more inclined to solve symptoms. As we do this, our ability to actually root-cause problems and solve them at their root atrophies. It is a side affect of the addiction cycle.

For example, say you have a customer service group. Let’s say that over the course of the last three months the number of calls into the call center has increased by 25% and the customer service groups is suffering low morale because of it–long hours and hostile customers. The problem at this point really is unknown. No one has investigated it. It could be as simple as an unclear instruction manual for a new product that’s been released. But, in the interest in getting the call center morale problem resolved the company invests in capacity for the call center. With more people in the call center morale improves and the symptom goes away, but the underlying problem remains…probably to recur at some point in the near future.

The “Shifting the Burden” archetype has an antidote. The antidote is to recognize when you’re applying Band-Aids–to recognize when you’re just solving the symptom–and to follow up that with a deep root-cause problem solving exercise. Of course, to be able to do this, you need a competency and capability of solving root-cause problems. This could be PDCA or, as EAC promotes, the LAMDA learning cycle.