Project governance, PMOs and compliance

In its first quarter, 21 of the scholarship portal’s 22 decisions waited for a steering committeesteering committee: The group, chaired by the sponsor, that directs a project for the organisation: it decides at stage gates and on anything beyond the sponsor's tolerance, and speaks for the users and suppliers the project depends on. that met once a month. A decision waited 15.2 days on average, six waited more than three weeks, and work behind the three blocking decisions stood still for 60 days in all. Nobody on the project was slow; the way it was governed was.

Governance is the part of a project that settles who may decide what, on what evidence and when. You will set it up for an invented project, a state higher education department’s online scholarship portal for college and university students: the bodies that decide, the rules that keep big decisions few and quick, the kind of PMOPMO: Project management office: a unit that sets and supports how an organisation's projects are run, through methods, templates, reporting and training, and sometimes by managing the projects itself. that suits the department, and the compliance work, India’s data protection law included, that a project plans like any other scope.

Governance decides who decides, on what evidence and when

Three organisations have a stake in almost every decision on the portal. The higher education department pays for it and answers for the scholarships; the state IT agency hosts it and lends the project its lead; 2,300 colleges must check their students’ applications before any money moves. Without written governance, each disagreement between them becomes a meeting, and each meeting waits for the most senior person who might object.

Project governanceproject governance: The framework of bodies, rules and evidence that directs a project: who may decide what, on what evidence and when, and where a decision goes when it is too big for the person who meets it. is the framework of bodies, rules and evidence that directs a project: who may decide what, on what evidence, how often, and where a decision goes when it is too big for the person who meets it. Management is the work done inside those decisions: planning, assigning, tracking and correcting. A project lead manages; the governance around the lead says what the lead may decide alone. PMI’s 2026 examination outline opens its business environment domain with governance. It asks a project manager to set up the structure, rules, procedures, reporting, ethics and policies, to define success metrics, and to outline escalation paths with their thresholds. The PMBOK Guide addresses governance within the environment a project runs in, and its eighth edition expands its coverage of the PMO.

Step through the portal’s governance, one body at a time, and watch the route a decision takes when it outgrows the project lead:

The map separates three jobs that projects often blur. The bodies that decide are the steering committee, the sponsorsponsor: The person who answers for a project's business case, issues its charter and decides when the charter must change; someone with authority over the money the project needs. More in “Writing a project charter with clear objectives” and the lead. The body that checks is assurance, independent of the lead. The body that makes evidence comparable is the PMO, which decides nothing on this project. Because the sponsor chairs the committee, one person answers for the whole.

The committee’s rules are written in its terms of reference: who sits on it, what it decides, how often it meets, its quorum, and the evidence it expects for each kind of decision. How single decisions are routed by their cost and delay is the subject of RACI charts, decision rights and escalation; governance sets the frame those decision rights sit in.

Stage gates and tolerances keep the board on the big decisions

The portal’s first charter gave the project lead almost no room. Any change above 50 thousand rupees, or any change that moved go-live by a single day, waited for the monthly committee. The program below replays the quarter’s 22 decisions under that charter (design A) and under written tolerances (design B), and counts how long each one waited:

"""How long the scholarship portal's decisions waited, under two ways of governing the same project.

The portal is an invented state-government project: a higher education department builds an online scholarship
application for college and university students. In its first quarter (days 1 to 91) the project raised the 22
decisions below. Each has an extra cost in thousand rupees, a delay to go-live in days, and two flags: `policy` (it
changes a public commitment, such as who is eligible, so no tolerance covers it) and `blocking` (work stops until it
is decided).

Design A, as first chartered: the project lead may decide only a change that costs at most 50 thousand and moves
nothing; every other decision waits for the steering committee, which meets on days 30, 60 and 90 (and next on day
120).

Design B, with written tolerances: the project lead decides within 200 thousand and 5 days; the sponsor decides within
1,000 thousand and 15 days, 2 days after the lead's exception report; everything larger, and every policy decision,
goes to the committee's monthly meeting, except that a blocking decision gets a short extra committee call 5 days
after it is raised.

A decision taken by the project lead waits 1 day. The program prints each decision's route and wait under both designs,
then the totals per level and the average and longest waits.
"""

