Project management – Critical thinking and logical fallacies

Managing a project is a tricky business, you are trying to deliver a successful project whilst working with multiple people, each person has their own unique thoughts, feelings, opinions and agenda.  As such an important skill of the project manager is critical thinking, there are times on a project when critical thinking is crucial.  Failure to apply critical thinking in status meetings or discussions/communications with key stakeholders can have a negative outcome on a project and who will ultimately be held accountable for the project……The Project Manager

 One skill of a critical thinking PM is to be able to recognise logical fallacies

 What is a logical fallacy?

All arguments or discussions have the same basic structure: They begin with one or more premises, which is a fact or assumption upon which the argument /discussion is based. They then apply a logical principle to arrive at a conclusion.  An argument or discussion that is based upon a logical fallacy is therefore not valid. If the logic of an argument is valid then the conclusion must also be valid.  By being able to identify a logical fallacy the PM to will be able to STOP wasting time or effort on activities where the premise is flawed and more importantly not put the project they are working on at unnecessary risk.

 Logical fallacies to be aware of:


 Project example, In a project meeting, there is a discussion taking place around a specific issue and the possible ways to resolve it, one of the suggestions is disregarded purely because it came from a new project team member or a non technical person


 Project example, An IT system is deployed shortly after which a bug is detected, if the PM does not control the communication of the issue and its resolution then different stakeholders can jump to conclusions about what the root cause was.


 Project example, The scope/direction of a project being directed from a Director or company executive that goes unchallenged by the team purely because of the persons status in the company rather than an informed risk based decision.

 Argument from Personal Incredulity I cannot explain or understand this, therefore it cannot be true.

 Project example, during a risk assessment, identifying a potential risk but not mitigating against it because the project team can’t imagine that situation happening (based on information they have at that time)

 Confusing association with causationThis is similar to the post-hoc fallacy in that it assumes cause and effect for two variables simply because they are correlated, although the relationship here is not strictly that of one variable following the other in time. This fallacy is often used to give a statistical correlation a causal interpretation.

 Project example, in a deployed IT solution, a user imports a file and notices shortly afterwards that the solution has a slower performance and blames the import routine rather than considering other factors.


 Project example, The BI on a project holding the PM accountable for a tight project deadline, when they have missed their agreed deadline for submitting the approved detailed requirements

 The Moving Goalpost A method of denial arbitrarily moving the criteria for “proof” or acceptance out of range of whatever evidence currently exists.

 Project example, A Project sponsor not accepting an IT solution as they have decided they want additional requirements/scope.  Requirements and scope can and do change during a project lifecycle but an IT project failing to meet the agreed baseline schedule should not be seen as a failure if the customer wants last minute changes.


 Project example, In Zone 2 EO demand IT the CONNECT solution (Project Server) was seen as a bad IT application because the data in it could not be relied upon and user s thought the system was difficult to use.  However the majority of the users were not skilled in using MS Project and so incorrectly built and maintained project plans that reflected as bad data in CONNECT


 Project example, In EO Demand IT the current PM methodology is Critical path, but over half of the projects overrun the baseline schedule and/or cost, so critical path methodology causes projects to overrun.  There is a failure to ignore other plausible factors affecting projects like mulit-tasking, a diminishing workforce and too many projects in the active portfolio


 Project example, a developer pushing back on a new submitted requirement because it will ‘open the flood gates’ for further requirement changes.  Although there is a risk of more requirements coming, as a PM you have to balance what the customer wants, what they can afford and when they want it, those additional ‘last minute’ requirements could be critical to the business but not identified by BI at the beginning of the project


 Project example, If updating a project sponsor with the bad news that, due to a specific project issue ie requirements/scope change that the original deadline cant be reached, they respond by asking why does IT always deliver projects late and charging more than an external vendor would do


 Project example, A project manager may claim that a project is so complex that they cannot maintain a project plan accurately so therefore all complex projects don’t need project plans


 Project example, 2 team members are looking independently at the same issue, during a status meeting 1 resource claims he was unable to find the root cause and dismisses the root cause the other team member proposed

 Unstated Major Premise This fallacy occurs when one makes an argument which assumes a premise which is not explicitly stated.

 Project example, as a project manager it is critical that all project assumptions are documented, maintained and available to all team members

This entry was posted in Critical thinking, Opinion, Project management, Random thoughts and tagged , , . Bookmark the permalink.

Leave a Reply


What is 6 + 9 ?
Please leave these two fields as-is: