“I’m just too busy.” I hear this phrase every single week from my customers and prospects. That followed by, “There’s no time for another meeting, we’re up to our neck in new design projects, it’s our busy season so we can’t even think about implementing another system, and we’re way too busy for training.”
For so long, I’ve equated success with being busy until I read this quote by Friedrich Wilhelm Nietzsche, “A man who is very busy seldom changes his opinions.” I’d like to think there is a parallel between being busy and product development. Professionals in Product Development are paid to change things, to push the envelope, and to challenge the cadence of our weekly schedules.

EAC offers LEAN Product Development seminars in different cities throughout the year. These seminars are packed with executives eager to learn the latest and greatest in LEAN theory. The executives in the room listen attentively as they begin to imagine how their organization can operate as a learning organization.

I often wonder what would happen if our keynote speaker (our fearless LEAN evangelist) stood up in the front of the room and told the audience to focus on learning for the remainder of the week. He would order VPs, Directors, and CEO’s to take their teams offsite while putting their backlog of projects, design review meetings, and production schedules on hold. Of course, that’s neither reasonable nor realistic. But what if?

According to Michael Kennedy, “the greatest waste in the enterprise is the absence of sustained, real-time organizational learning, and very little effort is being applied for resolution.” Why aren’t we all working towards becoming a learning organization? By definition, a learning organization is one that has a heightened capability to learn, adapt, and change. Isn’t that what product development should embody?

I see mission statements that claim a commitment to continuous improvement yet haven’t invested in a class in years. We find the money for new tools, but we can’t take time to learn how to use them. We invest in new product development, yet we don’t educate our people on the fundamental process behind it. Most importantly, we don’t take time to learn from our own mistakes. Why? I think the answer is our own perceived success, our busyness!

As we begin the lazy days of summer, I encourage you to start small and embrace each day. Focus on one area of your work or personal life and take some time to learn how to improve. Invest in yourself, because you are your own most powerful tool. As Dr. Seuss taught us so well, “The more that you read, the more things you will know. The more that you learn, the more places
you’ll go.”

A couple of themes that we regularly visit when consulting with companies are those of power-over versus power-to, and of the underutilized potential of common goals. In the lead up to Independence Day, these two themes again came to mind.

As is characteristic of most institutionally important characters, the stories of our founding fathers have been rendered as mythology. The generalized morals and values that we wish to perpetuate as inherent in our national character are played up, and the untidy, vulgar humanity of the founders is sanitized. Too bad, because the historical facts that surround the relationship of John Adams and Thomas Jefferson are both informative as well as confounding.

Adams and Jefferson were men of different backgrounds, different temperaments and held polar opposite views on the balance of power between the Federal government and the State governments. One was an arrogant, elitist New England farmer. The other was an erudite Virginia plantation master, architect, engineer and man of letters. And they were friends.

United by the common goal of breaking free of the perceived tyranny of King George, these two were assigned to the five person Independence Committee of the Continental Congress, and as a pair were assigned the action of drafting a statement declaring the secession and independence of the united American colonies.  Their work in articulating a broadly accepted and admired Declaration of Independence, and their positions in the conduct of the subsequent war and in the formation of the unique democratic experiment in government that resulted, established between them a deep respect for the purity of each other’s motives and a deep personal friendship.

Adams and Jefferson were ballot rivals when George Washington chose not to run for a third term.  Adams ran as a Federalist, Jefferson as a Democratic-Republican and Adams won by three electoral votes.  By quirk of how elections were conducted at that time, Jefferson from the competing party served as Adams’ vice president. The friendship that united them brought civility to their political disagreements. Specifically, they debated whether the federal government should control and build a dominant centralized power or whether it should distribute power to the states.

This debate continues to be played out today in the private sector as geographically dispersed corporations struggle with the balance point between the necessary controls maintained by headquarters and the degree of autonomy allowed to the distributed sites. Our personal bias is on the side of distributed management authority and autonomy in recognition that local effectiveness is in large measure contingent upon local control.

The mudslinging that characterizes modern politics and that makes the run up to elections so off putting is not modern at all.  The election of 1800 in which Jefferson defeated Adams in his attempt to secure a second term was so harsh with negative rumor and innuendo that it ruptured the bond between the two and bitterness filled the space between them.  These civil rivals became bitter rivals.

For eighteen years there was very little communication between Adams and Jefferson, but when Abigail, Adam’s wife of 54 years, died, a sympathetic exchange of letters opened up a ‘normalization of relationships’ between Jefferson and Adams. As the two again engaged in regular communication, the rivalry of their politics and their world views continued, but their exchanges were once again characterized by measured civility and respect.

As Adams and Jefferson became the sole survivors among the signers of the Declaration of Independence, Adams volunteered that he was determined to live to see the 50^th anniversary of the signing in 1826. The human will is an amazingly powerful tool. When applied to control others the common result is a war of wills, and we often find that the ends are suboptimal, skewed by the confrontational means. But when our will power is turned on ourselves in acts of commitment and determination, it is astounding what can be achieved.

Willing himself to live to 90 years of age, at a time when such longevity was rare, Adams did survive to see the 50^th anniversary of the signing. Astonishingly, he lived to reach the 50^th anniversary, but he died on that day. His last words were a competitive lament that ‘Thomas Jefferson survives’.   Unknown to the dying Adams was the fact that Jefferson had passed away earlier that same day.  That these two polar rivals among the founding fathers, the two assigned drafters of the Declaration of Independence and the last survivors among its signers both passed away on its 50^th anniversary astounds.

In our modern world and our focused segment of product development, the balance point between control and distributed authority remains an important consideration in the pursuit of business success. And the use of will to motivate ourselves to high achievement supersedes its misapplication in attempts to control the behavior of others. The lessons from the relationship of Adams and Jefferson are instructive. Perhaps most valuable amongst them are that civility can exist in the discourse of diametrically opposed views, and that the great strength of the bonds built on the successful pursuit of common goals, once shattered, can be gracefully repaired by the recovery of humanity and the application of good will.

At a recent seminar we gave that touched on root cause problem solving, one of the attendees asked a question about a problem at their company. The problem involved two individuals who were in conflict, in essence, over the definition of the problem. I gave an answer that suggested assigning the solving of the problem to a third individual who had not taken a no-compromise dig-in-your-heels position on it. The attendee said that the problem was actually the intractable insistent stand taken by the two employees in conflict, and that the personal conflict was the problem they were struggling to solve.

Since the seminar, understanding that I had not given a very good answer to the question, I have spent some time thinking about this situation and will share my thoughts in this blog.

The problem is one that we are all likely familiar with. The market requirements for a development project insisted on a product feature whose shape and tolerances were beyond the current level of manufacturing capabilities. The two individuals squared off alternately insisting the feature was necessary and then the other that the feature could not be created according to the spec.

A couple of quick thoughts have occurred to me right off the top that helped me put my considerations into context. First off, I recalled Deming’s instruction that 95% of what appears to us to be a people conflict or a people problem is in fact a system problem that comes to the surface in the guise of a people problem. And the second thought is courtesy of Peter Senge who postulates in the second law of systems thinking that pressure (pushed ideas, pushed requirements) creates its own resistance.

As is often the case with problems that have hooked in combatants, there are short term measures that need to be taken to get past the current incarnation of the problem, and then in follow up, a root cause problem solving project should be executed to prevent or at least mitigate future recurrence.

Let me insert here a brief disclaimer. In the problem solving technique we teach, we apply the ‘learning first’ paradigm that those of you familiar with Mike Kennedy’s writings will recognize. The technique calls out a principle common in all applications of the Lean philosophy, that the first step is coming to an understanding of the problem by going to the gemba (or in product development by following genchi gembutsu), that is going to the location of the problem and experiencing it first-hand. We have not done that, so this discussion will be generalized rather than specific.

First is the band aid to get past the current standoff. Power struggles that show no sign of resolution need to be escalated to move things forward.

Then, to start, the requirement should be dissected.Is it a real requirement — a must-have or a should-have, or is it a nice to have — a could-have? If the requirement is legitimate, then the second step is to confirm the ability of manufacturing to hold the specified tolerances.  If in fact both individuals are correct – it is a legitimate requirement and manufacturing can’t hold the spec – then what Covey calls the 3^rd Alternative must be sought. Because both combatants are right, the position of each combatant relative to the other is wrong, and new thinking is required. A list of alternate options would be created, and the tradeoffs of the viable ones would be analyzed against each other. For example, outsourcing seems a logical option, but that option needs to be evaluated on a cost/benefit basis of the required feature. If it is a must-have (we don’t have a product without it) compromise is not possible and the best cost for the feature should be sought. If it is a should-have (the market values this and our product would be better positioned including it) then the cost/benefit may in fact drive to a compromise position.

