Archive for May, 2013

The Histogram is a Helpful Tool

Posted on: May 31st, 2013 by admin No Comments

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?

Posted on: May 26th, 2013 by admin No Comments

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.

What did you do Yesterday?

Posted on: May 25th, 2013 by admin No Comments

Continuing with our communications theme and agile methods, we discuss the question, “what did you do yesterday?”  This simple question places a check in a few project management boxes starting with the mechanism for the control of the output – specifically the feedback portion of our project control system.  Learning what happened yesterday (coupled with yesterday’s question of what do you have planned for today) provide an assessment point of the project team’s accomplishments (establishes progress monitoring metric).  We now have a suitable position to plot trends via a comparison of what was supposed to be accomplished yesterday with what was actually accomplished.  As this control loop feedback is no older than 8 hours, we see we have the possibility of a responsive system indeed.

Progress sharing indirectly pushes team members as well.  When we see the progress the others are making on meeting the objective, we want to make sure we are doing our part (the positive impacts of peer pressure).  Many people are reluctant to bring the team’s performance down due to our actions (or inactions).

Additionally, this discussion out in the open with peers means when a team member is struggling to achieve an objective, we have the possibility of the differing perspectives of the team to “dislodge” the metaphorical log jam, fostering collaboration.

Value Engineering Book

Posted on: May 24th, 2013 by admin No Comments

We are  pleased to see so much interest in our book, Reducing Process Costs with Lean, Six Sigma, and Value Engineering Techniques.

The book is featured  featured at The Society of Cost Management:

And it was the subject of a webinar at ITMPI


Plausible Deniability

Posted on: May 24th, 2013 by admin No Comments

We felt the need to follow on from our previous blog on tracking testing results in the background using hidden ubiquitous spreadsheet or documents.  If all you have is a spreadsheet for tracking, then you make that visible to all relevant stakeholders.  If the company has a sanctioned or preferred way of handling “bugs” and we deliberately circumvent that process and tool then we are on a slippery slope.

So what is plausible deniability?  It is when a person can claim they have no knowledge on a particular truth that may exist because that person has been deliberately been excluded from that truth.

According to “the term was first coined by the CIA during the Kennedy Administration to describe the withholding of information from senior officials in order to protect them from repercussions in the event that illegal or unpopular activities by the CIA became public knowledge.

So how is passing back the test results discretely between the test person and the developer contributing to “plausible deniability”?  Simple, the project manager is not in a position to know the state of the product under test quality.  The “facts” of the testing and the product’s ability are not readily available for review or critique.  In fact, we must have access to one of the people who in fact have the sheet.  We cannot look at the project test statistics see how it is going. There is no information available for the project manager or the executive management to assess the situation.  We have made it possible for these people to say the product is fit for launch, when it may in fact not be so.  They have no evidence before them to say the product is not ready for launch. There is a difference between using the tools you have at hand to track the test results, and subterfuge, obfuscation and hiding.

We don’t need a stinking fault tracking system!

Posted on: May 23rd, 2013 by admin No Comments

We break form our blog run on sprint meetings due to incoming flambé du jour.

Sometimes we see organizations that are afraid to use the most fundamental of tools, for example, fault tracking from verification.  Instead of using a tracking and visibility tool, we pass back and forth excel sheets behind the scenes. Why would we do this?  We do not want to have a paper trail for things that “make us look bad”.  Fault tracking systems do not make people look bad. Fault reporting and tracking systems are used for just that – it is not a personal attack. The tool allows those who are in the project (including the management hierarchy) to interpret the real state of the project.  This information allows for altering decisions, changing resource allocations and ultimately understanding whether we are getting closer to a product that should or could be launched.

If you do not like what the fault tracking and reporting system is telling you, do not abolish a rational approach and tool, but find ways to alter (improve) the performance.  It does not make you look bad; it shows you where you can improve. Imagine a football player telling the coach not to measure his speed or telling the coach the number must be fudged, or do not recorded it. Take it on faith that I am getting better, faster. Make the teams plans based upon what I tell you and not on what you have objectively measured and can be verified. Seems to me this is a significant source of organization malady.

Esse quam videri

