00 Project Life Cycle
The six stages of OZOD's project life cycle, in the order of OZOD's document. Only the Initiation Stage is designed in this draft.
Starts when The BD opens the project on the system.Ends with Project closed after the final handover.
Stated
- Six stages: Initiation, Planning, Execution, Monitoring & Controlling, Initial Handover, Final Handover (OZOD document).
- Stages and activities can overlap: the next one can start before the previous one is closed, with a written reason (meeting; Eng. Hesham).
Added by Business Excellence Expert (to confirm)
- The stages are drawn in a row as numbered. How Monitoring & Controlling runs beside Execution is not designed yet.
01 Initiation Stage
The stage that hands the project from Business Development to Operations, studies it, fixes the estimation budget and checks readiness for Planning. Click a box to open the activity.
Starts when The BD opens the project on the system.Ends with The COO approves the move to Planning.
Stated
- Activities 1.01 to 1.06 as in OZOD's document; their order is flexible and they can run in parallel (Governance 2).
- The whole stage takes about 3 to 5 days (meeting).
- Mobilization is not part of this stage: the Mobilization Plan is Planning 2.03 and Site Mobilization is Execution 3.03 (agreed with Eng. Hesham).
- Site handover minutes: a task opened when it is due (Eng. Hesham).
- The COO holds five mandates in this stage: Internal Handover, Contract Approval, External Handover, Estimation Budget and Initiation Closure. 1.03 is internal work of the PM and the heads (Eng. Hesham).
Added by Business Excellence Expert (to confirm)
- The COO is accountable for each mandate through one decision; outside these decisions he follows SLAs and red flags.
- With the Project Director removed, the COO opens the site handover minutes task and assigns it to the PM.
- Reading of the order: Contract Finalization and Estimation Budget can start as soon as the project is opened; Integrated Project Review and External Handover follow the internal kickoff.
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-00-01 | Missing | SLA of the whole Initiation Stage: "3 to 5 days" counted from which event (award letter, project opened by the BD, PM assigned) to which event (COO decision at the gate)? |
| Q-00-02 | Missing | Escalation timing: when an SLA is breached, after how long does it go from the PM to the COO, and from the COO to the CEO? |
1.01 Internal Handover
Business Development hands the project to Operations for information: a structured package on the system, then the internal kickoff meeting where the BD explains the project.
Starts when The project is awarded, or expected (early activation by the BD).Ends with The COO confirms the internal handover is done, after every selected member confirmed receipt, every mandatory kickoff task is closed and the PMO entered the ERP project code.
Stated
- The BD opens the project, sets the project code in O1 and fills the handover package: templates (project and scope, stakeholders, start requirements), initial risks and issues as records, and an upload slot for each document type (Eng. Hesham).
- The package is for information. There is no Completed / Not Completed status on its items (Eng. Hesham).
- On submission the system notifies the COO and the default heads (Technical Office, Procurement, Project Control, MEP) (Eng. Hesham).
- The PMO is notified too and gets a task: open the project on the ERP (ePromise) and enter the ERP project code in its field in O1, so that the project information is complete (Eng. Hesham).
- The COO sees the whole team: the default heads come selected; he assigns the PM and can deselect a head who will not be engaged in the Initiation stage (Eng. Hesham).
- The COO sets the gate criteria of the project: which outputs are hard gates and which are carry-over (Eng. Hesham).
- The COO decides whether the kickoff is needed. It is mandatory by default; the COO can say "No need", for example on projects the team already knows (Eng. Hesham).
- If needed, the BD schedules the kickoff and sends the invitation; the COO, the PM and all heads attend; the BD explains the project (Eng. Hesham; OZOD document).
- The PM and the selected heads confirm receipt and review the package. A question is a mention on the document that opens a task to the BD, who answers or adds the missing information (Eng. Hesham).
- The actions of the kickoff minutes become tasks: the BD Manager creates them as mandatory tasks, each with an owner, a reviewer and a due date (the SLA). The owner completes it, for example by uploading a document. Only actions that must be done before the handover can close are recorded this way (Eng. Hesham).
- Each task has a reviewer, or is marked "no review". With a reviewer, the reviewer accepts (the task closes) or rejects it back to the owner with a comment. With "no review", the task closes when the owner completes it (Eng. Hesham, 23 Oct).
- The COO closes the internal handover. He cannot close it until every selected member (PM and heads) has confirmed receipt and every mandatory kickoff task is closed (Eng. Hesham).
Added by Business Excellence Expert (to confirm)
- A "No need" decision is recorded with a reason; with no kickoff there are no kickoff tasks.
- The task owner can be any member of the project team, the BD included.
- The ERP project code entered by the PMO is also a condition for the COO to close 1.01 (to confirm).
- The BD uploads the kickoff minutes; when the COO closes 1.01, 1.03 starts by itself for the selected team.
- The system builds the internal handover minutes (OZOD output 3) from the package, the kickoff minutes and the open questions with their owners and due dates (see REC-06).
- Award documents (award letter or assignment correspondence, OZOD input 1) added as the first upload slot.
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-01-01 | Missing | SLA from the award letter (or early-activation decision) to the BD submitting the handover package. |
| Q-01-02 | Missing | SLA for the COO to assign the PM, confirm the team and decide on the kickoff, from the package submission. |
| Q-01-03 | Missing | SLA for each selected member (PM and heads) to confirm receipt of the package. |
| Q-01-04 | Missing | SLA for the BD to answer a question raised on a document. |
| Q-01-05 | Missing | SLA for the BD to hold the kickoff, from the COO's decision that it is needed. |
| Q-01-06 | Missing | SLA for the COO to close the internal handover, once the last confirmation is in. |
| Q-01-07 | Missing | A mandatory kickoff task that cannot be done by its due date: can the owner ask for a new due date, and who approves it (BD Manager or COO)? |
| Q-01-08 | Missing | SLA for the PMO to open the project on the ERP (ePromise) and enter the ERP code in O1, from the package submission. |
1.02 Contract Finalization
The draft contract and its annexes are reviewed by the Commercial Committee, negotiated by Business Development, approved as per the Delegation of Authority (DoA) and signed, then shared with the project team.
Starts when The draft contract is received from the owner.Ends with The signed contract is on the system and shared with the project team.
Stated
- Review of the draft contract and annexes, comments addressed and terms negotiated, then approval and signing as per the authorities, then shared with those concerned (OZOD document).
- The BD owns contract finalization; the Commercial Committee (CEO, CFAO, COO, PMO, BDD) reviews the draft and gives its feedback; the BD revises and negotiates (Eng. Hesham).
- The approver follows the DoA matrix; Contract Approval is one of the COO's mandates (Eng. Hesham).
- OZOD has no DoA matrix yet; it is to be defined (Eng. Hesham).
- If the contract changes during the negotiation with the owner, the BD has two options: send it back to the Commercial Committee for review (the Committee reviews, then it returns to the BD to negotiate again), or take the decision himself, agree with the owner and go to the approval per the DoA (Eng. Hesham, 23 Oct).
Added by Business Excellence Expert (to confirm)
- The decision "Approved?" of the DoA approver and its loop back to negotiation.
- Example of the DoA rule: COO up to a contract value, CEO above it. The values are OZOD's (REC-12).
- If the signed terms differ from the budget basis, the budget review re-opens (REC-02).
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-02-01 | Missing | SLA for the Commercial Committee to give its feedback on the draft contract. |
| Q-02-02 | Missing | SLA for the approver (per DoA) to approve or return the contract. |
| Q-02-03 | Missing | SLA from approval to uploading the signed contract. Negotiation with the owner is external: is it tracked against a target date, or not timed? |
1.03 Integrated Project Review
Starts by itself when the COO closes the internal handover. The PM and every selected head review the package; the heads submit their risks, issues and concerns; the PM visits the site and can give ad-hoc tasks to anyone in the team, each with a due date. The PM then consolidates everything into one register.
Starts when The COO closed the internal handover.Ends with The consolidated risk and issue register is ready for 1.06.
Stated
- Mandatory on every project. When the COO closes 1.01 the system gives the PM and every selected head a review task, and the PM a site-visit task, without any action by the PM (Eng. Hesham).
- The PM reviews the package like the heads (Eng. Hesham).
- Each head reviews what concerns his discipline and submits his risks, issues and concerns (comments as text or an attached file). The head who raises an item is its first owner (Eng. Hesham).
- In this stage the PM can give a task to anyone in the team, in addition to the review. Every task the PM creates must have a due date, so that the SLA applies to it (Eng. Hesham).
- The PM does the pre-start site visit on the mobile app with a checklist and photos; the COO approves it, or asks for a revisit or an additional visit (Eng. Hesham).
- The PM can instead request that the visit is not required, with a reason; the COO accepts or refuses (Eng. Hesham).
- Everything ends in one register. The PM assigns the final owner and the mitigation or action plan of each item: this register is the output of 1.03 (Eng. Hesham).
- No readiness decision here: the COO decides in 1.06 (Eng. Hesham).
- A head can split the review into sub-tasks for his engineers (meeting).
Added by Business Excellence Expert (to confirm)
- The PM's own review findings go into the same register as the heads' items.
- A due date per register item, set by the PM with the owner and the mitigation.
- The site-visit owner is the PM by default; the COO can change it. The PM consolidates after all reviews and his ad-hoc tasks are done and the site visit is approved (parallel join). An ad-hoc task still open at that point is carried as an Open item with its owner and due date.
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-03-01 | Missing | SLA for the PM and each head to review the package and submit risks, issues and concerns. |
| Q-03-02 | Missing | SLA for the PM to do the pre-start site visit, from the task being created. |
| Q-03-03 | Missing | SLA for the PM to consolidate the register (owner, mitigation, date per item) once all heads have submitted. |
| Q-03-04 | Missing | SLA for the COO to approve the pre-start site visit (or ask for a revisit), or to decide on a "not required" request. |
1.04 External Handover
Business Development introduces the owner, the consultant and the PMC to the PM and the operations team, and hands over the communication channels.
Starts when The internal kickoff is held.Ends with Done, or closed as not required.
Stated
- Whether it is required is discussed at the kickoff; the COO decides. Required: a task that must be done. Not required: closed with "No" (Eng. Hesham).
- The BD sends a letter or e-mail with the contacts of the project team after the meeting (meeting).
Added by Business Excellence Expert (to confirm)
- "Upload minutes & letter" as the evidence that closes the task.
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-04-01 | Missing | SLA to hold the external kickoff with the owner, consultant and PMC, from the COO's decision that it is required. |
| Q-04-02 | Missing | SLA for the BD to send the letter with the contacts and channels after the meeting. |
1.05 Estimation Budget
The BD Estimation Team turns the pricing statement into the estimation budget and the CEO approves it. The approved budget is then handed over to the Commercial Committee in a meeting that explains every assumption. Comments, risks and issues raised there go to the PMO, who owns the budget from then on.
Starts when The pricing statement is ready.Ends with The approved budget is on the system and handed over to the PMO, with the comments, risks and issues of the meeting.
Stated
- The estimation is under Business Development: the BD Estimation Team prepares the estimation budget (Eng. Hesham).
- The CEO approves it; there is one approval (Eng. Hesham).
- After the CEO approves it, the budget returns to the BD Estimation Team, who uploads it without the management reserve (Eng. Hesham, 23 Oct).
- After the upload, the team schedules the handover meeting with the Commercial Committee (CEO, CFAO, COO, PMO, BDD). The system notifies the Committee, who sees the budget without the management reserve, the assumptions, and notes the points to discuss in the meeting (Eng. Hesham, 23 Oct).
- In the meeting the team explains every assumption. The comments, risks and issues raised are recorded in the minutes; there is no separate step to raise them (Eng. Hesham, 23 Oct).
- The minutes go to the Commercial Committee for review and approval. If something is missing they return to the team to be corrected, until approved. The approved minutes are the handover document and are handed over to the PMO (Eng. Hesham, 23 Oct).
- The comments, risks and issues become the PMO's responsibility; the PMO acts on them, because the PMO is responsible for the execution budget afterwards (Eng. Hesham).
- It is a financial ceiling for the project, not per item (meeting).
- Only what everyone may see is uploaded; whoever is in the project can see it (Eng. Hesham).
- A partial budget for early works follows the same cycle (Eng. Hesham).
- It is uploaded as Excel on a template still to be proposed (meeting).
Added by Business Excellence Expert (to confirm)
- If the CEO does not approve, the budget goes back to the BD Estimation Team for revision.
- The meeting does not reopen the budget: its outcome is the minutes, plus the PMO's actions and the risks and issues logged in the project registers.
- The approved estimation budget is the basis of the execution budget in Planning (2.06).
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-05-01 | Missing | SLA for the BD Estimation Team to prepare the estimation budget, from the pricing statement being ready. |
| Q-05-02 | Missing | SLA for the CEO to approve the budget (or return it for revision). |
| Q-05-03 | Missing | SLA to hold the handover meeting with the Commercial Committee, from the approval. |
| Q-05-04 | Missing | SLA for the PMO to act on the comments and log the risks and issues after the meeting. |
| Q-05-05 | Missing | SLA for the Commercial Committee to review and approve the minutes. |
1.06 Initiation Closure
A gate review, not a check that everything is finished. The PM requests it once the hard gates are met; the system builds the readiness pack; the closure meeting, chaired by the COO, settles every open point; the COO decides. Unfinished carry-over activities continue into Planning and stay tracked.
Starts when The hard gates of 1.01 and 1.03 are met and the PM requests the gate review (or the COO calls it).Ends with Go, Go with conditions, Hold or No-go from the COO.
Stated
- The closure meeting reviews what is done and what is not, and the team may decide to start even if some items are not finished, for example before the contract is signed (Eng. Hesham).
- For each project the COO sets which items are hard gates (must be done to start) and which are carry-over (can be finished after the start) (Eng. Hesham).
- All concerns are discussed, aligned and documented in the meeting (Eng. Hesham; OZOD document).
- Risks and issues still waiting (no owner or no mitigation) are Pending (Eng. Hesham).
- What the meeting reviews are the concerns, risks and issues of the consolidated register: the PM confirms them and sets an owner for each, and presents them to the COO for the move to Planning (Eng. Hesham, 23 Oct).
- The handover package of 1.01 is not checked again. Once the COO has closed 1.01 it is not reopened; a document missing from the package is not a reason for Hold or No-go (Eng. Hesham, 23 Oct).
- The PM gives the readiness report; the COO decides the move to Planning (Eng. Hesham).
- Starting before the contract is signed is allowed within the limits of commitments before contract (OZOD document, Governance 1 and 4).
Added by Business Excellence Expert (to confirm)
- The gate review can start before every activity is done: only the hard gates of 1.01 (handover closed, team assigned) and 1.03 (register consolidated) are needed to request it.
- The PM prepares, he does not close everything first: for each open item he proposes an owner, a date and whether it is carry-over, and gives his recommendation.
- The COO chairs the meeting; the BD attends when items wait for him. No item leaves the meeting Pending (to confirm).
- Four decisions: Go (all done); Go with conditions (hard gates met, the rest carry-over); Hold (project frozen, e.g. award delayed); No-go (a hard gate is not met: back to the readiness report).
- Go with conditions and the contract not signed: the COO records the conditions and a risk acceptance with the commitment limits per DoA; the CEO is notified (to confirm).
- Carry-over activities (for example 1.02 and 1.04) stay open with their SLA and escalation. The stage shows "Closed with conditions" and closes by itself when the last carry-over item is done.
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-06-01 | Missing | SLA for the PM to prepare the readiness report, from requesting the gate review. |
| Q-06-02 | Missing | SLA to hold the closure meeting, and for the PM to upload the minutes after it. |
| Q-06-03 | Missing | SLA for the COO to decide, from the final readiness report. |
| Q-06-04 | Missing | Maximum time a project can stay "Closed with conditions" before carry-over items are escalated. |
| Q-06-05 | Missing | Starting before the contract is signed: is the COO's risk acceptance enough, or does the CEO approve? |
Site Visit (mobile)
Every site visit is done on the mobile app. The visit type decides who requests it, who does it and who approves it. The one who requests a visit approves it.
Starts when A visit is requested, or created by the system (pre-start visit in 1.03).Ends with The visit is approved (checklist and evidence saved), or closed as not required.
Visit matrix (setting in O1)
| Visit type | Requester & approver | Owner (visitor) | Note |
|---|---|---|---|
| Pricing study visit | BD Manager | Named by the BD Manager | Before the project; outside the Initiation stage. |
| Pre-start visit (1.03) | COO | PM by default; the COO can change it | Created by the system when the COO closes 1.01. |
| Routine field visit | PM (to confirm) | Anyone in the team | To confirm when the Execution stage is designed. |
Stated
- Types: initial study visit (pricing), pre-start visit, routine field visit; each type has its own checklist (Eng. Hesham).
- Pricing study visit: the BD Manager requests it and names the owner who visits (Eng. Hesham).
- Pre-start visit: done by the PM in this stage; the COO approves it and can ask for the visit to be done again or for an additional visit (Eng. Hesham).
- The owner can request "not required" with a reason, for example when he already knows the site from a project next to it. The approver accepts (the visit is closed as not required) or refuses (the visit must be done) (Eng. Hesham).
- The checklists are to be given by OZOD (meeting).
- Evidence (photos) is attached per checklist item. Each item is set in the configuration: no evidence, optional or mandatory. One or more photos can be attached to an item (Eng. Hesham, 23 Oct).
Added by Business Excellence Expert (to confirm)
- General rule: the requester of a visit is its approver; requester, default owner and approver are a matrix by visit type, editable by the admin.
- Pre-start visit: the system creates it with the PM as owner, so the COO does not have to start it; the COO can change the owner.
- Three decisions: Approved; Revisit (same owner, reason and new due date mandatory); Additional visit (a new visit, the owner may change; the first one stays approved).
- Routine field visit: requested and approved by the PM (to confirm, when the Execution stage is designed).
- The number of revisits per visit is shown to the approver.
- The list of types can be extended by the admin (project rule: enumerated lists are open lists).
Business Excellence Queries
Information still needed from OZOD before this activity can be built. Each item is removed once the answer is reflected in the process.
| ID | Status | Query |
|---|---|---|
| Q-SV-01 | Missing | SLA to complete a site visit and save it, from the visit task being assigned (per visit type, if different). |
| Q-SV-02 | Missing | SLA for the approver to approve a visit or ask for a revisit. |
| Q-SV-03 | Missing | Maximum number of revisits before the case is escalated? |
| Q-SV-04 | Missing | SLA for the approver to accept or refuse a "not required" request. |
Handover package (1.01)
What the BD fills on the system when he opens the project. This is the specification of the BD handover screen for the prototype.
| Section | Type on the system | Content | Note |
|---|---|---|---|
| 1. Award documents | Upload slot | Award letter, or the correspondence the assignment rests on | OZOD input 1. Empty while the project is in early activation. |
| 1b. ERP project code | Field | Code of the project on the ERP (ePromise) | Entered by the PMO, not by the BD. |
| 2. Project & scope | Template | Project description and scope; site information: services, permits, obstacles | The BD can add a section with its own subject. |
| 3. Stakeholders | Template | Client, consultant, PMC and other parties, with contacts | |
| 4. Start requirements | Template | Commitments, urgent dates, guarantees, insurance, advance payment | |
| 5. Initial risk register | Records in the Risk Log | Risks known from the pricing study | Tagged "Identified by BD - Initiation". |
| 6. Initial issue log | Records in the Issue Log | Issues known from the pricing study | Tagged "Identified by BD - Initiation". |
| 7. Tender documents | Upload slot per type | Scope, drawings, specifications, BOQ, client requirements | One slot per type. |
| 8. Pricing documents | Upload slot per type | Supplier and subcontractor offers, queries and clarifications, correspondence, amendments | One slot per type. |
| 9. Offer documents | Upload slot per type | Technical and financial offer, negotiations, assumptions, exclusions, undertakings | One slot per type. |
| 10. Pricing site visit | Upload slot | Photos and report of the visit made during pricing |
Rules of the package
- All items are for information: no Completed / Not Completed status (Eng. Hesham).
- Every upload slot keeps versions: the latest issue is shown and earlier ones stay traceable (OZOD Governance 3, document control). Added by Business Excellence Expert.
- A question on any item is a mention that opens a task to the BD (BR-06).
- The field list of each template is to be agreed with OZOD before the prototype screen is built.
Review workspace of the PM and the heads (1.03)
What each head sees and fills in his review task. The PM sees all heads' entries and consolidates them into one register.
| Section | Type on the system | Content | Note |
|---|---|---|---|
| Project information | Read only | The handover package of 1.01: templates, documents, initial risks and issues | Same view for every head. |
| Risks | Records in the Risk Log | New risks seen by the head | Tagged with the head and "1.03 Integrated Project Review". |
| Issues | Records in the Issue Log | New issues seen by the head | Tagged with the head and "1.03 Integrated Project Review". |
| Document comments | Comment linked to a document | A comment written as text, or an attached file (for example a Word file with highlights) | The head chooses text or file. |
| Confirm reviewed | Action | The head confirms he reviewed what concerns his discipline | Closes his task. |
| Kickoff task (BD Manager, 1.01) | Task form | Title, description, owner (any team member), reviewer or "no review", linked document (optional), due date, evidence on closing, review result (accepted / rejected with comment) | Mandatory task: 1.01 cannot close while it is open. |
| Ad-hoc task (PM) | Task form | Title, description, assignee (any team member), linked document (optional), due date | Due date mandatory. Available to the PM from 1.03 on. |
Site visit form (mobile)
What is recorded for every site visit, whatever its type.
| Section | Type on the system | Content | Note |
|---|---|---|---|
| Visit type | List (admin can extend) | Pricing study, pre-start, routine field | Chooses the checklist and the matrix row. |
| Owner (visitor) | User | Default from the matrix; changeable by the requester | |
| Due date | Date | Mandatory | The SLA runs on it. |
| Checklist | Per type | Items to answer on site, each with its evidence setting (none, optional, mandatory) | Given by OZOD; evidence setting in the configuration. |
| Evidence (photos) per item | Upload (mobile), several per item | Photos taken for each checklist item | Per item, from the configuration: none, optional or mandatory. The visit cannot be submitted while a mandatory evidence is missing. |
| Not required request | Reason (text) | Filled by the owner instead of the visit | Accepted or refused by the approver. |
| Decision | Approved / Revisit / Additional visit / Not required accepted | Set by the approver | Revisit needs a reason and a new due date. |
Gate criteria, default template (1.01 / 1.06)
Proposed by the system for every new project; the COO adjusts it in 1.01. Hard gate: must be met to start Planning. Carry-over: can be finished after the start.
| Output | Default | Note |
|---|---|---|
| Internal handover closed, PM and team assigned (1.01) | Hard gate | No team, no start. |
| Consolidated register, no Pending item (1.03) | Hard gate | The risks are understood and owned. |
| Pre-start site visit approved or accepted as not required (1.03) | Hard gate | The COO may change it to carry-over for a project. |
| Estimation budget approved by the CEO, or an approved partial budget for early works (1.05) | Hard gate | No spending without a ceiling. |
| Signed contract (1.02) | Carry-over | Allowed with a risk acceptance and commitment limits per DoA. |
| External handover (1.04) | Carry-over | |
| Estimation handover meeting held and PMO actions logged (1.05) | Carry-over | |
| Site handover minutes | Carry-over | Done when the site is handed over. |
Readiness pack (1.06)
Built by the system for the closure meeting and the COO's decision. Nobody types it.
| Section | Type on the system | Content | Note |
|---|---|---|---|
| Activity status board | Dashboard (automatic) | Each activity 1.01 to 1.05: Done / In progress / Not started / N/A, against the gate criteria set by the COO (hard gate or carry-over) | Read from the activities, not typed. |
| Register by status | View of the Risk & Issue Logs | Every item with its owner, mitigation and date, grouped Open / Pending / Closed / Accepted | Pending: no owner or no mitigation. |
| Site visit | Link | The pre-start visit with its checklist and photos | |
| Contract and budget | Status | Signed contract (1.02) and approved estimation budget handed over to the PMO (1.05): done or not | |
| Carry-over list | Proposed by the PM | Each unfinished item with owner, due date and the condition attached | Confirmed in the meeting. |
| Minutes and decision | Record | Closure meeting minutes, the readiness report and the COO's decision (Go / Go with conditions / Hold / No-go) with conditions and risk acceptance | Filled after the meeting. |
Business rules of the Initiation Stage
Agreed in the meeting of 13 October 2026 and in Eng. Hesham's answers the same day.
| ID | Subject | Rule |
|---|---|---|
| BR-01 | Roles | The COO assigns the PM. There is no Project Director role. |
| BR-02 | COO mandates | The COO is accountable for five mandates: Internal Handover, Contract Approval, External Handover, Estimation Budget and Initiation Closure; one decision in each. Outside them he follows SLAs and red flags. |
| BR-03 | Fallback | No PM yet: the PM's tasks go to the COO. |
| BR-04 | Gate criteria | For each project the COO sets, in 1.01, which stage outputs are hard gates (must be met to start Planning) and which are carry-over (can be finished after the start). The system proposes a default template (see Data Model); the COO adjusts it. |
| BR-05 | Handover package | Filled by the BD for information: templates, initial risk and issue records, and an upload slot per document type. No Completed / Not Completed status. |
| BR-06 | Questions on documents | A question is a mention on the document; it opens a task to the BD, who answers or adds the missing information. |
| BR-07 | Team and confirmation | On submission the COO and the default heads are notified. The COO assigns the PM and confirms the team: default heads come selected and he can deselect a head not engaged in Initiation. Every selected member confirms receipt. |
| BR-08 | Internal kickoff and closing 1.01 | Kickoff mandatory by default; the COO can decide "No need" with a reason. If needed, the BD schedules it and invites the COO, the PM and the selected heads. Only the COO closes 1.01, and only after every selected member confirmed receipt and every mandatory kickoff task is complete. |
| BR-09 | Kickoff tasks | After the kickoff the BD Manager records the actions of the minutes that must be done before the handover can close as mandatory tasks: owner, due date and reviewer (or "no review") mandatory. The owner completes the task with evidence (a document or a note); the reviewer accepts or rejects it with a comment; a "no review" task closes on completion. 1.01 cannot close while one of them is open. |
| BR-10 | External handover | Decided by the COO at the internal kickoff. Required: a task that must be done. Not required: closed as not required. |
| BR-11 | Heads and engineers | Technical Office, Procurement, Project Control and MEP heads are assigned by default; the COO can change them. A head can split his review into sub-tasks for his engineers. |
| BR-12 | Integrated review | Mandatory. Starts automatically when the COO closes 1.01: a review task for the PM and every selected head, and a site-visit task for the PM. Heads submit risks, issues and concerns in parallel; the raiser is the first owner. The PM consolidates one register with an owner, a mitigation and a date per item. |
| BR-13 | Ad-hoc tasks | From the Initiation stage on, the PM can create a task for any member of the project team. Every task needs an assignee and a due date; the system will not save a task without a due date. SLA tracking and escalation run on that date. |
| BR-14 | Readiness | The PM requests the gate review and gives the readiness report; only the COO decides: Go, Go with conditions, Hold or No-go. |
| BR-15 | Item status | Every register item is Open (owner, action, date), Pending (waiting for an owner or a mitigation), Closed, or Accepted (risk accepted by decision). No item leaves the closure meeting Pending. |
| BR-16 | Closure meeting | Called by the PM when ready, chaired by the COO, with the PM, the heads and the BD when items wait for him. It discusses every concern, agrees who closes it, and is documented on the system. |
| BR-17 | Commercial Committee | A fixed group in O1: CEO, CFAO, COO, PMO and BDD. It reviews the draft contract (1.02) and receives the estimation handover (1.05). Notifications and tasks go to the group. |
| BR-18 | Contract | The BD owns contract finalization; the Commercial Committee reviews the draft and gives feedback. The approval follows the DoA matrix; signed by the authorised signatory; shared with the project team. |
| BR-19 | Delegation of Authority | Every approval on the system (contract, budget, and later variations and purchases) follows a DoA matrix that OZOD sets and can change in the system: approver by type and value. No approver is fixed in the workflow. |
| BR-20 | Estimation budget | The BD Estimation Team prepares; the CEO approves (one approval; not approved: revised by the team). The approved budget returns to the team, is uploaded without the management reserve and is handed over to the Commercial Committee in a scheduled meeting that explains every assumption. Comments, risks and issues are recorded in the minutes; the Committee approves the minutes, which are handed over to the PMO, who acts on them and owns the budget from then on. It is the financial ceiling and the basis of the execution budget (2.06). Partial early-works budgets follow the same cycle. |
| BR-21 | Visibility | Everyone in the project sees the handover documents. Only the budget content meant to be seen is uploaded. |
| BR-22 | Risks and issues | Separate risk log and issue log. Every item has an owner, who is notified with the action required. Commitments to the owner of the project go in the issue log. Each item shows who identified it and in which activity. |
| BR-23 | Order | The activities have a flexible order and can run in parallel. The stage takes about 3 to 5 days. |
| BR-24 | Gate | The gate review needs only the hard gates; other activities may still be running. Go with conditions moves the project to Planning and keeps carry-over activities open with SLA and escalation; the stage shows Closed with conditions until the last one is done. Starting before the contract is signed needs a risk acceptance with commitment limits per DoA. Hold freezes the project. |
| BR-25 | Escalation | Hierarchical: PM, then COO, then CEO. |
| BR-26 | SLA | SLA values are set later and must be editable in the system by OZOD. |
| BR-27 | Project code and access | The BD sets the project code in O1 when he opens the project. The PMO opens the project on the ERP (ePromise) and enters the ERP project code in O1. Access rights follow the role. |
| BR-28 | Site visits | On the mobile app; the visit type chooses the checklist. The requester of a visit approves it; requester, default owner and approver per type are a setting (Visit matrix). Decisions: Approved, Revisit (reason and new due date), Additional visit. The owner can request "not required" with a reason; the approver accepts or refuses. The pre-start visit is done by the PM in 1.03 and approved by the COO; 1.03 cannot close until it is approved or accepted as not required. |
| BR-29 | Site handover minutes | A task opened when it is due. |
| BR-31 | Gate scope | 1.01 is not reopened once the COO has closed it. The upload slots of the handover package are not checked at the gate: a missing document does not count against 1.06. The gate looks only at the hard gates set by the COO (activities) and at the register of risks and issues. |
| BR-30 | Mobilization | Not part of the Initiation Stage: Mobilization Plan (Planning 2.03) and Site Mobilization (Execution 3.03). |
Consultant recommendations
Points where the agreed process carries a risk for OZOD. The diagrams show the process as agreed; these recommendations are not drawn in and need OZOD's decision.
| ID | Area | Finding | Risk if left as is | Recommendation | Decision by |
|---|---|---|---|---|---|
| REC-01 | COO workload | The COO has a decision in five mandates on every project, in a stage of 3 to 5 days. | The COO becomes the bottleneck of every new project; the stage SLA is missed. | Make each COO decision one click on the system (approve / return with comment), with an SLA and automatic escalation. No data entry by the COO. | COO |
| REC-02 | Budget vs contract | The estimation budget (1.05) is approved while the contract (1.02) may still be under negotiation. | If negotiation changes scope or price, the approved budget no longer matches the contract, and nothing sends it back. | Add a rule: any contract change after the budget approval re-opens the budget for the CEO, and the PMO is notified. | CEO, COO |
| REC-03 | Budget visibility | Only the content meant to be seen is uploaded; overhead, profit and reserve are removed by hand before the upload. | Two versions of the budget: the approved one sits outside the system. No single source of truth; manual errors. | Upload one complete budget and hide fields by role (field-level security). | CEO |
| REC-04 | Early activation | A project can be opened and spend money before the award letter, but there is no path if the award does not come. | Pre-award and awarded projects are mixed in reports; costs of lost bids are not settled. | Add a project status (Pre-Award, Awarded, Cancelled) and a "Not awarded" path that closes the project and settles its costs. | COO |
| REC-05 | Gate criteria | The COO sets hard gates and carry-over items for every project. | Without a default, each project gets a different standard and readiness cannot be compared across projects. | A default template by project type (see Data Model); the COO only adjusts it for a project, and each change is recorded with a reason. | COO |
| REC-06 | Handover minutes | OZOD output 3 asks for internal handover minutes with deficiencies, reservations, owners and due dates; the package now has no item status. | The output required by the policy has no source on the system. | The system builds the minutes from the kickoff minutes and the register: the deficiencies and reservations are the risks and issues with their owners and due dates, not the documents missing from the package. No one types them. | COO |
| REC-07 | Risk owners | Risks and issues from pricing (raised by the BD in 1.01) get their final owner only when the PM consolidates the register in 1.03. | Items raised by the BD have no operations owner until then. | The PM becomes the default owner of BD items as soon as he is assigned (heads' items already have the raiser as first owner). | COO |
| REC-08 | SLA | SLA values are left for later. | Escalation cannot run automatically without values; the prototype cannot show it. | Agree default values now (for example 1 working day per decision, 3 to 5 days for the stage), editable by OZOD later. | COO |
| REC-09 | Budget ownership | The COO is a member of the Commercial Committee that receives the estimation, but the handover meeting has no formal acceptance step. | Operations are measured against a budget they never formally accepted. | Record the COO's acceptance of the budget for Operations in the minutes of the handover meeting (no extra step, no extra meeting). | COO |
| REC-10 | Meetings | OZOD's document calls the 1.06 meeting "operation kickoff", next to the internal kickoff of 1.01. | Two "kickoffs": people expect actions and miss that 1.06 is a decision. | Name it "Initiation Closure Meeting": 1.01 hands over, 1.06 decides. Update the name in the policy. | COO |
| REC-11 | Policy alignment | The agreed process differs from OZOD's document: the project code is set by the BD in 1.01 (document: 1.03); engineers are assigned in Initiation (document: Resource Plan 2.02); the kickoff can be skipped by the COO. | The system and the policy disagree. | Update the policy document to match the agreed process. | OZOD policy owner |
| REC-12 | Delegation of Authority | OZOD has no DoA matrix. The document says approval and signing are "as per the authorities" in several activities. | Approvers get fixed in the workflow; every change in authority needs a system change; approvals by the wrong level. | Define a DoA matrix (approver by document type and value) and keep it as a setting in O1. Start with contracts and budgets; extend to variations and purchases. | CEO |
Open points and changes from WF-01
Still open (inputs from OZOD)
- Delegation of Authority (DoA) matrix: not yet available at OZOD; needed before the prototype shows approvals (REC-12).
- Authorised signatory of contracts: per OZOD's commercial registration or power of attorney.
- Field list of each handover template (project & scope, stakeholders, start requirements): to agree with OZOD.
- Checklists of each site-visit type: to be given by OZOD.
- Estimation budget template and its mapping to the ERP: with the BD Estimation Team and Eng. Adnan (Cost Control).
- ERP project code: entered by hand in O1 by the PMO for now; an automatic link between O1 and ePromise can come later (with Eng. Adnan).
- SLA values of each step: to be set by OZOD; the list of missing SLAs is under each activity (Business Excellence Queries). See REC-08 for defaults.
- Limits of commitments before the contract is signed: to be part of the DoA matrix.
What changes
- Rev-07 (23 Oct): 1.06 made explicit: the handover package is not checked again at the gate and a missing document is not a reason for Hold or No-go (BR-31); No-go means a hard gate not met; "Open questions to the BD" removed from the readiness pack; Pending covers only risks and issues without owner or mitigation; REC-06 clarified.
- Rev-06 (23 Oct): site visit evidence (photos) is attached per checklist item; each item is set in the configuration as no evidence, optional or mandatory; several photos per item; the visit cannot be submitted while a mandatory evidence is missing.
- Rev-06 (23 Oct): in 1.05 the team schedules the handover meeting; the system notifies the Commercial Committee to read the budget and assumptions before it; comments, risks and issues are recorded in the minutes (no separate step); the Committee approves the minutes, which are then handed over to the PMO with the budget.
- Rev-06 (23 Oct): in 1.05, after the CEO approval the budget returns to the BD Estimation Team, who uploads it without the management reserve.
- Rev-06 (23 Oct): in 1.02, after the negotiation the BD chooses: send the changed contract back to the Commercial Committee for review, or go on to the approval per the DoA.
- Rev-06 (23 Oct): in 1.01 each kickoff task gets a reviewer, or "no review". The reviewer accepts or rejects back to the owner with a comment; a "no review" task closes when the owner completes it.
- Rev-05: the Commercial Committee is defined: CEO, CFAO, COO, PMO, BDD. It reviews the contract (1.02) and receives the estimation (1.05).
- Rev-05: in 1.02 the draft contract is reviewed by the Commercial Committee (was the project team: PM and heads).
- Rev-05: in 1.01 the PMO is notified on submission and opens the project on the ERP (ePromise), then enters the ERP code in O1.
- Rev-05: in 1.01 the BD Manager turns the kickoff actions into mandatory tasks (owner and due date); the COO cannot close 1.01 until they are complete.
- Rev-05: 1.06 becomes a gate review. The COO sets hard gates and carry-over items per project in 1.01; the gate review needs only the hard gates; decisions Go, Go with conditions, Hold, No-go; carry-over activities stay tracked after the move to Planning.
- Rev-05: 1.05 has one CEO approval. The approved budget is handed over to the Commercial Committee in a meeting; comments, risks and issues go to the PMO, who owns the budget. The estimation sits under Business Development (BD Estimation Team).
- Rev-05: a visit owner can request "not required" with a reason; the approver accepts or refuses.
- Rev-05: site visits get an approver: the requester approves (matrix by visit type). The pre-start visit is approved by the COO, who can ask for a revisit or an additional visit.
- Rev-05: in 1.03 the PM reviews the package like the heads, and can give ad-hoc tasks to any team member; every task needs a due date.
- Rev-05: in 1.01 the COO confirms the team (default heads selected, can deselect) and closes the internal handover himself, only after every selected member confirmed receipt.
- Rev-04: 1.03 ends with one consolidated register (owner, mitigation, date per item). 1.06 has a readiness pack built by the system, a closure meeting chaired by the COO and three decisions: Go, Go with conditions, No-go.
- Rev-03: the handover package is for information, with no item status; questions go to the BD as tasks from the document. The COO decides whether the kickoff is needed (mandatory by default). The clarification meeting is removed.
- Rev-03: 1.03 starts automatically after 1.01 (review tasks for every head, site visit for the PM). The PM gives findings; only the COO decides readiness (1.06). Mandatory items are now the stage outputs.
- Rev-03: in 1.02 the approver lane is "Approver (per DoA)"; the signed contract is shared with the project team.
- Rev-02: the Project Director role is removed. The COO assigns the PM directly.
- Rev-02: the stage is framed around the COO's five mandates.
- WF-01 (Rev-03 and the Rev-04 drafts) was PCONDT's first reading. This draft replaces its "Create Project" and moves "Mobilization" out of the start of the project.
- New against WF-01: the internal kickoff, the document study, the pre-start site visit, the external handover, the estimation budget cycle and the readiness gate.
Sources: OZOD "Project Life Cycle Stages" (Initiation Stage 1.01 to 1.06); discovery meeting with OZOD on 13 Oct 2026; Eng. Hesham's answers in the chat of 13 Oct 2026.