LEAD_A = (50, 0)            # (thousand rupees, days) the lead may decide under design A
LEAD_B = (200, 5)           # design B: the project lead's tolerance
SPONSOR_B = (1000, 15)      # design B: the sponsor's tolerance
MEETINGS = (30, 60, 90, 120)
LEAD_WAIT, SPONSOR_WAIT, EXTRA_CALL = 1, 2, 5

# (id, decision, cost in thousand rupees, delay in days, raised on day, policy, blocking)
DECISIONS = [
    ("D01", "OTP login for applicants", 40, 0, 3, False, False),
    ("D02", "Extra load test before launch", 120, 0, 5, False, False),
    ("D03", "SMS templates in two languages", 15, 2, 8, False, False),
    ("D04", "Second site for backups", 900, 0, 11, False, False),
    ("D05", "Income check through state API", 300, 10, 12, False, False),
    ("D06", "External accessibility audit", 180, 3, 15, False, False),
    ("D07", "Replace the vendor's test lead", 0, 4, 19, False, True),
    ("D08", "Dashboard for college principals", 650, 12, 22, False, False),
    ("D09", "Encrypt bank details per field", 220, 6, 27, False, False),
    ("D10", "Drop the paper application route", 0, 0, 33, True, False),
    ("D11", "Helpline for rejected applicants", 450, 0, 36, False, False),
    ("D12", "Fix duplicate-application bug", 30, 3, 40, False, True),
    ("D13", "Pilot in two districts first", 0, 7, 44, False, False),
    ("D14", "Vendor's new report pack", 380, 4, 47, False, False),
    ("D15", "Bigger SMS budget for reminders", 60, 0, 52, False, False),
    ("D16", "One more week of user testing", 140, 7, 58, False, False),
    ("D17", "Rebuild upload service (pen test)", 1400, 20, 61, False, True),
    ("D18", "Documents in state data centre", 500, 9, 66, False, False),
    ("D19", "Parental consent flow for minors", 260, 8, 70, False, False),
    ("D20", "Change the income ceiling", 0, 0, 74, True, False),
    ("D21", "Training videos for college staff", 90, 0, 81, False, False),
    ("D22", "Go-live moves by three weeks", 700, 21, 86, False, False),
]


def next_meeting(day):
    """The first committee meeting on or after `day`."""
    return next(m for m in MEETINGS if m >= day)


def within(cost, delay, limit):
    return cost <= limit[0] and delay <= limit[1]


def design_a(cost, delay, day, policy, blocking):
    if not policy and within(cost, delay, LEAD_A):
        return "lead", LEAD_WAIT
    return "committee", next_meeting(day) - day


def design_b(cost, delay, day, policy, blocking):
    if not policy and within(cost, delay, LEAD_B):
        return "lead", LEAD_WAIT
    if not policy and within(cost, delay, SPONSOR_B):
        return "sponsor", SPONSOR_WAIT
    wait = next_meeting(day) - day
    if blocking:
        wait = min(wait, EXTRA_CALL)
    return "committee", wait


