Archive for March, 2016

Career Ladder

Posted on: March 31st, 2016 by admin No Comments

Career Ladder

I am re-reading my copy of Paid to Think by David Goldsmith and I find myself surprised that I missed a late section titled Transparent Career Ladder[1].

 Just as important as the actual career ladder itself is leaders’ and staffers’ knowledge if we of how it works.  A good career ladder allows people to advance their careers at the wrong place.  It must be a vehicle that delivers reliable rewards, they can only do that if you build it without the all too often subjective and auditory benchmarks that gives some career ladders a bad name.  To truly empower people, you must create a mechanism that goes beyond offering the promise of hope; it must guarantee outcomes.  The sport’s coach tells his team of athletes that if they work hard, they’ll play in Saturday’s game.  In the use of many athletes in message rings, “Hard work equals playing time”.  In this scenario, some athletes take on the challenge, work extremely hard, and expect to play; but when the time comes to reap the rewards of their hard work and their coach doesn’t make good on the promise to play, the athletes can become disillusioned, stopped putting forth the extra effort, potentially leave the team, or all three.

 Paid to THINK

Career Track Record

I have spent some time in organizations that not only get this wrong by accident, but seem to contrive ways to intentionally make this situation bad or worse.  We see open positions within an organization being filled by preordained personnel, the interview process to find the candidate but a ruse to give anybody competent the illusion that they are a contender for the position.  An organization of any size often has a succession plan. That is, we generally know the talents we need to replace certain key positions and we likely have more than one contender for that replacement.  We should also not be surprised when we may get contenders that we did not know we had in our organization.  The larger the company, the more likely there are other people with the appropriate talent for the newly opened position.

Hope and Career

Hope, as well as not being a project management approach, is not a valid resource management, nor career growth mechanism.  An organization that chides the employees to work hard, do your best and hope you have a career rather than a job here, is providing poor counsel, and likely not the type of advice they would take themselves.  When hard work is not rewarded nor talent recognized, we should not wonder why those that have delivered for us so often in the past, decide it is no longer in their best interest to throw themselves into their work.  Perhaps they have saved us millions of dollars in material or product quality, or delivered critical projects.  Uncompensated overtime hours at one time freely given to reach an objective become grudgingly given and over time, resisted.

 Career and Quantified Targets

When you are able to quantify the targets, just like you would do in a project, you now have objective evidence of performance from which to justify movement through the hierarchy of the company.  Specific demonstration of capability and positive impact upon the company is required and then must be demonstrated by the individual team members.  Doing this removes or reduces the feeling that decades of accomplishments, investments in training and education are all for naught.

[1] Goldsmith, D., Goldsmith, L., & Abraham, J. (2012). Paid to think: A leader’s toolkit for redefining your future: Achieve more, earn more, live more. Dallas, TX: BenBella Books. page 401

Root Cause Analysis

Posted on: March 25th, 2016 by admin No Comments

Have you ever watched Air Disasters television show?  If you have then you see that all too often the reason for the disaster is a series of events that lead to a disaster.  Some of these miss-steps are quite small, but when added to the other miss-steps, ends up in disaster.  This is often the problem with root cause analysis in the business setting.  The sense of urgency often stops the exploration at the most immediate finding.  Even the 5-Why approach may be too short of an exploration.  Combinations of preceding events influence the outcome which is not taken into consideration.

Another problem with root cause analysis in the business setting is often the business processes.  First, there may be the little documented process (pilot documentation such as checklists and flight data recorder) in the organization so exploring the root cause via paper trail or process structures may not be possible.  We then must resort to word of mouth (no cockpit voice recorder), and what can be uncovered perhaps via informal documentation (email chains).  Second, even if we do have process assets such as documentation, we may not have followed the instructions; which leads us back to the prior set of implications and identification of those deviations from the documented process may be difficult.

There are many other issues that can make determining the real causes of the failure we are investigating such as the level of transparency within the organization.  Specifically, how willing the departments are to take a critical look or review of the events leading up to the failure.  Continuous improvement requires critically thinking about the details of the failure (not the people but the mechanisms) and how things can be improved.  Anything less than objectively seeking the truth that leads up to the failure is a disservice to anybody impacted by the organization failure, the company, and the employees.

