Archive for September, 2018

Common Cause and Special Cause Variation

Posted on: September 28th, 2018 by admin No Comments


Though sometimes we may refuse to recognize it, the world is a full of variation, even in the things we think or believe are constant. For example, my wife has been known to say, “you always do…”
or “you never do…”, to which I retort, I am human and I am not that repeatable.  I say that, but it is not just humans that are not so repeatable.  Everything has variation, and understanding this variation, is important for product development, project management, manufacturing, product testing and so much more.  To master this work, we need to understand this variation as completely as possible.



Common and Special Cause Variation

Shewart is credited for developing the concepts of special and common cause [1].  Special cause variation, are variations that are outside of the expected (intermittent) range of possibilities. Common cause variation, are the variation expected, we know about these, these are predictable, provided we have put some effort into learning about this variation. For example, the thickness of a piece of rolled out steel plate will have variation that is due to the material and process that delivers.  These are common cause, these variations are there by dint of the work, material selected and the processes that deliver the steel plate.  These variations will exist in the product and processes we use to develop and manufacture the product, and it is the in part the management’s job to help understand these variations and the impact and implications on the work.  It should be apparent, that not all variations are created equal, meaning, we do not need to respond equally to all variation, some are more painful that others.  When we design the product and the processes, we have determined the rages of variations that we are willing to accept, that is, variation within this defined range still means success. The product functions with that variation, and there are no perceived quality issues from the customer.

Product Variation

We get variation in the product due to tolerances of the constituent parts, both mechanical and electrical.  Our design has to account for the individual variations and the resulting interactions, and is the reason why we may choose 1% resistors for some parts and 10% for others.  For mechanical parts, we define the acceptable variation via drawing tolerances in plus/minus form.  How we handle this variation to some degree will influence the cost of the product.

Process Variation

The processes that create the production level product also have variation (also in the prototype phase but not important for this post).  Generally speaking, the tighter we control our production process variation, the more costly the manufacturing.  Not understanding what we truly need to produce the product meeting the quality expectations, means either too costly (in time and money) a process to deliver, or a process that is incapable, that is producing product that will not stand up to the customer’s expectation and cost in poor quality and warranty dollars.

Variation is here, it is not going anywhere.  We should understand the product use, environment and how we manufacture (process) it understanding the variation and the impact on the product quality. Knowing this baseline and being able to differentiate from the variation that we expect and that which is the unpredictable shot from nowhere, allows us to quickly respond to these situations without becoming desensitized by responding to the common cause variation believing this variation may lead to bad outcomes.


[1] Taguchi, G., Chowdhury, S., Wu, Y., Taguchi, S., & Yano, H. (2005). Taguchis quality engineering handbook. Hoboken, NJ: Wiley. page 1446

No Estimates, Business Case, and Sunk Cost

Posted on: September 26th, 2018 by admin No Comments

In our earlier posts, we explored abuses of estimates, and then the need for the estimates in the business prioritization or what projects shall we undertake, and securing the resources to accomplish the objective.

Business Case

In the prior blog we discussed the connection between the estimates and the business case for the work.  The business case, as we have seen, compare the costs for undertaking the project against the return or income generated.  some of these comparative approaches (IRR) allows the organization to compare the proposed project against other investments the organization could otherwise undertake with this amount of money, but in all cases we are trying to understand if the proposed project is prudent use of the organizations resources or if it is a low return and high risk endeavor.  We wold not want to spend $1Million to make $250 Thousand.

Estimates and Gate Reviews

We will derive the estimates, but our organization may have project management controls to periodically review progress and compare the expected expense to the actual for a segment of the project.   This is one of the reasons for the “stage gate” approach.  At the end of the stage, the budget, the expected accomplishments are then compared to the actual expenditures and accomplishment (Earned Value Management- Schedule Variance and Cost Variance for example) are reviewed and critiqued.  The affirmation that our expected deliveries have been met, and the cost is within the range of expectation, then another way point of money will be allocated to the next project segment.   If it looks like the project cannot deliver, or the expense is too high, that is the spending for this chunk of the work is too high, we may kill the the project, reduce the scope, or accept the new estimates to complete (performing a new IRR or ROI calculation on the new projected costs).  This is where the concept of sunk costs come into the picture.

Sunk Cost and Estimates

Sunk cost, are costs that have been incurred but cannot be recovered. In the case of our fore mentioned project in which evidence indicates we are exceeding the expected expenditures (estimates) and the business case is now in question, the cost to deliver to that first gate is sunk costs.  Nothing we can do will bring that money back.  If we terminate the project, we lose the money spent. If we continue, this money should be considered as part of the project expenditure (estimates), because, well, the expense was incurred on behalf of the project.  However, some people will not include this expenditure in the future business calculations, because, that money is already spent.  This leads us to the sunk cost fallacy:

