Archive for November, 2014

Asking for More Late in the Project

Posted on: November 26th, 2014 by admin 1 Comment

Asking for more…

Recently, I overheard a project manager discussing the use of a quality tool for their project. The project is well underway. Can you guess the tool under discussion?  It was the DFMEA or Design Failure Mode Effects Analysis.  There are a couple of things wrong with starting the discussion at this point, but let’s start with the FMEA itself.

Project and FMEA

The DFMEA (also has a cousin for manufacturing processes called the PFMEA) are a couple of the tools from the APQP (Advanced Product Quality Planning) suite. The FMEA provides a structured review or critique of the proposed product design or in the event of the of the PFMEA the manufacturing processes. I will not go into details on the structure of the FMEA, if you are interested give us a call. We can coach your team. It is sufficient to know that this is a well structured and planned activity.  We draw upon our historical record, and our team members experience and theorize what can fail and how. We will then develop some verification actions to test the veracity of our assumptions or perhaps just out right alter the design or process as a result of this critique / review.

 

FMEA headers

Example of DFMEA Template Headers

 

 

Late does not work in the project

First, an effective DFMEA is integrated with the product development work – early.  We explore the potential failures of our burgeoning design.  We think of the potential failures that can happen, as well as the cause. We devise ways to test to see if our theorized failure mode is correct.  We generate situations to which the product will be subjected that will confirm our refute (verification activities) the failure modes we believe will happen.  The result of this verification work are recorded.  We will then review the implications of the tests results on our product design incarnation. Specifically, what shall we do with the design?  For example, we may modify demonstrated weak areas, or we may accept the design in present form.  Waiting late in the project will put tooling money at risk. Additionally, we waste time with product iterations that will likely require rework or forbid start over.  So we need project time to reap the benefits – start early.

Second, the DFMEA is a cross functional approach and requires key talent and sufficient time to both go through the critique.  We may have people research past failures for similar products.  We will need talent and time to review the design intent and conduct the cross functionally, set up the verification plan and subsequent actions.  We will need a variety of talent and we will need time spent focused on these activities.

Conclusion

Asking for the time or money late in the project for something such as an FMEA is not productive. What happens if you find something significant? Is there sufficient business case to perform the development work twice?  Additionally, this is not likely to inspire sponsor confidence in the end product.  The only good that can come from performing this work late, and it is a real benefit, is to know what sort of product quality issues you are getting ready to launch on your customer.  It my be better than nothing, but the best solution is to consider these quality activities – time and cost early on in the project and stick with it.

Quality Project Outcome Origins

Posted on: November 24th, 2014 by admin No Comments

Quality Project Deliveries

No matter the expected delivery, objective or product from the project, to deliver a high quality outcome is the result of intention.  It comes from the understanding of the scope, the planning and execution of appropriate quality securing actions and consistent monitoring and adjustment to lessons learned along the way

Quality and Testing

Testing the product is but one tool for securing the product quality.  To be most effective testing should be recurring in parallel with the product development.  As the product grows and matures so too does the testing.  In the realm of testing, we have many approaches available to us.

Reviews and Quality

Reviews are another mechanism for securing the product quality. These reviews range from scope and specification reviews to design iterations and code reviews. We catch bugs before the investment of developing and testing.  For example, specification reviews can find errors that affording us the opportunity for correction before the first prototype part or model built.  Reviews are not limited to specifications, but also can include:

Drawings Models
Manufacturing line Development and manufacturing processes
Proposals Project scope document (for example SOW and Charter)
Work Breakdown Structure Processes (development and manufacturing)
Contracts Code
Functions Risk Registers
White books (lessons learned) Strategies
SWOT Prototype parts
and many more……  

Conclusion

These activities must be included the project plan with hours secured and resources made available to execute those actions.  If any one of these things does not happen, the activity will likely not happen, relegating quality to the result of the myriad of interactions and random events in the product development life cycle.   Going back to the project sponsor for more money and time to include these quality actions will be difficult or nigh impossible.

 

