Is this Strategy or Operational Effectiveness?


The Aerospace Defense market now has seen contraction for over six years. Companies have seen revenues steadily decline and all have taken measures to bolster margins and profits through artificial means: stock buy-backs, taking operational efficiencies, partnering, outsourcing and cutting overhead costs. During this time frame continuous improvements in operational effectiveness was absolutely necessary to keep and sustain superior profitability. At the same time the Federal Government sought ways to cut their acquisition costs and quickly migrated to the low-price-technically-acceptable (LPTA) procurements. This has created a market condition that had companies readjusting their portfolios to better position themselves for reasonable profit offerings, albeit while revenues continued to shrink.

Having a front row seat to all of this I keep thinking that we are seeing the things that Michael Porter addressed in his brilliant paper “What is Strategy?” subtitled “Operational Effectiveness is Not Strategy: (Porter, Michael E.., Harvard Business Review, Nov/Dec96, Vol. 74 Issue 6, p61, 18p). All the moves that the major Tier 1 and Tier 2 A&D competitors are taking are classic operational effectiveness (OE) moves, not strategy. Operational effectiveness is essential to stay in business, however when nearly the entire industry is doing the same, as Porter puts it “it leads to relative improvement for no one”. The second effect of everyone running sustained OE campaigns is what Porter calls “Competitive Convergence” where the more everyone benchmarks the competition, the more the look the same. I am seeing us all look the same in both structure and portfolio alignment.

So where can you find all the unique activities that represents a real strategy? Who has stepped out to take the next step and provide a unique offering and mix of value? I think some are thinking about strategy, because you can only take OE so far before you run out of options. Without mentioning specific companies, I have observed some activities that I think are beginning to indicate a strategy in the formation and not just following the pack. So what are these activities? First, you have to look at the customers, what is it they value most right now? In the A&D space its innovation. Commercial technology is rapidly challenging the traditional A&D high tech offerings allowing our adversaries to erode the technology gap. Technology used use to be a force multiplier. Those that can offer innovation at reasonably affordable prices (USDA Frank Kendall still says “Price is a significant factor in source selection”) then you now have something no one else has.

So what are the indicators of real strategy in the A&D market? In my opinion it is the companies that are ramping-up R&D, the ones buying unique, niche capabilities, the ones that are partnering with agile and innovative tech start-ups and the ones that are bundling capabilities to offer one-of-a kind capabilities. In short, the ones investing and not divesting. Don’t get me wrong, I don’t think there is much you can do in the low-wage services business to offer innovation at this time. Low margin services are commodities and the companies shedding their low margin services groups are probably doing so to concentrate on core activities. That’s another necessary OE move. The ones that take the next step and offer innovative products and services will be the ones that have moved beyond OE and into strategy. So now is the time to watch the early indications and warnings of the innovation companies as they could very possibly break up this stalemate of OE one-upmanship and start offering innovative solutions, and even possibly substitutes! Now wouldn’t that be fun!


Avoiding Pattern Recognition Traps In Analysis

“Reality is made up of circles, but we see in straight lines. Herein lies the beginnings of our limitation as systems thinkers.”

Peter Senge

For me, competitive intelligence, market intelligence and market research came naturally. The processes were all so somehow familiar. These activities are all systems consisting of these elements; planning, inputs, processes, outputs, reporting and feedback loops. I have been doing similar activities for at least 35 years. The trap you have to avoid in performing any research and analysis is overcoming naturally wired internal and personal biases. It’s too easy to come up with what you think the answer may be and then you drive your research to support your own suppositions. What drives us that way sometimes is our own liner thinking in a non-linear world. Our systems approach works well to fool us if we think linear, but we should not abandon our systems thinking, we need to modify it.

Let me explain. In linear thinking we look for cause and effect and expect to see proportional relationships—an ounce of cause produces an ounce of effect. In actual practice this is not always so, the world is non-linear and complex. Generally, our thinking is guided by deeply rooted assumptions, generalizations and perceptions and the danger is we are unaware of it. So when we are doing analysis and our mental modes kick in we are blinded as to why something occurred the way it did. We try to fit together the existing research and information to fit our biases and we are good at it. On top of that our systems that we built can easily support the wrong conclusions. We built our systems to analyze the very nature of the market to help us unearth and recognize patterns so we can better understand what is happening. Our mind works hard to push us to see patterns that may not really exist because we want to find something that we have seen before, are comfortable with and know. It’s a perception problem guided by our own mental modes.

