The Most Important Thing: Systems Thinking

PM Articles by Project Times. 

No One Thing

What is the most important thing in project management? You could say that there is no one most important thing. In the context of our bodies, is the brain more important than the heart, or lungs? One without the others is useless. Weakness in one weakens the others as well as the whole.

The same is true in managing projects. There is no single function – creating a plan, controlling the project, communication, team building, stakeholder, and human relations, etc. – that is most important. Creating a hierarchy of importance fails to acknowledge that bringing all those factors together in dynamic balance, influenced by the needs of the project environment, is critical to success.

The PMI Standard for Project Management[1] lists functions and principles. It supports the idea that none of them is any more or less important than the others.

Systems View

The way you view the world influences your behavior, your values, and goals,
and the degree to which you can handle challenges.

But maybe there is a most important thing after all. It is to view the whole, the parts, and the relationships among them in a dynamic ‘dance’ that influences performance. In other words, the most important thing is having a systems perspective with systems thinking.

The PMBOK supports systems thinking. “There are various components, such as portfolios. programs, projects, and operations, which can be used individually and collectively to create value. Working together these components comprise a system for delivering value…”[2] We can take that further to include all the project management functions and principles and the components of the project environment as part of that system.

The systems view recognizes the realities of interdependence, cause and effect, and continuous change. That makes it a practical model for describing the nature of the world of things, relationships, and the processes that dynamically tie them together. It is a model you can use to better understand your world and to be more likely to respond rather than react.

Remembering that any view or model is a concept that can only approximate reality, use the model as a way of simplifying the incredibly complex world we live in and giving guidelines for how best to manage it. The descriptions and boundaries of systems approximate the nature of the environment.


Intersecting Systems and Processes

The systems view sees our organizations, communities, economies, projects, operations, families, selves, bodies, as intersecting systems within an overriding system of systems. Systems change as they are influenced by changes in conditions and actions anywhere within or around them. Systems are activated and changed by processes – complexes of performers acting to make change. Processes are the way systems and parts of systems interrelate.

Having a sense of the interplay among the systems’ parts (including yourself), you can more effectively influence change and promote effective performance and quality of life. While being part of the system, assessing it analytically and objectively, as if you were outside of it, promotes objectivity and clarity.

Practical Application – Cause and Effect Analysis

Systems thinking and the idea of the interdependence of equally important factors is interesting but how does it help to optimize performance?

Since the view promotes objectivity clarity, it frees project managers from the biases and beliefs that get in the way of optimal performance. The project manager with a systems view knows that everything that happens in the project is caused by something – a condition or action in or around the project.

The systems-oriented project manager uses this concept in managing projects by cultivating two perspectives, 1) the big picture – the look and feel of the entire project within its environment and 2) the detailed view of the individual factors that influence the whole.

For example, project reporting and performance assessment is best structured to assess the project from both perspectives. The big picture view tells us if there is something that needs attention. The detailed analysis of the individual factors diagnoses the cause of the problem and enables solutions.

In one project, a high-level view gave the impression that things were not going well. There were an abnormal number of conflicts, late deliverables, and abundant changes. Assessing the situation to uncover the cause, it was found that client personnel were not dedicating quality time to the project. As a result, they did not pay sufficient attention to the definition of requirements. Knowing that there was a cause behind insufficient client dedication, instead of going into excuses and recriminations, the project manager assessed the situation further. Was it that the clients were too busy doing their operational tasks, a lack of understanding of the importance of the project, or poorly executed requirements definition?

The cause was not one single factor. The system was a complex one in which each of the factors – insufficient time, lack of priority, and requirements definition performance – contributed to the problem.

With an understanding of the “system” and a sense of how best to influence change in it, the project manager initiated a communication process that identified the issues, motivated senior management to communicate the importance of the project and the role of the clients. This enabled client availability. In addition, the requirements definition team was required to change its approach to one that made client engagement easier, less time consuming and more effective.

Stepping Back

Taking a systems view enables the clarity that not only helps in diagnosing and addressing problems. It helps to avoid them by enabling project managers to step back and accurately view their project and its place in its environment. Then they can identify all the factors that are needed to achieve objectives and the ones that are likely to get in the way. With that knowledge, planning is likely to be more effective.

[1] The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK), Seventh Edition

[2] PMBOK, Seventh Ed, P. 8.

When is a Decision Final?

PM Articles by Project Times. 

This article addresses the question, when can a decision no longer be changed?

Everything we do results from a conscious or unconscious decision. When it comes to anything important, it is better to make firm conscious decisions.

In projects, changing decisions about objectives, requirements, designs, staffing, and vendor selection is disruptive and costly. Not changing them may also be disruptive and costly.


When is a Decision Final?

A decision is final when it can no longer be changed. It can no longer be changed when the decision has been completely implemented or when authority, rules, and regulations say the decision cannot be changed.

We can’t revoke a decision to build a house once the house is built. It is physically impossible (in the absence of time travel) to go back and not build it. While it is physically possible to change a decision that has been deemed final by authority, there are political ramifications.

Models, Beliefs, and Relationships

Models and beliefs about sticking to decisions influence the decision-making process. Relationships among stakeholders are affected. Some expect that once a decision has been made the decision-making ends. They believe that going back to reassess a decision is a sign of poor decision making – being sloppy, wishy-washy or indecisive.

Consider the relationship between executives, clients, requirements analysts, and implementers.

  • Clients and executives love decisiveness and hate ‘analysis paralysis’ – they want to ‘get on with the work’
  • Clients often change their minds
  • Requirements analysts are charged with avoiding the need for changes and communicating changes to the implementers
  • Implementers are often ‘annoyed’ by the changes, thinking that the clients are indecisive and oblivious of the impact of their changes and the analysts are not doing a good enough job when eliciting requirements
  • Analysts feel that they are not given sufficient time and do not have sufficient access to decision makers.

We value both firm decisions and the flexibility to change them.

Expect Change

Change is inevitable. Consider a conscious decision-making process:

“1) Define values, goals, objectives and specifications underlying the issue or question

2) Define the decision making and target environments

3) Agree upon decision criteria

4) Identify solution options

5) Analyze and compare solution options vis-à-vis the decision criteria

6) Decide

7) Implement the decision

8) Monitor and adjust

9) Reflect on the process for lessons learned.”[1]

We see that step seven, Implement the decision, is not the finish line. We acknowledge the need for adjusting decisions whenever conditions change.


Decision Making and Change Management

This question of when a decision is final links decision making and project change management.

The heart of change management is deciding whether to change previously made decisions.

A change management process decides whether to allow change to earlier, frozen, decisions. Changes are costly. Changing a requirements or design decision before it is implemented costs far less than changing it afterwards. Changing a decision that has been baked into a contract can require legal proceedings. Changing a screen design in a website less costly than changing the design of a physical product, like a bridge or building once construction is started.

A Middle Way

Enable and minimize change.

We want to be flexible, open to changing our minds, and we want to avoid wasting time and effort caused by having to unnecessarily revisit decisions.

Let’s look at a case. A design team decided on the use of a certain type of handheld device. Based on that decision a procurement process was started. A couple of weeks into the procurement process for the devices, the design team changed its mind. They decided that a handheld device would not work. They changed the design to use work stations instead. This wasted the time and effort of the procurement team and the vendors they reached out to for bids.

Was the change warranted? Yes, it was recognized that use of handheld devices made operational costs excessive.

Could the design change have been avoided? Maybe. If the team avoided unnecessary changes by spending more time and effective effort to better understand the decision factors – objectives, work environment, criteria – using checklists, and making sure people speak up with ideas, comments and criticisms.


In this case, the design team became aware that they had not consider the operational issue of the loss, damage, and ‘shrinkage’ of the devices when a member spoke up to bring the operational issue to light.

Why hadn’t he/she/they spoken up earlier? Maybe the idea just dawned, or out of fear to speak up during the design sessions. Either way, it was a good thing the issue was raised and that the design team and leadership accepted the change, even though it disrupted schedules and wasted effort. The up front loss was miniscule compared to the expenses saved.

Imagine if design team leadership didn’t support the change, saying that it was too late or too politically dangerous to question the earlier decision. Not only would there have been an inferior outcome, but some members of the design team would also be demotivated, thinking that their leadership was unprofessional and cowardly.

If this kind of thing happened frequently it would be a sign that the design team’s process needed some improvement.


Adapt an approach that dynamically balances enabling and avoiding changes.

Any project decision can be changed until the decision has been completely implemented. Minds change when information regarding decision factors change. While you may never be perfect, make sure your decision-making process addresses all the factors that influence the decision. Take the time to get it as right as possible the first time.

Consider how often stakeholders change their mind after having decided, and how many decisions end up being poor ones.

Do you need to devote more time and focused effort to the decision process? Do you need more formal facilitation, brainstorming, checklists, and input from experts regarding objectives, decision criteria, environmental considerations, and options?


The Power of Decision Criteria

PM Articles by Project Times. 

Every decision is made based on criteria. Are you and your team conscious of your criteria?

Decision making is at the heart of project management. Doing it well requires skill and awareness of the process. This article addresses decision criteria and the need for up front and formal definition of them as part of a decision-making process. A previous article Get the Right Answers to Make the Right Decisions[1] discussed the need for the right questions to ensure high quality decisions. Among those questions is “what criteria will we use to evaluate options and decide?”

Poor decisions are made when people make them without consciously identifying their decision criteria. This happens at all levels, from individuals to decisions amongst project teams, executives, and members of boards of directors.

The Decision-Making Process

When decision makers are aware of their process it is less likely that they will overlook setting up mutually agreed upon decision criteria.

Being aware of the process means consciously recognizing that there is a set of steps for deciding. One of the steps is agreeing upon the criteria to be used.

There are many variations on the definition of the decision-making process. They share a common theme – consciously understand what you are doing and how you are doing it. Define your process and make it adaptable and flexible. Make it so that later steps influence earlier ones in an iterative refinement process.

Here are nine steps to sum up the process[2]

1) Define values, goals, objectives, and requirement specifications

2) Define the decision making and target environments

3) Agree upon decision criteria

4) Identify solution options

5) Analyze and compare solution options vis-à-vis the decision criteria

6) Decide

7) Implement the decision

8) Monitor and adjust

9) Reflect on the process for lessons learned.

The first step includes the definition of the desired outcome. The second step identifies who will make and influence the decision(s), levels of authority, process, tools, and techniques to use in decision making. It also makes sure that the decision makers have a good understanding of the nature of the environment that the decision will affect – the operational environment. Goals and objectives may be adjusted as step two is performed. Both steps one and two may be refined as criteria are identified. All three are subject to refinement as the process proceeds, as implied in step eight.

What are decision criteria?

Decision criteria are the basis for deciding. They “are the principles, values, rules, variables, and conditions that an organization or team uses to select an option or make a decision.”[3]


Why Define Criteria

Consciously defining decision criteria improves the quality and rationality of decisions.

The criteria always exist. Every decision is made based on some criteria, which may be consciously known or not. Many are prone to subconsciously consider factors that skew their decision. For example, a bias towards reinforcing privately held values may get in the way of reaching a practical decision.

When decision criteria are consciously considered, prioritized, and agreed upon by decision makers, biases can be identified and managed, criteria that may not be immediately obvious can be discovered. Without consciously addressing decision criteria, decisions are suboptimal. They will take longer than necessary to make, and they are more likely to turn out to be ineffective.

Decisions take longer because criteria emerge over the course of discussions rather than at the onset. For example, a team charged with the design of the interior of elevator cars became aware after deciding, but before the design was implemented, that there were design options that were more likely to protect against damage. The team had not directly assessed damage resistance when making their decision. Once aware of the newly identified factors, the original decision was put aside while other options were identified and assessed, causing a several weeks delay.

The team had not explicitly stated their criteria. Informally, everyone had an understanding that aesthetics was the main criterion, with maintainability as a key factor. Cost and availability were also considered. They reviewed several options and selected one. If the decision had been acted upon the team could have made a poor choice that looked good but was easily chipped or cracked. The result could have been costly.

Time and Effort

Besides thinking it is unnecessary, a reason that decision makers do not spend adequate time and effort considering their decision criteria is the perception that it will take too long and that it is overly formal.

The time it takes to define decision criteria depends on the situation. With a team that often works together on similar projects, the criteria for choosing supplier, design, or plan options may be already available in a checklist. Little time would be needed to review the checklist and verify its fit for the decision at hand. If on the other hand the team was not used to working together, was operating informally, and had no checklist, setting decision criteria can be more complex, requiring convincing team members that some formality is needed.

In most cases all it takes to identify decision criteria is a brief brainstorming session among the decision makers, informed about typical criteria for the type of decision they are to make. Going further to evaluate the criteria, prioritizing them, takes more time and effort.

How Formal Do You have to Be?

A formal process improves performance. But how formal is formal?

The minimal degree of formality is to have a written list of criteria. If during the decision-making other criteria come up, add them to the list.

A next level of formality is to weight the criteria to identify priorities among them and then use the weights to score each option, so the score becomes a factor in choosing one.

In all decisions some criteria are more significant than others. Sometimes the degree of significance, the weights, are used informally or unconsciously. With more formality weights are used to calculate scores in a documented process. This brings a greater degree of objectivity to the process, though making decisions purely on the numbers can be unskillful. Do not underestimate the power of intuition, particularly among experienced decision makers.

The degree of formality depends on the complexity and impact of the decision, the team’s confidence in their decision-making process, and their accountability for their decision. In some cases, rules and regulations mandate the documentation of decisions, in other cases it is useful to be able to show others that a rational process was used to make the decision.

How to Set the Criteria

Identifying the criteria for a decision is not a particularly creative process. Use readily available lists via a quick web search for decision criteria lists. For example:

  • Performance
  • Appearance – look and feel, aesthetics
  • User experience
  • Stakeholder acceptance
  • Cost – of implementation, operation, and replacement
  • Benefits
  • Risk
  • Security
  • Maintainability
  • Reliability
  • Resilience and flexibility
  • Environmental, social and governance considerations
  • Sourcing and availability
  • Time to implement
  • Reviews.

Use this list or one that is more specific to your decision as a starting point to craft your criteria.


Bottom Line

Consciously agreeing upon and documenting decision criteria in the context of a defined decision process promotes high quality decisions and avoids unnecessary delays. To apply this principle most effectively tailor formality to the nature of your situation, with the minimum being a list of agreed upon criteria.


[2] Adapted from Pitagorsky, Managing Conflict in Projects: Applying Mindfulness and Analysis for Optimal Results

[3] How to Write Decision Criteria (With Tips and Examples) | Canada

Best of PMTimes – Project Karma: What You Think, Say And Do Matters

PM Articles by Project Times. 

Projects are the vehicles for making things different. It is natural to want things to be different than they are.

Things can be better. Progress and improvement arise out of this desire. So may pain and suffering. Choosing the right projects and performing them well make the difference.

Projects are actions to effect change – to make more money; improve people’s lives. They deliver new and modified products, architectural wonders, events, and processes which impact both the environment the project work takes place in and the environment that receives the results. Within those environments people’s lives, the way they think, their values and how they relate with others are changed.

The Law Of Cause And Effect -Karma

Every action, whether to make things better or not, creates a ripple effect. The effect may be short lived or last for years, if not lifetimes. It may be felt near or far. Knowing that there is this ripple effect motivates one to be careful about what one does, what one says, and even what one thinks.

This is the Law of Karma or the Law of Cause and Effect. Every action has an effect. Everything is caused by something. Sometimes the effect is very subtle and minor; sometimes near and sometimes far. This is the foundation for process thinking and quality management.

Consider the project of planning a wedding. The way the planning and preparation are carried out influences the relationships among the stakeholders. The over controlling parent can turn-off the bride and groom and the other parents. An over controlling or over emotional bride can change the feelings of the groom and/or her friends and relatives. Even the decision of who gets to sit at which table can reverberate for years to come. One conversation can make or break a relationship.

A project to implement a new process for an operational group can disrupt the organization positively or negatively. It can cause ongoing conflict between management and labor, and either make for better ongoing performance or degrade performance depending on how well the project is executed and how the new process performed and maintained overtime.

A project to lay a pipeline across virgin territory can contribute to the pollution of the environment because of the immediate disruption of the construction project or a decade later when a leak spews oil into the land and water. The project can also result in profits, lower energy costs, and conflict among promoters, resisters, and supporters. There are any number of unforeseeable possibilities.


Decisions And Actions

A decision to ignore or dismiss testing results or concerns raised by project staff can lead to a disaster, as it did in the Challenger explosion, killing the crew, costing millions of dollars and destroying the reputations of NASA management because of their faulty statistical reasoning.

Intentions, biases, values, and beliefs are the drivers of decisions. Decisions drive behavior. The way decisions are made influences relationships and outcomes. For example, being overly aggressive or using underhanded methods to get one’s way can cause distrust and anger that clouds relationships going forward to other negotiations.

Working With Karma

There are a number of strategies to apply this concept of cause and effect to promote optimal performance.

Some people ignore the Law of Karma entirely. They act as if there were no consequences and then are surprised by the results of their behavior. Some of these do, in fact, know about the Law of Karma, others are ignorant of it. Either way, there are consequences.

Some others fall into analysis paralysis. They spend so much time analyzing and worrying about what might happen that they miss the opportunity to act.

Others take a middle path that considers the question from multiple perspectives. They balance their analysis with intuition. They consider the time factor, uncertainty. They realize that there may not be a “perfect” solution.

Take A Beat

This last strategy is one to aspire to. When faced with a decision take a beat.

Relax, pause, breathe and think about what you are going to do. Just reactively diving-in, risks unforeseen consequences. So take a beat. Respond after the due diligence of assessing from multiple perspectives the pros and cons, risks and rewards, ripple effects, alternatives, etc.

Make the duration of the pause and the nature of the decision process right for the situation. Do you have an hour, a day, a month or does the response have to be in the moment. In project work, immediate response is not usually required.

The way a soldier or police officer reacts in a life-threatening situation requires a well-trained reaction. Yet, even in those situations, it is easy to get lost in emotional reactivity. Reactivity does not allow for a step back to think about one’s actions and their consequences. We have seen many instances of inappropriate reactivity leading to unnecessary deaths and ruined lives.

Most project managers have at least a moment to step back and consider the ripple effect of what they do or say. It is only lack of mindful awareness that keeps some from realizing it.


With training in the cultivation of mindful self-awareness there is the possibility of a natural process of letting things unfold. Not in a sloppy, lazy way, but by being in flow so as to allow one’s skills, intelligence, analysis and intuition to emerge in perfect alignment with the needs of the situation.

Short of that, objectively observe what is going on internally and externally to create the platform for what to do next.

In any case, living requires decisions and actions. Actions include the actions of not acting, and of expressing oneself by speaking, writing, or with body language.

Responsiveness means making conscious decisions. Discerning whether they are unbiased or are really justifications or rationalizations after the action has been carried out. When reacting there is no conscious decision making, only the outburst or withdrawal.

No matter whether action stems from a well thought out decision or not, there is the ripple effect.

Picture dropping a stone in a still pond – the effect is ripples radiating out in all directions. Now imagine the stone falling into an already rippling pond into which many stones of different sizes are being continuously dropped in different places. That is more like our world. Complexity and volatility leading to uncertainty.

Sometimes in that kind of pond, the ripples from your stone, your action, are barely visible, sometimes they are operating under the surface to take effect later. Sometimes they don’t much matter. In any case, be mindful enough to remember the Law of Cause and Effect and responsive enough to choose what you do, say and think wisely