Managing change in an environment where the specifications originate outside the enterprise provides a unique set of challenges. This is the scenario for companies serving the engineered to order (ETO) marketplace. Communicating and tracking changes throughout the project’s life-cycle is critical to ensuring the solution meets the needs of the customer and is profitable for the supplier. The change can originate from multiple locations and at any time in the project. Changes initiated during the quote cycle will need a method for quick response so that the quote will reflect the request. Changes received after the order has been processed will need a method of review that will include costs and resource impacts.

One of the more challenging aspects of managing change for the ETO enterprise is the approval path for changes received after the order has been received. Sales will often push the change order through declaring that the proposed changes are within scope and should be “easy enough to do”. Or my personal favorite “can’t you just”. The decision on whether or not to accept the change needs to be a deliberate one. The change needs to be reviewed within the context and scope of the project by all functions that could possibly be affected. For most organizations this will cause significant delays, making schedule attainment nearly impossible. Instead the effects are dealt with as the project progresses, requiring huge effort to meet the demands of the schedule. The net effect is the amount of time and resources needed to complete the project will balloon. This will impact not only the project of immediate concern, but all other projects as well.

For a large number of businesses their ETO business represents a small overall portion of their total units sold. However that portion of the business often utilizes a disproportionate amount of the overall resources. Much of that wasted effort is expended closing the loop on the changes proposed by the customer as well as changes originating from within. Emails, phone calls, travel and sometimes even litigation are needed to resolve change issues. So why take on any ETO business? Most companies see it as a necessary evil, driven by a competitive environment and demanding customers. While I will not argue the need for customization here, I contend that the process does not have to be as uncertain as is practiced.

Changes from internal and external origins need to have a clear path for review and approval. The ability to measure the resource, cost, schedule and profit impacts, as part of the decision process will ensure that margin targets are met. While some may see this additional oversight as an impediment to responsiveness, the added control, associativity and transparency will drive increased efficiency. By making deliberate, informed decisions the development process will ultimately move forward more quickly.

The process of capturing, documenting, and agreeing on requirements for product change or development takes on an entirely different scope for companies engaged in Engineered to Order (ETO) businesses. While these requirements are generated internally for Make to Stock (MTS), Assemble to Order (ATO) and Configure to Order (CTO) product lines the ETO business relies on external sources. While everyone is familiar with the formal Request for Quote (RFQ) process, very few engagements will adhere to this. More likely, is a process of starts and stops requiring many man-weeks, months and years. The ability to efficiently; quote, process, develop and ultimately deliver an ETO solution is dependent on the enterprise’s ability to capture just enough information at the project’s inception to describe the product criteria, but not overly constrain the design team. Many a post-mortem analysis has revealed very small or non-existent margins from “specials”. By attending to the requirements at the project’s inception and ensuring that those requirements are of sufficient depth and breadth to quote and create specifications, scope creep can be prevented and margins preserved.

A requirement is a capability which the product or project needs to incorporate. For standard products, these are developed over time by internal teams during the ideation phase of product development.  The design and associated intellectual property are then developed as the project moves from ideation to fulfillment.  While this may describe the development of Intellectual Property (IP) for an ETO business, a different front-end is followed for ETO solution delivery.  As soon as the opportunity is identified by the sales team data (requirements) capture begins.  At an advanced maturity state, this data will be entered into the Customer Relationship Management (CRM) application with the correct associativity and visibility to the downstream (application engineering, procurement, etc) functions.  More often than not the customer contact data and a subset of the original notes will be entered. Another set of data is now stored in notebooks from phone calls and meetings. As more people become involved during the wooing and quoting phase more set of notes are created and NOT captured or associated formally to the opportunity.  Eventually, a quote is generated for the solution and delivered to the potential customer.  It is at this point where the troubles can really begin.  As the quote is iterated the data behind the iterations and the associated cost implications do not have as stringent review as the originals. When the project is finally won the margin has usually been eroded significantly from the original intent even before development starts.  During the quote iterations, technical oversight of the requirements is minimal.  This causes the potential solution being quoted to deviate from a variant of a previous design to the requirement to develop entirely new designs.  The effect is that the time estimates for the original design are now terribly inaccurate and the project won have been underbid.  If aware, most companies will choose to “eat” some of this as development time.  The problem is that most companies are not aware of this and schedule resources around original project estimates instead of the last iteration of the quote.  Now the pressure on the development team is substantial, to meet the new product deliverables at the same time allotted for the original quote.