In moving on to the long term solution for this problem, it is worth citing again Deming’s contention that this people problem is most likely a systems problem. If in this organization, like in many organizations, a marketing manager sets the requirements that a project manager must lead a team to satisfy and subsequently a production supervisor must see repeatedly manufactured, you have no natural constraint on the requirement setting. Even well intentioned product marketer can create a situation where it is impossible for other downstream leaders to succeed. Some organizations have set up a system where the individual responsible for setting the product requirements also runs the project and is thereby responsible for delivering against the requirements. This drives a natural rationality into the setting of the product requirements!

Other organizations have moved to the definition of product requirements as goals rather than as hard specs. In the case of must-haves, they are defined as technical specs. But for should-haves, a system of goals cascades from product level goals down to subsystem and assembly goals. This creates a more open design space for the development team, as opposed to the overly constrained space bounded by hard specs. It is common for product development organizations to adopt this practice on their path towards implementation of Set Based Design.

The best system level countermeasure to the cross functional conflict that we are discussing here is a product development system element that has been implemented in Japan, but to my knowledge no organization has implemented here. It requires extreme discipline and patience. This element is called a Kentou Phase, a study phase, inserted early into the development cycle. During it, cross functional team members share functional knowledge and functional need with other team members.  And the team members collectively study how to satisfy the goals of the project. In the end, this approach prevents even a strong individual pushing their ideas on the team ‘and building its own resistance’.

Resolving cross functional conflict is critically important, because quality problems arise on the interface between functions. Conflicts like the one that we are looking at here will result in a sub-optimal level of product quality if they are not successfully resolved.

If you’ve seen the television ad for Reese’s Peanut Butter Cups where the peanut butter and chocolate trucks collide to produce a novel tasty treat, then you’ll understand the basis for this blog entry.
In our case the peanut butter truck is a dialogue that has become a standard part of our engagements with consulting clients.  After seminars or during product development system discussions, we are often asked who are the major product development thought leaders who we most admire and who serve as strong influences on our own thinking. The chocolate truck counterpart is the parlor game in which people name the three people that they would like to invite to a dinner party. A group of my friends recently enjoyed this game, and yes, there was drinking involved, and yes, it is in my own career’s best interest not to go down the path of their interests!

But when I apply the question to my professional interest, and allow myself to expand the dinner group to four, I was able to come up with my own personal Fab Four of Product Development.  In no particular order here they are. They are all respected authors so you should be able to find lots of follow up material if your interest is piqued.

First invitation gets sent to Durward Sobek. Durward is a professor at Montana State University and a humble, focused thought leader in the world of Lean Product Development. Durward was the lead on-the-ground-in-Japan researcher for the first foreign team allowed behind the curtain that cloaked understanding of Toyota’s closely guarded product development system. Durward is co-author of the Shingo Prizing winning book, Understanding A3 Thinking, which gives a full and clear understanding of how Deming’s teaching have been applied and practiced with great success in Japan. On first meeting Durward and then reading his book, there was immediate recognition of how the tool in the book’s title was a potential game changer for Western product developers.

Second invitation goes to John Shook. Like Durward, Shook is a Shingo Prize winning author, who also focuses on the A3. Durward, I know personally, as well as through his various writings; John Shook I know just through his writings. Shook’s book, Managing to Learn, doubles down on the belief that product development is about the generation and application of new knowledge, innovation, but he also importantly charts out how the A3 process is used as a cornerstone of the ongoing professional development of engineers at Toyota. Shook’s writing is deeply insightful and resonates with authenticity, being based on his own experience as an early Western manager within the ranks of Toyota both in Japan and subsequently within the US. Toyota does a lot of things well; Shook helps us understand their important investment in people.

The third invitation goes to Don Reinertsen. I’ve only had the pleasure of meeting Don Reinertsen once, but it was after having followed his writings since the late 1990’s. When I met Don, I was in the middle of reading his latest book, The Principles of Product Development Flow. He told me it is a difficult read. It is. It is also worth the effort. Reinertsen uses communication theory and practice as a framework for considering product development, in that both systems are characterized by high variability and both have as a necessary goal, the flow of information. Reinertsen’s perspective on product development, his multi-decade promotion of Queuing Theory which challenges self-defeating behaviors in product development, and his emphasis on the economic consequences of our current “best” practices are all valuable contributions to efforts of improving how we operate.

