PMO-04.09.05 Phase 04: Planning

Request for Proposal

طلب تقديم العروض

tasleemat asset PMO-04.09.05 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 04: Planning

Sizing Tier Requirements

Validation Contract

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

tasleemat validate PMO-04.09.05 ./completed_data.json

Template Markdown (Bilingual)

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

Context and Definition:
A request for proposal invites suppliers to compete for work, and it is the
document that makes the competition contestable. It says what is being bought,
what the supplier must demonstrate, how the submissions will be handled, and
- this is the part that decides whether the contest was real - the criteria
each proposal will be scored against and the weight each one carries.

Two distinctions do most of the work here. The first is between evaluation
criteria and a justification: criteria published after the bids arrive are not
criteria, and no supplier can appeal to them because no supplier saw them. The
second is between clarification and amendment: an answer given to one supplier
is a private change to the requirement, which is why every answer goes to
every supplier.

It can receive information from:
*   The procurement strategy, which sets what will be bought and how
*   The source selection criteria, which the evaluation method must follow
*   The project charter, whose objectives the bought outcome has to serve

It provides information to:
*   The statement of work, which is drafted from the winning proposal and
    cannot contradict what was invited
*   The contract closeout report, which reads what was delivered against what
    was bought here
*   The vendor performance scorecard, which measures against requirements
    fixed at this point

Tailoring Tips:
*   Publish every answer to every supplier. One supplier's clarification is
    another supplier's change to the requirement, and a private answer is the
    mechanism by which a contest stops being fair without anybody deciding
    that it should.
*   Give every criterion a weight, and say what a high score looks like. A
    criterion without a weight is a criterion that can decide the outcome
    without deciding anything.
*   Close the question period before the submissions are priced. A question
    answered late is answered to whoever has already committed a number.
*   State what a price must include. A request that asks for a price without
    saying what is in it produces responses that cannot be compared, and the
    cheapest one is then the one that left the most out.

Alignment:
The request for proposal should be aligned and consistent with:
*   The procurement strategy, which decides what is bought and on what terms
*   The source selection criteria, which the evaluation method must follow
    rather than restate
*   The statement of work, which is drafted from the winning response and
    cannot contradict what was invited here

Section Instructions:
*   Invitation and Scope: what is being bought and who authorised the
    invitation, with the functional and non-functional requirements kept
    separate because a missing function and a missed performance target are
    different failures.
*   Process and Evaluation: how submissions are handled, and the scored
    criteria with their weights - the section that makes the contest
    contestable.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">REQUEST FOR PROPOSAL</h1>