Dependencies and Rate of Accomplishment

Posted on: November 19th, 2014 by admin 2 Comments

Review of Rate of Accomplishment

From our earlier blog post, we discussed task dependencies and how understanding these connections improve our probability of project success as it pertains to schedule. Additional information on dependencies can be found in our book Project Management of Complex and Embedded Systems.

Monitoring  Rate of Accomplishment means Measuring

So what does it look like to monitor progress?  We can start by sufficiently decomposing our project task via the WBS and provided description information in the WBS dictionary to the smallest level. This smallest level would make answering the question, are you finished with the task either a yes or a no. This is a binary (yes, no – 1, 0) easily understandable assessment of the state of completion.

 

WBS element

Binary Example

 

Accomplishment, Team Behavior – Saving Face

If you are a project manager or a project team member with any significant experience, you will not doubt have witnessed instances where our team members may over inflate the state of progress for a task.  This inflation is not known immediately, or when we periodically ask for assessment of state of completion. We find out just before delivery.  Sometimes it is difficult for a team member to say they are not able to keep up.  If a specific progress metric is established, we can make the measurement more progress assessment more objective and less subjective. That is, we report we have accomplished x amount per t time, rather than I believe I am on track or my gut says all is well.

 

Example of rate of progress.

Example of rate of progress.

Example of rate of progress.

Example of rate of progress.

 

Accomplishment Curves

Understanding this curve or rate of progress allows us to predict where we should be at a given time on the curve.  We then need to measure the actual progress and compare those two to see if we are on track, ahead of schedule or running behind schedule.  Below we provide a number of curves that our activities or rate of completion may follow.  We essentially use this as a road map, then measure the actual progress, and respond as needed adjusting the schedule or method of achieving the objective when we encounter deviation from this planned or ideal performance.

 

Example of rate of progress.

Example of rate of progress.

 

The agile approach relies less on an atomic decomposition and more on a continuous monitoring of the actions underway to meet the immediate objective. This progress is measured though as a collection of progress via the very simple burn down chart.  This chart meets the same sort of requirements as afore mentioned rate of accomplishment charts.  We monitoring closely the rate of accomplishment this is recorded in the burn down chart. We can see if our sprint is likely to achieve the objectives or if we are likely to not.  This chart will be updated and reviewed daily providing clear feedback allowing us to assess the probability of success and perhaps take some other actions rather than wait until hopelessly late.

Check Lists and Accomplishment

Check lists can help, but check lists show what is missing, not what may not happen within the expected time.  Check lists are better as a summary or review. For example, just prior to the gate to see if what is expected has been done.  To predict we need to measure

Summary of Rate of Accomplishment

Estimates have a bad reputation for being inaccurate. That is bound to happen when people are estimating things they may not have much experience.  The word is, after all, estimate.  Some refer to it as guess-timates.  To ascertain the validity of the estimates, were we even close, requires monitoring the actual performance (EVM, Burn Down Chart or some specific metric) to the planned performance.  This helps with the prediction, are we going to deliver this task, this objective within the time we planned.  Correctly done, this comparison puts us in the position to “predict” the progress. We will know ahead of the delivery date, transition time, that we are probably going to be late in advance of the date. We can work to find other ways, and we can begin managing expectations.

Accountability and Dependencies

Posted on: November 17th, 2014 by admin No Comments

Accountability and Dependencies.

There is much ballyhoo over accountability.  Accountability is very important as without responsibility and accountability a project or an organization will never survive let alone thrive.  There are times when we push for accountability; however, and few of the prerequisites for the accountability are not met.  I am writing specifically accountability as it applies to depending tasks.

Here is one way we get Accountability Failures

Here is how accountability failure due to misunderstood dependencies works.  The first task is late, or delivery is of poor unworkable quality.  The next person in the chain of events then receives pressure to deliver on their commitments. We tell them they are responsible for their delivery.  True –they are responsible for their delivery; however the precondition, timely and accurate inputs, were missed.

