IT Project Governance & PMBOK
The formal project management body of knowledge. Essential for managing client-facing IT projects, writing proposals, and communicating with large enterprise clients who speak this language. Complements Agile with formal governance structures.
What is PMBOK?
PMBOK = Project Management Body of Knowledge. Published by PMI (Project Management Institute). Now in its 7th edition (2021).
PMP = Project Management Professional certification. Recognized globally, required by many large enterprises and government contracts.
PMBOK defines a project as:
“A temporary endeavor undertaken to create a unique product, service, or result.”
Key characteristics:
- Temporary: has a defined start and end
- Unique: produces something that hasn’t existed before
- Progressive elaboration: details become clearer as the project progresses
PMBOK 7th Edition — 12 Principles
The 7th edition shifted from process-based to principles-based (more compatible with Agile):
- Stewardship: act responsibly for the organization and stakeholders
- Team: build a high-performing, collaborative team
- Stakeholders: engage stakeholders proactively
- Value: focus on delivering value, not just completing tasks
- Systems thinking: see the project as part of a larger system
- Leadership: lead by example, motivate, empower
- Tailoring: adapt the approach to the context (no one-size-fits-all)
- Quality: build quality in throughout, not just inspect at the end
- Complexity: manage uncertainty and complexity with adaptive approaches
- Risk: embrace risk proactively (opportunities AND threats)
- Adaptability: be ready to change course as learning occurs
- Change: enable and manage organizational change
The 5 Process Groups (PMBOK 6th edition framework, still widely used)
INITIATING → PLANNING → EXECUTING → MONITORING & CONTROLLING → CLOSING
↑ │
└────────────────────────────────────────┘
(feedback loops)
| Process Group | Key activities |
|---|---|
| Initiating | Project charter, stakeholder identification, business case |
| Planning | Scope, schedule (WBS, Gantt), budget, risk plan, communication plan |
| Executing | Build, manage team, procure, engage stakeholders |
| Monitoring & Controlling | Track progress, manage changes, control scope/schedule/cost |
| Closing | Formal acceptance, lessons learned, archive |
10 Knowledge Areas (PMBOK 6th edition)
| Knowledge Area | Key deliverables |
|---|---|
| Integration | Project charter, project plan, change control |
| Scope | WBS, scope statement, scope validation |
| Schedule | Gantt chart, critical path, milestone schedule |
| Cost | Budget, cost estimates, earned value |
| Quality | Quality plan, quality metrics, QA/QC |
| Resource | Resource plan, RACI, team development |
| Communications | Communications plan, status reports |
| Risk | Risk register, risk responses |
| Procurement | Make/buy decisions, contracts, vendor selection |
| Stakeholder | Stakeholder register, engagement plan |
The Project Charter — Starting Any IT Project Formally
The Project Charter is the document that formally authorizes a project and gives the PM authority to apply resources. It is the output of the Initiating process group.
Contents:
PROJECT CHARTER
Project Name: [e.g., NOTQIN IEIA Pilot — Textile Factory X]
Date: YYYY-MM-DD
Project Manager: Ahmed Ben Ahmed
Sponsor: [Factory Director or internal]
─────────────────────────────────────────────────────
PURPOSE / BUSINESS CASE
Why are we doing this? What problem does it solve?
What is the expected business value?
─────────────────────────────────────────────────────
OBJECTIVES (SMART)
1. Deploy IEIA to monitor 8 looms by Month 1
2. Achieve 80% anomaly detection precision by Month 2
3. Deliver CBAM compliance report by Month 3
─────────────────────────────────────────────────────
HIGH-LEVEL SCOPE
IN SCOPE:
- Physical sensor installation (8 machines)
- IEIA platform deployment (cloud)
- 3-month data collection and model tuning
- Monthly energy report and CBAM data
OUT OF SCOPE:
- PLC reprogramming
- Factory network infrastructure changes
- Regulatory filing (client responsibility)
─────────────────────────────────────────────────────
MILESTONES
M1 (Week 2): Sensors installed, data flowing
M2 (Week 4): IEIA deployed, baseline anomalies detected
M3 (Week 8): Model tuned, 80% precision achieved
M4 (Week 12): Final report + pilot review meeting
─────────────────────────────────────────────────────
BUDGET (HIGH LEVEL)
Hardware: MAD X
Cloud hosting: MAD Y
Ahmed's time (N days × MAD Z/day): MAD W
Total: MAD T
─────────────────────────────────────────────────────
RISKS (HIGH LEVEL)
R1: Factory network incompatibility (High/High)
R2: Client data access delays (Medium/High)
─────────────────────────────────────────────────────
STAKEHOLDERS
Factory Director (Sponsor) | Plant Manager (Key User)
IT Manager (Gatekeeper) | Ahmed (PM + Technical Lead)
─────────────────────────────────────────────────────
APPROVALS
Sponsor: ___________ Date: ________
PM: ___________ Date: ________
Work Breakdown Structure (WBS)
The WBS decomposes project scope into manageable packages. The fundamental rule: 100% rule — the WBS must represent 100% of the work scope.
SMARTEX IEIA PILOT
├── 1. Project Management
│ ├── 1.1 Project charter
│ ├── 1.2 Weekly status reports
│ └── 1.3 Final project report
│
├── 2. Hardware & Installation
│ ├── 2.1 Sensor procurement
│ ├── 2.2 Network assessment
│ ├── 2.3 Physical installation
│ └── 2.4 Connectivity test
│
├── 3. Platform Deployment
│ ├── 3.1 Cloud environment setup
│ ├── 3.2 IEIA backend deployment
│ ├── 3.3 Dashboard configuration
│ └── 3.4 MQTT → InfluxDB pipeline validation
│
├── 4. Data Collection & Modeling
│ ├── 4.1 Baseline data collection (30 days)
│ ├── 4.2 Anomaly model training
│ ├── 4.3 Model validation (precision/recall)
│ └── 4.4 CBAM data mapping
│
├── 5. Reporting & Handoff
│ ├── 5.1 Monthly energy reports (3×)
│ ├── 5.2 CBAM compliance report
│ ├── 5.3 User training
│ └── 5.4 Pilot review presentation
│
└── 6. Acceptance & Closing
├── 6.1 Client sign-off
├── 6.2 Lessons learned document
└── 6.3 Contract/invoice closure
WBS Dictionary: for each WBS element, document: description, owner, deliverable, acceptance criteria, effort estimate, dependencies.
Critical Path Method (CPM)
Used in schedule management. Identifies the sequence of tasks that determines the minimum project duration.
Terms:
- Activity: a task with a duration
- Dependency: A must finish before B can start (FS = Finish-to-Start, most common)
- Critical Path: the longest path through the network = project duration (no float)
- Float/Slack: how much a non-critical activity can slip without delaying the project
- Early Start (ES) / Late Start (LS): earliest/latest an activity can start
- Early Finish (EF) / Late Finish (LF): earliest/latest an activity can finish
Float = LS – ES = LF – EF Critical path: activities where Float = 0
Applied: In a NOTQIN pilot, sensor hardware procurement (3 weeks lead time) and factory network access (2 weeks to coordinate) may be on the critical path. Delay either = project delay.
Earned Value Management (EVM)
The most rigorous project performance measurement system. Tracks schedule and cost performance simultaneously.
Key Values
| Acronym | Name | Meaning |
|---|---|---|
| PV | Planned Value | Budgeted cost of work scheduled (what we planned to spend by now) |
| EV | Earned Value | Budgeted cost of work performed (value of work actually completed) |
| AC | Actual Cost | Actual cost of work performed (what we actually spent) |
| BAC | Budget at Completion | Total project budget |
Key Indicators
| Metric | Formula | Interpretation |
|---|---|---|
| CV (Cost Variance) | EV − AC | Positive = under budget, Negative = over budget |
| SV (Schedule Variance) | EV − PV | Positive = ahead of schedule, Negative = behind |
| CPI (Cost Performance Index) | EV / AC | > 1.0 = efficient, < 1.0 = over budget |
| SPI (Schedule Performance Index) | EV / PV | > 1.0 = ahead, < 1.0 = behind |
| EAC (Estimate at Completion) | BAC / CPI | Forecast of final project cost |
| ETC (Estimate to Complete) | EAC − AC | Remaining cost to finish |
| VAC (Variance at Completion) | BAC − EAC | Over/under budget forecast at end |
EVM Example
A 3-month project, budget = MAD 30,000. By end of Month 2:
- PV (should have spent): MAD 20,000
- EV (value of work done): MAD 15,000
- AC (actually spent): MAD 18,000
CV = EV − AC = 15,000 − 18,000 = −3,000 (over budget ⚠️)
SV = EV − PV = 15,000 − 20,000 = −5,000 (behind schedule ⚠️)
CPI = 15,000 / 18,000 = 0.83 (spending MAD 1.20 for every MAD 1.00 of value)
SPI = 15,000 / 20,000 = 0.75 (completing 75% of planned work)
EAC = 30,000 / 0.83 = MAD 36,145 (project will cost ~20% more than planned)
Change Control Process
On formal projects (especially enterprise clients), changes to scope/schedule/cost must go through a structured process:
Change Request submitted by [anyone]
↓
Impact Analysis (PM estimates effect on scope/schedule/cost/risk)
↓
Change Control Board (CCB) review — approve / reject / defer
↓
If APPROVED: Update project plan, communicate to team
If REJECTED: Document decision, explain to requestor
↓
Implement and monitor change
Why this matters for you: when a factory client says “can you also add a production line monitoring dashboard?” during the IEIA pilot, this is a scope change request. Without change control, scope creep kills margins and delays delivery.
Agile vs PMBOK — Reconciliation
| Dimension | PMBOK (Predictive) | Agile | When to use which |
|---|---|---|---|
| Requirements | Fully defined upfront | Emergent, refined each sprint | PMBOK for fixed-scope enterprise contracts; Agile for product development |
| Planning | Detailed, front-loaded | Rolling wave, just-in-time | Agile for internal products; PMBOK for client-facing projects with fixed budget |
| Change | Controlled, formal process | Embraced, flexible | Agile always; PMBOK on contract work |
| Reporting | Formal (EVM, status reports) | Lightweight (burndown, velocity) | PMBOK for executive/client reporting; Agile for team tracking |
| Risk | Upfront risk register | Continuous, embedded in retrospectives | Both |
Hybrid approach (most practical for you):
- Use PMBOK artifacts for client-facing governance (charter, scope doc, risk register, status reports)
- Use Agile internally (sprints, DoD, retrospectives, velocity)
- Communication to clients: PMBOK language
- Internal execution: Agile methods
Project Closure — Often Skipped, Always Valuable
Formal project closure includes:
- Formal acceptance: client signs off that deliverables meet acceptance criteria
- Lessons learned session: what went well, what to improve (keep as a note)
- Financial closure: final invoices, budget reconciliation
- Knowledge transfer: documentation, handover to operations
- Team recognition: acknowledge contributions
- Archive: store all project artifacts for future reference
Lessons Learned template:
Project: [Name]
Date: YYYY-MM-DD
PM: Ahmed
WHAT WENT WELL
1. [...]
2. [...]
WHAT TO IMPROVE
1. [...]
2. [...]
SURPRISES / UNEXPECTED
1. [...]
RECOMMENDATIONS FOR NEXT PROJECT
1. [...]
METRICS
- Planned duration vs. actual:
- Planned budget vs. actual:
- Scope changes: N change requests
- Client satisfaction (NPS): X/10
The IT Proposal Structure (for selling formal projects)
When responding to an RFP or writing a pilot proposal (e.g., AMEE, CRI, OCP):
1. EXECUTIVE SUMMARY (1 page)
→ Problem we're solving, our solution, expected ROI, our qualifications
2. UNDERSTANDING OF THE PROBLEM (1–2 pages)
→ Show you understand their context, pain, and constraints
3. PROPOSED SOLUTION (2–3 pages)
→ Technical approach, architecture, methodology (reference Agile or PMBOK as appropriate)
4. WORK PLAN / PROJECT SCHEDULE (1 page)
→ WBS, milestones, Gantt chart
5. TEAM & QUALIFICATIONS (1 page)
→ Ahmed's profile, relevant projects, ENSA affiliation
6. REFERENCES & CASE STUDIES (1 page)
→ NOTQIN pilot results, SijiLab deployment, NILM research papers
7. PRICING & TERMS (1 page)
→ Itemized budget, payment schedule, acceptance criteria
8. APPENDICES
→ Technical specs, architecture diagram, CVs, legal docs
Key PMI Terms for Enterprise Conversations
| Term | Meaning |
|---|---|
| Program | Group of related projects managed together for strategic benefit |
| Portfolio | Collection of programs and projects aligned with strategic objectives |
| PMO (Project Management Office) | Department that defines and maintains project management standards |
| Governance | Framework of rules and practices directing project decisions |
| SOW (Statement of Work) | Document describing what work will be performed under a contract |
| RFP (Request for Proposal) | Formal document soliciting proposals from vendors |
| SLA (Service Level Agreement) | Contractual commitment on service performance (uptime, response time) |
| OBS (Organizational Breakdown Structure) | Hierarchy of project team roles |
| RAM (Responsibility Assignment Matrix) | RACI for project deliverables |
See Also
- Modern Management Overview
- Agile & Scrum
- Stakeholder & Risk Management in IT
- NOTQIN Pilot Playbook
- Coordinator OS/07 — Cash & Runway
- Coordinator OS/08 — Decision Log
- PRD Template