Tailoring Plan

خطة التخصيص

tasleemat asset PMO-02.01 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 02: Project Approach and Tailoring

Sizing Tier Requirements

Tier 1 Tier 2

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-02.01 ./completed_data.json

Template Markdown (Bilingual)

<!--  
LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

Section Instructions:

**1. Tailoring Basis**
*   **Organizational Methodology:** The methodology this project is tailoring from, with its version. The version matters because a decision to deviate from a methodology is meaningless without knowing which one, and two projects claiming to follow the same methodology may be following different editions of it.
*   **Tailoring Drivers:** What makes this project different from the standard: size, risk, complexity, regulatory context, or organisational constraint. A tailoring plan written without drivers lists arbitrary decisions, because where nothing is forcing a change any change looks equally reasonable.
*   **Applicable Standards:** The governance, quality or regulatory standards that apply regardless of tailoring, and which cannot be traded away. These are the floor the tailoring operates above, and a plan that does not state them invites a decision to drop a mandatory control as an efficiency measure.
*   **Inherited Tailoring:** Any tailoring already decided at programme or portfolio level that this project inherits rather than makes. Most deviations in a project are inherited, and a plan that records only its own decisions implies it has full control over the approach when it does not.

**2. Tailoring Decisions**
*   **Process or Artifact:** What is being tailored, named specifically enough to be found in the methodology. "The risk process" is not a decision anyone can approve, because there are several and the one approved may not be the one implemented.
*   **Standard Requirement:** What the methodology requires by default, stated before the change. Without the default written down the reader cannot tell whether the tailoring loosened a requirement or only renamed it, which is the commonest form of undeclared tailoring.
*   **Decision:** Added, removed, or modified, and specifically what changes. Record the effect on the process itself, not the intent, since "simplified" is an intent and "the weekly risk review is replaced by a fortnightly one" is an effect.
*   **Rationale:** Why this change is right for this project, tied to a driver. A rationale that would be equally valid for any project is not a rationale, and is the usual reason a tailoring decision cannot survive a later challenge.
*   **Consequence:** What becomes harder because of the change. Every tailoring has a cost, and a plan that records only what improves is a summary of intentions; recording what is given up is what makes the decision reviewable.
*   **Reversibility:** Whether the change can be undone, and what would trigger reversing it. Most tailoring is reversible in principle and irreversible in practice, because by the time the cost becomes clear the team has built its way around the change.
*   **Impact on Artifacts:** Which downstream artifacts change as a result, such as the risk register, the schedule format, or the reporting cadence. A decision that changes a process without changing the artifacts that process produces leaves two versions of the truth in circulation.

**3. Governance of Tailoring**
*   **Decision Authority:** Who may approve a tailoring decision, and at what level each class of change is approved. Without an authority map the project either escalates everything or decides things nobody authorised.
*   **Review and Reapproval:** When the plan is reviewed, and what would cause a decision to be reopened. Tailoring decisions are rarely revisited, so the trigger has to exist before the decision rather than being invented once the cost is known.
*   **Compliance Check:** How the plan is checked against the applicable standards, and who performs the check. A self-check performed by the party that wanted the change is not a check.
*   **Change Control Link:** How a later change to a baselined decision is raised, since tailoring is baselined and any subsequent change is a change to the plan rather than an update to it.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Initiative_or_Project_Name}} - {{Assessment_ID}}</h2>
<h1 dir="ltr" align="center">TAILORING PLAN</h1>

