Project and Program Management

01Purpose and scope

• This manual supports the course Project and Program Management. It describes how the work is actually done in organizations that run temporary efforts to create a defined result, and how those efforts are grouped and steered when several projects must deliver a shared outcome.
• A project is a temporary effort with a defined start, a defined end, and a specific deliverable or set of deliverables. A program is a group of related projects and supporting activities managed together so that the combined benefit is greater than managing each project alone. Most practitioners spend more time on the coordination, decision, and communication parts of this work than on the technical content of any single deliverable.
• The manual covers the main activities, decisions, deliverables, stakeholders, tools, roles, and indicators that appear across most sectors. It does not teach a specific software product, and it does not replace the methodology your organization has adopted. Where your employer, client, or funding body requires a particular framework or approval path, that requirement governs.
• Practice changes with context. A small internal software update, a building construction job, a public infrastructure program, and a clinical research study all use the same vocabulary but differ in how much formal documentation, approval, and audit trail they need. Where a project touches regulated activity, legal contracts, public funds, or safety, the guidance here does not replace qualified professional judgment, approved procedures, or any required authorization.

02Core principles

• Start with the outcome, not the activity list. Before any schedule is built, the sponsor and key stakeholders should agree in writing on what success looks like, who will use the result, and how that use will be observed. A deliverable that is finished on time but never adopted is a failed project in most sponsors' eyes.
• Keep scope, time, cost, and quality visible together. Changing one usually affects the others, and a project team that negotiates scope in private will be surprised later. Make trade-offs explicit in a decision log so the sponsor sees what was given up and why.
• Manage by exception at the program level. A program manager cannot read every task update. A workable pattern is to receive short, consistent status from each project, look closely at anything that has crossed a threshold, and leave routine work with the project manager who owns it.
• Treat assumptions and dependencies as first-class items. Most schedule failures trace back to an assumption nobody wrote down, such as a vendor delivering in a given week, a regulator reviewing within a set period, or a team member being available for six months. Record each one with an owner and a date for verification.
• Decide who decides. Every decision needs a named owner with the authority to make it. Ambiguous decision rights are a leading cause of delay, and they are usually fixed by a short responsibility matrix agreed early.

03Planning and preparation

• Begin with a business case or project charter. The document should state the problem, the proposed solution, the expected benefits, the major constraints, the estimated cost range, and the options considered. Keep it short enough that the sponsor will read it. Two to six pages is typical for a mid-sized project, though the right length depends on the size of the investment and the governance expected.
• Identify stakeholders early and sort them by influence and interest. Interview the people who will use the output, the people who will be affected by it, and the people who can stop it. Record their requirements in their own words, then confirm them back to each person. Requirements gathered from only the sponsor often miss the operational detail that determines whether the result works.
• Build a work breakdown structure before estimating. Break the scope into deliverables, then decompose each deliverable into work packages small enough to assign to one person or team and to estimate with reasonable confidence. Estimates should carry ranges, and the basis for each estimate should be written beside it. Expert judgment, analogous estimates from past work, and parametric models each have appropriate uses, and each has limits.
• Set up governance before work starts. Decide the reporting cadence, the steering group membership, the change control process, the escalation path, and the approval thresholds for spending and scope. For a program, define how the portfolio of projects will be prioritized and how benefits will be owned after each project closes.
• Choose tools that match the team. A shared task board, a schedule tool, a risk register, a document repository, and a decision log cover most needs. A single shared workspace is usually better than a collection of personal files, but avoid building a system so detailed that people stop updating it.

04Recommended workflow

1. 1
   : Confirm initiation. Obtain formal authority to proceed from the sponsor, usually through a signed charter or approval record. Name the project manager, the sponsor, and the core team. Do not begin detailed spending until this step is complete.
2. 2
   : Define scope and success measures. Draft the scope statement, list what is excluded, and write the acceptance criteria for each major deliverable. Agree on the measures that will show the benefit, such as cycle time reduction, error rates, or adoption percentages, and note who will collect them and when.
