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:
Ad hominemAn ad hominem argument is any that attempts to counter another’s claims or conclusions by attacking the person, rather than addressing the argument itself.
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
Ad ignorantiam The argument from ignorance basically states that a specific belief is true because we don’t know that it isn’t true.
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.
Argument from authority Stating that a claim is true because a person or group of perceived authority says it is true. Often this argument is implied by emphasizing the many years of experience, or the formal degrees held by the individual making a specific claim.
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.
Inconsistency Applying criteria or rules to one belief, claim, argument, or position but not to others.
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.
Non-Sequitur In Latin this term translates to “doesn’t follow”. This refers to an argument in which the conclusion does not necessarily follow from the premises. In other words, a logical connection is implied where none exists.
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
Post-hoc ergo propter hocthis fallacy follows the basic format of: A preceded B, therefore A caused B, and therefore assumes cause and effect for two events just because they are temporally related (the latin translates to “after this, therefore because of this”).
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
Slippery Slope This logical fallacy is the argument that a position is not consistent or tenable because accepting the position means that the extreme of the position must also be accepted. But moderate positions do not necessarily lead down the slippery slope to the extreme.
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
Straw Man arguing against a position which you create specifically to be easy to argue against, rather than the position actually held by those who oppose your point of view.
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
Tautology A tautology is an argument that utilizes circular reasoning, which means that the conclusion is also its own premise. The structure of such arguments is A=B therefore A=B, although the premise and conclusion might be formulated differently so it is not immediately apparent as such.
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
Tu quoque Literally, you too. This is an attempt to justify wrong action because someone else also does it. “My evidence may be invalid, but so is yours.”
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