The Misconception: You make rational decisions based on the future value of objects, investments and experiences. The Truth: Your decisions are tainted by the emotional investments you accumulate, and the more you invest in something the harder it becomes to abandon it [1]

It is difficult to determine how to handle this dilemma, should you continue the project, or should you terminate?  To be sure the potential loss of the investment so far, loss because if you terminate the project now, you may not get anything out of the work while paying for it.   There are pressures to continue the project, and one way to do that, is to exclude the dollars presently spent from the business expense, as that money is lost. The project may become a money pit with each gate indicating costs are beyond the business case, yet we are compelled to continue because look how much we have spent on this project, to quit now, means all that money is lost for nothing.

[1] last accesed  9/25/2018

Instead of No Estimates

Posted on: September 25th, 2018 by admin No Comments


Instead of  No Estimates

Instead of no estimates, we should consider adjusting our approach to estimates that eliminate the abuse, and still allows for the answers to the business questions, “does this project improve our bottom line” allowing the business to determine if the company really wants to undertake the project, and if so, do we have the talent and resources to undertake this project.  Answering these two questions initiates the next steps to actually create a project and being planning and doing the work.

Besides the techniques below, we can estimate from top down, estimation comes from managers and executives, or bottom up, that is those doing the work or closest to the work, provide the estimates. There are draw backs and benefits to each of these approaches.

Estimating Techniques

There are many techniques for estimating.  Experience suggests organizations may not use much more than the least helpful, expert judgement.

  1. Analogous
  2. Parametric
  3. PERT
  4. Simulation (Monte Carlo Analysis)
  5. Expert Judgement


Instead of estimating each time like it were new, we can use our past work experience that is close to the work we are exploring.  We look at similar work products and similar projects to estimate what is required to complete this work. For example, our company has developed instrument clusters many times, we may look at the aggregate of that work to make estimates for this new instrument cluster projects.  To make analogous estimating work, requires tracking the past projects and historical data associated with those projects.


Parametric estimating uses historical data and statistical analysis of that data to derive a correlation between certain variables and the estimate of the quantity of work. You see this parametric estimating in action when you get a quote for creating an addition to your house when the contractor tells you the prices will be a certain dollar amount per square foot.  This estimating approach requires understanding the relationship of the costs and parameters based upon past historical performance.


Program Evaluation Review Technique (PERT) is also known as there point estimating.  In this technique we attempt to fit a range of estimates to a normal distribution curve, expressing the duration as a range of possibilities (duration – time) with an associated degree of probability (%) which corresponds to the degree of confidence. It is important to note that this is essentially a continuum of possible duration – the greater the estimate, the more probable.

Monte Carlo Analysis

Monte Carlo Analysis is a simulation technique used to evoke the probabilistic distribution of event(s) through the use of random and repeated sampling and simulation.  The simulation can start with those distributions we generated in the PERT method.  Through multiple simulations we generate a range of completion dates and probabilities, providing us with a range of possible answers  (time) along with corresponding probabilities (% / confidence).  In so doing we are able to select the value that represents the risk we are willing to accept.  It is important to note that this is essentially a continuum of possible duration – the greater the estimate, the more probable.

Expert Judgement

Sometimes we can use expert judgement, through mechanism like Wide Band Delphi and to a lesser extent planning poker (planning poker is a team engagement and as such an egalitarian form of Wide Band Delphi).  For specialized areas, and when we may not have appropriate historical information to support the estimates, expert judgement is another form of estimating.

Other Things to Consider

It is more than the method, it is also the processes or ways we think in association with the estimating work.  These areas below are also worth considering, especially the

  1. Estimates are subject to revision – constant adjustments – every time we learn something that has implications on cost or time, we update the estimates.
  2. Focus on the immediate – and keep track of the progress results (Earned Value Management Techniques)
  3. Do not take months or weeks to detail plan – we delude ourselves when we think we can detail plan months out into the future
  4. Model and historical data – historical data provide fodder for model development, models  make it possible to consider many variables and interactions in multiple explorations (statistical)
  5. Those estimating are not “responsible” for the veracity of the estimates – we cannot hold people accountable for these estimates as these are estimates and there are times when the scope of the work is new and requires learning to improve veracity.
  6. Earned Value Management – these project management techniques provide a clear comparison of the planned expenditure and rate of accomplishment with the actual.  Paying attention to these metrics (Schedule Performance Index,  Cost Performance Index, Cost Variance, and Schedule Variance) provide data that allows for constant adjustment to the estimates based upon actual performance.

Estimating and Business Case

Posted on: September 24th, 2018 by admin No Comments

Estimating and Business Case

Our last post explored the abuses of estimates. I thought it best to recognize the abuses, thinking acknowledging these thoughts from the no estimate crowd, may make them amenable to a discussion of how other see the problem and perhaps, eventually, a movement toward a solution that all find acceptable.