def main():
    results = {"A": [], "B": []}
    print(f"{'id':<4}{'decision':<35}{'cost':>5}{'days':>5}  {'design A':<14}{'design B':<14}")
    for did, name, cost, delay, day, policy, blocking in DECISIONS:
        a = design_a(cost, delay, day, policy, blocking)
        b = design_b(cost, delay, day, policy, blocking)
        results["A"].append(a)
        results["B"].append(b)
        mark = " (policy)" if policy else (" (blocking)" if blocking else "")
        print(f"{did:<4}{name:<35}{cost:>5}{delay:>5}  {a[0]:<9}{a[1]:>3}d  {b[0]:<9}{b[1]:>3}d{mark}")
    print()
    for design in ("A", "B"):
        rows = results[design]
        levels = {}
        for level, wait in rows:
            levels.setdefault(level, []).append(wait)
        parts = ", ".join(f"{lvl} {len(w)}" for lvl, w in sorted(levels.items()))
        waits = [w for _, w in rows]
        over_three_weeks = sum(1 for w in waits if w > 21)
        print(f"Design {design}: {parts}")
        print(f"  average wait {sum(waits) / len(waits):.1f} days, longest {max(waits)} days, "
              f"{over_three_weeks} waited more than three weeks, {sum(waits)} decision-days in all")
    blocked_a = sum(w for (lvl, w), d in zip(results["A"], DECISIONS) if d[6])
    blocked_b = sum(w for (lvl, w), d in zip(results["B"], DECISIONS) if d[6])
    print(f"Blocking decisions: work stopped {blocked_a} days under A, {blocked_b} days under B")


if __name__ == "__main__":
    main()

id  decision                            cost days  design A      design B      
D01 OTP login for applicants              40    0  lead       1d  lead       1d
D02 Extra load test before launch        120    0  committee 25d  lead       1d
D03 SMS templates in two languages        15    2  committee 22d  lead       1d
D04 Second site for backups              900    0  committee 19d  sponsor    2d
D05 Income check through state API       300   10  committee 18d  sponsor    2d
D06 External accessibility audit         180    3  committee 15d  lead       1d
D07 Replace the vendor's test lead         0    4  committee 11d  lead       1d (blocking)
D08 Dashboard for college principals     650   12  committee  8d  sponsor    2d
D09 Encrypt bank details per field       220    6  committee  3d  sponsor    2d
D10 Drop the paper application route       0    0  committee 27d  committee 27d (policy)
D11 Helpline for rejected applicants     450    0  committee 24d  sponsor    2d
D12 Fix duplicate-application bug         30    3  committee 20d  lead       1d (blocking)
D13 Pilot in two districts first           0    7  committee 16d  sponsor    2d
D14 Vendor's new report pack             380    4  committee 13d  sponsor    2d
D15 Bigger SMS budget for reminders       60    0  committee  8d  lead       1d
D16 One more week of user testing        140    7  committee  2d  sponsor    2d
D17 Rebuild upload service (pen test)   1400   20  committee 29d  committee  5d (blocking)
D18 Documents in state data centre       500    9  committee 24d  sponsor    2d
D19 Parental consent flow for minors     260    8  committee 20d  sponsor    2d
D20 Change the income ceiling              0    0  committee 16d  committee 16d (policy)
D21 Training videos for college staff     90    0  committee  9d  lead       1d
D22 Go-live moves by three weeks         700   21  committee  4d  committee  4d

Design A: committee 21, lead 1
  average wait 15.2 days, longest 29 days, 6 waited more than three weeks, 334 decision-days in all
Design B: committee 4, lead 8, sponsor 10
  average wait 3.6 days, longest 27 days, 1 waited more than three weeks, 80 decision-days in all
Blocking decisions: work stopped 60 days under A, 7 days under B

Under design A the committee took 21 of the 22 decisions, and a decision waited 15.2 days on average. Under design B the lead took 8, the sponsor 10 and the committee 4; the average wait fell to 3.6 days, and blocking work stood still for 7 days instead of 60. One decision still waited 27 days, and it should have: dropping the paper application route changes a public promise to students, which no tolerance covers.

Two tools did that work. A tolerancetolerance: The deviation from plan, in cost, time or another measure, that a level may absorb or decide on without referring it up; a decision beyond it goes to the next level. is the deviation from plan that a level may absorb or decide on without going up: here 200 thousand rupees and 5 days for the lead, and 1,000 thousand and 15 days for the sponsor. Tolerances can be set on scope, quality, risk and benefits as well as on cost and time, and some are zero. Management by exceptionmanagement by exception: A way of directing a project in which each level decides within its tolerance and reports up only when a forecast breaks it, so senior people see only the decisions that need them. is the rule that comes with them. A level reports up only when a forecast breaks its tolerance, and then at once, with an exception reportexception report: A short report sent up when a forecast breaks a tolerance: what happened, the options with their cost and delay, and a recommendation for the level that must decide.: what happened, the options with their cost and delay, and a recommendation.

Tolerances handle what goes wrong between decisions. A stage gatestage gate: A planned decision point at the end of a stage where a governance body decides, on evidence, whether the project goes on, goes on with conditions, holds or stops. is the decision planned in advance: at the end of each stage the committee decides, on a pack of evidence, whether the project has earned the next stage. Step through the gate at the end of the portal’s build stage:

The four endings matter as much as the gate itself. A gate that can only say go is a review, while one that can hold or stop protects the money the next stage would spend. Methods use their own names for the same pattern: PRINCE2 7 sets out seven principles, seven practices and seven processes that take a project from initiation to closure, and the UK government’s GovS 002 standard sets expectations for how portfolios, programmes and projects are directed and managed. Whatever the method, look for the same three things: decisions at planned points, written limits for each level, and a route for exceptions.

Three kinds of PMO hold different amounts of control

The department set up a PMO when the portal began, and within a month two of its project leads asked it for opposite things. One wanted templates and a coach; the other wanted it to stop asking for weekly reports. Both requests were reasonable, because they were asking for different kinds of PMO.

A PMO, or project management office, is a unit that sets and supports how an organisation’s projects are run: methods, templates, reporting and training, and sometimes the project managers themselves. Earlier editions of PMI’s PMBOK Guide sort PMOs into three kinds by the degree of control they hold:

• A supportive PMOsupportive PMO: A PMO that offers templates, training, advice and lessons from earlier projects but requires little, so it holds a low degree of control over projects. offers templates, training, advice and lessons from earlier projects, and requires little.
• A controlling PMOcontrolling PMO: A PMO that supports projects and also requires them to follow its methods, templates, reporting rules and gate reviews, so it holds a moderate degree of control. also requires projects to follow its methods, its templates, its reporting rules and its gate reviews.
• A directive PMOdirective PMO: A PMO that manages projects directly: the project managers are its staff and report to it, so it holds a high degree of control. manages the projects itself, and their managers are its staff.

Real PMOs vary more than three labels suggest. In a study published by PMI, Brian Hobbs and Monique Aubry analysed 500 survey responses about PMOs and listed 27 functions a PMO may hold. The group of functions rated most important was monitoring and controlling project performance, at 3.82 on a five-point scale, ahead of methods and competencies at 3.54 and multi-project management at 3.23. A PMO is defined by what it is asked to do, so its mandate deserves to be written down. Which kind fits depends on the organisation; answer the three questions in the table for your own:

For the department, the auditor’s question decides it. Every scholarship project must bring the committee the same gate evidence, so a supportive PMO is ruled out, and the project leads stay in their own directorates, so a directive PMO is ruled out too. A controlling PMO, with one gate pack and one status rule, fits. A PMO that serves a programme or a whole portfolio does the same work one level up, which Programmes, portfolios and OKRs takes further.

Compliance is scope with owners, evidence and dates

Twelve weeks in, the portal’s compliance work looked finished to anyone who had not counted it. The department had a consent noticeconsent notice: The notice given before asking for consent to use personal data, saying what data will be processed and why, and how the person can withdraw consent and complain., a contract with its system integrator, a CERT-In contact and an accessibility audit booked. The program below checks the project’s register at its status date of week 12:

"""Checks the scholarship portal's compliance register at the status date of week 12.

The portal is an invented state-government project (see escalation.py). Its compliance register lists each condition
the project must meet because a law, a direction, a standard, a contract or a department policy says so, with the
category it belongs to, its source, the one person who owns it, the evidence that will show it is met, the week it is
due and whether that evidence has been accepted.

The check does what a compliance plan asks: every category the brief names has at least one row; every row has an
owner, an evidence item and a due week; and the share of rows already due whose evidence is accepted measures how far
the project is in compliance today. Sources are named the way the lesson cites them (DPDP Act 2023 and Rules 2025,
CERT-In directions of 2022, WCAG 2.2). Week numbers count from the start of the project.
"""

