To repair complex systems, many resort to "random twiddling and part replacement" (RTAPR) when they're under time and resource constraints. Sadly, RTAPR doesn't work very well. For example, consider a system that has six commercial off-the-shelf components. Let's suppose that it isn't working right. We decide to replace Module 2, which produces no change — the system continues to misbehave. Some might conclude that this proves that Module 2 is OK, but that conclusion might be mistaken. Suppose that the problem lies in the firmware of Module 2, which controls how it operates on the data it receives from Module 1. Since both of our Module 2 boxes contained the same firmware, the system behavior didn't change when we made the swap. A conclusion that Module 2 was not involved in the fault would therefore be incorrect.
A more careful approach can work better than RTAPR. Here are some guidelines that form the basis of what is usually called the scientific method.
- Perform no random experiments
- Random experiments, especially those involving system configuration changes, are unlikely to produce new knowledge. The more complicated the system, the less productive are random experiments.
- Keep excellent records
- Record the Random experiments, especially if
they involve system configuration
changes, are unlikely to
produce new knowledgedetails of all experiments and results. Typically, you won't refer to these notes until you're completely stumped, but that happens with alarming frequency for complex systems. So write the notes so as to make them clear in that kind of desperate situation.
- Try to replicate unwanted behavior
- (a) If the unwanted behavior is reliably repeatable, observe the results of making a minimal change to the system. Any change in behavior can be revealing. (b) If the unwanted behavior isn't repeatable, try to find a system configuration that makes it repeatable, and then go to (a). In all such experiments, controlling the system's containing environment is essential.
- Base all attempts on hypotheses
- Because the input configuration for a complicated system is also complicated, proving that complicated systems work for all required inputs is difficult. Hypotheses about why the system isn't working are equally difficult to prove. Hypotheses can more readily be disproven than proven.
- Therefore, have a testable hypothesis in mind whenever you change the system configuration. Testable hypotheses are of this form (for example): "The fault might be A. If experiment B produces behavior C, then the fault cannot be A." Repeating this process gradually eliminates possibilities until only the truth remains.
- Fail forward
- Devise hypotheses and experiments that cause your investigation to "fail forward." That is, favor experiments that produce useful knowledge whatever the outcome of the experiment. If you make a change and the system starts working, that should help explain what was wrong. And if that same change causes some other result, that, too, should be enlightening information.
Adhering to these guidelines can be difficult, especially under pressure. If deviation is required, make note of it, and note how deviations affect your conclusions. First in this series Top Next Issue
Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!
Your comments are welcomeWould you like to see your comments posted here? rbrenrAYGBbBUFjbsevtyner@ChacNtVJPLKDXZafEdHPoCanyon.comSend me your comments by email, or by Web form.
About Point Lookout
Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.
Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.
Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.
More articles on Problem Solving and Creativity:
- The Questions Not Asked
- Often, the path to forward progress is open and waiting, but we don't recognize it, or we convince ourselves
it isn't there. Learning to see what we believe isn't there is difficult. Here are some reasons why.
- How to Reject Expert Opinion: I
- When groups of decision-makers confront complex problems, they sometimes choose not to consult experts
or to reject their advice. How do groups come to make these choices?
- Solutions as Found Art
- Examining the most innovative solutions we've developed for difficult problems, we often find that they
aren't purely new. Many contain pieces of familiar ideas and techniques combined together in new ways.
Accepting this as a starting point can change our approach to problem solving.
- The Paradox of Structure and Workplace Bullying
- Structures of all kinds — organizations, domains of knowledge, cities, whatever — are both
enabling and limiting. To gain more of the benefits of structure, while avoiding their limits, it helps
to understand this paradox and learn to recognize its effects.
- Virtual Brainstorming: II
- When virtual teams must brainstorm, they try to do so virtually. But brainstorming isn't just another
meeting. There's a real risk that virtual brainstorms might produce inadequate results. Here's Part
II of some suggestions for reducing the risk.
Forthcoming issues of Point Lookout
- Coming July 26: Strategic Waiting
- Time can be a tool. Letting time pass can be a strategy for resolving problems or getting out of tight places. Waiting is an often-overlooked strategic option. Available here and by RSS on July 26.
- And on August 2: Linear Thinking Bias
- When assessing the validity of problem solutions, we regard them as more valid if their discovery stories are logical, than we would if they're less than logical. This can lead to erroneous assessments, because the discovery story is not the solution. Available here and by RSS on August 2.
I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenVtlYqHadRXhDBLGBner@ChacitFLhXcmVGiVKCPjoCanyon.com or (617) 491-6289, or toll-free in the continental US at (866) 378-5470.
Get the ebook!
Past issues of Point Lookout are available in six ebooks:
- Get 2001-2 in Geese Don't Land on Twigs (PDF, USD 11.95)
- Get 2003-4 in Why Dogs Wag (PDF, USD 11.95)
- Get 2005-6 in Loopy Things We Do (PDF, USD 11.95)
- Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, USD 11.95)
- Get 2009-10 in The Questions Not Asked (PDF, USD 11.95)
- Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, USD 28.99)
Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500 words in your inbox in one hour. License any article from this Web site. More info
- Creating High Performance Virtual Teams
- Many people experience virtual teams as awkward, slow, and sometimes
frustrating. Even when most team members hail from the same nation or culture, and even when they all
speak the same language, geographic dispersion or the presence of employees from multiple enterprises
is often enough to exclude all possibility of high performance. The problem is that we lead, manage,
and support virtual teams in ways that are too much like the way we lead, manage, and support co-located
teams. In this program, Rick Brenner shows you how to change your approach to leading, managing, and
supporting virtual teams to achieve high performance using Simons' Four Spans model of high performance.
Read more about this program. Here's a date for this
- Baci Grill, 134 Berlin
Road, Berlin, CT 06416: September 19,
Monthly Meeting, Southern New England Chapter of the Project Management Institute. Register now.
- Baci Grill, 134 Berlin Road, Berlin, CT 06416: September 19, Monthly Meeting, Southern New England Chapter of the Project Management Institute. Register now.
- The Race to the South Pole: Ten Lessons for Project Managers
- On 14 December 1911, four men led by Roald
Amundsen reached the South Pole. Thirty-five days later, Robert F. Scott and four others followed. Amundsen
had won the race to the pole. Amundsen's party returned to base on 26 January 1912. Scott's party perished.
As historical drama, why this happened is interesting enough, but to organizational leaders, business
analysts, project sponsors, and project managers, the story is fascinating. Lessons abound. Read
more about this program. Here's a date for this program:
- CTCPA, 716 Brook Street,
Rocky Hill, CT 06067: September 20,
Full-day Workshop, Southern New England Chapter of the Project Management Institute. Register now.
- CTCPA, 716 Brook Street, Rocky Hill, CT 06067: September 20, Full-day Workshop, Southern New England Chapter of the Project Management Institute. Register now.
- The Power Affect: How We Express Our Personal Power
- Many people who possess real organizational power have a characteristic demeanor. It's the way they project their presence. I call this the power affect. Some people — call them power pretenders — adopt the power affect well before they attain significant organizational power. Unfortunately for their colleagues, and for their organizations, power pretenders can attain organizational power out of proportion to their merit or abilities. Understanding the power affect is therefore important for anyone who aims to attain power, or anyone who works with power pretenders. Read more about this program.