To combat this, rules and guidelines governing the boundaries for the solution need to be put in place. These guidelines can be as simple as size and complexity constraints or for often quoted, complex designs, configurators can be employed to accurately capture application data.  At the very minimum templates for customer data need to be developed and used to accurately capture the customer’s data. The templates need to be established with clear boundaries so that the correct oversight is employed as the quote is developed.   As important, is maintaining the data as the quote is iterated.  All data needs to be readily available to the enterprise for use during all phases of the project as well as reference material for similar projects.  Associating the original customer data to the quote and any subsequent design files will enable the organization to comprehend the effects changes will have on the overall project.  This data associativity and transparency will help to maintain the intended margin and ensure the project stays on track.

An enterprise’s ability to manage projects and programs will determine to a large extent the success or failure of the products they produce. Benefits reported by those companies that have completed Program Management Initiatives include:

• 27% greater return on investment in projects
• 30% improvement in project budget performance
• 34% improvement in project schedule performance
• 24% improvement in project risk
• 39% improvement in project requirements performance

Bottom line; Companies with a more comprehensive business perspective of program management are more successful. So how do these companies realize their program management goals?  By clearly defining key success factors, phases, milestones, roles and executing in accordance with these outlines.  Below we will define these characteristics and present a way to describe your organization’s implementation maturity.

The items we identify as key success factors are sometimes referred to as competencies.  We identify these as Key Success Factors to underline their importance in driving your project’s success. The order presented here is for convenience and should not be mistaken by the reader as ranking importance.

Key Success Factors

• Governance
• Alignment
• Coordination
• Management
• Planning
• Finance

Governance is the metrics and operations utilized to guide and measure progress. The development and adoption of these metrics enable the program team to gage progress. Incomplete adoption of this key success factor will cause misalignment of the team and the business decision points required for success.

Alignment is the ability to maintain the team’s view of strategies. Product portfolio, sales and overall corporate strategies need to be within the program’s targets to ensure the product contributes to the overall success of the enterprise. Failure to align program goals with overreaching strategies will cloud decision making at every turn.

The coordination of data across the team and enterprise enables all stakeholders to work from the same assumptions. Incomplete data will disable the team’s ability to work effectively. Delays and missed targets will result if current data is not available to all.

Management’s ability to provide guidance, insure accountability and remove obstacles will set the tone for the program. Managers need to be proactive to deliver a best practice solution. Driving decision making and ensuring the team is equipped for the challenges presented.

The planning required to connect information and resources to maintain schedule and meet deliverables is the responsibility of program management. Aligning goals with the availability of information and resources will enable schedule attainment. Conversely, excessive dwell or loopbacks in the dissemination of data will cause delays.

Tracking financial goals and progress across program checkpoints to determine target alignment and support decision gates is imperative to the program’s success. Failure to do so will result in missed targets, ballooning budgets and ultimately canceled programs.

Incorporating a continuous improvement process to assess performance and take advantage of lessons learned. This is a way of institutionalizing the capture of tribal knowledge. Process improvement initiatives reduce the opportunities to repeat mistakes.

Mastering the above factors increases the enterprise’s ability to execute projects. As an enterprise’s execution maturity increases program management efficiency will follow. Continuing to monitor and improve performance will enable more projects and drive growth. Delivering successful products to the marketplace efficiently becomes engrained within the organization. On time and within budget are the typical metrics cited to define a program’s success. But, neither sufficiently define a product’s success once in the market. To do this meaningful metrics need to be established and tracked. Market share, profitability, and performance criteria targets need to be defined early in the program and tracked throughout. The phases and their respective phase gates described below enable the program team to track their progress and move the program forward

Program Management Phases

Step 0: Establish Processes for Various Types of Development Programs

• Define standard phases, gates, and decision criteria
• Develop templates for standard process deliverables
• Define guidelines for process execution and gate facilitation

