Blog 395 – When to Say When

Nobody likes to admit defeat. Nobody enters into a deal expecting to lose. Nobody starts a project that they don’t expect to complete. But sometimes, unexpected stuff happens. Partners don’t live up to commitments. Suppliers can’t supply. Developers forget how to develop or run into unexpected issues. It happens. The question that is now faced is, when do you say “enough” and cut the loss?

First and foremost, this is a time for a “business” decision. Pride and emotion should not come into play. Multiple issues and disciplines need to be reviewed. Prioritizations need to be made and weighted values need to be assigned. There will always be multiple stakeholders in the decision that will believe that their specific issue should take precedence and be the basis for the decision. There will also be those who are probably best ignored in the greater scheme of things. I’ll try to sort through some of the various topics and inputs that should go into this decision.

The first input is one of the most critical inputs of all: Time. No one immediately finds themselves in a failure situation. It is usually the compounding of many items over time that causes the “Ah Hah” moment where the issue manifests. It must be understood that “All errors are Additive”. Two wrongs do in fact not make a right. It is usually a series of small errors or issues that add and multiply to create the failure state.

If you are interested, there is a Harvard University paper on error propagation that can provide you the mathematical foundations of this idea at http://ipl.physics.harvard.edu/wp-uploads/2013/03/PS3_Error_Propagation_sp13.pdf.

The business equivalent here is that there are usually many disassociated errors across time that add up to what can be viewed as a non-recoverable situation. Always correlate all error or issue reports, then review how long the failure condition really existed before it was noticed.

The second is based on the business nature of the issue: Is it an External – Customer Related Issue, or is it Internal to the Business itself? If it is a customer related issue, then the loss of business, both current and future should be the deciding factor. If the customer is committed and dependent on the product, good or service at question, then there probably is no alternative than to continue to commit resources (money, people, components) until either a resolution or work-around is achieved. Here the pain of the customer must outweigh the pain to the business. Effectively, the plug cannot be pulled.

If the customer has recognized the issue and has taken steps to mitigate their exposure, or made other plans based on expected non-compliance, move quickly to achieve an appropriate solution (give them their money back, substitute other products or solutions, etc.,) and move on quickly. The same would apply if the effect on the customer’s business can likewise be minimized.

Understand that engineers will always say that with a little more time and budget they should be able to find a solution. Developers will always say with a little more time and budget they should be able to get the solution working as desired. All will point to the amount that has already been spent and how with just a little more it should be possible to recoup it.

Personally, I have yet to see this work. This argument usually results in an incrementalistic approach that ends up costing more people, time, money, with little more in the way of deliverable results to show for it. One thing to remember here is that if you have hit the point where you have to examine the business case for continuing on along a certain path, then you have probably already passed the point when it was appropriate to stop doing whatever you were doing.

Internal programs, projects and developments are far easier to analyze. The question will always be: Is it strategic to the future of the business? And of course, the answer to this question from those responsible for the topic in question will always be “yes”. Just remember that strategic topics and programs usually encompass years on the timescale and similarly large values on the funding scale. A good rule of thumb is: If multiple years have not already passed by the time you are examining the “Stop / Continue” decision, then it is probably not a strategic topic that is being discussed.

There will always be those that want to continue whatever program, project or development that is being reviewed. These will be the people and groups that have budget and resources stemming from the program. There will always be those that will want the program to be stopped. They will be the people and groups with competing programs that want the budget and resources. These groups can also almost always be immediately discounted as input into the decision.

The internal stop / continue decision must be taken out of the hands of the technical groups (engineering, research and development, etc.,) and put in the hands of the financial and business management teams. How much more will it realistically take to complete? How much revenue or cost reduction will be foregone if not completed? How much longer will it take? What is the project’s trajectory? Will it take a restart / rewrite, or is it truly a defensible incremental piece of work (be very careful here)? It is here that the money should talk, not the desires or beliefs.

Occasionally a business may find itself at the mercy of another business group or supplier as the cause of the program, project or product delay. Instead of a stop / continue decision, you will be faced with a “wait / continue” decision. This means instead of stopping permanently and moving all resources to other projects, the decision is now do you stop temporarily, move resources to other projects and await the outcome of the delaying party, or do you continue with your piece of the project and just hope the offending party will be able to catch up?

Almost every time when presented with this decision, those associated with the project in question will want to continue on and hope the other group or supplier catches up. From their own budgeting and staff assignment point of view, this is the best and simplest solution for them. They will always try to justify this decision by stating that it will be more expensive to stop, reassign the resources, then reassemble them and restart the project at a later date.

Most of the time, since they are the technical resources associated with generating the costs associated with this decision, their assertion is not questioned.

This is a mistake.

Always question, quantify and justify costs to both stop and restart a project. Stopping should usually be nothing more than the cessation of charging to the project. Starting may require some re-familiarization with the project but should not entail significant time. What this means is that from a business and financial point of view, it will almost always be less expensive, and better for the business, to pause all efforts on a third party delayed program or development than it is to continue to work while the third party is delayed.

It may add complexity to those groups whose budgets are now in somewhat of disarray due to the pause and inability to keep charging, but it is better for the business overall.

The only potential mitigating circumstance is how long the third-party delay is forecasted to be. If it is on the order of days to a few weeks (less than four as an arbitrary limit) than continuing may be the right solution based on future resource availability. If it is on the level of a month or more, the decision starting point should be biased toward stopping the costs and investments until such time as the third party has caught up.

So, summarizing the decision tree associated with when to say when on failing or delayed programs, projects and developments:

If the customer business is dependent on the commitment, then whatever it takes to complete is required. Not only current customer business, but potentially all future customer business is dependent on competing the deliverable.

If the customer business is not dependent on the commitment, then the business case for stopping, substituting or finding a work around should be examined. Only the current customer business is dependent on completing the deliverable.

For internal programs and developments, the question of how strategic the program or development is will be key. We all know that nothing ever fully goes according to plan. For those strategic topics, requiring large budgets and long time-lines this is even more evident. Those that are truly strategic it may be best to continue to push on through, but with significant monitoring to make sure further issues and delays do not continue to show up, causing incremental failure.

For those non-strategic programs and developments, it should be a financial / business case decision based on the cost to complete versus the foregone revenues or cost reductions associated with a successful completion. Question all inputs and let the numbers fall where they may.

Finally, when the decision to wait or continue when a contributing entity is the cause of a delay, it is almost always a financially better decision to reassign resources and wait for the third party to complete their work than it is to continue to work in the expectation that they will catch up. It may be more complex and disruptive to those entities assigned to the program, but it will be better for the business.

Finally, understand that any time you ask for the inputs on the decision from the groups that are directly involved with the program in question, they will almost always declare that the program should continue at current funding and spending levels. While this may be beneficial and easier for them, it is the least financially viable approach to the decision in question. Always question inputs and justifications from all parties. Remember, when it comes to money, either internally to the business, or externally from the customer, there will be those that want it, and those that want to spend it.