Individuals cannot do all the things they want to do, and so to it is for businesses.  Whether the business is for profit or a nonprofit, there are limited funds and available talent, that put constraints upon what can be undertaken.  These constraining factors lead the organization to optimize the projects that are undertaken to both fit within the capabilities and constraints, but also to maximize the benefit, the benefit being profitability for the for profit, and biggest benefit to the most constituents for the non-profit concern.

In addition to these afore mentioned constraints and benefits, we have risk.  There is risk associated with any project undertaken by the organization, in that the project takes resources, but does not provide the believed benefit when concluded.  There is even the possibility that the project will never deliver the expected benefit.  This requires we recognize the possibility that the expenditure for the work, may not bring any income into the organization or otherwise provide any benefit to the customer.

There are some fundamental ways we evaluate the benefit of the project. These are:

  • Return On Investment (ROI)
  • Payback period
  • Internal Rate of Return (IRR)

Return On Investment

Investment in this regard, refers to the expenditure for the project. Expenditure is how much is going to be spent, and since we must do the project before we truly know how much will be spent, we must find a surrogate for this information.  We need some way of getting a reasonable, as rational as we can, and because there are components of this information that are rooted in professional experiences, analysis and judgement, we call this an estimate.

Return on investment is the benefit of the investment (money brought in or saved) divided by the amount of money spent. It is funny that often both are estimates or guesses.  It should be obvious that the larger the benefit with respect to the cost the better off we are. The larger this number, the more consideration is given to this project, once we also account for the risks.

ROI = (Gain from the Investment – Cost of Investment) / Cost of Investment

Payback period

In this less mathematical approach we consider the cost (again derived from the estimates) and compare this to the money brought into the organization annually due to the result of this project (that is the product or service that we make).  We look at the amount of profit per year we make and see how long it takes to pay back the investment.  This is a very simple calculation and does not consider the time value of money for the return or the consequences of applying this expenditure to some other project. Even with this low level of sophistication, we still require something on the cost side of the sheet, that is what are we spending before we spend it – or estimates.  We estimate the project to cost $500,000 dollars, the annual positive cash flow is $250,000, tells us the payback period is 2 years.

Payback Period = total investment / annual positive cash flow

Internal Rate of Return

Internal rate of return, or IRR, is the annualized compound return rate for the investment.  If a project’s rate of return is better than the alternative uses of the funds, the project is deemed to be a good investment and acceptable. We will make more money investing in this project than another or even another type of investment (bank or stocks).[i]