In my own personal experience in performing market analysis during the slowing down of my  industry, I got used to see the same patterns of behavior from the companies; layoffs, property reduction, buying back stock, divesting, issuing larger than normal dividends, focus on profits and margin while revenues shrink. The patterns were linear, single events caused predictable reactions. It made sense. The system, market and environment helped me develop new mental modes. Mental modes are contagious, once I explained my analysis to others they caught my mental modes, it spread like a virus. Then it happened, a company did something unexpected, it threw me for a loss because it was not something I was expecting. My first reaction was to think, they made a mistake, when in fact they did something brilliant. My new mental modes were working hard to preserve the pattern recognition I worked so hard to build!

So how do we solve this dilemma? How do we not fall into the trap of seeing patterns that our mind likes to see and treat each new analysis as if it were our first? Breaking mental modes is hard,  the truth be it some mental modes are good in some circumstances, but in a dynamic, non-linear world we need to remain agile. We have to look inward and challenge ourselves constantly, but that is only one step. We need to have others challenge us on a regular basis. In this process we are constantly learning, molding ourselves to think out-of-the-box, or as Peter Senge, author of “The Fifth Discipline”, points out become a learning organization.

So the next time you rush to a conclusion, stop and think for a moment, challenge yourself, have others challenge you. It may surprise you!

(C) Copyrite Caldgaran and Associates 2015

Plan Do Check Act (PDCA): the First Competitive Intelligence Cycle

What is it about processes that so attract us and yet so aggravate us? Just how are processes born? One explanation is that people always try to find the least path to resistance and once they find it they want to repeat it—hence a process is born. I am not sure I totally buy into that, but who wants to reinvent the wheel each time they do routine tasks? I think people want to be successful so we seek ways to do things that are fruitful and repeatable. Consistency is an important element after all aren’t we are creatures of habit? Processes provide consistency. We also like doing things we are comfortable with so processes provide us that safety net. Just try to move our cheese and see what happens. I also have a hunch that we are generally systems thinkers and we like to do things in steps, so we break down projects into small chunks that we can digest and that’s how some processes are born. Once we have it down the way we like it, we seek to do it better and faster until we can do it in our sleep. Easy is better. Simplify. Until you get the government involved, your process remains simple to execute.

Now take the flip side, you are new to an office and someone unveils “the process” for doing things and immediately our hair stiffens. Is it that we did not invent the process? Perhaps we want to learn how things work first before we buy into an unknown process. Maybe it’s just pride or ego, regardless, having a new process thrust upon is not always easy. I generally find the simpler the process the easier it is to accept, understand and implement.

We have a process for competitive intelligence that I have yet to find anyone seriously challenge or reject. Its simple and has built in feedback. I  find it universally accepted and in use across different industries and even in the military. There are slightly different versions out there, but they all seem to embody the same five elements: planning and direction, collection, analysis, dissemination and feedback as shown below. Feedback, that’s the continuous improvement step that would make Edward Deming smile.

CI Cycle

So who invented this process? Who was the first person that said, here is the Competitive Intelligence cycle for all ages to use? I never see any footnotes attributing this construct to someone. I did find a SCIP article by Kristan Wheaton, Assistant Professor Intelligence Studies Department, Mercyhurst College where he thinks it came from two Army military intelligence authors, LTC Phillip Davidson and LTC Robert Glass, instructors at the Command and General Staff College, where they outline a simplified intelligence cycle in their 1948 book Intelligence is for Commanders. The figure below is from their book that includes four simple steps: Use of intelligence; Direction of the Collection Effort; Collection of Information and Processing of Information all driven by mission needs.

Early CI cycle