The chain of events often starts when we spend insufficient time understanding the task connections or were missing team members (cross functional).  We over look key dependencies and associations between tasks or have unclear attributes of a task outcome (WBS and WBS dictionary).

 

Example of the Decomposition via WBS

Example of the Decomposition via WBS

 

Our team is unable to differentiate a good or adequate up stream depending task.  The receiving party gets the input that is largely or even entirely unusable or late.  Braking down the scope into these smaller tasks puts us in a position to ask relevant questions, and more importantly receive more accurate answers, on the state of completion or rate of progress. That is one of the benefits of the agile approach.  We will write more on rate of accomplishment in a future blog.

Dependencies Failures and Implications

The second thing that happens, we forget the logic of time and the connection of those dependencies as the pressure to make the schedule come to bear.  Project managers then admonish the depending task responsible to deliver on commitments when the requisite inputs were late, or entirely un-useable.  This has more in common with witch hunt than accountability.

Accountability is not the next person or the final person in the delivery chain.  Delivery requires all parties bear and deliver their portion of the project timely and accurately.  Understand how the parts fit together.  Define progress metrics and monitor closely. Do not wait until the prior “delivery” to find out the delivery is late.  Do not allow prior poor deliveries to infect subsequent links in the delivery chain. Do not admonish the next person in the chain to deliver on their commitments.

Product and Project Change Management

Posted on: November 14th, 2014 by admin No Comments

Scope Change and Failure

Change happens in that there can be no doubt.  Projects must contend with this pitching deck of an operating environment while achieving the end objective.  A significant negative impact can be change.  Even controlled change can have a detrimental effect on the project success.  To fit the classification of controlled change we assess the tasks, time and cost of the change prior to accepting the consequences. After this critique we plan the introduction of this change. Uncontrolled project (product) change happens when we accept the consequences without knowledge of what those consequences may be.  Consider a project that is already over budget and late.  This project has already failed these two constraints.  Yet we still entertain and acquiesce to changes, bound to make an already bad situation worse.  We must articulate the state of the project, including the original over spend and time issues as well as inform the project sponsor of this increase due to the changes for their acceptance.  We should say no until we understand the consequences of the change and can account for the resources, time and money required.

Change Not Communicated

Another failure comes from uncontrolled changes. In the product development environment, this may originate from engineers that are responsible for portions of a system. Those engineers may find a need for a change in the system.  The need may in fact be quite necessary. One engineer calls the other engineer responsible for the interfacing component to make this seemingly innocuous alteration.  Ultimately the entire system goes together and the system does not work as expected. The change had consequences on other parts of the system of which these team members were not cognizant.  This is not change management.  We should instruct our team members to say no to change without this level of exploration with other areas of the project to determine all those implicated in the change.

Change Management Solutions

Change management within the context of the project need not be a long lead time or logistical challenge.  Collocating team members, constant interaction between the team members, the project manager and project sponsor can go far in reducing the adverse impact of change.  A constant review of the design, even if manual can be very helpful.  Product lifecycle management tools that allow all team members visibility into the present state of the individual subsystem parts facilitates communicating the design direction to the team.  To some this may seem like an ad hoc approach, but that would not be true. Stripping away the clutter and maintaining a system that provides quick adjustments and response to change is not necessarily ad hoc but can follow more of an agile approach.

Of course, an organizationally adopted change management process is an effective approach.  This may be less responsive to change, however this often comes with institutionalizing the organizations approach to change – less neglect.  To arrive at this level of institutionalization we must train and instill in our talent our approach to change management.

Industrial Disease and Parkinson’s Law

Posted on: November 12th, 2014 by admin No Comments

It was a beautiful weekend for working in the yard. Specifically, mowing the leaves as a way to mulch them and return nutrients back to the soil.  I was fortunate that I had an interesting  song playing in my head. Not one of those annoying ones that often can get stuck in your head and you cannot stop the recurring replay in your mind of a song that you could just barely stand to hear once.  In this case, I had a Dire Straits song, Industrial Disease off of the Love over Gold album playing in my head, a band and a song that I have always enjoyed.