The internal rate of return equation looks like this (reference


Internal Rate of Return

Internal Rate of Return


What now?

What I would like to know, is how do we know which project to undertake? With no estimates, none of these equations can help us understand or model the potential situation.  Without some modicum of consideration for the cost and the potential up side for the project, we are not able to ascertain a reasonable decision (albeit with limited information but armed with perhaps at least a review).

You may not like estimates, and you may not think you get anything out of these, but ultimately you do. The money secured for doing the work, that pays for the work, that is based upon more than an ego somewhere or a general idea that it could be good to spend this money on this project and hope it will all work out.  Perhaps that is possible to go without estimates for lower end projects that do not require great expenditures, but significant project spending, puts more at risk.  It is prudent to consider the expenditure and what that means for the viability of the organization over time.



[i] Pries, K. H., & Quigley, J. M. (2009). Chapter 2 Technical Tools. In Project Management of Complex and Embedded Systems (pp. 60-62). Boca Raton, FL: CRC Press.

Abuses from Estimating

Posted on: September 21st, 2018 by admin No Comments

I would like to start off with has anybody seen an appropriate study of estimating when it comes to doing the work? Not a study that already knows the conclusion they want, but an actual scientific study.  The thoughts below are not based upon anything like that but, having seen many estimating boondoggles. I have also read portions of the works of Barry W. Boehm, and Constructive Cost Model which is a tool for estimating, many years ago.

I find myself in many discussions with the #noestimates crowd. I am not a no estimating person.  The latest “exchange” was around the abuses that estimating brings. This I am in full agreement with them. I just do not go as far as they would to say, no estimates because people are abusive in this regard. My retort, people abuse antibiotics, but we do not ban these.  It is interesting to note that most if not all the people I “hear” decry no estimates, are developers, albeit I say this is not via study be anecdotal evidence.

I operate on the assumption (perhaps errantly) that the no estimate response is from the abuse, that is the expectation that what you provide as estimate is law, you are accountable, there is no variance, or variation, or the other abuses cited below.

The following is from input from Ankur Saini‏, Peter Kretzman and Kim H Pries through Twitter exchanges.  I wanted to go through the abuses first blog post.  The next post will go through why the business people need to have these estimates.

Why do we estimate?

I think we should start with we perform estimates. Estimated are not really for the developers, my guess is many of these folks are not part of the capital (money and cash flow) working of the company.  The developers are not likely responsible for financial decisions on which project should get priority, what expenditures (investments and operations) can be made.  Projects are temporary, and if you are a for profit concern, a decision on which project to undertake is based at least in part on the potential profitability and perhaps loss (risk versus reward) calculation. The people closest to the work, are usually the most knowledgeable in this regard.  Meaning, managers and executives that have not done the work recently are probably less able to make the estimates.  So the best place to look for this estimate, to ascertain business viability for the project, is with the people that do the work, even if their perception is that they get nothing out of it.


Now we get to abuses, and there are a few.

  • Too much time waste / Estimating everything up front without research and sticking to those estimates
  • spending exorbitant amount of time estimating rather than doing work
  • You are accountable (anchor bias)
  • Adding layers of padding for CYA / Forget to multiply the software fantasy by at least 3
  • Letting accounting or marketing estimate

Too much time

There are some organizations, that want to detail plan the exact cost and time for the work, more than 12 months out to arrive at the estimates.  This takes weeks and is a very big waste of time.  We think we can predict out this far, we have no idea what we will learn in the first 90 days to be able to do any detailed predictions. That is not to say we cannot “ballpark” our estimates for the work.  Everybody involved should understand that estimates are a combination of professional judgement, historical record (where possible) and guess work, and the further out in time we go, the more guess work there is.  That does not mean eliminate estimating, that means make a quick estimate based upon the things you know.

Spending exorbitant amount.

We can improve our estimates through learning, and this learning requires either studying or more often doing some of the work.  When we defer all work to do nothing but estimate we lose this chance to learn while doing and use this learning to help with the veracity of the estimates.


I have seen “estimates” with a significant guess component, turn into factual discussions and this happens often.  This preliminary work through of the work is taken as the actual, factual, expected end.  We use this to coerce the team into meeting these guesses, through phrases like “honor your commitment” and “you are accountable” for meeting this expectation that you have set.   Anchoring bias takes over and people treat these guesses as if these were infallible and based upon hard calculated infallible numbers, and revision causes some measure of consternation to the powers that be.

Adding layers of padding / Forget to multiply the software fantasy by at least 3

This abuse is likely the result of the “accountability” abuse, that is, if we are held to keep this guess as the law, we want to ensure we do not go over the estimate, so the estimate must be larger than what we think it takes to do the work.  This gets complicated as multiple handling of the estimates can result in yet more padding. Consider that I add 20%, the next in the chain of the estimate – the project manager or manager – adds another 20%.

On the other hand, we should recognize, generally speaking, that people tend to think positively, probably for those famous words “hey y’all watch this.”  We should consider that the first estimates are likely much lower than what is reported.  To that end, when it comes to budgeting for the work, for the business case (in a later blog post), we should consider the envelop of possibilities when it comes to the project costs and time.

Letting accounting or marketing estimate

Letting accounting or marketing estimate the work, is another form of abuse.  The marketing people are often not skilled in the product development or technical arts.  These folks can be biased by what the customer is wiling to pay for the product and this colors their judgement also. Similarly, the accounting folks may know how much money is available for the project and use this as the cost of the project having no correlation to the actual work.  It is sort of like wanting to purchase a Corvette, but my budget is an Elantra, and expecting to get my Corvette anyway. That is not how this work.

So now what.

The business personnel need to understand the costs associated with the work.  If the way estimates are handled or treated in your company cause problems, then fix those underlying problems.  Estimates, we have said this before, are not accurate or specific project religious doctrine.  As we learn, estimates are revised (up or down). We do not need (neither will we get) a perfect estimate at the beginning, the more we do, the more we learn and know about the project, the more accurate the estimates will potentially become. This requires time doing the work.  Estimates are part of the decision process for undertaking the project, answering the question “is this something we can do and feed and house our team and their family, or is this something that represents a loss, risk to the organization.” You cannot make these assessments by not considering the costs, and the costs projections are necessary to understand.  Just because you do not see the need for the activity, that does not the mean the activity is not needed. Poor handling of the estimating process, does not mean we just dump that work.

I would like to thank these gentlemen again. Thank you Ankur Saini‏Peter Kretzman and Kim H Pries.

The next posting will be on the business case, demonstrating the connection between the estimates, business case, and prioritization of the potential projects of the organization.



Clues! Signals

Posted on: September 20th, 2018 by admin No Comments

Clues! Signals!

Below is the result of a collaboration with John Cutler. He posted a document on Google Docs, and I liked the outline so much I felt compelled to post my thoughts In fact, it was surreal adding my contents to the Google docs and John coincidentally showed up on line, at the same time and was approving my contribution as I was writing it!  I had to write fast to stay ahead of him. I wrote the top level part of the outline, making it easy to think about that topic and what can and often does go wrong.   It was such an interesting collaboration, unscripted, accidental, and fun.  We had talked about making a short video, teasing out a few of the more interesting ones and talking about them, but the new father has plenty of other more important work.  In  fact, the collaboration was so easy, it turns out making a decent outline in WordPress is the most difficult part.  If anybody can point me to accurate text on how to make an outline in WordPress blog, I am grateful.  Everything below this paragraph is the result of the collaboration.  We hope you enjoy.

Pay attention.  There may be an an opportunity for improvement…

1.)   Might as well do [some extra thing] while we [do the original thing]

  • Distraction consuming hours putting the original thing at risk (hours available and cost) (see 6 myths of product development).
  • Second thing not being communicated with the rest of the team members may come at cost to the system when entirety is assembled – something unexpected by other team members = cost poor quality rework.