I think it’s easy to imply that their intelligence cycle is driven by the mission since they are using gears for each process. I have looked at this for some time and I think that the two intelligence officers were heavily influenced by a remarkably similar process created twenty years earlier by a statistical mathematician named Walter Shewhart. Walter Shewhart was born in New Canton, Illinois on 18 March 1891. He received Bachelor’s and Master’s degrees from the University of Illinois, then attended the University of California at Berkeley from which he was awarded a Doctorate in physics in 1917. He taught at both universities and went on to head the department of physics at Wisconsin Normal School at LaCrosse for a short period of time. Shewhart worked at Western Electric Company from 1918-1925 then went on to work at Bell Telephone Research until his retirement in 1956. Shewart is probably best known for his work in statistical process control, control charts and focus on variation. He heavily influenced Edward Deming, the father of the modern day quality movement and Shewart’s methods are what the “Six Sigma” processes are based. It’s his other work in management thinking that I think has been a major influence across systems processes since the late 1920s. What Shewart came us with as a simple cross of management process and statistical analysis, almost too simple, but it has had a major impact on Japanese and American manufacturing for decades. Simply called the Plan-Do-Check-Act (PDCA) cycle or sometimes the Plan-Do-Study-Act (PDSA) cycle, this became the heart of many industrial improvement processes since the 50s.   The Shewhart cycle has the following four stages (Often called the Deming cycle as Ed Deming promoted this cycle everywhere):

  • Plan: identify what can be improved and what change is needed
  • Do: implement the design change
  • Study: measure and analyze the process or outcome
  • Act: if the results are not as hoped for


The resulting process looks like this:


As I mentioned before this may be too simplistic to take seriously, but if you are like me, you see this pattern all the time in systems processes. It’s intuitive. It’s what we do when we are not thinking about a process but thinking about how to solve a problem or approach a project. This is what systems engineers do for nearly every one of their engineering challenges, it’s what program managers do to approach a project and it it’s what competitive intelligence professionals do when they approach a new market. In short its ready, aim, fire, then check the target to see where you hit, adjust the scope and do it again. While I can’t prove it, I think this is what influenced LTC Phillip Davidson and LTC Robert Glass in the building of their process. For sure both had to have been through the military education by the time they were assigned as instructors at the Command and General Staff College and could have easily have studied Shewhart’s work, the scientific methods and most probably the Hawthorne studies based on Shewhart’s work. These were important academic works at the time of LTC Davidson and LTC Glass.

So here is my supposition; nearly all systems thinkers are born with the PDCA cycle imprinted on their brains. It’s what we do, it’s logical, it’s sequential, and it has built in improvement. It’s ready, aim, fire and it’s remarkably similar to the present CI cycle. This is why systems thinkers and systems engineers become very good CI analysts, its second nature to us. In a nutshell, I think we can look to Walter Shewhart as one of the potential early creators of our CI process and thank him for the simplicity that makes it so acceptable. Now for those that are fire, ready, aim type thinkers, this is a process you can learn as well, it just might take a bit longer to overcome those habits.

(C) Copywrite Caldgargan and Associates

Systems Engineering applied to Business Model Analysis

One of the most important thing you can do as a competitive analyst is to figure out and understand the business model or at the tactical level, business case of your competitors. After doing this for many years I see a lot of people struggle with just trying to figure out what a business model is or is not. I finally have learned to tell people, the business case is how companies make money. It may seem simplistic, but it’s the truth. To work through a competitor’s business model or business case I have learned to apply some systems engineering techniques that have always served me well: I break everything down into discrete components and then analyze the interfaces, cause and effect and the overall inter-reaction of the model.

Sounds complicated doesn’t it? Well its not. Let me show you a simple way to do this. A few years back I came across a book called “Business Model Generation” by Alexander Osterwalder & Yves Pigneur that described a business tapestry used to help anyone wanting to build a successful business model from ground up. I has a lot of good concepts but after going through it I tossed it aside, after all this was a process to build a business, not tear one down for analysis. Then one day working on a competitor profile I started going through a supply chain analysis and kept thinking, I have seen this somewhere before, and then I remembered the tapestry. The tapestry is not much different from standard supply chain analysis only that the tapestry had two key elements that were specifically focused on answering that business case question “How does a company make money?” and the answer was in cost structures and revenue streams.