I fancied myself a bassist when I was younger (still plunk around with my 70’s Fender P Bass). I listen to this song for the technical content, the complexity, the timing and even the lyrics to some lesser extent. I liked how the words fit together.  As a kid or young adult I knew very little of working life as the song rattles off the traumas and trials of working corporate / industrial life.  I could not begin to make much of a real world connection.  However, this weekend, decades into my work life, I really considered these lyrics.  I was particularly stuck with the line about Doctor Parkinson and wondered if this is the same Parkinson that gave us Parkinson’s Law.

The corollary of which is typically used in business, and is generally stated the time it takes to complete a task is the time available to complete the task.  For example, give somebody two weeks to complete, the task or objective will be me in two weeks.

The marriage of the song Industrial Disease, maybe, to a real doctor suddenly became very exciting.  I had thought this to be a mythical doctor – a rhyming contrivance, and now, perhaps there may be more significance to this song than I had given previously.

As the song continued to play through my mind, I began to ruminate on Parkinson’s Law or at least on the corollary that asserts the task will expand to the amount of time available. Meaning, if you estimate a task at two weeks, the task will take two weeks.  There are a few things that make me consider this law to be not so accurate.  I have seen many a project schedule dictated from on high that had duration for delivery that did not seem commensurate with the number and duration of tasks or objective. For example, testing of a complex network system that had more than 3,000 test cases and the time allotted was less than 2 weeks with given head count.  Even upon pairing down just those requirements that, if failed, could cause harm to the customer, the amount of time to perform would be much more than 2 weeks.

Perhaps this is just a song and there is not secret meaning. It is possible it is just great music, a great song, from in my opinion a great band.  Then again……

Testers Do Not Break the Product II

Posted on: November 10th, 2014 by admin No Comments

The blog “Testers Do Not Break the Product” was posted on LinkedIn and there were considerable responses and exchanges.  In an effort to continue that same discourse, I post some of that exchange.

Many thought the language “breaking”, as did many others, to be unclear or ambiguous. The language in this discussion originates from the Twitter exchange. Perhaps we can refer to it as “failure”.

If the product does not fail during testing or in the field has it failed? No. The potential failure can be in the product and the product presently performs as expected. Perhaps that combination or timing of stimuli never will occur in the field.  The potential or possibility of failure of the memory write handling during power interruption is exploited by the test engineer, evoking a hard failure – the product fails to work at all (previously referred to as break).  To “fix” the product requires technical manipulation, something a customer cannot do in the field.

The product was not in the failed state prior to the test.  No, the product performed as expected until the time the specific test is executed. The failure or break did not exist before the tester performed the test.  The defect, that would allow the failure, was dormant – the opportunity for failure was there. I am sure you would agree that this instantiation of the product is failed (broken), and we can deduce (or surmise) that any iteration of this product so built may have the same latent defect that will produce under the similar conditions a similar failure (broken).  Consider this[1]:

Observer’s paradox: the observation or measurement itself affects an outcome, so that the outcome as such does not exist unless the measurement is made.

If you are saying, the possible / probable defect is in the product before the test engineer performs the testing, I would agree.  The test engineer does not add to the product, they test the product.  There resides within the product an opportunity for failure.  No matter how well constructed the product; there are opportunities for a failure.  It is arguably the test engineer’s responsibility to find how it can fail (be broken).  If that key stimuli to provoke the failure is not encountered either in testing or in the field, there is no failure – the product does not “break”.  Proof (evidence) that the stimuli are harmful to the product (or causes unintended consequences) is demonstrated by a failure of the product.  The possibility or probability of a failure exists until there is in fact a demonstration of failure – vis-à-vis a failed (broken) product.  To thoroughly verify the product our testers must find the limits.

Single Sign On provided by vBSSO