2.)   We don’t want to have to revisit [some decision]

  • Staying with a solution that is not a solution, or will end poorly. wasting time and effort.
  • Unable to make a decision or decision takes inordinate amount of time for fear that the decision is irreversible.

3.)   While we’re waiting on [some blocker], let’s start [something new]

  • When the block is removed we are unprepared or distracted due to task switching.
  • Too preoccupied with new something to contribute to the blocked cause.
  • No learning from blocked cause by those others that are not participating in resolution (which may be okay).

4.)   It would probably be more efficient if we ……

  • Doubling up when things should be consecutive puts depending tasks at risk of rework and unable to adapt to actual outcome.
  • If we neglect some base product management (cutting schedule time is not necessarily efficient).
  • Throw talent at the problem believing that 9 women pregnant for a month can produce a baby (do no know the laws of diminishing returns).

5.)   It’s too early to [some interaction with users/customers]

  • Waiting for feedback means more built and the possibility of being farther away from the desired objective (like a pilot that only checks the compass after hundreds of miles from take off).
  • Mockups, quick product demos and prototypes that look little like the end product can be effective to get this information from the customer the earlier the better.

6.)   If we bundle these things together we will get [some efficiency]

  • Over 80% capacity we are looking at larger delays for small difficulties –  queuing theory.

7.)   We don’t all need to be in the room for [some decision]

  • Different perspectives help uncover:
    • Un-vetted assumptions.
    • Different ideas to explore and pursue.
    • Communications needs of different people or team members.
  • Ultimately project failure due to limited or conflicting communication and excluding voices that should have been heard.

7.)  We can “get ahead of it” by [a series of hand-offs]

  • Every hand off is a communication hurdle and opportunity for missed communications.
  • Risk dependency, probability of success 1 X probability of success 2 = Sum of probability of success.
  • Think of this as the more exchanges the more opportunities for failure (systems engineering).

8.)   Well [some person] is the only person who can do [some task]

  • Lost opportunity to get rid of this limitation when we do not double this up seasoned person and new but interested person.
  • When this person leaves the company we have no-one.

9.)   It doesn’t work now, but it will work when [some future task is done]

  • How do you know, if you are incorrect, you find out way too late and are unable to respond.

10.)   If we have a little downtime, we might as well try to fit in [another task]

  • If this is not part of the scope this is a waste of time and money.
  • Team synchronization / communication – that is working on parts  that other team members should be aware.

11.)   We’ll have to wait on [some person] to make that decision

  • Delaying decisions delay the project, this consequence must be accepted.
  • No escalation plan – could put you in a holding pattern indefinitely.

12.)   It’s the right the to do but [some excuse masquerading as pragmatism]

  • Not looking at long term consequences – lack of systems thinking.
  • Lack of courage our team does not feel comfortable saying things that “rock the boat”.

13.)   We just need to “lock down” [some specification] and then we can……

  • Some portions of the specification, certainly. The entirety no, it really depends on how these specification elements are connected.
  • We do not know what we do not know, requires specification changes, no need to waste time with reworking the specification.

14.)   Just this one time lets [some cut corner] and then we’ll fix it, hopefully

  • This become habit we will do this for any modicum of pressure.
  • Those not technically oriented wil challenge when you want to resort to no corner cutting.
  • People will forget what correct looks like because we now have many ways to do this.
  • The path of least resistance becomes common even i this is not the best approach.

15.)   We need to do this to close [one deal]. But I’m sure it will apply elsewhere……

  • See the prior items.

16.)    Oh I’ll just do this on the side. That way it will not be micromanaged…

  • No communication with other team members.
  • Fit issues.
  • Micromanagement is a problem also – that would be what should be solved -your team does not believe they can make decisions and take the initiative. You paid for talent then let it waste away.

17.)   Oh, this doesn’t need UX [or QA, Ops, etc.]

  • You will likely find out later that the product does not meet the customer needs.
  • Poor quality in the field comes with rework and replacement in the field, litigation, service costs, reputation impact.
  • Not including operations means we may not have the ability to build this thing and ship to customer or deploy.

18.)   So we have this [side project]…can you attend the meeting to [plan in secret]?

  • Missing key players – un-vetted assumptions, few possible ways to approach (idea generation).
  • Trust issues – don’t want to share for whatever reason.
  • Distraction of workforce if this person should be working on another project.

19.)   Oh we can’t risk [trying some valuable goal]…

  • No risk = no reward.
  • Exploration need not be risky – could find an easy low risk way to explore.
  • Eliminating learning opportunity for team members.
  • No desire for innovation which comes from this type of exploration.

20.)   Oh you can’t test [some feature] because [some perceived limitation]

  • Testing incremental iterations provides feedback to the developers.
  • It is possible to test some portions that work to learn about that work.
  • Configuration Management (via release notes) provides the map of features able to be tested.
  • Waiting for all functions available to start testing means finding bugs up against the launch deadline.
  • You are destroying the iterative and incremental model of working.

21.)   We need individual owners otherwise [some inability to track/punish]

  • Problem when you punish – trust issues in the organization.
  • One perspective often does not provide a true view of the field.

22.)   Well, we’re unique because [some non-unique challenge]

  • Unique or not unique, there is likely a solution that will meet the objective if you explore, test and learn. Otherwise you are stuck in this morass for the rest of your days.
  • No way to get better living with the limitations without exploration.

23.)   This is too big for one sprint, so we’ll do phase one now and….

24.)   I’m pretty sure I can represent the customer in this case…

  • Not sure any individual not a customer is in a position to actually.
  • Myopic one perspective.
  • Likely discovered when the product goes to the customer things that were missed resulting in rework.
  • Gets in the habit of making the call for the customer rather than asking the customer.

25.)  [Some effort] is too big to fail. We need to get this right…

  • Still requires attacking incrementally (how do you eat an elephant).
  • Building all, means we find all of the errors and poor decisions late or at the end.
  • Requires rework – and late with no time to adequately address.

26.)  We need some quick wins because [normal wins take too long]

  • Then find a way to improve the normal wins rate.
  • Work on your corporate discipline – delayed gratification.
  • Eroded the corporate discipline and any repeat-ability.

27.)  I think we can parallelize [two related efforts]..

  • If these are to be sequential there is risk of rework of the depending task when the preceding task does not deliver exactly as expected (see compounding impact of risk).
  • Delays delivery of the iteration.

28.)  And then [some other group] can maintain it, right?

  • There was learning in the development of the product that only the group doing will have.
  • Communications challenges with the transition – what should we tell and to whom.
  • Better to keep some members of the maintaining group involved during development if this must be a different group.
  • Problems with the ability to maintain, constant interaction with the developers.
  • Ultimately poor post development support.

Team Building Not all Roses

Posted on: September 19th, 2018 by admin No Comments

Team Building Phases

Teams are not as easy as throw our collection of individuals into a room together and bang, thus is a team created.  We are fond of the description of the steps a team will go through by Bruce Tuckman we list below.  Our experience suggests this list to be a reasonable list of the phases a group goes through to become a team.

  • forming -the collection of individuals are put together
  • storming  the clash of personalities as well as social mores
  • norming – the group establishes the group’s norms and mores
  • performing – the collection of individuals are now performing (the sum is greater than the individuals)

Collection of Individuals

It takes more than placing people together in a room and pointing them at an objective, will not necessarily turn this collection of individuals and turn them into a team.  This story is about the start of a project, actually the first time this collection of people worked together.   The work objective and scope are explored and understood.  The available staff for the project is limited, and as is often the case, the schedule is close.  A review of the prospective individuals and available talents, help us determine the areas of responsibility per those individuals.  Who can, and is going to do, what? The work was distributed based upon things believed about the individuals, for example, generating the specifications for the product features were distributed to the senior engineers with experience on the product line.

The project commences, and after some period of time, a review the progress of the work is scheduled.  The technical lead reviews the specification work being performed by one of the senior engineers, and finds that the documentation is largely without merit, describes the technical aspects of the feature errant, with large parts elements missing.  The technical lead decides, it is the lack of a well defined format and structure that clearly identifies what is important, and this makes generating the specifications difficult.  So the lead engineer creates a template to lead the senior engineer into what was important with the subsystem specifications, including information required by the developers.

Some time passes again, and the developers come to the lead engineer, complaining that they could not build anything based upon the quality of the specifications delivered by the senior engineer. The lead reviews the documents produced and agrees with the conclusion of the developers.  A meeting is scheduled with the senior engineer and their manager.  In the course of the meeting it was discovered that the senior engineer never wanted to be part of the project. Upon receiving this information the team member is dismissed from the team for other activities.  The manager and the lead engineer are left to find a solution.  The team is now short handed and behind schedule.

Oops, Team Stress

Now the project is behind schedule, with the majority of the specification missing after burning a few weeks of time.  The senior engineer is removed from the team, and a new strategy is undertaken to deliver the requirements. This new strategy included a just in time approach to the subsystem specifications.