Take your time, as the old idiom goes, make haste slowly employ an organized approach to discovering the situation.  As you learn, refine the questions, do not expect things to end at the answer to the fifth question in the 5-why.  Take a systems view of the problem running the evidence to the logical conclusion.

Effective root cause analysis is important for the organization as the failures provide is with opportunities for learning, and these learning opportunities are mechanisms by which the organization can improve. We would not want to burn our hand on the metaphorical stove over and over again – if we can help it.

There is More than One Way

Posted on: March 22nd, 2016 by admin No Comments

I am writing this post after a discussion with some people on product development and project management processes.  The discussion took a turn to process intensive approach or not to use a defined process.  There are many ideas of how this can work, for example the Capability Maturity Model Integration is an example of the technical or knowledge areas and levels of associated processes.  This document describes the many processes and individual capabilities from each process area, for example, requirements management contains a number of specific goals with a number of specific practices.  I was reminded in this discussion, of a time when I was developing and documenting the processes for a department.  For each activity, we had an objective.  There was a reason for the activity and if the reason was not valuable, then that task was eliminated from the workflow. That seldom happened.  However, there were some steps in the work that were fairly common and we documented these. For each step, we clearly articulated the objective, the reason why we are doing this step in the development process. Then we described the inputs, the process and articulated the expected output in terms of tangible quality attributes.

In today’s fast paced environment it is sometimes a desire to be flexible.  We see times when some of the prerequisites are not met, yet we must find a way to proceed.  That is the reason for articulating the objective of each of the steps.  Knowing the objectives provides us with the context for the step, we can understand when an objective does not apply to a project or product.  In that case, that specific step can be removed from this particular project.  Knowing the objective of the step also provides us with some ideas for an alternative approach to the task should we need to meet the objective but the prerequisites or processes are missing.  In these times, we have to think creatively about how we are going to meet the demand without those things we say we typically need to do so.  We can find other solutions to meeting need rather than eliminating a key step as is sometimes the case.  If the step is needed, but cannot be performed as described in our process documentation, we need to find another solution or way to achieve the objective.  Determining this alternative approach is possible when we understand the objective and is a fundamental premise of agile as “individuals and interactions over process and tools”[1].

The problem comes when we just remove or eliminate steps without considering the ramification and determining a suitable substitute method. 

  1. Think of the working environment as a system and identify the goal or objective the specific task was to achieve, and any implications if we do not perform the task.  Some examples of the areas the task may address are below.
    1. quality (and reliability)
    2. project or product cost
    3. timely delivery
  2. Identify actions that can be taken given the limitations. For example, in lieu of design review (perhaps due to the availability of staff or time constraints) we can substitute a review of the design by subject matter experts.
  3. Institute those actions best possible

 A capitulation of the objective is not the same thing as finding alternative solutions. If the action does not need to be done, then do not do it.  If the activity has an impact on the outcome, then find the best way to meet the objective. That means adapting. That may include pairing down the way we would typically handle the task and objective.  If you must eliminate the task and objective, ascertain the worst that can happen from doing so.  Think about the development as a system and theorize the worst case outcome for eliminating.  If you find that acceptable, then perhaps elimination is what you need to do.  Consider also any mitigating actions that can be taken should the worst case risk comes to fruition.

[1] Manifesto for Agile Software Development last accessed 3/21/2016

Success and Back-up Plans (Plan B)

Posted on: March 18th, 2016 by admin No Comments

I recently noticed a LinkedIn post on success and failure that led me to the need to comment.  The quote from the article that gave me some consternation:

The minute you have a back-up plan, you’ve admitted you’re not going to succeed. ~Elizabeth Holmes
Theranos Founder & CEO

When I am driving a car, I keep in mind I may have to find an alternate path, lest in my obstinacy I run headlong into another car that shows up on my side of the road.  This was part of my driver’s education so many years ago and it is generally sound advice.  Back-up plans (plan b) are more akin to this type of action than admitting failure or that failure is possible.  Back up plans can be alternative routes to our objective.  If we extend the above argument a bit further, my plan is to take interstate 85 to Greensboro, and if that is blocked due to an accident, I will sit there rather than re-route using any number of other solutions to reach the objective.  I would not think of nor act upon an alternative plan in which to resort as it was not part of my original plan.

