Archive for June, 2013

Product Life Cycle – Growth

Posted on: June 29th, 2013 by admin No Comments

If we have developed a product that is useful to our clients, our production volumes will grow allowing us to improve our product cost and pricing structures. Additionally, besides the volume purchase of material cost improvements, we will work with our manufacturing line, improving those processes and subsequent first pass yields thereby reducing the associated rework costs. We may choose to steadily drive our price down also to increase the number of consumers benefiting (as well as our company). It is possible to both reduce the sale price of the product AND improve the profit.  This situation is unlikely to last for long as other potential suppliers see our success and want to follow our lead with their own offering.

We will see further coverage or refinements in our product delivery methods. We can see securing other contracts for the product with more customers over time, adding to those we have already acquired so we see the amount of the product we produce steadily grow.

Also during the growth phase of the product, we may find other adaptation for the product.  If we designed the product to be extensible, we may elect to reinvest some of the profits into the product to meet more consumer demands that price cannot alone achieve.  In doing so we improve our sales volumes yet more (or again).  Small adaptations to the product may allow us to penetrate entirely different and prior untapped market segments.  If the product has software components, we may be able to radically alter the performance or the features facilitating access to these other areas.

Eventually, our rate of growth will start to decline. Though the slope is still positive, we will have a lower rate of slope (less steep) as we move to the maturity phase in our product lifecycle.

Product Life-Cycle – The Introduction or Launch It!

Posted on: June 21st, 2013 by admin No Comments

In our previous blog, we developed a product that was based on market research and perceived opportunity. We have tested that product both from the market perspective and the quality expectations from the customer and our own business case requirements. Now it is time to make the product available to our clientele.

We are concerned with the marketing and distribution channels of our product line. How do we get the product to the right people?  Since we now have a product to move, our plans for introduction will now be executed. If this product has some similarities to the rest of our product line we will likely rely on those existing distribution mechanism.

We may discover product uses that we did not envision in our development work. In this case we are not talking about new markets but more errant uses of the product that we may have to remediate.  As an extreme and a bit flippant example; we were not aware that the customer will use the product while in the water. We then decide that we should seal the enclosure.

We have not finished learning about the product even in this phase of the life cycle.  Our product development process may have called for such manufacturing development activities such as:

  • Process Studies
  • Measurement System Assessment
  • Process Failure Mode Effects Analysis
  • Control Plans

However these are experientially based theoretical exercises.  We have not likely produced product at the rate we can expect in our expected production volumes.  Even if we have ran a volume we believe to represent our expected volume, we have not done it for days or weeks on end as we may expect when we are at full production volumes.  The stress of full production will likely illuminate process improvement areas as we ramp up to the production volumes.  The improvements can come from any part of the chain to deliver the product to the customer. However, experience suggests, since our manufacturing line was likely not stressed through the prototype product development we may find things to improve.

Product Development Life Cycle

Posted on: June 20th, 2013 by admin No Comments

Our previous blogs have been largely on product development issues. We realized that we really have not discussed the product development life cycle in depth.  One model of the Product Development Life Cycle is illustrated below. Our next series of blogs will cover the product development life cycle from this perspective:






Each of these areas has an associated range of activities and risks. Each of the areas requires an organization to accomplish certain objectives or supply a variety of inputs to ensure the success of that phase and maximize the benefits to the organization. Our next blogs will break each of these down and discuss what happens, the types of activities the organization will do to maximize the potential and mitigate risk.

Can you do me a favor?

Posted on: June 18th, 2013 by admin No Comments

Have you ever heard this before at work? Can you do me a favor? As I was leaving a work place one day, I overheard a gentleman on the phone talking to what certainly sounded like a co-worker. Upon termination of the call he was tetchy. He started with, “nothing is too difficult for the person who does not have to do it” and things did not improve with the progression of words emanating from him afterwards. A request came to him as – “can you do me a favor”? This struck me as weird – favors, at least in my perspective, are not accompanied by a hard and immediate deadline. My friends ask me to help them move, for example, I will make all effort to help them, and even do what I can to adjust to their schedule but largely since it is a favor there are some constraints.

That led me to thinking, how many times do we use such a euphemism or equivalent in our communications? We have shown other more egregious communications faux pas in our blog post Organization and Commitment and some other postings. What about this communications issue? Are we really asking for a favor? It seems more like a command or at the very least a demand. Perhaps we should call it what it is, and perchance this direct approach will reduce the sense of vexation with the request. Something akin to “I need you to do for me and now. Thank you for getting this done on such short notice”!

Training Development and Pre-Delivery

Posted on: June 11th, 2013 by admin No Comments

After we have identified the objective and the preferred delivery mechanisms we will set about building the training.  We will consult subject matter experts, and put material together.  That material will include:

  1. Develop Training Material
    1. Course Objective and Description
    2. Rubric
    3. Lesson plan (including formative assessment questions)
    4. Presentation, application exercises and practice material
    5. Student material (perhaps a handbook)
    6. Summative Assessment Materials (student tests – did they learn the objective?)
    7. Pre-test as a mechanism to identify those the need the training and those who already know the subject
    8. Student assessment of course (what did the student think of the course and instructors delivery?)

Once we have generated the material we will need to review the material – just like any other good design and development work.  We seldom find all of the issues with our own work.  While I am not fond of having people bleed (red ink all over my work) I would rather that than launch the material with bugs or errors.  My friends Fred Starkey and Kim H. Pries are great at that work!

  1. Training Material Review
    1. Trainers and Subject Mater Expert peer reviews
    2. Approved training material

We can even employ the train the trainer event or activities to also find the inconsistencies and errors in the material.  We train the trainer because while the people we identify to support the training or deliver the training may be Subject Matter Experts, these same people may not have training experience, and may fall to pontificating from the podium. Not the best way to teach.  Working through the material with our trainers help ensure the transference of the training event in a way that the outcome is repeatable.