The final invitation goes to Mike Kennedy; last, but in fact perhaps most significant and influential. I attended a seminar Mike gave in the early 2000s, and it was an epiphany. It began my conversion from corporate executive to a product development consultant focused on Lean Product Development. Mike has been the major voice articulating both his own and the late Allen Ward’s understanding of ‘a better way of doing product development’. EAC has an ongoing partnership with Mike. He is a champion of the LAMDA process (the PDCA process as practiced at Toyota, interpreted and recast by Allen Ward to suit Westerners), and the developer of Learning First Product Development. He is also the first author to elaborate the theoretical framework for Lean Product Development and then follow it up with a guide to its pragmatic implementation in Western environments. This latter contribution is captured in his book, Ready, Set, Dominate. Mike now travels the world as an evangelist, or perhaps better, as the Johnny Appleseed of Lean Product Development.

So that’s my dinner party.  For me it would be a slice of heaven.  I should probably start a bucket list and get this on line 1.

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.

Recently, while delivering a seminar, I had an adverse reaction when I was referred to as an expert.  My reaction was to feeling that I was being put in a box (even if a box that was intended as flattering).  It was also a reaction to the negative baggage associated with the word in the world of management theory.  And it was recognition that in the arena of product development it is the technical, not the theoretical, expert that makes the profound contributions.

The baggage tied to the word ‘expert’ is a carry forward from the management theory of Fredrick Taylor.  Taylor’s theory has become the basis for how we practice management in all venues within a business.  Taylorism based management has established intractable habits that are both deeply ingrained in us and detrimental.

Briefly, Taylor’s theory, focused on optimizing work efficiency, divides the various elements of work among different individuals.  The decision on what to work on (responsibility) is left to a manager.  The design of the method by which the work will be done (knowledge) is left to an expert.  The actual work (action) is done by a third individual.  This system believes there is one best way of doing work.  But the system has no way of incorporating the fourth element of work – feedback, the element of learning from doing, the element that informs improvement.

While Taylor’s approach to work had both supporters and disparagers when it was applied to blue collar work in the first three-quarters of the 20^th century, it was universally rejected — at least theoretically — as an inappropriate management style for knowledge workers.  Knowledge workers emerged and rapidly expanded as a significant part of the workforce in the late 20^th century. And this is the part of the workforce that includes the vast majority of us working in product development.

Do you want to be told what to do?  Like most, you would probably prefer not to be told what to do, but for the sake of organizing and coordinating efforts to accomplish goals, most of us recognize the logical necessity of focusing work efforts through the assignment of task.  Do you want to be told how to do what you are told to do?  I have never heard anyone volunteer that being micromanaged was a positive in their work life!

So my historical sense of experts who arrogantly believe they can devise the best way of doing work without actually doing the work themselves is part of why I shied away from the label.

The word does hold positive resonance.  It denotes a qualitative threshold on the learning curve, the passing of which, like receiving an advanced academic degree, is recognized and imbued with a measure of admiration and trust.  But, just as learning curves bend towards an asymptote, the expert can be seen as someone who has arrived at the flat grade of the learning curve. Here one can be characterized as knowing lots but now learning little.

The arrival at a destination of great knowing is vulnerable to the onset of hubris and the loss of the ambition to learn more.  Like the Newtonian physicists confronted by the emergence of quantum physics at the end of the 19^th century, the arrogance of thinking you know it all is the harbinger of comeuppance.

For knowledge workers, the fairly recent concession that the individuals who do the work are the real experts of that particular work is both a reprieve from the worst constraints of lingering Taylor style management, and also a positive internal motivator to energize the work and to lighten its burden.

The last part of my discomfort came from admiration for the technical experts who are the real driving force of product development achievement and competitive strength.  One of the pillars of Lean Product Development is the development of a work force comprising ‘responsible experts’. The responsible part refers to individual contributors who have both the responsibility for some defined accomplishment and the authority to participate in the definition of the achievement plan.

The expert part derives from two commitments. An individual’s commitment to continual self-directed and externally directed learning is the necessary personality part of the equation. The other commitment is the organization’s commitment to the continual development of technical individual contributors, through systematic cultivation of a learning organization. This latter is the environment part of the equation. Appropriate personality and environment lead to desired behavior. And the appropriate behavior in this context leads to the generation of knowledge and the cultivation of experts.

A final thought is that most effective product development organizations are characterized by a variety of healthy, dynamic tensions that provoke change and continuous improvement. The technical individual contributor has their own analogous internal tension. The evolving expert balances a self-centered entrepreneurial ambition towards accomplishment and actualization against a necessary commitment to the larger community and its shared goals and knowledge. This internal tension of the hungry ambitious learner motivated by a larger purpose fuels the development of profound expertise. The best the rest of us can do is to ply our own knowledge to tend the development environment in support of the maturing of these business critical subject matter experts.