Step 1: Initiate Program Phase

• Identify and recruit core program team
• Review program phase objectives and inputs
• Review standard operating procedures & identify exception
• Allocate responsibility and accountability

Step 2: Monitor, Control & Report

• Monitor process tasks, deliverables & metrics
• Manage development schedule & costs
• Manage program-level issues and risks
• Conduct internal program reviews
• Communicate to external stakeholders as appropriate

Step 3: Conduct Gate Reviews 

• Assemble gate packages for review
• Evaluate program performance against evaluation criteria
• Adjust allocated resources and funding as appropriate
• Review objectives, resources and deliverables for next gate
• Communicate to stakeholders as appropriate

Step 4: Transition Program

• Transition product to steady state management, if appropriate
• Archive program deliverables for reuse and historical reference
• Evolve, improve & institutionalize lessons learned

The above steps and their respective descriptions are provided here as the minimum criteria for a program to meet the established goals. Therein lies the secret to a program’s success; establishing the goals at the program’s inception. Without clearly defining the goals a program is essentially rudderless. After the goals have been established by a small cross functional team, a broader team can be engaged to initiate the program. Once initiated, progress is monitored to track goals and insure that all stakeholders are still informed. Monitoring is a way to manage risks as they arise. Gate reviews are performed only as necessary to maintain alignment with stated goals and milestones. As the program progresses the steps above and the associated reporting assure all stakeholders that the original targets established are to be met. Towards the end of the program when success is near certain the program transitions to archiving the success and developing a maintenance and improvement plan.

Program management is the work done to add substance and value to a set of disparate inputs to deliver products and services.  An enterprise’s success in the marketplace is determined by the ability to deliver products and services that meet the needs of the target customers. Obviously the success of the enterprise is driven by the capability to manage programs. Developing the capability of consistent governance to establish project goals and coordinate project teams will fuel growth. As these capabilities mature the enterprise will find it easier to aggregate performance metrics with financial targets.  Mastering the Key Success Factors through all phases of the program will drive increased maturity.  The ability to increase the problem solving and decision making capacity across an organization will enable the mastery of the competencies driving maturity. How an organization creates distributes and consumes data will provide the tools for solving problems and making decisions.

In an earlier blog we talked about the Lean concept of Cadence in organic terms as a heartbeat.  And then we moved out of the comfort of that pat analogy to suggest that other periodic organic processes might serve as a better analogy of cadence in Product Development in consideration of its extended cycle times. Today let’s move back to the analogy of the heartbeat and explore the concept of Perfect Cadence.

If we look at takt time on a production line as a two beat cycle — in one cycle the line advances, in the other the value adding tasks are executed – the heartbeat and our circulatory flow do serve as clarifying models for the Lean elements of Cadence and Flow.

Heartbeats have been in the news recently with the minor dustup over the suspicions of privilege in Dick Cheney’s successful heart transplant.  Below that opinionated noise there is a far more interesting story, and one that has caused my Lean head to spin — continuously — and to muse.  This other story begs the question of what would happen to the relationship of Cadence to Flow, and to our heartbeat analogy if there were no driving beat but rather continuous flow.

Prior to his heart transplant, Dick Cheney had an LVAD (left ventricle assist device) implanted to help support his failing heart and to keep him alive until a candidate heart could be found.  There are over 10,000 heart disease patients who now have one of these LVADs embedded.

The development and adoption of artificial hearts have been constrained by the rapid wear and tear on the implanted mechanical pumps, as well as by the difficulties of supplying power to the devices. The hundred days of life extension given to Barney Clark by the Jarvik 7 heart in the 1970’s set a course for medical engineering research, but the goal of a natural life with an artificial heart has remained unfulfilled.  Because of the practical limitations of artificial hearts, they have been used exclusively as devices to prolong life while patients waited for an available heart for transplant.

In the 1980’s, a doctor-engineer was inspired by an experience he recalled. A decade earlier on a volunteer mission to Africa, he had observed how water was pulled from wells by an Archimedes Screw, essentially an auger in a pipe. His inspiration and subsequent research led to the development of heart devices that moved blood not by pumping, but by means of compact turbines. Early fears that the rotating blades of the turbine would do damage to blood cells were allayed and this technology became the basis for LVADs.