So putting on my systems engineering hat I took the company I was researching, broke it down into discrete parts, only this time the buckets included cost structure and revenue streams and bingo, the light bulb went on. It was if I was seeing things from a totally new perspective, and I was. Now it was just a simple matter of examining all the elements, their interfaces and how they inter-react, or more specifically, cause and effect of each element on the whole.  Below is an example from Business Model Generation (dot com) that illustrates how you would break down the discrete components of a business for analysis.


I have used this technique before when I was a quality adviser and was working process improvement for business units. I would always start off with what I called COPIS focus. In this exercise I would break down each business unit into their discrete process functions, in this case Customers, Outputs, Processes, Inputs and Suppliers (COPIS) to run my analysis. Again much like a supply chain analysis but focused internally on satisfying the customer. Again a systems engineering approach where you first define the customer needs and requirements and then proceed on with designing and validation. Every part of the design process is a discrete step built upon the previous.

So that’s my slice on business model or business case analysis, keep it simple: Its all about how an organization makes money; based on cost basis and revenue streams. The rest is analyzing the discrete functions that feed into the cost and revenue functions of the organization.

Systematic Analysis

I had the chance to sit next to a regional business librarian last night during a dinner and we had a long discussion about business research.  I cued in on the fact that she did B2B research, notice that I said SHE DID THE RESEARCH!  I always thought that librarians were talented and trained guides, but this lady would do research for you.   We talked at length about the different data sets available for free, if you have a library card.  All of which can be accessed from home.  I am sure we were boring the rest of the table, but I found it quit fascinating. As a competitive analyst, we basically use the same tactics,  techniques and procedures as research librarians.  The methodology is the same; define the question, investigate, draw assumptions, challenge through more research, then form conclusions and finally report.

When it came to on-line tool sets, she was not as familiar with the vast array of databases one could tap to do business research.  I started talking about my now hour and a half tutorial on the web and she pulled out a pad of paper and took notes, now that surprised me.  I think sitting on all those resources on a daily basis got her into a rut of using certain resources in a certain order.  We both concluded that research on private companies is the most challenging.  Even using Hoovers or Duns and Bradstreet provided only clues to actual financials.  I told her if I really wanted to know and had the time (that’s the catch–having the time) I would pull up contracts, look at award history, facility size, number of employees, etc.. and then I could derive a much finer grained level of detail.

At the end of about 2 hours, this is what I learned, systematic analysis is the same, whether you are a systems engineer, a competitive intelligence analyst or a business research librarian, systems analysis is the same.

“Science is the process that takes us from confusion to understanding…” ― Brian Greene

I like what Brian Greene says about process and how aptly it applies to Competitive Intelligence.  I want to continue pulling the thread about how systems thinking parallels performing competitive intelligence functions.  There is a standard systems engineering process that we call the Systems Engineering “Vee”.  It is called a “Vee” because a “V” is often used as the shape of process actions that take you from concept to results.  To me I find the overall structure the same as the competitive intelligence cycle, different shapes but the same basic components.  Let me show you the similarities by briefing describing each.   The Systems Engineering “Vee”  focuses on defining customer needs and required functionality first, then  documenting requirements.  Next an engineer would proceed with a design synthesis and system validation while considering the complete problem.  The classic Competitive Intelligence cycle consists of seven basic steps:

  • planning and direction
  • collection and research
  • processing and storage
  • analysis and production
  • dissemination and delivery

Today I just want to address the very beginning of the “Vee” there are still a lot of comparisons down the road, but I want to keep this simple (yet another CI and Systems Engineering shared principle: Keep it Simple).  Whenever you start a new CI project or a systems engineering project the first steps are the same, you have to understand the needs or the gap.  In CI we do this by interviewing the marketing lead and an outcome is often what we call Key Intelligence Topics (KITs).  The KITs you develop help you determine the scope of the effort and then you can develop a collection plan.  In systems engineering you interview your customers or project managers to determine the needs of the project and you develop a high level diagram of all the elements that will determine your scope and plan.  One tool I used to capture requirements was a modeling language called Unified Modeling Language (UML).  UML provides a graphic notation that captures all the elements of the requirements, it looks remarkably similar to a flow chart, but was very useful to capture the essence of what I was trying to engineer.   Whether you are developing KITs or a UML model the intent is the same, define the requirement with the end in mind, which brings us to one of the systems engineering principles that I think apply just as well to Competitive Intelligence:

Start with Your Eye on the Finish Line

  • You should reach consensus at the very beginning of the project on what will constitute success at the end. This means that the stakeholders should start with an agreement of what the project should accomplish and the metrics that will be used to measure the success of the project. This initial focus on the finish line must be sustained by project management as project development progresses and competing interests and project complexities begin to dominate the day-to-day work.

The next principle of systems engineering is equally important in Competitive Intelligence and that involves your end customer.  One of the things we work hard at in CI work is to manage expectations.  Too often those unfamiliar with what we do think you can generate good intelligence overnight.  Many have the idea that the internet is like Hitchhikers Guide to the Galaxy, that has an answer to every question you could possibly ask in just seconds (from the  Douglass Adams book same name). Part of the first step is to set up the right expectations  when talking about the requirements KITs or Engineering goals.  We don’t all have unlimited resources so we need to scope out the effort.  It reminded me of a project I was working and this  customer became so enamored with UML he  told me that we could use this “UML” thing to define the Starship Enterprise.  I mentioned to him we could do the designs but unfortunately we were still 300 years away from the technology behind it.  The second principle is:

Stakeholder Involvement is Key

  • Successful projects involve the customer, users, operators, and other stakeholders in the project development. Systems engineering is a systematic process that includes reviews and decision points intended to provide visibility into the process and encourage stakeholder involvement. The systems engineering process includes stakeholders through all stages of the project, from initial needs definition through system verification and acceptance. The stakeholders who are involved in any particular step will vary, providing managers, operators, and technical personnel with an opportunity to contribute to the steps in the process where their input is needed.

I like keeping my capture manager involved not only from the aspect that I can gleen a lot of intelligence from the capture team, but also to keep us all in sync on were we are with the KITs and focus on the end results.  In both systems engineering projects and competitive intelligence endeavors keeping your customer in the loop on what you are doing at all times is one of the most important things you can do.  I consider my KITs a sort of contract with the capture lead.  When I plan out the size and scope of the effort up front it is much harder to find additional resources later if there is a major increase in expectations from the capture lead.  Good Competitive Analysts are always overtasked and just try to get more time–that will never happen.

Next time I am thinking of working through more stages of the “Vee” and making comparisons on what we do in Competitive Intelligence.  I have been a bit behind on moving this blog along,  I never knew how much time it takes to do one, so I am taking it in smaller chunks.  Yes that is another principle for another day.

Competitive Intelligence and Systems Thinking

I have a bulk of my education and training as a systems engineer and systems manager. I have a Maters Degree in Systems Management and have years of undergraduate work in Systems Engineering. I was a Systems Engineer for much of my career.  I am not saying this to impress anyone, not by any means, I just want you to know where I am coming from.  Ever since I got involved in Competitive Intelligence I could not overlook the similarities between Systems Thinking and CI analysis techniques.  For those competitive intelligence professionals that actually might read this blog; systems thinking is a holistic approach to analysis that focuses on the way that a system’s constituent parts interrelate and how systems work over time and within the context of larger systems.  That’s the formal definition.  However, I think you can see that much of what Michale Porter talks about with his Five Forces and his Value Chain analysis are wrapped systems thinking and systems thinking is the foundation for systems analysis.  Did I lose anyone?  Let me explain further.

When you do a full-blown five force or industry analysis you are defining the system and performing systems analysis.  The same holds true for doing value chain analysis, this is classic systems analysis. Let me give you an example of when systems analysis crossed paths with Competitive Intelligence nearly 25 years ago.   When I was a quality adviser I was asked to look at ways to improve our value chain.  This was a time period when the Military was taking the dive into what we called Total Quality Management or TQM. Since I had this assignment from my Directorate I did what I normally do for new things, find people smarter than me and ask them, So I gathered up a group of my quality adviser peers and we came up with a simple systems analysis tool set we called COPIS Focus. This was not a total new creation as others were doing parts of this, we just expanded it and I applied my rules of systems analysis to the mix.  The result was COPIS Foucs ( COPIS standing for Customers, Outputs, Processes, Inputs and Suppliers).  This was a simple value chain analysis where each of the COPIS elements were analyzed for improvement using Statistical Process Control (SPC).  In the quality world you improved processes using SPC as a metric tool. This was a classic systems analysis tool but was also a cousin to Porter’s Value Chain Analysis, which we never heard of back then. Both COPIS Focus and Porter’s Value Chain analysis are classic systems analysis techniques. 

I could go on, but blogs are supposed to be short and to the point, so at this point I want to share with you seven habits of good systems analysis.  I think these are useful for any CI analyst.   As you go through these see how many of them you use in you CI analysis techniques.  I put some of my suggestions in Italics after the initial title.  Let me know what you think; are you a systems thinker?


Seeks to understand the big picture (Five Force Analysis)

A systems thinker “steps back” to examine the dynamics of a system and the interrelationships among its parts. S/he sees the forest, rather than the details of any one tree.

Questions to ask…

“How can I maintain balance between the big picture and important details?”

“What time frame should be considered as I view the system?”

“Am I keeping my focus on areas of influence, rather than on areas of concern that I cannot influence?


Observes how elements within 

systems change over time, 

generating patterns and trends (Developing Key Intelligence Topics, Setting Alerts, Identifying Strategic Risk)

Dynamic systems are made up of interdependent elements, the values of which change over time. A systems thinker may use a tool such as a behavior-over-time graph to record and observe the patterns and trends those changes generate. The graphs can provide insight into the interdependence of the elements and the structure of the system.

Questions to ask…

“What important elements have changed in the system?” 

“How have the elements changed over time?”

“What changing elements represent amounts and how quickly/slowly are they increasing or decreasing?”

“What patterns or trends have emerged over time?”


Recognizes that a system’s structure 

generates its behavior (Five Force Analysis, STEEP Analysis (or PEST))

A systems thinker understands that blame is not an effective practice to bring about lasting change to a complex system. Rather, focusing on the structure of the system facilitates an understanding of the outcomes of the system.

A systems thinker realizes that to effect change within a system, s/he must use knowledge of the system’s structure.


Questions to ask…

“How do parts affect one another?”

“How does the organization and interaction of the parts create the behavior that emerges?”

“When things go wrong, how can I focus on internal causes rather than dwell on external blame?”


Identifies the circular nature of 

complex cause and effect relationships (STEEP or PEST Analysis, Four Corners Analysis)


A systems thinker knows that the cause-effect relationships within dynamic systems are circular rather than linear. Complex cause and effect relationships include balancing feedback, in which the system is trying to reach and maintain a goal, e.g. the heating system in a house. There also may be reinforcing feedback, such that the more you start with the more it increases over time, e.g. population.  

Questions to ask…

“How do parts affect one another?”

“Where does circular causality/feedback emerge?”

“Is one feedback loop more influential over time than another?  If yes, how?”


Changes perspectives to increase understanding  (Wargaming and Black Hats)

To understand how a dynamic system actually works, a systems thinker looks at the system from a variety of different angles and from differing points of view, perhaps in collaboration with others.

Questions to ask…

“Am I open to other points of view?”

“How do different points of view influence the way I understand the system?”

“Who should I approach to help me gain new perspectives on an issue?”

“As I learn about new perspectives, am I willing to change my mind?”


Surfaces and tests assumptions  (Wargaming, Four Corners Analysis and Black Hats)

A systems thinker will rigorously examine assumptions in order to gain insight into a system. Insight put into action can lead to improved performance. The Ladder of Inference (shown below) is a visual tool that helps people consider how and why assumptions are made, beliefs are developed, and actions are taken based on perceived data.


Questions to ask…

“How do my past experiences influence

the development of my theories 

and assumptions?” 

“How well does my theory or model 

match the system under study?” 

“When considering a possible action, do I and those I work with ask ‘What if’ questions?”