The lessons learned are:

  1. Ensure the people proposed to be team players (where this collection does not organically happen) actually want to be on the team.
  2. Define metrics and take constant samples of those metrics that help prediction.
  3. Just in time specification based upon what are the most important things for the project, product or technical attribute.

Do you want to be on the team?

You have little chance of building a team if the members wish they were doing something else.  If you cannot get past this hurdle, then the depending effort is at risk.  Perhaps you can convince the person(s) that this effort is worthwhile. If you cannot, then depending upon the desired schedule, you may have to quickly find the right talent that is motivated by the work.

Define metrics and measure.

Don’t wait too long to see how things are going. Do not assume that the work is going according to plan, even if you believe the person doing the work is competent and motivated to do the work.  Product development should be evidence based, and that is just as valid for the project management work.

Just in time specifications

I have never worked on a project wherein all of the requirements were required up front. I say this because I frequently hear what is referred to as stage gate, as all of the requirements before moving on to all of the next step. I have said this before, I have never worked in a project that was laid out or executed like this.  However, the ultimate solution for this particular project, was very small increments of everything from the requirements, builds, testing and iteration available for vehicle integration and field testing activities.

A team does not come together just because you need this collection of individuals to perform so.  Finding out late that you have team members that do not want to be there doing that work, only delays the inevitable unless their attitude or mindset can be altered.  It is probably appropriate to mention, that the remaining collection of individuals made the objective even short handed and won recognition from the organization.




Product Development and Cognitive biases

Posted on: September 18th, 2018 by admin No Comments

Project Management and Critical Thinking

To wash away those things that impede clear thinking may be more difficult than we may think.

To wash away those things that impede clear thinking may be more difficult than we may think.

There are a good many cognitive biases that can impact discerning the truth or what is valid and true.  Yet knowing what is valid and true is important for any business decision, product development and especially for project managers.  Project managers are often part of decision arm and execution arm of the business objectives.

If you do not think cognitive biases do not impact you, and that there are so many of them, perhaps you should shuffle on over to Wikipedia an do a search list of cognitive biases[i].  There you will find a long list of biases that can get in the way. These biases are so subtle that you may not even be aware that it is affecting how you think. Cognitive biases are shortcuts for us to make decisions.

For example; let’s consider a few of those biases starting with confirmation bias.  Confirmation bias impacts product development and project management in many ways.  We seek information that supports what we already believe and when we find it, we stop looking and proceed or make some decision.  The problem, as pointed out by the great philosopher Karl Popper, is that finding positive evidence does not confirm what you believe to be true, it just gives you the illusion that it is true. Hypothesis are explored for veracity by finding information that refutes our thinking and the hypothesis (falsification[ii]).  Evidence we find that confirms, does not mean what we believe, is in fact true.  There are many cases where a product after undergoing testing, all is well, the product is good, only to have catastrophic problems in the field, recalls, and legal action.

Another interesting bias is the Dunning-Kruger effect, which is the tendency for unskilled individuals to overestimate their own capability and the tendency for experts to underestimate their own ability. A team consists of a stratum of competencies.  We go to put the schedule together and get estimates from our team members. Something we find the estimates to be quite high or the “I don’t know response” and for some things, we find that the estimates seem too low, or some of the team members indicate some portion of the work to be quite easy.  All of this results in project schedules that have inaccuracies both high and low.

The brain is set up to quickly determine patterns.  The cognitive bias known as clustering illusion is the tendency to overestimate small runs of data, without understanding the sampling and what that means.  Those reviewing the data can see “patterns” in the data and take-action on what we see is a pattern, however, the truth is, there is no pattern, or our view of the pattern is incorrect.  Bad data, or misinterpreted data amount to the same thing, failure.

In general, people are optimistic, in my experience. We occasionally find those “Marvin the Robot” from the book The Hitchhikers Guide by the late great Douglas Adams[iii], but by a large those are exceptions to the rule.  This optimism can become a negative thing with optimism bias, when we are trying to find out what will likely happen.  We delude ourselves of the probability of success and the risks associated with our work and the product.  We choose to set our project up without due diligence to the risks associated, that is there is little thinking about what can go wrong.  Similarly, when it comes time to launch the product, in the absence of information telling us there could be a defect (see confirmation bias), we put on our rose-colored glasses, and off we launch believing nothing can go wrong.

Lastly, we will review survivor bias.  We become subjected survivor bias when we decide to review our successes to find a common theme, thinking if we do what those earlier projects did, we should be successful.  The problem comes when we only look at those success stories. It is possible those things we attribute to those project’s successes were also used in those failing projects, and something else drove the project to success.  Without looking at the failures, we never know.  My friend Kim Pries used to say, “if we walk into Toyota’s bathroom, and it is tiled in blue, does that mean if we tile our bathrooms in blue, would we have a successful project and company”?

