R in the news

If you're nervous about applying free software in your work, see what the New York Times had to say about R, the free statistics system. Thanks to Andrew Gelman for pointing out that article.

I'll highlight another free tool in my next posting.

Introducing literate modeling

Organizational modeling has much in common with programming. If you create or ask for organizational models in any one of a number of text-based systems, you likely realize that. If you use any one of a number of GUI-based systems, you may recognize what you're doing as visual programming.

In organizational modeling, the challenges are many:

• How to create a competent model
  
• How to make the process transparent so others can collaborate and still others can benefit
  
• How to organize the model in ways that are understandable both to people and the computer
  

It's both easier and harder than it sounds: it's easier to produce useful, insightful models than many might think, and it's harder to create solid models than some would have you believe.

Despite the claims of some, I don't think there's one right way: I think we need a diversity of approaches. To that end, I've been exploring text-based modeling and simulation for the last few years. Recently I've begun to merge the ideas of literate programming and organizational modeling into what you might call literate modeling. Strictly speaking, that's only doable with text-based modeling languages. It brings with it a few features that seem important:

• Thinking about the model and creating the model go hand-in-hand. I've already found that text-based modeling has helped me think in new and deeper ways about the problems I've addressed, and literate modeling strengthens that thinking by linking them even more tightly.
  
  Why is that so? Part of the reason has little to do with literate modeling and textual programming per se: I found that splitting up the work of modeling and simulation into different types of tasks (conceptualizing and modeling a problem, designing experiments to test theories of action, analyzing and thinking about experimental results, and communicating those results to others) helped me do a better job at each stage.
  
  Literate modeling adds a writing component, which may help us think more carefully about our modeling decisions, to the modeling process. Forcing the explanation of the model to go hand-in-hand with its creation seems to keep me from making assumptions I can't support. In fact, I tend to let the writing drive the modeling, which I think drives models even more from the aspect of hypothesized causality than from the aspect of what works technically. You can see what others have said about literate programming; I think those ideas apply to literate modeling, too.
  
  Of course, you can document normal models extensively, too. As others have said, literate approaches link the thinking required to explain a model (or a program) to other people tightly to the model (or program) itself; the model flows from the thinking and writing instead of the writing becoming partially a reverse engineering of the model code.
  



• Model consumers, collaborators, and even developers think most naturally about models in a sequence that doesn't necessarily match the sequence needed by the simulator. Literate modeling allows you to decouple those two sequences completely.
  



• To explain a model, you sometimes need graphs, diagrams, pictures, tables, or other non-textual components. A good literate modeling system can integrate all those components easily without being tied down to the features offered by a particular simulator. In a way, this is the old Unix philosophy: use a collection of smaller tools, each well-suited to the task at hand, and put them together flexibly as you need them.
  



• Literate modeling is one approach to applying some of the best of the lessons of software engineering to a related field in order to do better work.
  

Why do you care? Why should you care?

If you work with or use organizational simulation models to make better business or organizational decisions, perhaps literate modeling offers you a way to have more transparent, more collaborative, more understandable, and more well-thought-out models. Better models, applied appropriately to generate better insights, might just help you make better decisions. Better decisions, carried through with good implementation, might just lead to better results over the long haul.

Is literate modeling or, for that matter, text-based modeling the only way to go? By no means! By the rule of diversity, if nothing else, that would be wrong. Each of the graphical modeling tools I use has brought its unique strengths to the problem-solving process, and I continue to use them. "Horses for courses," as they say. Yet don't count out text-based tools for effectively engaging those with whom you're working, don't think that text-based modeling and literate modeling has to be ponderous, and don't count out the power of text and writing to help you think more effectively about the challenges you face.

What do you think?

Road Maps to Peace

Yesterday I blogged about what I see as one of the two big problems we face: how we deal with the load we're placing on the planet. I think the other big problem is how we deal with disagreements among those of us who live on this planet. As the load we place on the planet increases, I think the importance of figuring out how to get along will increase, too.