| **Date Prepared:** {{Current_Date}} | **Methodology Lead:** {{Methodology_Lead_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Tailoring Basis
<!-- What is being tailored from, what forces the change, what cannot be traded away, and what is inherited. -->

**Organizational Methodology:** [ Add details... ]

**Tailoring Drivers:** [ Add details... ]

**Applicable Standards:** [ Add details... ]

**Inherited Tailoring:** [ Add details... ]

---

## 2. Tailoring Decisions
<!-- One row per decision: the default, what changes instead, why, what it costs, and what it affects. -->

| Process or Artifact | Standard Requirement | Decision | Rationale | Consequence | Reversibility | Impact on Artifacts |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. Governance of Tailoring
<!-- Who approves, when decisions are revisited, how compliance is checked, and how a baselined decision is changed. -->

**Decision Authority:** [ Add details... ]

**Review and Reapproval:** [ Add details... ]

**Compliance Check:** [ Add details... ]

**Change Control Link:** [ Add details... ]

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Methodology Lead** | {{Methodology_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **PMO Lead** | {{PMO_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Sponsor** | {{Project_Sponsor_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> TAILORING PLAN | <strong>Ref:</strong> PMO-02.01 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Tailoring Plan

Document Reference: PMO-02.01

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

1. What?

A baselined record of every departure from the organisational methodology, and of the decisions and standards the project operates under. It states what is being tailored and from which version of the method, what forces the change, which standards apply regardless, which tailoring is inherited from above, and for each decision what the default was, what replaces it, why, what it costs, and whether it can be undone.

2. Why?

Because a methodology is a default rather than a law, and the value of having one is that everyone starts from the same place. Tailoring destroys that value unless it is recorded: an unrecorded departure is invisible to the next person who joins, to the assurance function, and to anyone reviewing the project afterwards, and it is always discovered late. Recording the default alongside the decision is what makes the departure legible, and recording the consequence is what makes it reviewable.

3. When?

This artifact is primarily prepared, utilized, and updated during the PROJECT APPROACH AND TAILORING Process Group of the project lifecycle. It is baselined before execution begins and revisited whenever a decision is challenged by its consequences or the project's circumstances change.

4. Who?

Responsibilities: Developed by the Project Manager with input from the project team and Subject Matter Experts, then baselined. Approved by the PMO lead, who is accountable for the consistency of the approach across the portfolio, and by the sponsor where a decision affects a standard the sponsor is required to uphold.

Tailoring Tips

The plan may record only the decisions that differ from the methodology, provided the methodology version is stated, since a reader with the methodology in hand can derive the defaults. Recording the defaults explicitly is still preferable where the decision is one that will be challenged.
Inherited tailoring from programme level should be recorded rather than assumed, since most deviations a project finds are not its own and the project inherits responsibility for them whether it made them or not.
A small project may consolidate the basis and governance sections into a short preamble, but the decisions table should retain the default and the consequence, as those are the two columns that make a decision defensible.
Where a decision was made under time pressure, it is worth recording that explicitly, because an expedited decision reviewed later looks identical to one that was never challenged.
The plan may be superseded rather than amended after baseline, since a change to a baselined decision is a change to the plan and should be traceable as such.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Project Charter (PMO-03.01)
- Organizational PMO Methodology
Optional / Contextual:
- Program Charter (PMO-00.02)
- Risk Management Plan (PMO-04.08.01)

2. Downstream Dependents

Mandatory:
- Project Management Plan (PMO-04.01.01)
- Quality Management Plan (PMO-04.05.01)
Optional / Contextual:
- AI Governance Plan (PMO-02.02)
- Team Charter (PMO-04.06.05)

5. How?

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

Organizational Methodology: The methodology this project is tailoring from, with its version. The version matters because a decision to deviate from a methodology is meaningless without knowing which one, and two projects claiming to follow the same methodology may be following different editions of it.
Tailoring Drivers: What makes this project different from the standard: size, risk, complexity, regulatory context, or organisational constraint. A tailoring plan written without drivers lists arbitrary decisions, because where nothing is forcing a change any change looks equally reasonable.
Applicable Standards: The governance, quality or regulatory standards that apply regardless of tailoring, and which cannot be traded away. These are the floor the tailoring operates above, and a plan that does not state them invites a decision to drop a mandatory control as an efficiency measure.
Inherited Tailoring: Any tailoring already decided at programme or portfolio level that this project inherits rather than makes. Most deviations in a project are inherited, and a plan that records only its own decisions implies it has full control over the approach when it does not.
Process or Artifact: What is being tailored, named specifically enough to be found in the methodology. "The risk process" is not a decision anyone can approve, because there are several and the one approved may not be the one implemented.
Standard Requirement: What the methodology requires by default, stated before the change. Without the default written down the reader cannot tell whether the tailoring loosened a requirement or only renamed it, which is the commonest form of undeclared tailoring.
Decision: Added, removed, or modified, and specifically what changes. Record the effect on the process itself, not the intent, since "simplified" is an intent and "the weekly risk review is replaced by a fortnightly one" is an effect.
Rationale: Why this change is right for this project, tied to a driver. A rationale that would be equally valid for any project is not a rationale, and is the usual reason a tailoring decision cannot survive a later challenge.
Consequence: What becomes harder because of the change. Every tailoring has a cost, and a plan that records only what improves is a summary of intentions; recording what is given up is what makes the decision reviewable.
Reversibility: Whether the change can be undone, and what would trigger reversing it. Most tailoring is reversible in principle and irreversible in practice, because by the time the cost becomes clear the team has built its way around the change.
Impact on Artifacts: Which downstream artifacts change as a result, such as the risk register, the schedule format, or the reporting cadence. A decision that changes a process without changing the artifacts that process produces leaves two versions of the truth in circulation.
Decision Authority: Who may approve a tailoring decision, and at what level each class of change is approved. Without an authority map the project either escalates everything or decides things nobody authorised.
Review and Reapproval: When the plan is reviewed, and what would cause a decision to be reopened. Tailoring decisions are rarely revisited, so the trigger has to exist before the decision rather than being invented once the cost is known.
Compliance Check: How the plan is checked against the applicable standards, and who performs the check. A self-check performed by the party that wanted the change is not a check.
Change Control Link: How a later change to a baselined decision is raised, since tailoring is baselined and any subsequent change is a change to the plan rather than an update to it.

📥 Associated Templates

6. Reference Example

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

📖 Completed Example: 02_01_Tailoring_Plan_Example.md

LLM Generation Prompt & Agent Instructions

TAILORING PLAN - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the TAILORING PLAN. When asked to populate this form, use the guidance provided for each section below to accurately generate the required content. Reference parameters.md for global project variables.

Context & Definition: Tailoring is the deliberate departure from a standard method, recorded as such. The distinction that matters is between a decision and a default: a methodology says what to do unless there is a reason not to, and tailoring is the part where the reason is written down. An unwritten deviation is not tailoring, it is a departure that will be discovered later by someone auditing the project, and by then the team has built its way around it.

The three sections follow the life of a tailoring decision. The basis establishes what is being tailored from, what forces a change, what cannot be traded away, and what the project has already inherited from above it. The decisions record each change with the default it departs from, because without the default a reader cannot tell whether a requirement was loosened or merely renamed. The governance section establishes who may approve what, and what would cause a decision to be reopened.

The field most often skipped is the consequence. Every tailoring has a cost, and a plan that records only what improves is a summary of intentions. Recording what becomes harder is what makes the decision reviewable by someone who was not in the conversation when it was made.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Project Charter (PMO-03.01), Organizational PMO Methodology * Optional: Program Charter (PMO-00.02), Risk Management Plan (PMO-04.08.01) * Downstream Dependents: * Mandatory: Project Management Plan (PMO-04.01.01), Quality Management Plan (PMO-04.05.01) * Optional: AI Governance Plan (PMO-02.02), Team Charter (PMO-04.06.05)

1. Tailoring Basis

Organizational Methodology

Instruction: The methodology this project is tailoring from, with its version. The version matters because a decision to deviate from a methodology is meaningless without knowing which one, and two projects claiming to follow the same methodology may be following different editions of it.