In the environment espoused by the above quote, I could justify using the same plan, that I have watched fail over and over again, just so it would not look as if I believe failure is possible.  It sets up a scenario in which I metaphorically (and perhaps literally) burn my hand on the same hot stove repeatedly and never learn, or adapt the planned approach or appropriately alter the objective.  Here’s perhaps news, failure is always possible whether or not you acknowledge or account for that possibility.

There is no admission of failure in altering the plan or coming up with an entirely new plan as an alternative approach should the present plan not succeed.  The approach that you believe will work in the beginning may not as you learn about the risks and the objective.  My experience suggests many executives believe this tripe.  Rather than altering to a plan that may have a higher probability of success, they maintain pushing the square peg plan into the round holed objective.

It is also not an admission of failure to learn and understand what you thought may have been a good plan and a worthy and achievable objective are in fact not.  There are real circumstances which can make the plan or the objective not feasible.  The travesty is in believing that all that is needed is to stick to the one plan or objective and an unwillingness to adjust to the facts on the ground for fear of the acknowledgement that things can go wrong.  Failure can happen whether you acknowledge the possibility or not.  The key is to learn from that, adjust your plans and perhaps objectives accordingly, and continue to work toward the goal.   There are many other letters in the alphabet that can be attempted.

Onboarding part 2

Posted on: March 16th, 2016 by admin No Comments

This is the second part of our onboarding writing.  We have seen many opportunities for growth and development in this area. In fact, the onboarding process is where those who know little about us, how we work and what we value, are guided toward a fit in our organization.  Our candidate selection and vetting process provided us with the ability to determine which candidate would most likely be a fit. However we have not completed the process with the acquisition, we have only completed the selection.

 Corporate Culture and Growth

If we value the present corporate culture, we must take steps to assimilate the new talent in such a way that our culture remains strong.  If we are moving how we work to some future state (as in continuous improvement along with personal mastery) we work to guide the new talent to this future state.  The talent we are bringing to our organization may now know what is expected of them. Take our previous blog post for example.  The new talent will likely deduce that our company holds little regard for the veracity measurements and documentation.  Their previous behavior may be modified in this light and all subsequent measurements and documentation may also abide by this cavalier approach.  Rather than build new; we contaminate, the new facilitating behavior that is less than the desired and inconsistent with our organization’s development plan and our plans with the new hire.

 Onboarding Improved with Checklists

To improve the situation we should ensure our frontline onboarding personnel, exemplify the core values and mission statement of the group and the company as a whole.  We should not select the onboarding staff solely upon availability.  We should also build a prioritized checklist of the things we need to demonstrate or teach the new talent.  This prioritized list will allow us to focus on increments of learning rather than expecting the entirety in one blast.  Additionally, this list will also allow those new members to be an active participant of their own onboarding.  As Bo Barry, a professor of mine from undergraduate engineering days said of summer school, “it is like drinking from a fire-hose, you open your mouth to catch all you can and hope to hell it does not kill you.”  We would rather not risk this with the new talent, so we prioritize what the new talent needs to know with the checklist and schedule these over a period of time wherein they may be able to acquire the skills and knowledge, for example, over a period of weeks or months.  If metered properly, the experience can be beneficial to both the new and old team members alike.


As we have said in the past, big bang cultural change is mostly disruptive and likely to produce little we could call success.  Real change takes time and is incremental.  Bringing new talent into the company and not managing their integration can actual delay or even shut down our progress toward this goal.  Take some time, plan this out, and make sure you do not contaminate new talent with old behaviors you wish would go extinct.

Risk Probability, Severity and ….

Posted on: March 14th, 2016 by admin No Comments

When we discuss risk in project management circles, we often discuss it in terms of severity and probability.  There is much more to risk and how it impacts and the implications it may have on our project.

 Risk Probability and Severity

As the saw goes, few things are certain, except death and taxes.  The more probable or more likely the malady is to come to fruition the greater attention we may need to give to this potentiality.  We couple this probability with severity.  We all know about risk severity.  The greater the negative impact on our project, the greater the severity.  The greater the severity, the greater attention we may have to pay to this risk. When coupled with probability we have a method for prioritizing project risks.  However, what you rarely see in many a project book is the discussion of the level of controllability. 

