General / Books

What is ‘The Goal’ for Engineering?

Cleaning out the closet the other day, I came across an old favorite book of mine called The Goal (wikipedia entry). I read it a couple of years after coming out of engineering school to get a little perspective on the business side of manufacturing.

Now there’s a lot to this book, but fundamentally I remember it for something the author, Dr. Eliyahu Goldratt coined as the Theory of Constraints (wikipedia entry). Here’s an excerpt from the wikipedia definition.

Theory of Constraints (TOC) is an overall management philosophy introduced by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal, that is geared to help organizations continually achieve their goal. The title comes from the contention that any manageable system is limited in achieving more of its goal by a very small number of constraints, and that there is always at least one constraint. The TOC process seeks to identify the constraint and restructure the rest of the organization around it, through the use of the Five Focusing Steps.

Sounds dry, I know. But the brilliant context of the book is that the protagonist, Alex Rogo, is trying to figure out how to keep the plant he runs for a fictional company UniCo Manufacturing from closing. In the case of the plant, the goal of the plant was increased profits. The constraints to that goal were bottlenecks in production as well as sales volumes. Alex ends up tweaking and twisting those bottlenecks to up production as well as bring in more sales at lower margins but huge volumes.

Besides bringing back memories of years ago, I have to admit, this book got me thinking. What’s the analogue of the plant’s goal and constraints in engineering?

I think we all know what engineering does, whether it’s digital or on paper. I think we all know a good amount about the difficulties that the engineering organization faces with layoffs with no falloff in workload. We know a lot about the trends in the engineering organization like globalization and the recession. But finding the analogue of the plant’s goal and constraints might not be as easy as you might think. It certainly wasn’t easy for Alex in the book. At that time, there were all sorts of long-standing and well-known trends and initiatives in manufacturing. However Alex didn’t figure out that profitability was the goal of the plant until halfway through the book. He didn’t figure out that production bottlenecks and sales volumes were constraints until not long after he recognized the goal. So let’s pose the same questions here.

What is the goal of the engineering organization?

What are the constraints limiting the engineering organization from achieving that goal?

What do you think? I’ll post my thoughts in a follow up post next week.

Take care. Talk soon. And thanks for reading.

The ‘Get It Right The First Time’ Principle

Last week, in the post about the engineering minefield and unplanned work, I promised some principles to help with avoiding the 15 hour engineering emergency that blows up your week. The ghist coming out of that discussion was that product issues that proceed downstream eventually make their way back to engineering as unplanned work. That’s when the firedrill lands on your desk. So how do you minimize the firedrills, the unplanned work and the product issues that get downstream?

Get it right the first time.

For those unfamiliar with the concept, the idea is to do things differently prior to design release so product issues never get downstream. As a result, those errors, change orders and issues never turn into firedrills in the first place. Furthermore, it saves other organizations in the company too. Those are errors and change orders that purchasing, quality, manufacturing and legal never spend time on.

Now I know you’ve probably heard about this concept many, many, many times before. It’s been cited so frequently by software providers in the context of their engineering software tools that it’s hard to associate it with anything else. But while technology can be part of the answer, it’s far more than that. What else does it involve?

  • Take More Time Up Front: I know schedules are ridiculously tight. I know you’ve probably got more work than you can handle. But the fundamental concept behind a get it right the first time principle is that you take more time up front to save even more time later. You can’t simply keep the same schedule up front and expect to reap the rewards downstream. That has to be a mantra time and again to management.
  • Procedural / Process Changes and Measurements: Also realize, however, that just doing the same thing slower will only incrementally improve things under a get it right the first time initiative. If you want to catch more product issues before they get downstream, you to change your activities so they can affect that goal in a measurable way.
  • Software is an Enabler, not THE Answer: Engineering software applications and system can go a long way towards enabling this principle. But plugging in a new tool into the same old problematic process won’t result in the changes you want. Don’t get me wrong. Software helps. But it’s an enabler with other changes. Not the endgame answer by itself.

A get it right the first time principle can help a lot. But there are other things you can also do to address problems associated with the engineering hero work issue. Next time, we’ll take a look at non-value-added tasks and how to deal with them.

Take care. Talk soon. And thanks for reading.

The Engineering Minefield and Unplanned Work

For the past couple weeks, I’ve outlined a few thoughts on the difficulties related to doing engineering hero work. Before we move on to identify how to responsibly do your job yet maintain some reasonable quality of life, there’s an important question that we should contemplate: why is there such a frequent need for engineering hero work in the first place? If we took a survey to answer that question, I’d be willing to bet money the most frequently selected choice would be that development projects are understaffed. And absolutely, I agree projects are understaffed. However, in my experience, that incrementally increases the amount of planned work for each team member. The big problem is the occasional spike of work that becomes a 15 hour work day that is the real backbreaker. That often is not due to planned work, but instead is a result of unplanned work. Where does the unplanned work come from? There’s three characteristics that contribute to unplanned work.

All new products have unresolved issues after design release.

When one thinks of engineering work, lots of different terms come to mind: experimentation, discovery, invention, innovation and exploration to mention a few. But regardless of what word you use to describe it, engineering a new product often involves the development of new systems, materials, components or any number of other new items. Any new item will have a number of issues that, if left unresolved, will cause product level issues. And despite analysis, testing, qualification or any other type of procedure, some amount of product issues will be unresolved beyond design release. From there, they proceed downstream in the product development process.

The remainder of the product development process catches many product issues, which come back to engineering as unplanned work.

What happens to those product issues after design release? Luckily (or hopefully) a good number of those product issues are caught during the sourcing, production and quality testing activities in the rest of the product development process. These product issues are then entered into the change process where they return to engineering for resolution. However, returning unresolved product issues aren’t part of the schedule. If aware of them, they are resolved prior to design release. So all of these product issues show up as unplanned work.

Engineering is a flexibly resourced organization and acts as a buffer in the development schedule.

The problem here is that most engineering staff already has a fully loaded schedule. As we mentioned before, with many development projects already understaffed, the amount of planned work has already incrementally increased. But the unplanned work associated with these product issues are actually highly prioritized because the product is so close to their launch or delivery dates. As a result, both the planned work and unplanned work must be completed. That’s how engineering suddenly becomes a flexibly resourced organization. It’s not that some work is outsourced, that part time engineers are hired or more engineers have flex-time. It’s just that the same engineers work longer hours until the planned work and unplanned work is complete. Simply put, that’s the nature of engineering.

All in all, there are a few takeaway points.

  • Development projects are understaffed, but it’s the unplanned work that causes the 15 hour days for engineers.
  • The unplanned work comes from a sequence of events as follows.
    • All new products have unresolved issues after design release.
    • The remainder of the product development process catches many product issues, which come back to engineering as unplanned work.
    • Engineering is a flexibly resourced organization and acts as a buffer in the development schedule.

In the next few posts in this series, we’ll talk about some principles to follow to address these core issues.

Take care. Talk soon. And thanks for reading.

What is the Impact of Siemens PLM’s HD Strategy on Decision Support?

This series of posts will cover new product releases, changes in product strategy and acquisitions by engineering software providers affect engineering stakeholders. New posts in this series will be published based on software provider activities. Today’s post focuses on the relevance of Siemens PLM’s HD strategy for NX and Teamcenter. This post includes a breakdown of the impact of these new offerings on different stakeholders in the engineering organization.

Dates and Events: Since fall of last year, Siemens PLM (wikipedia entry) has introduced had a series of announcements centered around a new framework called HD-PLM. First, as part of the October 2009 launch of the 7.0 version of NX (wikipedia entry), they released HD3D (HD3D press release). Then, in May of this year, Siemens PLM launched a Visual Reporting offering called HD-PLM (HD-PLM press release) as part of Teamcenter (wikipedia entry). In June of this year, I attended the PLM World event in Dallas and received public and private updates on Siemens PLM’s HD strategy. These announcements from Siemens will be part of an ongoing strategy that will result in the future release of other new capabilities and products.

New Capabilities: In short, the HD3D capabilities of NX and Visual Reporting capabilities of Teamcenter provide a means of visually navigating 3D models to access and report on data and information. Stakeholders in either NX or Teamcenter can run visual reports, coloring components or assemblies, based on attributes and status within Teamcenter. Furthermore, these visual reports offer a ‘drill down’ capability to provide more detailed information about the components or assemblies in the visual report. As a result, a user can browse or navigate the product visually instead of textually. The purpose is to support decision making in the development process. To be clear, these capabilities do not change how NX design and simulation data is managed by Teamcenter. More details on the capabilities of HD3D can be found in their HD3D Fact Sheet. More on HD-PLM can be found at the HD-PLM microsite.

  • Commentary for Designers and Analysts, some Engineers (CAD and CAE Users): For those that use CAD and CAE applications frequently, most of your interaction with the PLM system is focused on data management activities such as checkin, checkout and managing versions, revisions and configurations. However, you definitely need access to broader product information to support design decisions along the way. How do you get it? Login and textually navigate the PLM system yourself or track down someone that can. And let’s be honest, either way is painful and/or time consuming. The new capabilities in NX provides a means to look for information in the PLM system through an application with which you are familiar, CAD or CAE, in a medium with which you probably most comfortable, 3D design or simulation models. This means you can access what you need without dealing with everything else in the PLM system. However, be aware that setting up a visual report on your model will require some orientation to understand which attributes represent what in your projects. Most PLM systems house many attributes. Make sure what you think an attribute means actually means it.
  • Commentary for Most Engineers (non-CAD users): Moreso than most stakeholders, engineers need access to a lot of information from different products and different projects. That frequently means you need information that exists in many enterprise systems like ERP, SCM and PLM. That means you often track down individuals from numerous departments to get the information you need, which unfortunately is often outdated by the time you get back to your desk. What does these new capabilities mean for you? It can provide a way for you to get that information directly from the product model, shortcutting some of the ‘trackdown game’ that wastes so much of your time. But there’s a caveats. Using this new approach will be easier but not brainless. Just like many designers and analysts that infrequently use PLM, you’ll need to familiarize yourself with the attributes in the system. Otherwise you’ll be working off the wrong information, which is worse than the ‘trackdown game.’
  • Commentary for Engineering Managers and Executives: How do you, as a manager or executive, get development project summaries today? If you’re like most, you have someone in your team or organization pull together, either manually or with some automation, a report on a daily or weekly basis. It takes time to do. Its a resources dedicated to administrative work, not new development. The information can be difficult to conclusively verify. These new capabilities provide an alternative to that approach. You could run and navigate a 3D visual report on your own, drilling down into particularly problematic areas and defining corrective action as necessary. It would provide access to status in real time. You could dedicate that resource to real development instead of administrative work. However, you will need to be somewhat technology savvy to run and navigate these 3D visual reports as this isn’t just a document you open. Like other stakeholders that may be unfamiliar with the PLM system, you will also need to familiarize yourself with some attributes in the PLM system.

Summary: Siemens PLM’s HD strategy provides stakeholders a way to visually access and navigate information in Teamcenter, Siemens’s PLM offering. For stakeholders that are not heavy PLM users and tend to avoid textual navigation of the system, this new framework provides an easier and faster way to get to information yourself. However, to utilize these capabilities, you will need to familiarize yourself with the attributes used in the PLM system and be somewhat technically savvy.

Take care. Talk soon. And thanks for reading.