3. 3
   : Build the schedule and cost baseline. Sequence the work packages, identify the critical path, assign resources, and add reserves for uncertainty. Present the baseline to the steering group for approval. Once approved, changes to the baseline go through change control rather than being edited directly in the plan.
4. 4
   : Execute and manage the work. Hold a short daily or twice weekly coordination meeting with the delivery team, depending on the pace of the work. Track progress against the baseline using completed work rather than reported percentage complete alone, since percentages often stall at 90 percent for weeks.
5. 5
   : Monitor risks, issues, and changes. Review the risk register at each steering meeting, update probability and impact, and confirm that responses have owners. Separate risks that may happen from issues that have already happened. Route change requests through the agreed impact assessment, showing effects on scope, schedule, cost, and risk before a decision is made.
6. 6
   : Verify and accept deliverables. Test each deliverable against its acceptance criteria, record the results, and obtain formal acceptance from the named receiver. Partial acceptance is common and should be recorded with the conditions attached.
7. 7
   : Close, transfer, and review. Transfer ownership of outputs to operations or the client, release resources, close contracts, archive records, and hold a lessons learned review. For a program, confirm that benefits tracking has been handed to a named owner before the program is formally closed.

05Quality checks, risk controls and compliance

• Quality planning should specify how each deliverable will be checked, by whom, and against what standard. Peer review,测试 or inspection, user acceptance testing, and independent audit are different controls with different costs. Choose the level that matches the consequence of failure. A low-risk internal report needs a reviewer and a checklist. A system that handles payment data or patient records needs documented test evidence and sign-off from the people accountable for that risk.
• Risk controls work best when they are specific. A risk entry should name the cause, the event, and the effect, for example: because the data migration vendor has not confirmed its staffing, the cutover may slip by two weeks, delaying retirement of the old system. Each risk should have a owner, a rating, a response such as avoid, reduce, transfer, or accept, and a trigger that tells the owner to act.
• Compliance depends heavily on jurisdiction and sector. Privacy obligations, procurement rules for public bodies, safety standards for construction, financial reporting requirements, and export controls can all apply to a project. Identify the applicable obligations during planning, assign an owner for each, and confirm current requirements with the organization's legal, compliance, or safety function and the current authoritative source. This manual does not establish legal requirements for any jurisdiction.
• Where a project affects health, safety, financial reporting, or legal rights, the project team should not treat this guidance as a substitute for qualified professional judgment, approved procedures, or required sign-off. Those approvals stay with the people and bodies assigned to them.
• Well-known frameworks can inform these controls. The PMI body of knowledge describes risk and quality management processes, and ISO 21500 offers high-level project management guidance. Both should be applied with judgment to the actual context rather than copied as a checklist.

06Collaboration and documentation

• Good project documentation is short, current, and findable. The essential set usually includes the charter, the scope statement, the baseline plan, the risk and issue registers, the decision log, the change log, the stakeholder register, meeting minutes with actions, and the acceptance records. Each document should name its owner and its last update.
• The decision log deserves particular attention. Record the decision, the date it was made, the options considered, the person who decided, and the reason. Teams that keep this log avoid reopening the same question every few months, and new members can understand why the project looks the way it does.
• Collaboration across functions requires agreed interfaces. When a software team depends on a procurement group, a training team, and an operations unit, each dependency should have a named contact and an agreed handoff format. Many delays come from work being finished in one group and sitting unread in another group's queue.
• For programs, a single integrated view matters more than any single project plan. The program office maintains the interdependency map, the consolidated risk view, the benefits register, and the combined milestone schedule. Project managers keep their own plans but feed consistent data upward on a fixed schedule.
• Document in the language of the audience. A steering group needs decisions, options, and exposure. A delivery team needs task detail and acceptance criteria. Avoid burying a decision request inside a twelve-page status report.

07Measures and continuous improvement

• Choose a small set of indicators that reflect the project's success, not just its activity. Common project measures include the percentage of work packages completed against the baseline, schedule variance and cost variance in both amount and percentage, the number of open high-rated risks, the count and age of unresolved issues, and the number of approved changes compared with those rejected. For programs, add benefits realized against the business case, the percentage of projects on or ahead of their baseline, and the combined spend against the authorized budget.
• Indicators need definitions. Write down how each is calculated, which data source it comes from, how often it is updated, and the threshold that triggers a review. A measure without a definition will be interpreted differently by each reader.
• Use earned value only where the team understands it and the work is measurable. Earned value management can give a consistent view of cost and schedule performance on large, well-defined work, but it is harder to apply to exploratory or highly uncertain work. Where it is not appropriate, use simpler measures with clear definitions.
• Improvement comes from reviewing the evidence. At each phase boundary and at close, compare the baseline with what happened, identify the causes of the largest variances, and record the changes that would help the next team. Lessons that are not written into a template, checklist, or standard tend to disappear when the people involved move on.
• Be cautious about benchmarks. Published productivity figures and success rates vary widely by sector, method, and reporting definition. Compare your own project history first, and treat external figures as context rather than targets.

08Common mistakes and how to prevent them

• Starting delivery before the scope is agreed is the most common mistake. Teams build something, then discover that the sponsor expected something else. Prevent it by requiring signed acceptance criteria before the baseline is approved, and by making any later scope change pass through change control with a visible cost.
• Treating the schedule as a promise rather than a forecast causes trouble when dates slip without warning. Update the forecast every reporting cycle using actual progress and known remaining work, and show the sponsor the effect on the end date as soon as it changes.
• Letting risks sit in a register without owners or triggers is another frequent failure. A risk list reviewed once a quarter does not manage anything. Review open high-rated risks at each steering meeting, and retire risks that no longer apply so the list stays useful.
• Overloading the status report hides the important points. Lead every report with the three or four items that need a decision or attention, then provide the supporting detail behind them. Keep the routine material in an appendix that readers can consult when needed.
• Assuming that a program will deliver benefits because its projects delivered outputs is an error with real consequences. Assign a benefits owner in the business who is accountable for the change in operations, and measure that change after the project has closed.

09Practical checklist

• Confirm written authority, named sponsor, project manager, and core team before major spending begins.
• Record the problem, expected benefits, constraints, and the options considered in the charter or business case.
• Agree scope, exclusions, and acceptance criteria for each major deliverable with the receiving party.
• Build a work breakdown structure and estimate each work package with a stated basis and range.
• Set the reporting cadence, steering group membership, change control route, and escalation thresholds.
• Keep the risk register current, with a cause, effect, owner, response, and trigger for each entry.
• Log every significant decision with options, decision maker, date, and reason.
• Identify applicable legal, safety, privacy, and procurement obligations and assign an owner for each.
• Review the schedule forecast and cost forecast at every reporting cycle and show the effect of any change.
• Confirm formal acceptance of each deliverable before releasing resources or closing the related work.
• Transfer benefits ownership to a named business owner and set a date to review realized benefits.
• Hold a lessons learned review and update templates and standards with the findings.

10Stakeholder and sponsor roles

• The sponsor owns the business case and approves major decisions. The project manager plans, directs, and reports on day-to-day delivery and manages the team within agreed limits. A program manager coordinates several projects, manages interdependencies, and reports consolidated status and benefits. Each role should have a written description so that gaps and overlaps are visible early.
• Functional managers often control the people the project needs. Agree resource commitments in writing, including the percentage of time each person will give and the period it covers. Resource conflicts between projects are normally resolved by the program or portfolio governance group, not by the project manager alone.

★Learning sources

• Micro Degree: Project and Program Management
• Micro Degree: Leadership and Team Management
• Micro Degree: Business Intelligence Management
• Micro Degree: ESG Advisory Services