Risk Controllability 

Controllability is our ability to adapt accordingly to the risk when it comes to pass.  Premeditated or control prior to the event, is called mitigation or risk reduction.  That is we are taking controlling actions to eliminate or downplay the risk.  However, there is an element of control that happens after the risk comes to pass.  Do we have the ability to respond or control the outcome to an acceptable degree such that our project is not terribly impacted?  That is the controllability to which we are writing.  What will happen when the risk occurs, are we able to find alternate paths?  The mere structure of our organization or our methods may improve or reduce this level of controllability.  Controlling is just as important as identification of severity and probability in our view.

 Risk Register Download

We have built a download excel sheet which demonstrates the use of the Failure Mode Effects Analysis technique used for product design (DFMEA) and manufacturing processes (PFMEA) in the automotive world applied to project management risk.  

Onboarding can be Costly

Posted on: March 11th, 2016 by admin 1 Comment

Onboarding Defined

First, we should probably explain or define onboarding.  Onboarding is the collection of activities associated with our present staff socializing and training our newly acquired talent.  The older employees take time out of their day to demonstrate behaviors and pass on specific knowledge and skills.

Onboarding New Hires

Recently a person that I know was hired for a job at a company.  This person has no experience with this company or this industry.  They do not know the clientele and they do not know their coworkers.  Many of you probably recognize this way of indoctrination to the company.  It often conjures the images of being thrown to the wolves.

This person is spending time going through the company training.  The thing is, the company training is not so much training as it a ride along with people that just go through the paces of doing the work, not explaining the reasons behind the actions.  There is no demonstration of how to do particular activities and why things in the organization work the way it works.  Everything is ad hoc and ad hominem.  Perhaps that is the way it should work for this company, but I doubt it.  To be sure not everything should be a scripted process, but for a commercial endeavor, one in which we seek to secure the longevity of the organization, consistency is a significant contributor.  We secure the longevity of the organization by improving income where possible, decreasing cost, and improving the quality of our outcomes.  To do this, our people must know how to do the work efficiently and effectively.

Onboarding and Measurements

It does not end there.  This position requires the employee to take specific measurements.  The person training the newly acquired demonstrates a lack of attention to detail regarding the measurement that amounts to fabrication.  Perhaps this measurement does not matter, in which case, why measure. If it does matter, then fabrication should not be of the order of the day.  In this way, bad practices are perpetuated throughout the organization.

Onboarding and Cost

From experience, I would bet many companies suffer from this ineffective and insufficient approach, assigning present staff to help the new talent learn their roles in the organization.  The problem comes when the old guard does not really teach or instills poor practices in the new.  An organization can take years to uncover these misguided actions and considerable expense to make these old errant practices right.  It would probably work, if the management knew the capabilities of those providing the onboarding training for the employee.  Instead of selecting the person that is nearby, find those employees that exemplify the behaviors you want to see in your organization.  This is too important to manage so cavalierly.

Scrum and Merged Roles

Posted on: March 9th, 2016 by admin No Comments

Is it okay to merge scrum team roles, for example can the scrum master also be the product owner. Our experience suggests, merging the roles of the team members in scrum is not a good solution. Besides a dilution of focus, there is a compromise in objectivity.

Testing, Trade-off and the Emissions Tango

Posted on: March 8th, 2016 by admin No Comments

The Emissions Tango

There is so much to learn from this case for those who develop products for a living and automotive products in particular.  Understanding the impact of concept selection and testing of the product on the project success and product quality is important.  The early decisions we make regarding the development of the product will stay with us long after launch or we may find ourselves reworking the entire product.

Trade – offs

Most every design solution requires trade-off considerations.  For example, we sacrifice weight for reliability; or we may increase the cost to obtain a longer battery life.  Making this trade-off decision requires forethought and systems level thinking regarding the consequences and risks to product development and production.  In the case of the VW diesel situation, the trade off was NOx and CO2. [1]