Some of you may know of Rick Steves as a travel guide who also writes newspaper columns, produces TV and radio shows, owns a travel agency, and sells travel gear. He also has a more serious purpose in life, or, perhaps, as I've written about Bernie DeKoven and sustainability, his more serious purpose is inherent in what he does in his travel business.

On September 6, he hosted Lord Alderdice in a discussion called Road Maps to Peace. Lord Alderdice played a key role in helping people work to end the "Troubles" in Northern Ireland, and he has continued his work by helping others to reduce conflict in their regions.

Rather than me taking the time to summarize Lord Alderdice's message, listen to him directly. The recording is about an hour long. I encourage you to listen carefully, with an open mind, to the end, for there are many good ideas. Often we hear people expressing opinions (or express them ourselves) about how peoples should get along; Lord Alderdice is talking about what has worked in helping peoples to get along together. I found ideas that I can apply in interpersonal relationships as well as in thinking about larger political issues we help decide at the ballot box or in dialog with our elected officials as well as in working with or inside organizations.

One message he gives (but not the most important—I'll let you listen to find the essence of his ideas) is that we should all listen to news from other parts of the world so that we gain a broader perspective. That's a message I've given here before. I've long thought we should strive to have personal friends and professional contacts in multiple parts of the world, for I suspect we'd be more likely to work things out and less likely to go to war with countries where we have those connections.

As with my previous message, I really would appreciate your comments on these ideas.

Prediction, system dynamics, and Future-Fusion

Recently, I made the claim that we're better off focusing on adapting to the present than predicting the future. I've made similar claims in the past, too. I've even given one example in which predictions serve a useful purpose.

That's all a bit simplistic, of course. Even system dynamicists could be said to predict the future in a way: we show behavior over time we feel is more likely to occur (although we may warn people away from point predictions based on a behavior over time graph). In other words, I might suggest that your current policies could produce a boom and bust effect in your business, but I wouldn't want you to draw the conclusion that your business will grow another 172.3% by June 15, 2009 before taking a tumble that afternoon.

Because we all would like to know the future, I've experimented with blending system dynamics and Bayesian analysis to quantify the probability of a particular behavior pattern, for example. Of course, that probability is conditioned on both the historical data and the model being correct, which is a loophole big enough for a good-sized locomotive to run through: models are always incorrect. Still, I think this approach may give more useful insight in certain cases.

Now Kshanti Greene of Stottler Henke Assocates, Inc. has shown me a Bayesian tool they've developed called Future-Fusion, and I've been exploring it a bit. They are using Bayesian networks and the power of groups to get a better handle on what the future holds. Much as Data360 looks at the past, Future-Fusion attempts to look at the future. As of this writing, they've created four test areas which you can explore: the 2008 US presidential election, the Iraq war, corporate strategy, and energy. Try it out: learn how to use the system, see current predictions, and add your own (I think you only have to create a free account if you want to add your own predictions). Perhaps you'll learn something, and perhaps they will, too.

Kshanti has pointed out a recent addition to Future-Fusion that may intrigue some of you: time. They've enhanced their technology to allow limited dynamic execution of a network model, which begins to narrow the gap between Bayesian networks and system dynamics from the Bayesian network side, much as what I've tried has narrowed it from the system dynamics side. To try that out, go to the energy model, select a prediction (e.g., "Reduced SUV sales"), click "view graph," note the numbers, and then click "Next Time Step."

I think this is all still experimental in many ways, but it's a good opportunity to learn a bit about this technology by trying it out on real-life issues. I'll be curious what you discover.

Making a big difference

Business Week just published John Hagel and John Seely Brown's Changing the World from the Edge describing how University of California, Berkeley students are making a real difference in the world, this time in issues such as "energy efficiency, Third World poverty and disease, and sustainable housing, among others." By the end, they summarize lessons those of us in business might find useful. I like all three of their three lessons, and I'm looking for ways to apply them, too. If you have suggestions, comment here, or get in touch.

That's related to my recent posting called It's a new world in business education. In all these cases, strong change leadership is again coming out of universities and focused on making the world a better place.

Thanks again to the TP! Wire service for the link.

The importance of a focus on disconfirmation

Here's a lesson from John Sterman's Business Dynamics: Systems Thinking and Modeling for a Complex World section 1.3.7: we gain little to no new insight by observing cases where data supports our hypotheses. We gain much from testing cases where data might disconfirm our hypotheses.

For more on that, see Raymond Nickerson's Confirmation Bias: A Ubiquitous Phenomenon in Many Guises, Bob Dick's Rigour and relevance in action research, the Skeptic's Dictionary entry on confirmation bias, Wikipedia's entry on the same subject, or one of my prior essays on skepticism.

Focusing on the symptom or the cure?

I recently read Jay Forrester's "Churches at the Transition Between Growth and World Equilibrium," a paper prepared for the National Council of Churches and published as part of Toward Global Equilibrium: Collected Papers, ed. Meadows and Meadows and published in 1973 (also available from Pegasus Communications).

Forrester emphasized two points that may be worthwhile today to some of you reading this:

• When fundamental changes happen in the environment in which we operate, old rules of thumb likely no longer appply.
  
• Trying to fix problems by focusing on symptoms is highly risky, for, even in static times, our intuitions don't always work as well as we need. In times of transition and turbulence, it's especially important to ensure one understands the dynamic causes of the problem being faced before engaging in actions that could be counterproductive.
  

Forrester was a bit more direct than I was in my paraphrase. "One should never attempt to find a solution without first establishing the dynamic causes," he wrote, and system dynamics was his tool of choice for testing whether one had found the underlying causes or not.

Today we face increasing energy costs, increasing population density, increasing effects on climate and on the inhabitants of the Earth from the by-products of our industrial and private activity, fundamental shifts in the distribution of production and wealth, a scarcity of resources that were abundant in the past, and the fall-out from overextended financial markets. No matter your type of organization, the complexity of these changes taxes our understanding.

In a time of such changes, how do you make sense of the challenges your organization faces? How do you determine which actions to take to achieve the sustainable successes you want?

If you'd like to discuss ways in which you might make more sense of those issues, ways you might understand the likely causes of the dynamics you face, and ways you might test your proposed actions faster and at less risk than by just trying them, get in touch. Perhaps I can be of help as you seek to fix problems and not just reduce symptoms. Of course, there's no charge or obligation from such an initial discussion.

There's another problem, too

In my last two postings, I've written about what I think is a very important issue we face as individuals, as businesses, and as a society. I think there's another issue that goes hand-in-hand with that issue: how we deal with tough, stressful problems, how we deal with conflict, and how we deal with perceived inequities. In almost any significant situation, we'll have differences of opinion, some small, some very large. (If we didn't, we should perhaps wonder if we're considering all the evidence.) How we deal with those differences can make all the difference as to what sort of outcomes we achieve.

No matter whether we're talking about differences between individuals, differences between groups in our companies or organizations, differences between factions involved in our local or national governments, or differences between nations, we have various approaches. Some approaches are violent; some are not. Some seem to lead to good resolutions; others do not. Some seem coercive, at least to some involved in those deliberations; others do not. Some seem to solve the problem today while creating new problems for the future; others don't.

If we can't figure out how to act effectively in such situations, I fear we'll have increasingly difficult times as stress mounts from climate change, from energy shortages, from perceived inequities (whether between individuals, groups, or nations), or simply from the challenges of doing business in competitive markets.

There are many ways to make communications in such situations more productive. As I've advocated for the use of multiple approaches (triangulation) in making sense of problems, I will say that I don't think any one approach has ability to save all deliberations about differences. Yet I have found the work of Chris Argyis, work he calls action science, to be impressively powerful in helping groups to hold productive discussions, to make breakthroughs in their organizations' abilities to get work done, and, as a nice side benefit, to help people feel good about working in their groups, not because they get their way, but because they get heard. It's based on three premises about productive decision-making in times of conflict and stress:

• Free and open decision making
  
• Testable and tested data
  
• Mutual commitment
  

The first, among other things, means I can't force you to use this approach. I can at best model the behavior I believe in and that I would like you to adopt; I have to give you the right to decide whether you want to follow suit.

The second means that we are willing to test data about all our important assumptions, not just the ones about quantitative data. Perhaps I (think I) know you'll never accept a certain proposal. If I'm following my principles, I'll figure out a effective way to test that assumption on my part (perhaps as simple as asking); otherwise, I'm unilaterally taking one possible solution off the table without us having the ability to talk about it.

While these are all hard in practice, while they require great attention to one's self, and while they sometimes require great courage, the third sometimes seems the hardest. Perhaps you and I disagree about a situation. Perhaps you've made your best case, and I see important issues I perceive as favorable to your position that you didn't bring up. If I'm committed to the first two premises of making free and open decisions with tested and testable data, then I'm committed to bringing up those issues, even if I perceive they weaken my case, for that's the path towards more productive, effective decisions. That may sound easy now; it isn't always so easy when I'm in a discussion involving a strongly-held belief.

I can introduce this approach to a group in perhaps 15 minutes, including some techniques for applying these premises in practice. It's hard work, though; it may take months of active help before a group begins to internalize these ideas in their routine interactions. This work is some of the hardest and yet some of the most rewarding I do. The first time I saw a group I had helped really begin to act this way, I was blown away by the progress they had made. Using these ideas along with others, they had shortened their process times by over 80%. They were highly effective at working together, cutting the time of making decisions from hours and days down to minutes, and the quality of those decisions had improved markedly. Deliberations were sometimes amazingly direct, and yet people felt really good about them. As one said (paraphrasing), "Now I know that people really hear me." If you're curious, you can read about that project in "Emphasis on Business, Technology, and People Cuts Turnaround Time at Hewlett-Packard's Lake Stevens Division." If you'd like to talk about this for your organization, give me a call.

And, when you're thinking about the topics of climate change and oil depletion (or business strategy and customer satisfaction), remember that how we talk about those issues may be as important as what we now think about those issues in achieving good results.

More on factorial designs and simulation

Factorial designs and simulation: apparently Professor Barlas is teaching it in Istanbul!

For the analytically-minded among you, I'd note that MCSim, coupled with a bit of infrastructure you can develop, can make running small factorial experiments (up to a few hundred runs) a fairly quick and painless task. That includes their development, their execution, and their analysis. If a system dynamics model is deterministic, as many are, there's no need for replication.

You can see a simple example in my upcoming TAFTO contribution. I was pleased at the way in which a factorial design approach enabled me to generate and see useful results from a relatively simple model.

"Scientific thinking" the modern way

Yesterday I wrote about Barry Richmond's notion of "operational thinking." I encourage you to read that essay; Barry had many good and important things to say. If you're not familiar with system dynamics but are curious, his essay offers a good introduction to pieces of the thinking approach that gives system dynamics its power.

Nevertheless, I disagree with his description of "scientific thinking," and I figure I should clarify that before others call me on it. On page 19, he writes, "People thinking scientifically modify only one thing at a time and hold all else constant." That used to be true, before Sir Ronald A. Fisher began describing a process for the design of experiments. Fisher and others gave us means to vary multiple factors at a time in a series of experiments and to learn more accurately, effectively, and productively that way.

One can do such designed experiments using any of the common system dynamics simulators, of course, but one of the reason that I like MCSim so much is that I found myself automatically doing factorial experiments using MCSim from the very beginning without thinking about it, thanks to the way it's designed. With other tools, I have tended to start with simpler approaches and then find myself having to make explicit decisions to design better experiments. Besides, MCSim can give results in a format that seems especially suited to this type of analysis.

Some of you might note that two of Fisher's attributes of designed experiments are randomization and replication. Those don't quite apply to many system dynamics models, those created without modeling any random effects. That's okay; it's still important to understand the effect of changes in various parameters, and, if the system is nonlinear (most are), it's important to understand interactions among those parameters, all of which is done effectively using methods pioneered by Fisher.

What does this all mean? It simply means that Fisher's designed experiments give us better and faster means to extract insight from tests on system dynamics models than the old one-factor-at-a-time approach.

I thank Deb Schenk, then (and perhaps now) statistician at Hewlett-Packard Company, for teaching me and others about the design of experiments using Statistics for Experimenters: An Introduction to Design, Data Analysis, and Model Building back in 1981-82.

Now go read Barry's essay.

A systems language for business

Some time ago, I had an opportunity to teach system dynamics to a particular work team. It was a small team of perhaps 8-10 people, (only) one of whom had some system dynamics experience and one with some exposure to what system dynamics was all about.

On the first morning of the week-long class, I overheard a discussion between two or three of the participants during a break. They were talking about some issue they faced at work; one person said (let me paraphrase), "ABC," and the other said, "XYZ." The first repeated "ABC," and the second repeated, "XYZ."

You've probably heard these discussions before; you may even have participated in them. Both parties were stating their positions in what they saw as a clear and convincing manner. Neither either saw the need or had a way to try to link the two statements together so they could make progress deciding which was more useful to them, and so they kept talking past each other. It continued until the end of the break; there was no natural resolution. It was polite, it was friendly, and it wasn't very productive. I've heard those discussions many times in my career.

The system dynamics course was fun and intense: three full days of work learning system dynamics and working example problems, intermingled with two homework days in which they worked together as teams to solve some fairly difficult problems using simulation and without my help except by email. It must have been successful, too; while I had hoped to get the opportunity to come back and help their organization address specific problems using system dynamics, they felt comfortable enough afterwards to do it themselves.

I enjoyed working with that group for a number of reasons. One thing particularly caught my attention. In a break on the last day, two or three people, perhaps the same group, again started a discussion about a problem they faced at work. This time, instead of stating and restating their positions without a way to achieve resolution, the first person said, "DEF" (different problem this time) and then drew a stock and flow diagram that helped make that position clearer. The second person said, "UVW" and drew a stock and flow diagram to clarify that view. Then they started talking productively, using those models, about how their world really worked, about specific questions they had about each model, and about what they might need to change in one person's or the other's view to align more closely with reality and to be more useful for their work. While they didn't (yet) agree on answers, they gave every sign that they understood and appreciated each other's thinking and that they could converge on a common answer that was good for the organization, not necessarily one that agreed with their originial position.

Four and a half days of serious thinking on their part had taken them from being a normal workgroup to being one that could express ideas clearly, advocate for them effectively, and engage in serious dialog on ways to test their ideas and come to a resolution about how to proceed. While they didn't create a simulation model in that 15-minute break, they gave every sign they could likely have done so, given a bit more time.

Moreover, I think they had learned how to peer into each others' now rather explicit mental models to find the crux of problems or differences, which should let them focus their simulations on the essence, the core, of the situation and not the entire problem.

I was proud of them. In four and a half days, they had learned and decided to use what Barry Richmond called "operational thinking." I'm not sure they would have done that without the experience of learning to model and of seeing what their simulations could bring.

Do you see people saying "ABC" and "XYZ" in your organization? Do you wish your people had a better language for wrestling with tough problems? What techniques do you use?

While I like Barry's article quite a bit, I do have one point I'd like to take issue with. I'll save that for tomorrow.

Peer assists

Action learning has long had a process known as learning sets to help people develop the understanding they need to address their own problems. Now Bellanet and the University of Ottawa have described something quite close to this in a short Flash session on Peer Assists (also available in French). (Thanks to colleague Nancy White of Full Circle Associates for the lead.)

I've found that journaling can be a helpful adjunct to such a process. Perhaps the learning logs Bob Williams and I created may be of help to you. As a bit of practical advice, I've also found that it helps to inject new ideas into your thinking, either by reading or listening, while reflecting through journaling and working with a learning set.

If you're interested in studying action learning or its close cousin, action research, check out the excellent, free, online (asynchronous) AREOL course offered twice a year by Bob Dick. AREOL 25 begins February 2007; sign up soon!

Time horizons, step two

Yesterday, I posted about time horizons in problem solving. Step one was to expand your time horizon when looking at problems to ensure you see potential patterns of problems.

What should you do if you do identify that your problem is part of a pattern?

Step two is to figure out what might be causing that pattern. Often, it's something structural in the organization. In the example I gave, the organization inadvertently hid certain key financial information from managers, and that led to repeated bouts of overspending.

How do you figure out what structural issues might be causing the pattern you're seeing? Sometimes it's obvious; sometimes there are multiple, competing explanations, and you're not sure which is most likely.

One way to pick the right explanation is to do an experiment. Try making the structural changes that you think matter, and see what happens. If you observe no change (or if you make things worse), you probably picked the wrong explanation. If the problem disappears, you probably picked the right explanation.

Of course, patterns play out over (a long) time, and so it may take you a while to be sure whether you've seen a change or not. (If you do see an improvement in a bad situation, be sure you're not just seeing regression to the mean.)