| **Date Prepared:** {{Current_Date}} | **Project Manager:** {{Project_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |

---

## Invitation and Scope

### Purpose and Authority

[ Add details... ]

---

### Project Overview

[ Add details... ]

---

### Scope of Work

[ Add details... ]

---

### Deliverables and Schedule

[ Add details... ]

---

### Technical Requirements

[ Add details... ]

---

### Commercial Requirements

[ Add details... ]

---

## Process and Evaluation

### Submission Requirements

[ Add details... ]

---

### Evaluation Criteria and Weights

[ Add details... ]

---

### Clarifications and Questions

[ Add details... ]

---

### Award and Contract

[ Add details... ]

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Procurement Manager** | {{Procurement_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Manager** | {{Project_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Procurement Committee Chair** | {{Procurement_Committee_Chair_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> REQUEST FOR PROPOSAL | <strong>Ref:</strong> PMO-04.09.05 <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: Request for Proposal

Document Reference: PMO-04.09.05

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

1. What?

Two sections. The first is what is being bought and who authorised the invitation: the purpose and its authority, the background and objectives, the scope with its boundaries, the deliverables against their dates, the technical requirements with the functional and non-functional kept apart, and the commercial requirements including what a price is expected to contain. The second is what happens to the responses: how they must be submitted and by when, the criteria they will be scored against with their weights, how questions are asked and answered, and what the award commits anyone to.

2. Why?

Because a request for proposal is the only document in which a supplier can find out what it is being judged on. Everything difficult about a procurement dispute comes from the fact that this information was not available at the time: criteria settled after the bids arrived cannot be appealed to, because no supplier saw them, and a clarification given to one bidder is a private amendment to the requirement that the others never saw. A request that omits the weights, the answer rules and the deadline meanings does not simplify the procurement; it moves every one of those arguments to the point where nobody can act on the answer.

3. When?

Once, before responses are invited, and then revised only by re-issuing it, because an amended request that is circulated rather than re-issued is a document whose suppliers hold different versions. The question period closes before responses are opened or priced, since a question answered late is answered to whoever has already committed a number. Read again at award, where the question is whether the winning proposal is the one the published criteria selected, and again at closeout, where it is whether what was bought is what was invited.

4. Who?

Owned by the procurement manager, who holds the procurement and is the only party who can commit the buyer, with the project manager supplying the requirements and schedule context so the scope described is the scope the project is managing. The committee chair signs because the evaluation criteria are a commitment to more than one supplier: they are what the losing suppliers were told they would be judged against, and a chair who has not read them cannot certify that the award followed them.

Tailoring Tips

Publish every answer to every supplier. One supplier's clarification is another supplier's change to the requirement, and a private answer is how a contest stops being fair without anybody deciding that it should.
Give every criterion a weight and say what a high score looks like. A criterion without a weight is one that can decide the outcome without deciding anything.
Close the question period before responses are priced. A question answered late is answered to whoever has already committed a number.
State what a price must include. A request that asks for a price without saying what is in it produces responses that cannot be compared, and the cheapest one is then the one that left the most out.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Project Scope Statement (PMO-04.02.05)
- Cost Baseline (PMO-04.04.04)
- Project Schedule (PMO-04.03.08)
Optional / Contextual:
- Risk Register (PMO-04.08.02)
- Resource Requirements (PMO-04.06.02)

2. Downstream Dependents

Mandatory:
- Statement of Work / SOW (PMO-04.09.04)
- RFP (PMO-04.09.05)
- Contract Closure Report (PMO-07.02)
Optional / Contextual:
- Vendor Performance Scorecard (PMO-06.09)
- Contractor Status Report (PMO-06.03)

5. How?

To accurately complete the Request for Proposal, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Purpose and Authority: What this request is authorised to invite, and by whom. The authority clause is what makes the contest defensible: it names the instrument that authorised the procurement, so a later reader can tell an invitation the organisation is entitled to issue from a document somebody drafted because they wanted something.
Project Overview: The background, the objectives, and the outcome being bought - enough that a supplier who has never heard of the organisation can decide whether this is work they want. A request that describes deliverables without describing the problem produces proposals that are technically compliant and solve something nobody had.
Scope of Work: The work and the boundaries of it, described so that two suppliers would propose the same work from this description alone. The exclusions matter as much as the inclusions, because an omission reads as an inclusion and the supplier who priced it that way is the one whose price becomes impossible to deliver.
Deliverables and Schedule: What will be handed over and by when, milestone by milestone. A supplier prices the schedule it is given, so a schedule stated only as a total duration invites every supplier to assume its own plan and the evaluation to compare plans that were never compared.
Technical Requirements: The functional and non-functional requirements the solution must satisfy, separated because they are evaluated differently: a function that is missing is a gap, whereas a performance target that is missed is a shortfall, and a form that treats them as one list cannot say which of the two has occurred.
Commercial Requirements: The pricing structure, the currency, what is included and what is billed separately, and the period the price holds for. A request that asks for a price without saying what it must include produces responses that are not comparable, and the cheapest one is then the one that left the most out.
Submission Requirements: How a proposal must be submitted and by when, in a form the buyer can actually open: who may submit, what the deadline means, whether a proposal may be withdrawn before the deadline, and what happens to one that arrives late. Each of these is a point at which a well-meaning supplier can be turned away by accident, and an accident at this point is indistinguishable from a rigged contest.
Evaluation Criteria and Weights: The criteria the proposals will be scored against, each with the weight it carries and what a high score looks like. This is the clause that decides whether the contest was real. Criteria published after the bids are in are not criteria but a justification, and no supplier can appeal to them because no supplier saw them; a stated weight also stops a criterion nobody expected from deciding the outcome.
Clarifications and Questions: How questions are asked, answered, and published, and the date the answer period closes. Two rules carry this section: every answer goes to every supplier, because an answer given to one is a private amendment to the requirement; and the question period closes before submissions open the work of pricing, because a question answered late is answered to whoever has already committed their number.
Award and Contract: How the successful supplier is chosen, what happens next, and what the award does and does not commit anyone to. Naming the route from award to statement of work is what stops the gap between winning and signing from becoming a second negotiation with no rules.

Associated Templates

6. Reference Example

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

📖 Completed Example: 04_09_05_Request_for_Proposal_RFP_Example.md

LLM Generation Prompt & Agent Instructions

Request for Proposal - LLM Generation Prompt

SYSTEM INSTRUCTIONS: This document is the detailed instruction set for generating the Request for Proposal. When asked to populate the template, follow the guidance for each section below to produce the requested content. Refer to parameters.md for the general project variables.

Context and Definition: An invitation to suppliers to compete for work, and the document that makes the competition contestable. It states what is being bought, what a supplier must demonstrate, how submissions will be handled, and the criteria each proposal will be scored against with the weight each one carries. The difference between that last part and a justification is the difference between a contest and a decision that was already made.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Project Scope Statement (PMO-04.02.05), Cost Baseline (PMO-04.04.04), Project Schedule (PMO-04.03.08) * Optional: Risk Register (PMO-04.08.02), Resource Requirements (PMO-04.06.02) * Downstream Dependents: * Mandatory: Statement of Work / SOW (PMO-04.09.04), RFP (PMO-04.09.05), Contract Closure Report (PMO-07.02) * Optional: Vendor Performance Scorecard (PMO-06.09), Contractor Status Report (PMO-06.03)

Invitation and Scope

Purpose and Authority

Instructions: What this request is authorised to invite, and by whom. The authority clause is what makes the contest defensible: it names the instrument that authorised the procurement, so a later reader can tell an invitation the organisation is entitled to issue from a document somebody drafted because they wanted something.