The starting point of the diesel matter was, in hindsight, the strategic decision by Volkswagen in 2005 to start a major diesel campaign in the United States and to facilitate a breakthrough for this technology which at the time was already very popular in Europe. For this purpose, the Company decided to develop a new diesel powertrain unit with the EA 189 type diesel engine that features high performance and cost-efficient production.

The U.S. emissions limits for emissions of pollutants are strict. Under the strictest standard in the U.S. at the time, only 31 mg/km of nitrogen oxides (NOx) were allowed to be emitted, about six times less than under the EU5 standard applicable in Europe at that time. When designing modern diesel engines, technicians and engineers face the challenge that any measure to reduce nitrogen oxides has a knock-on effect with regard to other parameters (e.g. CO2).

The trade must be characterized and understood before making final decisions regarding the product.  This is often done theoretically and through the use of design of experiments (DOE). This data is used to generate limit curves and trade-off curves that demonstrate the relationship between the two variables.  Once we understand this relationship perfectly, we can make informed decisions as to the proposed design solutions ability to meet the demands

Bench Testing

How many times have products worked on the bench only to be a disappointment in the field?  Testing the product on the bench should happen early allowing the design team to learn about the product.  However, the bench is not the real world and hanging our hat on the bench as the definitive answer regarding the product’s suitability for the field is dangerous.  To get the most out of bench testing, there must be some correlation to the real world application.  The closer the bench test replicates the real world, the better.

In the ensuing period, in order to resolve this conflicting objective satisfactorily within the timeframe and budget of the EA189 project, according to the current state of knowledge, a group of persons – whose identity is still being determined – at levels below the Group’s Management Board in the powertrain development division, decided to modify the engine management software. With this software modification, emissions values were generated in bench testing that differed substantially from those under real driving conditions.

Bench testing informs the development staff if the design is close to workable, and not the final proof that the development work is out of the woods.  Most automotive manufacturers will build versions of the vehicles and log miles on them to understand the true performance in the real world.  In the case of heavy vehicle manufacturers, there are often customers with a strong relationship with the brand that get the product early to get some feedback from the customer and log miles of actual work to understand the suitability and reliability of the product. In the case of emissions, that would not work as emissions are not the type of feature the customer would likely notice.  However, it is possible to recover these vehicles after some driving time to understand the performance after the fact.

Hindsight and Defeat

At the end, the explanation for the technical causes for the irregularities, from the perspective of the Management Board member’s, amounts to a defeat of the emissions system according to the article.

At the end of August 2015, Volkswagen technicians gave a full explanation of the technical causes for the irregularities discovered regarding the emission of nitrogen oxides in the U.S. to lawyers from the Volkswagen Legal Department as well as to the U.S. attorneys from Kirkland & Ellis. These detailed explanations led to the Management Board member’s realization that the modification of the engine management software constituted a prohibited defeat device under U.S. law. It was then decided to communicate this information transparently to CARB and EPA. This occurred during a meeting with the U.S. authorities on 3 September 2015. Mr. Winterkorn was informed accordingly in a note dated 4 September 2015.

Let’s take a moment to revisit the bench testing.  If the altered software constitutes a defeat of the emissions system, how was it possible for the system to pass bench testing?  It could be that the bench testing did not sample or include the variables that are associated with emissions.  There are likely other explanations, but it should be clear that the testing is insufficient or the results were manipulated or interpreted errantly.


Product development can be very complicated and complex.  To hit the target requires selecting the optimum strategy to achieve the results desired.  That is matching money, benefit, scope and time for the project. Selecting what appears to be the easiest or cheapest solution may, in fact, be more costly than planned when you add the quality and non-conformance costs to the product.

I have seen companies select what amounts to the riskiest strategy given the constraints for the project. This is especially true for projects that have fixed dates such as vehicle emission projects.  In addition to selecting the best concept, there must be a constant sampling of the proposed design solution, comparing that performance against the performance expected from the final product. Lastly, the product testing must have some basis in fact or real situations.  In this case, the discrepancy between the bench test and the testing conducted by other entities that demonstrated non-compliance.  This discrepancy does mean the testers cheated or there was some manipulation of the system, but it does mean it is time to explore how the company tests the product and the test department’s approach to quality.  Testing is often the last opportunity for discovering these types of issues.

Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO