Project Action Principle #5: Suppress Project Entropy, Selectively

Following on from the article outlining my five Project Management Principles, this article expands the fifth Principle:

Project Action Principle #5: Suppress Project Entropy, Selectively

Project Action Principle #5: Suppress Project Entropy, Selectively

Trust the implementation and guidance for the first 4 project management principles to significantly reduce the entropy in your project. For the remaining entropic events, selectively invest time only where the result will materially improve the achievement of project outcomes.  Do not attempt to implement comprehensive entropy control processes.

Also see “Additional Resources” at the end of this article for detailed strategies and techniques.

Project Entropy

“Project Entropy” is a term for negative project impacts: design problems, technical defects, requirement changes, office bureaucracy, risk events, and all those events that arise from the human factor. “Managing” entropy or its impacts, is the overwhelming focus of most “branded” project management practises.

Enormous efforts are put into the various processes for entropy detection, control and management, that often takes focus away from creating value for customers and achieving outcomes. Then entropy management becomes the project manager’s prime directive with the value-add stuff left to the project owner and other folks.

As we’ve described in Principle #3, project managers under this regime build mental models that focus on entropy and filter out inputs that are not related. This means less time is spent on what the project is building or delivering.

Normal tactics for dealing with entropy…

…actually create even more entropy.

Using any methodology is, in theory, designed to be anti-entropic by organising successful and repeatable practices and establishing a common communications framework amongst all the team members and stakeholders.

However, that methodology creates more entropy by:

  1. Slavishly following the methodology in its fullest form.
  2. Misapplying or gaming the methodology.

The impact on team productivity is enormous with a significant portion of their time wasted on these processes. By trying to control entropy, the situation often creates additional entropy instead of resolving it. I am sure you have seen the disagreements and tension that is created in teams when assessing events and their impacts.

Take Agile methodologies (which I support and try to foster) as an example. These methodologies create the most entropy because they are seen as lowering constraints and to be open to misapplication or gaming of the process.

Another approach to dealing with entropy is to create buffers: if you think a task is going to take 1 week, you report needing 2 weeks; if you think you need 50k for a task, you ask for 100k; and so forth.

The problem is that everyone is doing it, from the individual coder who is asked to estimate their components, to the team leader who will aggregate all their estimates, to the platform manager, to the departmental engagement point, and so on up to the project manager.

This creates entropy in different ways:

  • It promotes a culture of mistrust and dishonesty.
  • It creates project proposals which either don’t get approved or enter a cycle of investigations, deep dives, re-estimates, revalidations, comparisons and so forth.

Manage or suppress?

Techniques such as Issue Management, Risk Management, Scope Management, Change Management, Testing & Defect Management and so forth are intent on managing and controlling entropy.

Ultimately we don’t manage entropy because these forces are typically too unpredictable, too strong or beyond our humanly control. What we can constructively do is manage how we interact and engage with entropy. This includes ignoring it, which is often quite difficult for project managers and teams.

The predictability of entropic events is also a dilemma for project managers.  Some events are so predictable in a project that we may as well treat them as an “issue” because the only thing we don’t know is exactly when they will occur.

For example, even in a modestly dynamic environment, entropic events such as these can be given a probability of 1 (i.e. 100% likelihood of occurring):

  • Change in personnel assigned to key roles
  • Major change in requirements
  • Major change in business priorities
  • Key milestone under threat

This is all standard Risk Management which is an extremely well researched and documented in project management. And depending on how the project is run, they can be both positive and negative influencers.

Risk Management, run badly, can actually increase the amount of entropy in project. But done correctly, it can be one of the best tools to use for entropy suppression.  See <link>Risk Management a WOFTAM</link>.

How to change your focus in your projects

You’ll never find a way to manage all entropy.  There are an infinite number of ways for projects to fail, but only a few ways for the project to succeed.

Applying the first four project management principles will naturally eliminate much of the common entropy that occurs in projects, without the need for additional processes.

The next is to ensure that teams:

  1. Are aware of the basic processes such as hiring people, requesting additional resources from internal teams, etc.
  2. Establish a model to resolve high probability events with a fix not a process to manage.

The benefit of these project management principles is that your main action is NOT to implement some of the tools and processes mandated by many methodologies.

Then, there are very few events that are truly unpredictable or unanticipated, and these events are typically outside the project manager’s control, which I call “Rissues”.

Conventional risk management says that you should invest time to anticipate the impact and to plan the responses. But when things happen, almost all planned are “canned” and typical responses appear: delay the project, add more people, drop functionalities, re-assess the business case and so forth. So a lesson learned would be to engage these unpredictable events only when they occur.

In terms of basic execution and the issues that arise, the most common causes of entropy are usually very ordinary and common:

  1. Lack of knowledge on how to execute basic processes (e.g. get bills paid, hire new people, get people assigned from service departments, and don’t understand who to escalate to and how).
  2. Lack of “situational awareness” to understand the signals of what’s actually happening.
  3. Internal dysfunction: teams overloaded, poor management culture, lack of accountability, differing views of the “value” and “purpose” of project management.

Entropy should be tackled on two fronts: focusing on those things that you can control, and doing what you can to finesse around deep-seated existing problems.

Processes are only followed in limited cases; plus, you should be slow to implement processes that have little chance of successful.


Understanding and applying the first four project management principles will directly and significantly reduce the entropy in a project, by using positive approaches which are essentially “core” or “value-add”.

Remember, there are an infinite number of ways for projects to fail, but only a few ways for projects to succeed.

In a stable and relatively unchanging environment, a high focus on entropy management is useful because it is relatively easy to identify the entropy and its direct impacts.

But with the world today so dynamic and unpredictable, your project environment will have a high level of noise. Focus on the goals, the team and moving forward quickly.  And be careful what you attempt to control.

Additional Resources