It may seem that we are using clear thinking, but there are so many subtle things going on in our brain, some of which we are not even aware, others we are aware, and it seems like we are acting rationally, but perhaps we are not, or perhaps we are not taking the best course of action based upon analytical application rather than some random cognitive bias.

[i] last accessed 8/15/2018

[ii] last accessed 8/15/2018

[iii] last accessed 8/15/2018


Posted on: September 17th, 2018 by admin No Comments




I had a brief chat with Tom Cagley  of the famous SPaMcast the other night about teams. We periodically take time to talk about product development topics, and I frequently appear on SPaMCast podcasts.  Last night we talked about teams an whatever magic makes a collection of individuals move to the point of performing better than the sum of he constituent parts.

I have worked professionally for nearly 30 years, and a decade before that as a field worker, fast food worker, and what we self-referred to as a yard dog – the guy who moves trailers, puts hitches on vehicles, cleans up vehicles and much more.  In my 30 years professionally, I can recall being on 3 groups that were what could be referred to as a team.  In fact, the story of one of those teams can be found in the book by Peter Taylor in The Project Manager Who Smiled book.

If there were a perfect recipe for creating a team, that is follow these simple instructions and yeah verily there shall be a team, there would a rush to purchase or secure that tome in our possession.  It benefits all when we figure out how to develop or create an environment that facilitates this building of individuals into the result being greater than the sum of the parts.

I started thinking about generalizations from those team experiences.  I came up with this quick list of the things that I think matter.

  • Behave as you speak
    • The rules apply equally no matter what position you hold in the team, your rhetoric must match your actions.
    • If you are the team lead, know when to use what management style (autocratic, democratic, and Laissez-Faire)[1]
  • Fun integrated with the work
    • Work is important, but it is also important for the team to blow of steam at times.
    • Practical jokes are not a bad thing.
  • Distributed responsibility – but not entirely solo work.
    • Collaborations were born out of challenges in the work, even though specific people were assigned specific portions and deliverable
  • Some compelling objective
    • We need something to focus the effort, it can be competition from outside the organization, or, as in the case of one of my experiences, a dramatic increase in the responsibilities of one part of the organization (see The Project Manager Who Smiled contribution).
  • Close communication
    • The team members feel okay to say what they need to, including recognizing when uncomfortable things happen and don’t couch the words in “opportunity” as in opportunity to work uncompensated overtime, or work through the holiday.

This is not to say if you follow these rules you will end up with a true team. Teams are emergent events. There is no doubt we can take actions to ensure we never see a team develop from our collection of individuals. The best we can do is create an environment in which it is at least possible that we will end up with the sum being greater than the individual talents.



Soft Skills and Training

Posted on: September 14th, 2018 by admin No Comments

Are we starting to believe and behave as if all conflict is bad? Not just bad, but something to be avoided at all costs. There are upsides to conflict, that we may be forgetting.  For example, the tension between what I wanted to be able to do with my life outside of employment at the time, created a tension that got me off my duff and go back to school. The tension within a team working on a development project, can deliver a better quality product, as with each perspective or potential design solution presented, there is a vigorous attack and defense on the technical merits.  Note the attack is on the idea, nothing personal, just working to find the best solution given the resources, talent and constraints.

Even companies that provide training in the soft skills, in my experience, expect this training to be some sort of weird cure all to avoid conflict, and not necessarily constructive conflict resolution.  In our modern work spaces with psychological safety, we perhaps have swung too far the other direction, afraid to make somebody uncomfortable via difficult organization and performance discussions. I recently had a discussion with a coach, who said he was limited in what he could do and say to constructively improve the situation. Of course, there have always been limits to what or how a coach provides guidance. Well perhaps so much in the middle of last century, however, in my opinion, the limits of what is said can become so constrained that real helpful and improvement possibilities are crushed under this weight of fear.  That’s right fear, but not fear of the idea, or fear of a person being stressed, but the fear of a vigorous and rigorous discussion of the design, development approach, strategies, tactics and performance under consideration lest we run afoul or otherwise damage our team mates.  This can create a timidity about the work, and can leave quite a bit on the table for improvement. To be sure there are preferred ways to go about having these discussions, but in a time when engagement is low, it seems to me that we run the risk of suppressing any passion for the work. when we have great concern for what can be said. In fact, it could be argued, that the safest space, is a space where we can say thing about the project, the product development and the team, and there will be no retribution for our articulated perspective.

Part of a good preforming team, is performance, and coaching can require some difficult conversations. If we are unwilling to have those conversations, can we say we are a coach? If the organization does not allow room for these uncomfortable conversations, or waters down these discussions, fearing the consequences of our effort to truly be clear and helpful, are they really working to make things better or have our soft skills become distilled down to nothing ever contentious? There is such a thing as creative tension and in my experience it helps move people, teams, products and processes from one state or way of performing to another.

Subscribe to our Newsletter

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