Considers an issue fully and resists the urge to come to a quick conclusion (Primary job of a CI analyst: Objective Outside view of the Market)

A systems thinker is patient. S/he will take time to understand the system’s structure and its behaviors before recommending and implementing a course of action. A systems thinker also understands that succumbing to the urge for a quick solution can create more problems in the long term. S/he is aware of the tension created when a resolution is not immediately implemented and is able to hold that tension while a deeper understanding of the system is developed.


Questions to ask…

“How much time do we need to allow for the consideration of this issue?” 

“How can we manage the tension that exists when issues are not resolved immediately?”

“How can I help others be patient while living with unresolved problems?”


Considers how mental models affect current reality and the future ( Four Corners Analysis and Facilitation techniques used in CI sessions: Black Hats, Wargames, etc.)

In any given situation, an individual perceives and interprets what is happening, thus creating a picture, or mental model, of some aspect of the world. Mental models are comprised of assumptions, beliefs, and values that people hold, sometimes for a lifetime. A systems thinker is aware of how these mental models influence perspectives and ultimately actions taken.



Questions to ask…

“How are the current mental models advancing our desired results?” 

“How are the current mental models hindering our efforts in this area?”

“How am I helping others see the influence that mental models have on our decision-making?”



Uses understanding of system structure to identify possible leverage actions (Strategic Analysis following Industry Analysis)

Based on an understanding of the structure, interdependencies, and feedback within a system, a systems thinker implements the leverage action that seems most likely to produce desirable outcomes. According to Senge (1990), leverage is “…seeing where actions and changes in structure can lead to significant, enduring improvements.”

Questions to ask…

“Where might a small change have a long-lasting, desired effect?” 

“How can we use what we know about the system to identify possible leverage actions?”

“Are there other small changes that we have not yet considered that could bring us desirable results?”



Considers both short and long-term consequences of actions (Strategic Analysis following Industry Analysis)


Before taking action to change a dynamic system, a system thinker weighs the possible short and long-term outcomes of the action. This practice increases the probability of the chosen action producing the desired outcomes


Questions to ask…

“Are we examining the effects of actions within a logical time frame?”

“Are we considering long-term effects even though this long view may seem unimportant?”

“Are we willing to accept ‘short-term pain for long-term gain’ and recognize that short-term gain can lead to long-term pain?”



Finds where unintended

consequences emerge  (Strategic Analysis following Industry Analysis)

Before any action is taken to change the outcomes of a dynamic system, a systems thinker uses proven strategies (e.g. systems archetypes or a system dynamics model) to anticipate unintended consequences. If it is determined that probable unintended consequences are unacceptable, another course of action is explored.



Questions to ask…

“What are the possible consequences of the proposed actions?”

“What are the trade-offs of each identified consequence?”

“Are there unintended consequences that could lead to new actions?”


Recognizes the impact of time delays when exploring cause and effect relationships (Strategic Analysis following Industry Analysis)


 A systems thinker recognizes that when an action is taken within a complex, dynamic system, the outcome of the action may not be seen for some time. A systems thinker will account for the impact these delays may have within the system.

Questions to ask…

“If we make a change to the system, how long before we see the results that we desire?”

“How can we identify the role of time delays in the effects we expect to see?”

“Will the change we propose show immediate results or will we need to wait to see improvement?  If we need to wait, for how long?”



Checks results and changes actions if needed: “successive approximation” (Revisiting KITs, alerts and analysis, performing updates to STEEP or PEST factors)

Questions to ask…

“What indicators will we expect to see as we look for progress?”


“Have we scheduled time to pause, assess the effects of our current plan and take necessary action?”

“When considering changes, are we accessing other systems thinking habits?”

By definition, dynamic systems are constantly changing over time. A systems thinker, therefore, monitors and evaluates the behavior of the system and takes action when needed to assure the system continues to produce the desired results. For example, initially it may be difficult to determine a ‘best solution’ to a perceived problem.

By trying a solution and then assessing the results, understanding of the issue will increase. Over time, each cycle or successive approximation, of checking results and changing actions if needed, will move the system closer to a desired goal.