The Curse of Knowledge in Pre-Project Requirements
Last updated: December 31, 2025 Read in fullscreen view
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 246/1907 - 13 Apr 2024
Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 59/1004 - 02 Nov 2021
What is Terms of Reference (ToR)? 31/1508 - 03 Apr 2022
Microsoft Solutions Framework (MSF) 20/1209 - 18 Dec 2023
The Cone of Uncertainty in Scrum & Requirement Definition 9/668 - 02 May 2022
What Is RAID in Project Management? (With Pros and Cons) 8/778 - 18 Oct 2021
Key Elements to Ramping Up a Large Team 8/1145 - 11 Jul 2022
Cost benefit analysis for software development 8/688 - 18 Sep 2025
Pilot Projects Explained: What They Are and How to Use Them Effectively 7/32 - 05 Jun 2023
Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 7/126 - 10 Apr 2024
The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 7/433 - 08 Jan 2024
Ask Experts: Explicitation/Implicitation and Elicitation; two commonly used but barely unraveled concepts 6/307 - 07 Jul 2022
Managing Project Execution Terms 6/391 - 20 Jul 2022
Software Myths and Realities 6/839 - 14 Jun 2022
Example and Excel template of a RACI chart in Software Development 5/758 - 12 Aug 2022
What is End-to-end project management? 4/398 - 03 Jul 2022
What is the difference between Project Proposal and Software Requirements Specification (SRS) in software engineering? 4/986 - 03 Jul 2022
Occam’s Razor and the Art of Software Design 4/493 - 15 May 2022
20 Common Mistakes Made by New or Inexperienced Project Managers 3/264 - 01 Mar 2024
(AI) Artificial Intelligence Terms Every Beginner Should Know 3/290 - 24 Nov 2023
The project management paradox: Achieving MORE by doing LESS 3/198 - 26 Sep 2024
Successful Project Management Techniques You Need to Look Out For 3/382 - 23 Jun 2024
Best Practices for Managing Project Escalations 3/195 - 21 Jun 2024
Dead Horses and the Escalation of Commitment 2/129 - 02 Nov 2022
Difference between Change Management and Project Management 2/222 - 22 May 2022
What are common mistakes that new or inexperienced managers make? 2/267 - 27 Jan 2020
Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 2/415 - 09 May 2022
Build one to throw away vs Second-system effect: What are differences? 2/305 - 01 Oct 2024
23 Overlooked Types of Non-Functional Requirements You Shouldn’t Ignore 2/30 - 12 Apr 2025
How to Ask Powerful Questions Like Socrates 2/28 - 10 May 2022
Levels of Teamwork 1/185 - 03 Jan 2023
Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) 1/352 - 06 Jun 2022
Change Management at the Project Level 1/297 - 17 Oct 2021
Does Fast Tracking increase project cost? 1/356 - 13 Jan 2020
Quiz: Test your understanding project cost management 1/580 - 07 Dec 2023
12 project management myths to avoid 1/177 - 01 Mar 2024
10 Project Management Myths 1/132 - 01 Aug 2022
Is planning "set it and forget it" or "set it and check it"? /271 - 02 Jun 2024
Reviving Ancient Wisdom: The Spiritual Side of Project Management /212 - 30 Nov 2023
Project Managers, Focus on Outcomes — Not Deliverables /145 - 14 Feb 2024
Early BA Engagement: “Earning” Pre-Project Work /152 - 02 Dec 2021
3 Ways to Avoid Scope Creep in IT Consulting /193 - 06 Mar 2024
Most Common Software Development Methodologies /150
A Silent Risk for BAs and PMs
In the pre-project phase, Business Analysts (BAs) and Project Managers (PMs) are expected to clarify business needs, align stakeholders, and lay the foundation for successful delivery. Ironically, this is also the phase where one of the most subtle cognitive biases can cause serious damage: the Curse of Knowledge.
The curse of knowledge occurs when someone who has deep expertise finds it difficult to imagine what it is like not to know what they know. In requirements work, this bias quietly distorts communication between BAs/PMs and clients-especially before a project is formally approved.
Why the Curse of Knowledge Is Dangerous in Pre-Project Work
Unlike delivery phases, pre-project discussions are:
- exploratory rather than structured
- ambiguous rather than detailed
- heavily dependent on shared understanding
When BAs or PMs fall under the curse of knowledge, they unintentionally:
- assume the client understands technical or domain concepts
- skip critical clarification questions
- interpret vague statements through their own mental models
The result is false alignment-everyone thinks they agree, but they don’t.
Common Manifestations in BA/PM Requirements Conversations
1. Assuming Business Clarity That Doesn’t Exist
Clients often describe problems using symptoms, not root causes.
An experienced BA may subconsciously “fill in the gaps” instead of validating assumptions.
Example:
Client: “We need a dashboard to monitor performance.”
BA assumption: KPIs, real-time data, drill-down, role-based access.
Reality: The client may only want a weekly summary in Excel-like format.
2. Overusing Internal or Technical Language
BAs and PMs may use terms such as:
- workflow
- integration
- automation
- exception handling
These words feel “obvious” to experts but may mean very different things to business users.
The curse of knowledge makes experts forget to translate complexity into business language.
3. Asking Leading Questions Instead of Discovery Questions
Instead of asking:
“How do you currently make this decision?”
The BA asks:
“So you want the system to automatically approve this, right?”
This subtly forces the client into confirming the BA’s mental model, rather than revealing their own.
4. Misjudging Stakeholder Readiness
Experienced PMs may assume stakeholders:
- understand project trade-offs
- accept constraints
- can prioritize effectively
In reality, during pre-project stages, stakeholders are often:
- emotionally attached to ideas
- unclear about feasibility
- unaware of cost–scope–time implications
Business Impact of the Curse of Knowledge
If left unchecked, the curse of knowledge leads to:
- misunderstood requirements
- unrealistic expectations
- inaccurate estimates
- scope creep later in delivery
- erosion of trust (“This is not what we discussed.”)
Most project failures attributed to “changing requirements” actually originate from misunderstood requirements in the pre-project phase.
How BAs and PMs Can Actively Counter the Curse
1. Treat Ignorance as a Tool, Not a Weakness
Deliberately ask “naïve” questions:
- “Can you walk me through this step as if I were new?”
- “What happens today if this system doesn’t exist?”
This invites storytelling and exposes hidden assumptions.
2. Separate Listening from Interpreting
In early conversations:
- capture exact words used by the client
- delay solution thinking
- reflect back what you heard before proposing anything
Validation before interpretation is key.
3. Use Progressive Clarification
Instead of jumping to full requirements:
- start with goals
- then scenarios
- then rules
- then exceptions
This reduces the risk of premature conclusions driven by expertise.
4. Explicitly Surface Assumptions
Make assumptions visible:
“I’m assuming this data needs to be real-time. Is that correct?”
Turning assumptions into questions neutralizes the curse of knowledge.
5. Re-frame Requirements in the Client’s Language
Before closing pre-project discussions:
- summarize requirements using business terms
- avoid diagrams or jargon unless requested
- ask clients to confirm understanding, not just agreement
Conclusion
For BAs and PMs, expertise is essential-but in pre-project requirements work, unchecked expertise can become a liability.
The curse of knowledge doesn’t announce itself. It hides behind confidence, experience, and good intentions. Recognizing it-and deliberately slowing down thinking-is often the difference between a project that “starts well” and one that actually succeeds.
In the pre-project phase, the best BAs and PMs are not the ones who know the most-but the ones who understand what the client does not yet know how to say.





Link copied!