STATUS_WEEK = 12
REQUIRED = ["data protection", "security", "data residency", "accessibility", "records",
            "health and safety", "sustainability", "audit"]

# (id, requirement, category, source, owner, evidence, due week, evidence accepted)
REGISTER = [
    ("C01", "Consent notice in English and the state language", "data protection", "DPDP Act s.5",
     "data protection contact", "notice text and screen test", 10, True),
    ("C02", "Decide how applicants under 18 are handled", "data protection", "DPDP Act s.9, Rules",
     "data protection contact", "legal view and flow test", 12, False),
    ("C03", "Processor contract with the system integrator", "data protection", "DPDP Act s.8(2)",
     "procurement officer", "signed contract clause", 4, True),
    ("C04", "Breach procedure: tell students and the Board", "data protection", "DPDP Act s.8(6)",
     "", "rehearsal record", 14, False),
    ("C05", "Answer access and correction requests in 90 days", "data protection", "DPDP Rules 2025",
     "helpdesk lead", "request log design", 16, False),
    ("C06", "Report cyber incidents to CERT-In within 6 hours", "security", "CERT-In directions",
     "vendor security lead", "runbook and registered contact", 8, True),
    ("C07", "Fix high findings of the penetration test", "security", "department policy",
     "state IT agency", "retest report", 18, False),
    ("C08", "Keep system logs for 180 days inside India", "data residency", "CERT-In directions",
     "vendor operations lead", "", 12, False),
    ("C09", "Application form meets WCAG 2.2 level AA", "accessibility", "WCAG 2.2",
     "UX lead", "external audit report", 15, False),
    ("C10", "Erase personal data once its purpose ends", "records", "DPDP Act s.8(7)",
     "records officer", "retention schedule", None, False),
    ("C11", "Safe halls and first aid at enrolment camps", "health and safety", "college safety policy",
     "district coordinators", "camp checklist", 11, True),
    ("C12", "Audit trail of every eligibility decision", "audit", "state finance rules",
     "finance officer", "sample of the audit log", 9, True),
]


def main():
    print(f"Register at week {STATUS_WEEK}: {len(REGISTER)} rows")
    print(f"{'id':<4}{'category':<18}{'owner':<24}{'due':>4}  evidence")
    gaps = []
    for rid, text, category, source, owner, evidence, due, accepted in REGISTER:
        due_text = f"w{due}" if due is not None else "-"
        state = "accepted" if accepted else ("not yet" if evidence else "none named")
        print(f"{rid:<4}{category:<18}{(owner or '-'):<24}{due_text:>4}  {state}")
        missing = [name for name, value in (("owner", owner), ("evidence", evidence), ("due week", due)) if not value]
        if missing:
            gaps.append(f"{rid} {text}: no {' and no '.join(missing)}")
    print()
    covered = {row[2] for row in REGISTER}
    for category in REQUIRED:
        if category not in covered:
            gaps.append(f"category '{category}': no requirement listed")
    print(f"Gaps ({len(gaps)}):")
    for gap in gaps:
        print(f"  {gap}")
    complete = sum(1 for row in REGISTER if row[4] and row[5] and row[6] is not None)
    print()
    print(f"Rows complete (owner, evidence, due week): {complete} of {len(REGISTER)}")
    print(f"Categories covered: {len(covered & set(REQUIRED))} of {len(REQUIRED)}")
    due_now = [row for row in REGISTER if row[6] is not None and row[6] <= STATUS_WEEK]
    accepted = [row for row in due_now if row[7]]
    open_rows = [row[0] for row in due_now if not row[7]]
    print(f"Due by week {STATUS_WEEK}: {len(due_now)} rows, evidence accepted for {len(accepted)} "
          f"({100 * len(accepted) / len(due_now):.0f} %); still open: {', '.join(open_rows)}")


