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.

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.

In a recent meeting at a client, the CEO said that the flow of new products was the lifeblood of his organization. The company relied on product development to establish its competitive position in the marketplace. That sentiment can be generalized to most companies. But what we’ve observed as we visit a wide variety of companies is that most of the competitive energy around product development is focused internally.  There is more observable ‘competing within’ than ‘competing on behalf of’ their companies.

We understand that a significant portion of the basis of this in-fighting ties to the unconscious, habitual application of the management principles of Frederick Taylor.  Current leaders of product development appear to collectively understand there is a need for change, but lack the tools to overcome deeply entrenched, counterproductive management habits.

Our last great chance to shuck off this flawed and self-limiting management style occurred during World War II.  Training-Within-Industry (TWI) was the successful Army-led effort to create an efficient workforce out of the men and women entering the factories, replacing former factory workers who were now on the front lines.  While Henry Ford a half-century earlier had lamented that every set of hands came attached to a whole, questioning person, TWI embraced the whole being and taught workers not only the key point of what they were building but went so far as to explain WHY they were key points.   TWI’s “Every person must be seen as an individual” was a clear precursor to Lean’s “Respect and trust your workers”.

The improvements brought to management during the war were lost as the returning tide of ex-soldiers reclaimed their spots along the assembly lines and in the offices of the factories.  Management reverted to pre-war ways.

At the same time, MacArthur was bringing TWI to war-ravaged Japan.  TWI, by then reformed as a private company, helped reestablish an industrial base in Japan. And the more effective management practice that had been ‘piloted’ in American factories during the war became the basis of Japanese practice.  This exportation of competitive advantage flew under the radar in optimistic and prosperous post-war America.

Early in my career, I worked as a research engineer in Japan at electronics giant, Sharp Corporation.  As a part of my basic training, I was led through a problem-solving approach (now associated with Lean) that combined the benefits of the Deming Cycle (PDCA) and the A3 communication tool.  When I returned to the states and throughout my career (which has centered on product development) I was regularly challenged by the chaotic environment in which we execute Product Development, especially in comparison to my experience in Japan.

When Lean Product Development emerged as a new management framework in the early 21^st century, I saw that it reflected what I had observed first hand in Japan.  As I was drawn deeper into an understanding and appreciation of the system, I came full circle back to A3s.  Through the A3 insights in the writings of Durward Sobek and John Shook, and in private conversations with Sobek, I realized the power of PDCA and A3s.  I also realized that my basic training had provided me with an advantage that had been displaced on my return to the States – a personal microcosm of the abandonment of our advantage when the World War II veterans returned home.

Peter Drucker was a results-based champion of Frederick Taylor and of Taylor’s contribution to economic growth in the 20^th century.  But in the 1980s, with the emergence and expansion of the knowledge workforce, Drucker realized that the limitations and problems inherent in Taylor’s management methods were inappropriate and ineffective in the information age and the knowledge economy.  To achieve necessary high productivity from this new class of worker, something better than blunt force management was needed.

So let’s think of product development, executed by knowledge workers, as a competitive event. Like an athletic contest in which we encounter an advantaged opponent, we need a game changer. The obvious game changer is a field leveler.  It is the widespread embrace and adoption of that American creation, PDCA, the scientific method applied to knowledge work, and its application through its companion tool, the A3.

A parting thought is that to just pick up these tools and apply them at a tool based level will blunt their effectiveness.  They must be applied at a principle-based level with a full understanding of their motivational and developmental value in the context of a larger system. But more about that in a later blog.

Hair on fire. That was a definition of “Priority” I was given a couple of weeks ago.

The actual story goes a little something like this: I was visiting a customer discussing Priority as it exists in their product development environment. I asked if he could make one wish to help change or improve how they managed priority, what it would be.  He replied, “get me a fire extinguisher, we’re running around here like our hair is on fire and I’d like to put it out”.  Yes, if you’re wondering, at that point I did just about spit out a mouthful of coffee after which we both had a good laugh.

But all laughing aside, this is a true challenge in today’s product development environment; EVERYTHING is seen as a PRIORITY, and let’s face it, if everything is a priority, then nothing is… To add to this thought, if there is no prioritization to the irons in your fire, then how can you really give them adequate attention and be certain that your best, and most intelligent effort is being given? The answer: you can’t.  Something will give. Timelines will expand and deadlines will be missed. Bosses will frown and a customer will ultimately be greatly dissatisfied. The age-old analogy of burning the candle at both ends, i.e., just throwing more hours a day at the challenge does not solve it with knowledge workers. The excitement of the challenge turns from myth buster to morale buster, and they will get burned out.

A recent analogy shared by a colleague was to Shrink the Change (insert Priority). You all know this one, right? Individually or as a team, make the list, and either a) define and tackle the small ones to get them out of the way, so your bandwidth (and brain) becomes more manageable, or b) actually define a true Priority queue for these tasks.  In doing so, tradeoffs will have to be made; some will be happier with the tradeoffs than others.  But by doing so, you’ve now created an achievable path to your team’s goals. And ideally, you’ve set up a series of intermediary wins that will reinforce the effort and sustain the team’s commitment. Ultimately, the small and larger wins will gain focus and push the defeatism of fire-fighting out of the spotlight. And the team will find the motivation (and brain power) to accomplish the tasks at hand, as well as playing an increasing role in defining new priorities.

So instead of beating yourself up for the thought of procrastination, pat yourself on the back for being wise to prioritize, and push some of the right tasks off until tomorrow – another good piece of advice from that colleague.

Oh, and if you’re wondering about the customer referenced above, well we were a little too late with that fire extinguisher. He’s as bald as a cue ball!