← Older posts

Can you do me a favor?

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

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!

2. 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

In our previous post we discussed training needs tied to the organizations 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

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

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

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

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 cancer that can kill a company.  I see that he is correct.

Why so long?

When I was but a young engineer, I was developing an embedded product for a small organization whose product line went all over the world.  Partially through the development of the product, a new permutation became needed. The owner of the company, also an Engineer that at one time did work for NASA, asked me to make an iteration of the product that would fulfill this newly identified need.  I went through a breakdown of what it would require to hit the objective.  In small organizations the employee is required to wear a number of hats so I knew of the implications of the scope of the change on the product.  It is funny, I knew nothing of the concept of Work Breakdown Structures, but I did know that to estimate effectively, you must know what will be required to reach the goal.

After my breakdown I estimated the amount of time to achieve each element and responded back to the owner with my estimate. He did not like my answer and said “why does it take so long?”  I told him, there were specification changes, hardware changes, software changes and testing and corrective action activities.  Still, I went back and reworked my estimates to come up with another number. He once again chided “why does it take so long?”  In the end I asked him when he would like the product completed. I now knew his ideal date, and also knew that would not be possible.  I told him why his date would not be very likely and if it did happen would likely be fraught with quality problems.  I did not (could not) commit to the target date that was not possible.  Eventually, the time for the work was closer to my original estimate.

 

The Histogram is a Helpful Tool

Like the Ishikawa Diagram, the Histogram can serve us well.  The histogram allows us to visualize the trends based upon a category.  It is a graphical distribution of data, in the example below we see the distribution of the duration to prepare an incoming vehicle to be a suitable device to put under test out of 126 projects.  From this graphic we can make some assessments about how long this event (should it be in our project schedule) may take to accomplish.  We can see, for example, that a project should not expect to see this objective accomplished in 1-3 days. It could happen, but the probability of success does not look good based upon the distribution in this chart.

 

Vehicle Preparation Time for Systems Testing

 

This chart tells only ½ of the story. The next set of questions we would want to ask (if we do not like this distribution) would be focused upon what makes the duration distribution this way. Perhaps we would employ our other friend Pareto or Ishikawa or both to determine the causes of the variation.  If we want to have any chance of changing this performance, we must know why it is this way.

What problems or obstacles are in the way?

The daily sprint meeting has connections to our risk management as well. We have seen from the previous posting the fact we are having the meeting daily can hasten our project’s (system’s) ability to respond.  The sprint master is now asking about the obstacles or impediments to achieving the objectives of the sprint. Impediments and obstacles are risks to the objective.

Not all risks can be identified from the early stages of developing a project plan. Even if that were efficiently possible, meaning did not consume and inordinate amount of time, the reality is you will see the real risks much more clearly as you move through the execution of the project.

Again we are able to bring the entire team focus on these issues if that is required. At a minimum, the sprint master will have to do something about these obstacles.  That may include brining the project sponsor into the team for discussions to resolve the predicament.

← Older posts