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:
http://www.costmgmt.org/march-2013-book-feature/
And it was the subject of a webinar at ITMPI
http://www.itmpi.org/SearchResults.aspx?Search=quigley
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 Ask.com “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 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
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:
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? |
|
| What problems or obstacles are in the way? |
|
| What is your plan for today? |
|
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.
“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.
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 to issued, 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.
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.
The customer is the receiver of the output; the customer can be an internal end customer or an intermediary to the next “chain” of events on the way to the final customer. Ultimately, we are aligning our actions (Suppliers, Inputs, Processes, and Outputs) in a way that provides the biggest benefits for our final customer. The presumption is that satisfying the intermediary customers will improve the probability of ultimately satisfying the final customer’s needs. This stands up to logic. Imagine deliveries to the transitional organization that are such that the organization cannot use. For example, imagine our systems specifications were not written good enough so as to allow for the generation of the software specifications. We now are at risk of delivering something totally errant, or revisit and deliver the specifications yet again. This amounts to a waste of time, talent and resources.
Using SIPOC as a process review, critique or simply uncovering how you work makes it possible to streamline the delivery of the final product. Additionally, you will find that your team will become more aware of what constitutes successful delivery (metrics) even for the intermediate. This is where we find our leading indicators.
To go on further with the output discussion, we need to make sure we have an understanding of indicators. Indicators inform us what is going on. My stomach growling is a pretty good indicator that I am hungry, and sweating while mowing the lawn is a good indicator I will need a refreshing beverage upon completion. Similar mechanisms should be used to understand the state of the product development system. To determine the indicators, we must understand the system.
Lead indicators, are those metrics that allow us to predict with some confidence – what is going to happen next. For example, when we test the product “appropriately”, we learn something about the products ability prior to the launch. The failures we witness during our testing provide a glimpse of what we can expect see in the field. Thus it is a leading indicator – we are able to make some prediction on the final output based upon this earlier variable. Some examples of these leading indicators:
Lag indicators, on the other hand, do not allow you to predict in advance. Lag indicators are measurements that do not offer this p
In our testing example above, the lag indicator would be:
With some planning and identification of key metrics, we can be in a position to predict and not just react to the situations we find ourselves. Some systematic thinking up front can save you greatly in the end.
How do we know when our output is successful? Well, when the customer takes acquisition can be the first tangible evidence for many organizations the output is “good”. So we know what we mean by good, I provide a brief list:
Key Product Characteristics are what makes the product the product. Consider a tire pressure monitoring system that mounts into the tire. We have physical characteristics and electrical characteristics (see outline below)
It seems the identification of these Key Product Characteristics does not happen. It happens even less when we are working with the intermediate outputs (output from groups to group and not the final customer – see previous blog). However, these intermediate “outputs” can be just as critical. The sum of these intermediate outputs will ultimately “provide” us with the end product quality (Garbage-In-Garbage-Out.)
If we do not build the intermediate outputs in a way the depending organization can use, we have added to our time of development and probably degrade our final product quality.