Daily Sprint Meeting and Communications

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

Another beneficial attribute of Agile, particularly Scrum, is the daily sprint meeting. In this very short and focused meeting that includes the immediate project team and as needed the sponsor, we will learn much about the state of our project. The questions three that are up for discourse are:

  1. What did you do yesterday?
  2. What problems or obstacles are in the way?
  3. What is your plan for today?

These questions and serve a number of purposes in the project.  We will discuss these further in the next few blog posts.

Question Benefit
What did you do yesterday?
  • Progress sharing – pushing team to perform
  • Establishes progress monitoring metric
  • Facilitate team cohesion
What problems or obstacles are in the way?
  • Risk identification
  • Quick responses possible due to constant daily monitoring (only 8 hours into any problem)
  • Provides team focus on solutions to these potential obstructions
What is your plan for today?
  • Focus on next set of actions
  • Aide in reduction of unwanted or unnecessary tasks (team generated best approach)
  • Coordinates efforts across the team


Of course, there is nothing that says this communications approach could not or should not be used in conventionally managed projects. There is no body of documentation that I know, that counsels a project manager to sit in an ivory tower and expect the issues to be reported to him timely.

Communications via Agile

Posted on: May 19th, 2013 by admin No Comments

“The more elaborate our means of communication, the less we communicate” ~ Joseph Priestley

In our experience, this is one of the significant benefits of the agile approach to project management.  Agile, with the recurring sprint meetings and constant involvement and participation by the project sponsor greatly facilitates the communications process. We can rely less upon detailed plan, when our key players are speaking daily with an uncensored and open dialog.

Viewing from a control system perspective, the daily reporting provides us with short forays down the wrong road before making the correction. Having the sponsor so connected allows for quick adaptation when things are not going according to the plan or when other opportunities are presented. Contrast this with the typical conventional project communication plan.  We have a description of the communications with the sponsor who are not often included in the day to day workings, the communications happens with either a lengthy dwell time, or when the project is under significant pressure.

Of course, nobody tells project managers to keep the project sponsor at distance or have long lines of communications that only open periodically. Any aspect of Agile that is of benefit, an easily be adapted to the conventional project management approach.

The problem is solved by the person feeling the pain

Posted on: May 18th, 2013 by admin 1 Comment

We like this saying and see much merit and believe it to be an axiom.  We have touched upon this a bit in our blog on sponges.  We see areas where one part of the company or development process makes due or improvises with the malodorous input received.  The receiving entity may complain and attempt to explain the burden placed upon them due to the conformity or “poor quality”.  This discussion usually ends poorly. After all, the pain is felt by the receiving organization and not the delivering. 

So what is the solution? It is not to absorb if you ever wish for or need this situation to change. The best way to actually solve is employ the SIPOC approach to coach or educate regarding the needs updating the way of working as you progress with the work – cooperating to solve.  If this is not possible, the solution that can work frequently is to place the burden on the delivering organization. In our previous example regarding requirements associated with specific system incarnations, we may choose to write fault reports for everything that deviates from the entirety of the system content even though this delivery likely does not contain every requirement in all of the specifications. Issuing a profusion of fault reports, we will now see some action to resolve as this concern has been handed back to the development groups, and we have clearly articulated the source of the issue. 

If it is not possible to collaborate to improve the outcome or otherwise make the change, transfer the pain in some way to the responsible party.  They will find a way to fix the problem, especially if you work with them. It is not personal, but sometimes we need to be the tough coach or have a little tough love to improve.

Agile versus Conventional Project Management

Posted on: May 17th, 2013 by admin No Comments

Recently I have had email and physical discussions on the merit (or lack of from some perspectives) of Agile Project Management in developing embedded products.  I think the discussion is more about what is the correct tool for the job at hand.  I have been part of agile managed projects that have delivered wonderfully.  In fact, this team was much smaller than the other teams performing the same work for other sites around the globe.  It was a small team, well focused and with the variety of talents required for a self-contained cross functional development team.

The agile approach is not a panacea for product development woes. It is a tool that should be used within the right organization, the correct scope and appropriately skilled team members.

Subscribe to our Newsletter

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