if __name__ == "__main__":
    main()

Register at week 12: 12 rows
id  category          owner                    due  evidence
C01 data protection   data protection contact  w10  accepted
C02 data protection   data protection contact  w12  not yet
C03 data protection   procurement officer       w4  accepted
C04 data protection   -                        w14  not yet
C05 data protection   helpdesk lead            w16  not yet
C06 security          vendor security lead      w8  accepted
C07 security          state IT agency          w18  not yet
C08 data residency    vendor operations lead   w12  none named
C09 accessibility     UX lead                  w15  not yet
C10 records           records officer            -  not yet
C11 health and safety district coordinators    w11  accepted
C12 audit             finance officer           w9  accepted

Gaps (4):
  C04 Breach procedure: tell students and the Board: no owner
  C08 Keep system logs for 180 days inside India: no evidence
  C10 Erase personal data once its purpose ends: no due week
  category 'sustainability': no requirement listed

Rows complete (owner, evidence, due week): 9 of 12
Categories covered: 7 of 8
Due by week 12: 7 rows, evidence accepted for 5 (71 %); still open: C02, C08

It finds four gaps that no status report showed. The breach procedure has no owner, the log-retention row names no evidence, the erasure rule has no due week, and sustainability, a category the project brief names, has no row at all. Nine of the 12 rows are complete, and of the 7 rows due by week 12, 5 have accepted evidence: the project is 71 % in compliance today, a number the committee can follow from gate to gate.

A compliance requirementcompliance requirement: A condition a project must meet because a law, a regulator's direction, a standard, a contract or the organisation's own policy requires it. is a condition the project must meet because a law, a regulator’s direction, a standard, a contract or the organisation’s own policy requires it. A compliance registercompliance register: A list of a project's compliance requirements, each with its category, its source, one owner, the evidence that will show it is met, a due date and whether that evidence is accepted. lists each one with its category, its source, one owner, the evidence that will show it is met and a due date. PMI’s 2026 outline describes the work in steps that the register records:

• Confirm the requirements; the outline’s own examples are security, health and safety, sustainability and regulatory compliance.
• Classify them into categories and find the threats to each.
• Choose the methods that support them, and analyse what non-compliance would cost.
• Decide the actions, then measure how far the project complies.

On a software project, add accessibility (the W3C’s WCAG 2.2, usually at level AA), records and their retention, audit trails, and the places where data and logs may be stored. Treat every row as scope. On an agile team it becomes a backlog item with acceptance criteriaacceptance criteria: The conditions a deliverable must meet before it can be accepted, written so that any result is a clear pass or a clear fail. More in “Quality planning, assurance and control” that name the evidence, for example “the notice appears in English and the state’s language before any field is filled, and the screen test is attached”, so it is planned, built and finished like any other item instead of in a launch-week scramble.

A register is only as good as its weakest row, and a row without an owner is the one that fails quietly.

India’s DPDP law turns personal data into a workstream

Each year the portal collects names, phone numbers, bank details, marks and income certificates from about 120,000 students, and some first-year students are 17. In India that brings the department under the Digital Personal Data Protection Act, 2023, and the DPDP Rules, 2025, which give organisations an eighteen-month period to come into compliance in phases.

The Act names three roles. The data fiduciarydata fiduciary: Under India's DPDP Act 2023, the person or organisation that decides, alone or with others, why and how personal data is processed, and answers for that processing. decides why and how personal data is processed: here the department. The data principaldata principal: Under India's DPDP Act 2023, the individual the personal data is about; for a child, the parent or lawful guardian is included. is the person the data is about: each student, and for a child the parent or lawful guardian as well. A data processordata processor: A person or organisation that processes personal data on behalf of another, which under India's data protection law may be engaged only under a valid contract. processes the data on the fiduciary’s behalf, here the system integrator, and may be engaged only under a valid contract. For a project, the Act and the Rules turn into work items:

• A lawful ground for each purpose: consent given after a notice, or one of the legitimate uses in section 7, one of which covers the State providing a subsidy or benefit under the conditions the Act sets.
• A consent notice that says what data is processed and why, how to withdraw consent and how to complain to the Data Protection Board, available in English or a language of the Constitution’s Eighth Schedule; the Rules ask for a separate notice in plain words.
• Withdrawal that is as easy as giving consent, and erasure once the purpose is served, unless a law requires the data to be kept.
• Verifiable consent of a parent or lawful guardian before a child’s data is processed, a child being anyone under 18, unless one of the Rules’ exceptions applies; the summary of the Rules names healthcare and education among them.
• Reasonable security safeguards, including for processing done by the processor.
• A procedure for a personal data breachpersonal data breach: Under India's DPDP Act 2023, any unauthorised processing of personal data, or its accidental disclosure, use, change, destruction or loss of access, that harms its confidentiality, integrity or availability. that tells the Board and each affected person.
• A published contact for questions, a way to settle grievances, and answers to access, correction and erasure requests within ninety days.

A breach procedure is real only once it has been rehearsed. Step through the portal’s drill, from the vendor’s alert to the people who must be told:

The drill met a second law on the way. CERT-In’s 2022 directions ask service providers, data centres, companies and government organisations to report the listed cyber incidents within 6 hours of noticing them, so two clocks start from the same alert, and the plan has to name who starts each one.

Plan the work from the first week. Each duty becomes a row of the compliance register with an owner and evidence, a backlog item with acceptance criteria, and a line in the gate pack before go-live. The DPDP compliance checklist walks through the same areas, and the decision about under-18 applicants goes in the decision log with the legal view behind it.

Practise

Every question below comes from the portal: its committee and sponsor, its 22 decisions, its PMO, its register and its students’ data. Settle on an answer first, then check it:

Interview questions

Interviews for project lead and PMO roles test governance by asking for distinctions first and judgement after. Two distinctions, answered:

Warm-up: how does project governance differ from project management?

Governance is the frame and management is the work inside it. Governance settles who may decide what, on what evidence, how often and where a decision goes when it is too big: the sponsor, the steering committee, the stage gates, the tolerances and the reports they rely on. Management plans, assigns, tracks and corrects the work within those limits, and that is the project lead’s job. A quick test is to ask who could stop the project: the answer is a governance body, never the lead. When the two blur, a lead takes decisions beyond the lead’s authority or a committee starts managing tasks, and both slow the project down.

Warm-up: what separates supportive, controlling and directive PMOs?

The control each one holds over projects. A supportive PMO advises, with templates, training and lessons from earlier projects, and suits experienced leads on varied work. A controlling PMO also requires compliance with its methods, gate packs and status rules, and suits organisations whose board or auditor needs the same evidence from every project. A directive PMO manages the projects itself, with the project managers on its staff, and suits the few critical projects that leadership wants run centrally. None of the three takes the board’s decisions; a PMO makes the evidence comparable for the people who decide.

The next two ask for judgement under pressure, on cases unlike the portal’s:

Key takeaways

• Governance settles who may decide what, on what evidence and when; management does the work inside those decisions, and a sponsor who chairs the steering committee keeps one person answerable for the whole.
• Tolerances let the lead and the sponsor decide inside written limits, and management by exception sends up only the forecasts that break them; on the portal that cut the average wait for a decision from 15.2 days to 3.6.
• A stage gate is a planned decision on evidence that can end in go, go with conditions, hold or stop, and a gate that can only say go is a review.
• Supportive, controlling and directive PMOs hold rising amounts of control; choose by the evidence the organisation needs and by who should employ the project managers.
• Compliance is scope: each requirement has one owner, named evidence and a due date in a register, and the share of due rows with accepted evidence measures it.
• India’s DPDP Act and Rules give a data fiduciary work to plan: notices and consent, children’s data, safeguards at processors, erasure, breach notice to the Board and the people affected, and answers to requests within ninety days.