Since you're making structural changes to the organization, you may find your experiments are costly in financial and material resources, in risk to the organization if you select poorly, and in human patience.

Is there a better way?

Perhaps.

What if you could create a mockup or simulation of your problem? What if that simulation could recreate the essence of your problem in a simpler form (a model), and you could conduct experiments on the model rather than on the real organization? What if you could take the lessons from that exercise and apply them to your real-world problem successfully?

There are lots of ways to model problems.

• You can create what is, in essence, a board game, and you can bring in people to help you experiment using the game. Of course, that may take time, and people's patience may run thin if you ask them to try too many different lengthy experiments using the board game.
  
  
• You can create a mathematical model (a set of equations) of your problem and solve them to give you your answer. Unfortunately, most organizational problems need rather complex mathematical models, and we can't solve most of those models as readily as we did homework assignments in school.
  
  
• You can create a computer model of your problem. The computer model may take time to create and test, but it simulates your problem and your proposed solutions much faster than the people playing the board game. The computer doesn't get bored if you ask it to run more experiments.
  

If done well, your model (of any sort) should exhibit the same problems you see in the real world, and its structure should match the key aspects of the real world.

Now you can try to fix the problem in the model by changing it. There are many approaches to help you do this effectively; the key is to determine which fix (or combination of fixes) in the model eliminates your problem. There's a good chance that your (successful) fix has identified the key factors causing your problem. There's a good chance that the same fixes, if applied in the real world, would fix the real problem. What you learned in making the model work might tell you what you need to monitor closely in the real world.

There's a bit more to it than that, of course, and you need to be skeptical of your model and your conclusions to avoid being misled too easily.

What might such models look like? You can see a small collection of one type of modeling in the archives of my At Any Rate^TM column published by Pegasus Communications.

Time horizons

Most of us spend much of our days solving (or attempting to solve) problems. We each probably have our own approaches, tailored by our life experiences, ideas we've read, and training we've received.

Here's a suggestion from the system dynamics tradition: pay attention to the time horizon of your problem.

Sometimes a problem is a one-time event. That's great, for those problems are often simpler to solve: fix it, and you're done.

Sometimes, though, a problem is part of a pattern. It's not just that you had a production or sales or financial (or other) problem at the end of last month; it's that you have such a problem at the end of every month (or quarter or year).

Such pattern-related problems usually arise because of something structural in your organization or work. If you fix the problem, you'll see it again next month (or quarter or year). If you fix the structure, you might just make it disappear.

The next time you're faced with a problem, take a few moments to look back, oh, at least twice as far as you think is reasonable. Do you see a pattern now?

For a real-life example, see "Pipeline Inventory: The Missing Factor in Organizational Expense Management" (National Productivity Review, Summer 1999) and "Applying System Dynamics to Business: An Expense Management Example".