---

Tasleemat Forms Guide

Project Artifact: Assumption Log

Document Reference: PMO-03.03

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Assumption Log in alignment with the Tasleemat framework.

---

1. What?

A dedicated register capturing all operational, technical, and environmental assumptions and constraints.

---

2. Why?

Unverified assumptions and untracked constraints are leading causes of project risk and schedule slippage.

---

3. When?

Initiated during project initiation and continuously updated through execution and monitoring.

---

4. Who?

Maintained by the Project Manager with input from the project team and stakeholders.

---

Tailoring Tips

• Review and validate assumptions at every milestone gate.
• Convert invalid assumptions immediately into risk register entries or issue log items.

---

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

• Mandatory:
  • Project Charter (PMO-03.01)
  • Business Case (PMO-01.01)
• Optional / Contextual:
  • Feasibility Studies (External)
  • Statement of Work (PMO-04.09.04)

2. Downstream Dependents

• Mandatory:
  • Risk Register (PMO-04.08.02)
  • Project Scope Statement (PMO-04.02.05)
  • Cost Estimates (PMO-04.04.02)
• Optional / Contextual:
  • Duration Estimates (PMO-04.03.06)
  • Decision Log (PMO-05.02)

---

5. How?

To accurately and professionally complete the Assumption Log, the responsible party must populate the following critical sections based on the project context (ensure parameters.md is referenced for global project variables):

• ID: Unique identifier for the assumption or constraint entry.
• Type: Specify whether this entry is an 'Assumption' or a 'Constraint'.
• Category: The category of the assumption or constraint (e.g., Technical, Financial, Schedule, Resource).
• Description: A clear, detailed description of the assumption or constraint.
• Impact if invalid: The potential risk or impact to the project if the assumption proves false or the constraint is breached.
• Responsible party: The person or role tasked with following up on the assumption to validate its accuracy.
• Due date: The target date by which the assumption needs to be validated or reviewed.
• Actions: Specific actions required to validate the assumption or monitor the constraint.
• Status: The current status of the assumption (e.g., active, validated, closed).
• Comments: Any additional information, operational context, or status updates.

---

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 03_03_Assumption_Log_Example.md