LVADs are not intended as artificial hearts, but rather as ‘crutches’ for diseased hearts.  Because of their compact technology they provided mobility and freedom from hospitalization for patients awaiting transplant. Astonishingly, LVADs also demonstrated the ability to help reverse heart disease apparently in the same way a crutch relieves the burden on a leg and lets it heal.  But even greater astonishment awaited as the LVAD patient population grew and flourished.

In 2003, a patient from Central America came to the United States and was fitted with an LVAD. Communicating through a language barrier, he misunderstood the instructions for him to return frequently.  Upon release from the hospital, he disappeared. A year later, he returned for a checkup and explained that he had not returned sooner because he felt so great.  During his physical, astonishingly, he had no pulse.  His heart had given out entirely and he was being kept alive solely by the circulation provided by his implanted turbine.

Since that experience, an artificial heart based upon dual turbines has been developed and has been implanted successfully into a small number of patients as a treatment of last resort.  For now, those patients thrive and there is optimism that research has embarked on a path to a practical, long lasting artificial heart.

The circulation that results from these turbine-based artificial hearts gives continuous flow (Perfect Flow?) but no pulse, no cadence.  The critical value-add process of gas exchange in the lungs can be accomplished as the blood flows continuously. So does Perfect Cadence result from the absence of the no-value-added-but-necessary half of our two part cycle? Is it achieved when we are able to provide all necessary value contributions under the condition of continuous flow?  I think in theory it is, but as I try to visualize this in practice the only image I can summon is Lucille Ball laboring and stuffing her face at the candy factory.

Cadence is often a conscious feature.  We consciously create cadence to regulate workflow.  This enabling control feature also carries a cost, and the cost is that it keeps us from Perfect Flow.  If Perfect Cadence is that which enables Perfect Flow, then the approach to Perfect Cadence is the cadence that results as the duration of the no-value-added-but-necessary part of the cycle approaches a limit of zero.  This may not exist in the organic model that we choose to apply to our knowledge work, but it likely has conceptual value in areas like production where, like in the world of medical devices, both organic and mechanical models apply concurrently.

Cadence.

In the world of Lean, the timing of the complex dance of syncopated work is managed through cadence.

The most visible and familiar example of cadence in Lean systems is the concept of takt time that controls the production line. The work of each station along a production line or in a work cell is executed within the same time-duration bounding-box. The concept of cadence enables load leveling, the act of shifting work from one production workstation to a neighbor so that the time of execution at all workstations can be balanced to fit into the shortest, most efficient takt time. The most efficient takt time produces the most efficient total cycle time and serves the high-level goals of Lean production systems.

One of the five fundamental principles of Lean is Flow, the uninterrupted movement of value across boundaries. Cadence is the heartbeat that determines the flux of value within the system. The analogy of a heartbeat is doubly appropriate.

Like a heartbeat, the cadence of production has a systolic stage that forces flow, as work in progress moves from one station to then next. And the cadence has a diastolic stage of low flow pressure, during the execution of the tasks at each station.

The second valuable aspect of the analogy of the heartbeat is its organic nature. With increasing focus on knowledge work and management efforts to humanize the workplace in the pursuit of greater productivity, mechanical models have been increasingly displaced by organic, systemic models. And so the heart organ replaces the ticking clock or the metronome as the timing event.

In Lean Product Development also, cadence serves to both coordinate and drive the timing of events. But unlike in the manufacture and assembly of product, the cycle times of product development are much longer and the model of the beat-per-second human heart is useful, but less insightful. An example of the use of cadence in Lean Product Development is the use of Integrating Events in Set Based Concurrent Design. These events are used to put innovation ‘on a clock’ but in a way that is not counterproductive to the creative work.

The period of this development cadence extends over several weeks. For what kind of creature does this describe their heartbeat? Obviously, none, and so some other organic cadence function likely serves as a better model. The menstrual cycle leaps to mind — appropriate by period of cadence, by its somewhat variable regularity, and by its key role in the creative (innovation?) process. Of interest to me is the time variance between the two strokes of the integration event cycle, if fact of any cadenced cycle. It gets me thinking.

In a heartbeat, the two halves of the ‘lub-dub’ cycle are approximately equal in duration. In a factory setting, the division of takt time between the task of adding value and the task of movement to the next station are ideally not approximately equal in time, but rather the value-add time is maximized and the non-value-add-but-necessary time is minimized.

Allow me to detour for a quick, justification side bar here. A common caution to Lean practitioners is to avoid blindly applying the tools of Lean, but rather to use them with an understanding of the underlying principles that guide their application, the ‘why’ of the tools. Like the standards that we have developed to make our work more efficient and more effective, the principles of Lean themselves must be analyzed and sometimes challenged in the cause of continuous improvement. And so I embark on a perhaps Quixotic dive into thinking about flow and cadence.

My thinking calls into focus another fundamental principle of Lean, the pursuit of Perfection. Principle based Lean practitioners recognize Perfection, the idealized future state, as being more of a compass heading than a destination. And so the question is begged, what is Perfect Flow? Is it the reduction to zero of non-value-add but perhaps-necessary time? And if that is so, does that mean no movement (so no flow) or that value-add can be done during movement? We’ll rip this apart in our next blog. And we invite you to send your thoughts on this and all future blogs in to us to help guide our thinking and our learning.

And so as we speak of the next blog and of the value of cadence, we are announcing that we will now put a cadence to our postings, to make it easier and more predictable for those who wish to follow. We will put up some new thoughts on the first and third Tuesdays of the month, with the occasional ‘organic’ variation to our regularity. And on occasion, we may throw up an intermediary blog as we get something off our mind and into words. And, again, we are interested in your feedback, so please share your thoughts with us.

It has been a great year looking back upon 2011! Many of us have been very busy and have accomplished many goals. I was asked to continue my PTC U Certifications within the Windchill course offerings alongside keeping up with the new Creo Elements Pro 5.0 (ProEngineer Wildfire 5.0) courses. I will continue to talk about Windchill during next week’s topic. This week I would like to reflect on those customers that have accomplished their goal of learning a new CAD system. Here is one perspective on switching CAD software from someone who has done it before.

Lately, I have had many customers that have taken my Introduction to Creo Elements Pro 5.0 course with extensive prior knowledge of a different CAD system. These experts of the other CAD system usually always appear a little reluctant to learn something new. I can totally understand! These customers are being asked to take a week off from being productive at work as well as their productivity will be down while trying to produce work within a new CAD system. In addition to this their old habits, comfort, etc. will be put the test and will most likely have to be either lost or recreated. All of this equals stress!

As I teach these customers I like to take away that stress. The less stressful I can make the training environment the better it is for learning. Switching CAD software is a process. I too made a similar switch a dozen years ago when I learned Pro/ENGINEER being a prior AutoCAD user. This switch from a 2D CAD system to a 3D CAD system can be the most difficult scenario I run into. I like to let the customer know this fact to ease any of their frustrations they are having during class, as well as reassure them that they are doing really well in the learning process. I also like to let the customer know of similar or different terminologies and concepts. However, they soon learn that this 3D element opens a whole new world of capabilities and precision.

Another common customer I run into during these Introduction classes are ones switching from a smaller company to a larger company. Sometimes smaller or startup companies go with a less powerful CAD choice like Inventor, Solid Edge, or Solid Works. When customers leave those positions in search of new opportunities they tend to find themselves having to now learn a version of Pro. This switch is not as difficult if the learner is actually willing to except the change. Meaning, I sometimes find an individual in my class that will not be 100% to the change even though they openly admit that Pro is a much more powerful CAD system and they even understand that many of the other parametric 3D CAD systems are based off if it. This customer will still wish they can continue to use their old CAD system.

Both situations go back to the customer’s habits and comfort. To ease the transition of switching CAD software I tell them that the only cure I know of is to make switch with an open mind and build more models. The more models they build, the more time on the system, and the more they will understand it. I can even see this during the one week I spend with them. Thursday and Friday are always easier for all learners during the Intro class than Monday was. I must run and prepare for some Windchill training next week…Take care!