The Critical Path ALWAYS Goes Through Problem-Solving

Everyone wants their projects and programs to run predictably. We set up business plans and market entry plans and product introduction plans based on product development plans coming true. Unfortunately, those plans most often don't come to pass as hoped. However, there is a profound common cause and we can take active steps to improve our outcomes.

The vast majority of product development projects proceed unpredictably, and always in the direction of more time and more money. Depending on the level of sophistication of the organization, there may be some official buffer built into a schedule, or there is just a cynical expectation that “our programs just don’t deliver on time”.

There are different techniques that have been developed to deal with program schedule uncertainty. The Critical Chain method is complex, hard to implement and probably spends a lot of effort in good faith, but missing the problem. Probability-based methods are a little less complicated and get closer to the problem, relying on Monte Carlo simulations and Bayesian statistical estimates that depend heavily on the knowledge of estimators to produce probability densities. Probability-based methods are terrific for a number of reasons, but they are a starting point rather than the finish line for running programs predictably.

The limitations of the afore-mentioned methods are found in the lack of fore-knowledge of what will happen along the way. Programs depend on lots of things that are relatively unknown at the outset, that will crop up as the program progresses. Resource availability, delivery times from suppliers, constraints on resources, capabilities of resources, and many others are mentioned in every survey of project complexity. Senior leaders just want the thing to finish, with an understanding that work needs to be done. Mid-level leaders want to satisfy their bosses and work hard to both produce the desired results and to assure the bosses that they are going to get what they want. 

There is, however, a simple aphorism that should drive the common understanding: the critical path — the shortest line to completion — will run through problems and problem-solving.

Our software colleagues have understood this from their beginnings, that review-debug-test-debug cycles take up as much as a third to a half of development time, and that these cycles limit the ability to finish. Software development techniques, such as Agile, bug tracking and resolution trajectories, recognize that The Critical Path Always Runs Through Problems.

If only all of our disciplines understood this as axiomatically as our software colleagues. Software design principles have evolved to become less issue-producing: archetypal architectures, re-use, common modules, auto-generated code, among others. Do things that generate fewer issues and you have fewer issues and less uncertainty in outcomes. 

However, in many of my own experiences and observations as a technical program leader, R&D leader and consultant, non-software technical disciplines dismiss those methods as not applicable to their own arts. Having seen this over and over, I’ve concluded that the only real difference between software development and other disciplines is that the turn-around time and effort on problem-solving is much, much more rapid. The “manufacturing” part of software is integration, the usually-daily cycle that yields a modified product every 24 hours. No other development discipline has that sort of turnaround tempo. Every discipline has the same underlying process:

• Needs
• Requirements
• Architecture
• Design
• Model
• Test
• Prototype
• Test
• Refine
• Test
• Integrate
• Test
• Refine
• Etc.

The front end of this cascade is fairly independent of discipline, as it is mostly on paper or in application tools. However, as we go to Prototype and beyond, well, that’s where things diverge — a mechanical engineer needs to get something fabricated, a chemical engineer needs to build something, an electrical engineer needs to do a quick turn, materials people need to acquire and fabricate. All that takes time and is based on educated guesses, so we are into some number of iterations through test and refinement cycles.

It is the same pattern, but longer time, possibly more cost, and often less predictable than software — software turnaround time allows a lot of engineers to get a lot of experience quickly, start to see patterns rapidly, get real-time coaching and training, especially in the more collaborative development techniques.

This isn’t to beat up on non-software developers, but to show how they all have similar process but much different obstacles to overcome. In fact, we are all aware of the aphorism, “Well, we can always fix it in software”. Software usually closes out last because it is often dependent on characterization of electro-mechanical phenomena to finish, resolving some of the electro-mechanical issues, and for final behaviors to be worked out once the physical form is in hand. Software folks live with the knowledge that they will always wind up on the critical path to completion at the end of a program.

However, the critical path up to the point where software climbs on it is driven by other disciplines and problem-finding/problem-solving that requires those longer iterations for Prototype-Test-Refinement.

So…what does this tell us?

A big thing is to be sure that technical leadership behavior in all disciplines is not problem avoidance, but rather PROBLEM-FINDING. I have recently observed a multi-year program spending eight figures per year studiously avoid problem-finding and wind up with serial problem-solving episodes over 4 years that ultimately killed the program. The problem-avoidance was particularly strong on this program, deferring problem finding and solving problems to an almost absurd, but not unique, degree. I have seen problem-avoidance over and over, and it happens for a couple of reasons:

1. People who don’t know any better — walking blithely through a minefield, unaware that disaster lies inches below the surface.
2. People who are trying to avoid management scrutiny and preserve the program — maybe even knowing or suspecting problems exist, but putting the burden of proof on the problem actually manifesting itself. A program leader was once warned about a software architecture choice and the response was that others had been consulted and thought is was fine, and that it hadn’t been a problem yet. They had also deferred testing for that unit, so reality was delayed. That didn’t turn out well for the program.

Both of these are senior leadership issues to fix. 

Either you don’t have folks with the right capabilities working on your programs, or your folks don’t trust you enough to get all the facts on the table and let you do your jobs. The program I mentioned above had no real fatal issues, nothing that violated the laws of chemistry and physics. It did have an unwillingness to admit there were real fixable issues to be faced. There were almost no organizational consequences for these behaviors on that program.

The Burden of Proof.

That is a fulsome concept, and it is misused repeatedly. Misusers say that we are ok as long as we haven’t found anything bad. The burden of proof is put on the hypothetical tester, who is constrained from testing. You are actually not unlikely to find what you aren’t looking for — you will ultimately find it, just not at a time and place of your choosing. The burden of proof is on the developer to demonstrate that there are not issues, latent or not, rather than the other way around.

How many programs have that as an underlying principle? Prove to me that there are no instances that fall within the anticipated use window with some design margin in which the design will fail. And, do you know enough about the anticipated use window to know where your design margins really are?

The earlier that proof comes, the less likely you are to be surprised and take delays.

Here’s a proposition:

If Problem-Solving is ALWAYS on the critical path, doesn’t it make sense to put Problem-Finding in the plan and early? Acquisition and investment strategies often look for points where the target is “de-risked”. Have we de-risked our program by looking for risks, issues, problems before we are committed to a design?

Transition the program from selling itself — “this is the greatest product since Google Search, everything is going to be great” — to insuring itself against later delays and problems. Problem-solving is ALWAYS on the the critical path. Pull problem-finding forward. Put the burden of proof on the designer rather than the tester or reviewer.

Look, every program has some number, call it N, problems. How long do you want to wait to find N? Especially when not all problems are created equal in terms of time and effort to fix, and later leaves less time and money, along with higher levels of program risk and scrutiny. The concept of Technical Debt is particularly useful -- Risk is a mean old bugger and he's going to be paid one way or another, with interest, often at a point where there is limited time and ability to pay.

Mid-level leaders, use some of software developers’ techniques to track problems, bugs, as it were. What is your test coverage of all requirements and performance windows, including design margin? Do you know your design margins? Use modeling to test sources and ranges of variation — you’ll never be able to make enough samples and assemblies to cover all that in test. Use the tools and technical educations for which we all paid so dearly, and protect your program from serial delays due to issues that ALWAYS form the critical path. Part of your job is to ask yourself, “I know I’m being paranoid, but am I being paranoid enough?”.

Senior leaders, make clear your expectations that you expect to see and hear reviews of Problem-Finding early and often in programs. You need to have the outcome, not good news at every review, especially not when the good news is bound to run out. If you can’t take anything but good news, well, you are likely in the wrong profession.

Finally, here are two additional points to the value of Problem-Finding: 

1. Problem-Seeking is the most powerful element of innovation — find valuable problems to solve and you are on your way to providing valuable solutions.
2. Going back to the cascade of engineering process, the top several layers of the cascade are fundamentally problem-seeking, problem-finding and problem-defining — they are the “Problem Space”. They are fundamentals of early-stage Systems Engineering and are underutilized to our disadvantage. Explore the Problem Space robustly to give your solutions a chance to succeed.

Good hunting!