Training Delivery Decisions

Posted on: June 6th, 2013 by admin No Comments

In our previous post we discussed training needs tied to the organization’s objectives. In that work, we uncovered the scope of the needed training to address specific areas for improvement with very specific metrics identified.  The discussion and subsequent research of the objectives also provided us with input to help ascertain the best delivery mechanism.  What form will the training take?  You may view training as an instructor led, go to a conference or hotel room and listen to the pendant pontificate from the podium. Okay, so I went a bit far with the alliteration. Seriously, we probably the experience most of us have regarding training (by the way that is not how Value Transformation views training).  However, that is not all there is!  We have a number of options available to us, I provide a short list below: 

  • Instructor Led Classroom
  • Instructor Led Distance Learning
  • Self-Instruction (for examples check out The Quality Council of Indian)
  • On the Job Training

Each of these methods and some have their respective strengths and weaknesses.  There are also a number of other tools at our disposal to facilitate learning though these are neither instruction nor conscientious directed learning but facilitate improvement. Those examples are:

  • Work Instructions
  • Directions (assembly)
  • Poke Yoke Devices

We employ many of these methods at Value Transformation and presently developing online training in support of all of the books that we author and much more!  

Training needs are tied to Organization Performance Objectives

Posted on: June 5th, 2013 by admin No Comments

Training development follows similar set of processes or activities as product development. First and foremost we must know what we are trying to achieve.  What is our scope? What is our ultimate objective? Those same steps we use to evoke the requirements or our product targets for our training requirements.  The objectives of our training must be stated clearly and measurably, just like product requirements.  Without this clear articulation, how do you know you have met the objective instead of wasting time?  The objective must be time bound – otherwise, the activity can languish on in perpetuity – neither succeeding nor failing nor delivering the expected performance.  We must constantly monitor the progress of key metrics that inform us as to the state of the work (the feedback loop of our control system).

Hits Production

Posted on: June 4th, 2013 by admin No Comments

I have been brought back to this topic many times over the past few months. Hits production is sort of like “hitting the fan.”  We release our product after development and then put our fingers in our ears hoping to not hear the metaphoric explosion at the plant. It is no wonder.  We have the culmination of all of our development activities as well as the risks associated with the transition from prototype part volume to sometimes significant product volumes – with the associated time demands.  We have manufacturing personnel that may have all too recently learned of the product change and any requisite process changes required.  We have a situation fraught with uncertainty.

The things we can do to improve this situation are:

    • attention to details in the manufacturing area as in the development area,  for example use of Process Failure Mode Effects Analysis (PFMEA)
    • manufacturing personnel in the development team early and use the objective feedback
    • prototype part used also by manufacturing personnel
    • design for manufacturing in conjunction with the development work

We have seen “run at rates” or “trial production runs” help improve this transition. During these events, we stress the manufacturing line as if we were in production mode but we do it well before start of production.  We will see where there are issues on the manufacturing line (process or tool related), whether our line layout will in fact, achieve the volume rates and quality of our objective.  However, we also see organizations balking due to the costs associated with these activities.  We believe this may be a case of penny wise but pound foolish.

The Reason for Metrics

Posted on: June 3rd, 2013 by admin No Comments

The team works toward an objective of developing and releasing software according to a schedule.  The delivery date comes, and the team has not achieved the objective.  The project manager is at a loss for words. What happened? The team then informs the project manager – “we always said the time was tight”.  The team indicates they just missed the release schedule.  However, they work the new plan; the project manager finds that is delivery date is more like ten weeks out.  The project manager then learns that the team responsible for the delivery had forgotten to include the verification activities in the release so the delivery was never tight – it was impossible.

So what went wrong here?  First, we did not effectively breakdown the tasks to achieve the objective because we missed some verification activities.  Second, we did not identify the correct measurement or metrics for the activities that would have informed us earlier whether or not our team was going to make the schedule.  We needed to identify those objectives, break them down as a list and monitor the results. For example, let us consider that this team was to deliver ten new functions. We can look at the rate of achieving each function, the rate of verifying those functions and predict earlier what was likely to happen.

As a project manager, line manager or a team lead, you must understand the key metrics for the objective, and track them.  Determining these key metrics and monitoring progress is how you know what is likely to happen – not what you hope will happen.  Coming back at the end rarely if ever works.  We must review the objective evidence that will portend the delivery date and quality, not await the end of the project and then find out we are unable to deliver.

Chickens Come Home to Roost

Posted on: June 2nd, 2013 by admin No Comments

Perhaps some of you recall our post on project commitment. We have a continuation of that story now that is revealing.  In that post we saw how not communicating clearly about actions that could possibly happen or actions that were not even remotely possible can put our project at risk.  In that post, we show an example of appeasement to keep the peace over being forthright and articulating our schedule needs.  We now show how that course of action manifests later in the project.

A project manager had a team working toward a tight schedule, even up to the week before the team made this tight schedule assertion. Now, just hours before the delivery, the project team informs the project manager that they will not make the delivery date, and fall back on “it was a tight schedule”.  Upon closer inspection, we see that it was not a tight schedule – but an impossible schedule.

The project manager and the executives counting on the project are understandably livid.  However, this organization appears to sanction the use of indirect speech and couching of words (don’t rock the boat) we would not want conflict.  If the management does not believe that conflict can be a good thing and harness it appropriately, we will see more of these events. Our people should not be afraid to deliver the news – tell the truth as they see it with supporting facts.  I have had a discussion with a Vice President on this topic.  He told me the unwillingness to deliver or accept the bad news is like a a cancer that can kill a company.  I see that he is correct.

Subscribe to our Newsletter

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