Project Management

Introduction

Project management is the disciplined practice of turning an intended change into a defined result. A project is temporary, has a beginning and an end, and produces a unique product, service, or result. Project management applies knowledge, skills, tools, techniques, judgment, and leadership so that a team can meet project requirements and create useful outcomes.

At university level, project management is best understood as both a technical and a social discipline. You need to plan scope, time, resources, cost, quality, risk, and change, but you also need to make decisions under uncertainty, work with stakeholders, lead teams, communicate evidence, and connect the project to organizational strategy. Strong project managers do not simply follow a plan: they continuously compare intentions with reality and adapt responsibly.

The course uses examples from research, software, construction, public services, events, product development, and organizational change. As you work through it, imagine that you are managing a university project such as launching a student mental-health information service, organizing an international conference, developing a research prototype, or introducing a new digital learning platform.

Learning Goals

After completing this aiMOOC, you should be able to explain how projects differ from routine operations, formulate objectives and success criteria, analyze stakeholders, develop a work breakdown structure, construct and interpret schedules, assess project risks, compare predictive and adaptive delivery approaches, monitor performance, manage change, and close a project in a way that preserves learning and accountability.

You should also be able to justify project decisions rather than merely name tools. In professional practice, the central question is rarely "Which template should I fill in?" It is usually "What information do we need in order to make a responsible decision now?"

Foundations of Project Management

Projects, Operations, Programs, and Portfolios

A project is temporary and unique. By contrast, operations are ongoing and repetitive activities that sustain an organization, such as running payroll, maintaining a library system, or providing routine customer support. A project may create or improve an operational system, but once the temporary change effort ends, the continuing work becomes operations.

A program coordinates related projects and other activities so that benefits can be achieved together. A portfolio groups projects and programs to support strategic priorities and investment decisions. This distinction matters because a project can be well managed yet still be a poor strategic investment. Project success therefore includes both delivery performance and the value or benefit the organization expects from the result.

Project Life Cycles

A project life cycle describes the progression from idea to completion. Many projects pass through broadly recognizable activities: initiating, planning, delivering the work, monitoring and controlling, and closing. These activities may occur sequentially, overlap, or repeat depending on the chosen delivery approach.

In a predictive life cycle, important requirements and plans are developed relatively early. In an adaptive life cycle, teams learn through short cycles and refine the solution as information emerges. A hybrid life cycle combines elements of both. Choosing an approach is a form of tailoring: the management system should fit the project's uncertainty, technology, stakeholders, regulatory context, and risk profile.

Defining Value, Objectives, and Success

From Business Need to Project Charter

Projects should begin with a clear reason for existing. The initiating logic normally connects a problem or opportunity to intended outcomes, expected benefits, major assumptions, constraints, and decision authority. A project charter is commonly used to formalize this logic and authorize the project.

A useful charter is concise enough to guide decisions yet specific enough to prevent ambiguity. It may include the project purpose, measurable objectives, high-level scope, major risks, key stakeholders, milestones, assumptions, constraints, sponsor, project manager, and approval conditions. A charter is not a full plan; it is an agreement about why the project exists and who is empowered to lead it.

Objectives and Success Criteria

Good objectives describe an observable change rather than vague activity. "Create a new website" identifies a deliverable, but "reduce the average time students need to find scholarship information from five minutes to two minutes by the start of the next academic year" describes an intended outcome. The second formulation provides a basis for measurement.

Success criteria should be agreed before the team becomes emotionally attached to its chosen solution. Consider multiple dimensions: scope, schedule, cost, quality, stakeholder acceptance, safety, sustainability, legal compliance, learning, and benefits. Some criteria are thresholds; others require trade-offs.

The classic project management triangle illustrates the tension among scope, time, and cost. The model is useful as a conversation starter, but university-level analysis should go further: quality, risk, resources, benefits, ethics, and stakeholder expectations can also constrain decisions. A change in one area may create consequences elsewhere.

Stakeholders, Governance, and Decision Rights

Stakeholder Analysis

A stakeholder is a person, group, or organization that can affect the project, is affected by it, or perceives itself to be affected by it. Stakeholder analysis asks who matters, what they need, how much influence they have, what risks or opportunities they create, and how the project should engage them.

Do not confuse stakeholder management with persuasion. Ethical engagement includes listening, surfacing conflicts of interest, documenting decisions, and making participation meaningful. A stakeholder with little formal power may still carry critical knowledge or experience.

A simple engagement process is to identify stakeholders, analyze their interests and influence, plan communication and involvement, engage them, and review whether the relationship is changing. In controversial projects, you should also examine who is missing from the discussion.

Governance and Roles

Project governance defines how authority, oversight, escalation, assurance, and accountability work. Typical roles include the sponsor, project manager, steering group, team members, subject-matter experts, customers, users, suppliers, and assurance functions.

A project manager coordinates work and decisions but does not automatically own every decision. Clear decision rights prevent two common failures: decisions that no one feels authorized to make, and decisions made by people who do not understand their consequences. Responsibility-assignment techniques such as RACI can clarify who is responsible, accountable, consulted, and informed.

Scope and Requirements

Requirements and Boundaries

Scope defines what the project will deliver and, just as importantly, what it will not deliver. Requirements translate stakeholder needs into conditions or capabilities that the result must satisfy. Poorly defined boundaries make estimation, scheduling, quality assurance, and change control unreliable.

Requirements should be testable whenever possible. For a digital service, "easy to use" is ambiguous; a measurable usability criterion is more useful. Requirements can be functional, non-functional, regulatory, technical, operational, or transition-related.

Work Breakdown Structure

A work breakdown structure, or WBS, decomposes the total project scope into smaller, manageable components. It helps teams see the full body of work, assign ownership, estimate effort and cost, identify dependencies, and control changes.

A WBS should be oriented toward deliverables and complete enough to represent the agreed scope. The lowest level used for planning is often called a work package. Decomposition should stop when the team has enough detail to estimate, assign, monitor, and control the work without creating unnecessary administrative burden.

Scheduling and Dependencies

Activities, Dependencies, and Milestones

A schedule connects work to time. Begin by identifying activities needed to create the deliverables, then estimate durations and sequence the activities according to dependencies. Dependencies may be logical, technical, resource-based, contractual, or externally imposed.

A milestone is a significant point or event with no duration, such as approval of a prototype or completion of regulatory review. Milestones help communicate progress at a high level, but they do not replace the detailed logic required to understand how work reaches them.

Gantt Charts

A Gantt chart displays activities against time. It can show start and finish dates, durations, overlaps, milestones, progress, and sometimes dependencies. Gantt charts are powerful communication tools when the amount of detail matches the audience.

A schedule should not be treated as a decorative promise. If an activity slips, ask which successor activities are affected, whether float is consumed, whether resources can be reallocated, and whether the target date remains credible.

Network Logic and the Critical Path

A network diagram emphasizes the logical relationships among activities. In a conventional critical-path analysis, the critical path is the longest-duration path through the network and determines the earliest possible completion date under the stated assumptions. Activities on the critical path have no total float in the basic model, so delay to one of them can delay the project unless corrective action changes the schedule logic or duration.

The calculation is only as good as the assumptions. Uncertain durations, limited resources, external dependencies, and rework can make a deterministic schedule look more precise than reality. For complex projects, scenario analysis and probabilistic estimates may be more informative than one official date.

Cost, Resources, and Quality

Estimating and Budgeting

Cost management begins with realistic estimates. Common approaches include analogous estimation using comparable past work, parametric estimation using measurable relationships, bottom-up estimation based on detailed components, and three-point estimation that considers optimistic, most likely, and pessimistic cases.

A project budget should distinguish planned expenditure from contingency for identified uncertainty and, where organizational rules permit, management reserves for unknown-unknowns. Cost estimates should state assumptions, confidence, and exclusions. A precise-looking number without these explanations can mislead decision-makers.

Resource Management

Resources include people, equipment, facilities, materials, data, funding, and specialist services. A schedule that ignores resource availability may be logically correct but operationally impossible. Resource leveling can resolve over-allocation by changing dates; resource smoothing adjusts work within available float where possible.

Human resources require special care because people are not interchangeable units. Skills, motivation, cognitive load, communication overhead, working conditions, accessibility, and team continuity all affect delivery.

Quality Management

Quality means that outputs are fit for their intended purpose and conform to agreed requirements. Quality planning defines standards and acceptance criteria; quality assurance improves the processes used to produce the work; quality control checks whether outputs meet expectations.

Prevention is usually more efficient than late correction. Build reviews, tests, peer feedback, prototypes, and acceptance criteria into the work rather than relying on a final inspection at the end.

Risk and Uncertainty

Identifying and Assessing Risk

A project risk is an uncertain event or condition that may affect objectives. Risks can be negative threats or positive opportunities. Risk management therefore is not only about avoiding failure; it is also about making informed choices under uncertainty.

A risk register commonly records a risk description, cause, possible effect, owner, probability, impact, response, trigger, status, and residual exposure. Good risk statements are specific enough to support action. "Technology risk" is weak; "the external API may change before integration testing, causing rework and a four-week delay" is much more useful.

Qualitative assessment often uses probability and impact scales to prioritize attention. Quantitative analysis may use decision trees, sensitivity analysis, expected monetary value, or simulation. A heat map helps discussion, but it should not create false mathematical precision from subjective categories.

Risk Responses and Resilience

Threat responses may include avoiding the risk, reducing probability or impact, transferring part of the exposure, accepting it, or escalating it when it lies outside project authority. Opportunity responses may include exploiting, enhancing, sharing, accepting, or escalating.

A response is incomplete without an owner and a trigger. Resilience also requires contingency plans for events that occur despite preventive action. Regular risk reviews should search for new risks and retire risks that are no longer relevant.

Teams, Leadership, and Communication

Team Development

Project teams often work across disciplines, organizations, cultures, and time zones. Effective leadership creates clarity about goals and roles while enabling the people closest to the work to contribute their expertise. Psychological safety, constructive disagreement, and transparent escalation improve the quality of project decisions.

Conflict is not automatically a failure. Task conflict can reveal hidden assumptions when it is handled respectfully. The project manager should separate the issue from the person, identify interests behind positions, and select a resolution approach appropriate to urgency, stakes, and relationships.

Communication as a Management System

Communication should be designed around decisions, not merely around meetings. A communication plan can specify what information is needed, by whom, when, in what format, through which channel, and for what purpose.

Different stakeholders need different levels of detail. A technical team may need a dependency log and issue tracker; executives may need trends, exceptions, decisions, risks, and forecasts. A useful status report distinguishes facts, forecasts, assumptions, decisions required, and unresolved issues.

Predictive, Agile, and Hybrid Approaches

Predictive Delivery

Predictive approaches are useful when requirements can be defined with reasonable stability, major changes are expensive, and planning dependencies early creates value. Construction, regulated infrastructure, and hardware-heavy projects may contain significant predictive elements.

Predictive does not mean "never change." It means that the project establishes baselines and uses controlled change when new information justifies altering them.

Agile Values and Adaptive Delivery

Adaptive approaches are useful when uncertainty is high and frequent feedback can reduce the risk of building the wrong solution. The Agile tradition emphasizes people and collaboration, usable increments, customer involvement, and responsiveness to change.

Adaptive teams use short feedback cycles to inspect outcomes and adjust priorities. They still plan, estimate, manage risk, and communicate; they simply do so at a cadence that matches uncertainty.

Scrum

Scrum is a lightweight framework for complex work. The Scrum Guide defines a Scrum Team with three accountabilities: Product Owner, Scrum Master, and Developers. Work happens in fixed-length Sprints of one month or less, with events that support transparency, inspection, and adaptation.

Scrum artifacts are the Product Backlog, Sprint Backlog, and Increment. Each artifact has a related commitment: Product Goal, Sprint Goal, and Definition of Done. Scrum should not be reduced to a daily meeting or a task board; its purpose is empirical control of complex work.

Kanban and Flow

A Kanban system visualizes work and limits work in progress so that flow problems become visible. Teams can measure lead time, cycle time, throughput, and blocked work. Limiting work in progress encourages finishing rather than constantly starting.

Kanban can complement predictive or adaptive management. A team might use a predictive master schedule for external commitments while managing daily work through a flow-based board.

Hybrid Design

Many real projects are hybrid. For example, a university may use predictive milestones for procurement and governance while an internal software team uses Scrum to develop the digital product. The key is not to label the whole project with one fashionable method but to design coherent interfaces among different forms of work.

A hybrid system fails when teams use incompatible definitions of progress, unclear decision rights, or conflicting cadences. Integration points, acceptance criteria, and reporting conventions therefore require explicit design.

Monitoring, Control, and Change

Baselines and Performance Information

A baseline is an approved version of a plan used for comparison. Scope, schedule, and cost baselines help teams distinguish planned performance from actual performance. Monitoring gathers data; control interprets the data and decides whether action is needed.

Useful indicators can include milestone achievement, schedule variance, cost variance, defect trends, risk exposure, cycle time, forecast completion, resource utilization, and benefit measures. Choose metrics that support decisions. A dashboard with many numbers but no management action is not control.

Change Control

Change is inevitable, but unmanaged change can destroy accountability. A change-control process records the proposed change, analyzes effects on scope, schedule, cost, quality, risk, resources, benefits, and contracts, identifies decision authority, records the decision, and updates the relevant baselines and communication.

Not every project requires a heavy change-control board. Tailor the process to the project's size and risk. The principle is traceability: stakeholders should be able to understand what changed, why it changed, who approved it, and what consequences were accepted.

Issues and Escalation

A risk is uncertain; an issue has already occurred or is currently occurring. Issue management records the problem, impact, owner, due date, action, and escalation path. Delaying escalation because a team fears bad news often increases damage.

Effective escalation is not blame. It provides the information and authority needed to resolve a problem that cannot be handled at the current level.

Closing, Benefits, and Organizational Learning

Project Closure

Closing verifies that agreed work has been completed or formally terminated, obtains acceptance where appropriate, closes contracts and financial records, transfers deliverables to operations or users, archives essential information, releases resources, and documents unresolved obligations.

A project can also be closed early when its business case no longer makes sense. Stopping a low-value project can be a sign of strong governance rather than failure, provided the decision is evidence-based and responsibly managed.

Lessons Learned and Benefits

Lessons learned should capture both what happened and why. Useful lessons are specific, transferable, and connected to future action. "Communicate better" is weak; "include the laboratory manager in procurement planning because installation constraints were discovered six weeks late" is actionable.

Benefits may emerge after the project team has disbanded, so ownership for benefit measurement should be assigned to an operational or business role. The project manager should help establish the transition, but long-term value often belongs to the organization that receives the deliverable.

Ethics, Sustainability, and AI in Projects

Ethical Project Leadership

Project decisions affect people, resources, communities, and environments. Ethical project leadership includes honesty in reporting, responsible handling of confidential information, avoidance of conflicts of interest, respect for affected stakeholders, accessibility, and attention to unintended consequences.

Pressure to meet a deadline does not justify concealing a safety concern or manipulating performance data. When objectives conflict with legal, professional, or ethical obligations, the project manager must escalate rather than normalize the problem.

Sustainability and Systems Thinking

Sustainable project management considers more than short-term delivery. Ask how materials, energy, labor conditions, accessibility, maintainability, and long-term operating impacts affect the project's value. A deliverable that is cheap to build but expensive to maintain can shift costs rather than create value.

Systems thinking helps you examine feedback loops and indirect effects. A change that optimizes one subsystem can damage the wider system if dependencies are ignored.

Artificial Intelligence in Project Work

AI tools can support activities such as summarizing meetings, identifying patterns in issue logs, generating draft plans, comparing scenarios, and assisting with documentation. They can also introduce hallucinations, bias, privacy risks, intellectual-property concerns, security risks, and overconfidence.

Treat AI output as evidence to evaluate, not authority to obey. Use human review for consequential decisions, protect sensitive data, document important assumptions, and verify generated facts against trusted sources. Good project governance applies to AI-supported work just as it does to other tools.

Reference Frameworks and Further Reading

The following sources are useful starting points for deeper study and for checking terminology against recognized professional or primary sources:

Project Management Institute: What Is Project Management provides a concise professional overview of projects and project management.
PMBOK Guide: PMI PMBOK Guide provides a broad reference framework for contemporary project management practice.
Agile software development: Manifesto for Agile Software Development states the original Agile values and links to the supporting principles.
Scrum: The Scrum Guide is the primary definition of the Scrum framework.

A Practical Project Management Workflow

For a medium-complexity university project, a coherent workflow might look like this:

Project charter: Clarify the problem, desired outcomes, authority, constraints, sponsor, and initial risks.
Stakeholder analysis: Identify affected groups, decision-makers, users, partners, and sources of expertise.
Requirements engineering: Define what the result must achieve and how acceptance will be judged.
Work breakdown structure: Decompose the scope into manageable deliverables and work packages.
Project scheduling: Sequence activities, estimate durations, identify milestones, and analyze dependencies.
Risk management: Record uncertainty, prioritize exposure, assign owners, and prepare responses.
Resource management: Confirm people, skills, equipment, funding, and capacity.
Project communication: Design reporting and engagement around decisions.
Change control: Assess and authorize changes with traceable consequences.
Project closure: Transfer deliverables, confirm acceptance, capture learning, and assign benefit ownership.

The workflow is not a universal recipe. Tailor it. A six-week student research project should not carry the same administrative burden as a national infrastructure program, but both still need clear objectives, responsible decisions, and evidence of progress.

Interactive Tasks

Quiz: Test Your Knowledge

Which statement best distinguishes a project from routine operations? (A project is temporary and creates a unique result) (!A project repeats the same process indefinitely) (!A project has no defined objective) (!A project never affects operations)

What is the main purpose of a project charter? (To authorize the project and establish its high-level direction) (!To record every daily task completed by the team) (!To replace all later planning and scheduling) (!To calculate only the final project cost)

What does a work breakdown structure primarily decompose? (The total project scope into manageable components) (!The organization into permanent departments) (!The budget into accounting years) (!The stakeholder list into communication channels)

What does the critical path determine in a basic network schedule? (The earliest possible project completion based on the longest-duration path) (!The stakeholder with the greatest authority) (!The cheapest sequence of project activities) (!The number of people required for the project)

Which statement describes a milestone? (A significant project point or event with no duration) (!A recurring operational task) (!A person who approves project funding) (!A cost estimate with contingency)

What is the correct distinction between a risk and an issue? (A risk is uncertain while an issue has already occurred or is occurring) (!A risk is always positive while an issue is always negative) (!A risk concerns cost while an issue concerns schedule) (!A risk belongs to the sponsor while an issue belongs to the team)

Which practice is central to Kanban? (Limiting work in progress to improve flow) (!Fixing all requirements before work begins) (!Eliminating visual management) (!Assigning all decisions to one manager)

Which set contains the three Scrum accountabilities? (Product Owner Scrum Master Developers) (!Sponsor Project Manager Auditor) (!Customer Architect Controller) (!Manager Analyst Supplier)

Why are baselines useful in project control? (They provide an approved reference for comparing planned and actual performance) (!They prevent every future change) (!They guarantee that estimates are correct) (!They remove the need for forecasting)

What is the most responsible use of AI in project management? (Use AI output with human review and verification for consequential decisions) (!Treat generated output as automatically correct) (!Upload all confidential project data without checking policy) (!Replace stakeholder consultation with generated summaries)

Memory Game

Charter	Formal authorization and high-level direction for a project
Milestone	Significant project point or event with no duration
Baseline	Approved plan version used as a reference for comparison
Backlog	Ordered list of work or needs to be addressed
Contingency	Planned allowance or response for identified uncertainty
Sponsor	Senior role that supports the project and provides organizational authority
Deliverable	Verifiable product service or result produced by project work
Retrospective	Structured reflection used to improve future team performance

Drag and Drop

Match the correct terms.	Topic
Project charter	Authorizes the project and states high-level intent
Work breakdown structure	Decomposes scope into manageable components
Risk register	Records uncertainty ownership assessment and responses
Gantt chart	Displays project activities against time
Lessons learned register	Captures experience for future use

...

Crossword Puzzle

Charter	What document formally authorizes a project and states its high-level direction?
Stakeholder	What do you call a person or group that can affect or be affected by a project?
Milestone	What significant project point has no duration?
Baseline	What approved plan version is used as a reference for performance comparison?
Backlog	What ordered list contains work or needs to be addressed in adaptive delivery?
Retrospective	What meeting or activity reflects on completed work to improve future performance?

LearningApps

Cloze Text

A project is a temporary endeavor that creates a unique

. A project

establishes high-level direction and authorization. A

can affect or be affected by the project. A work breakdown structure decomposes the agreed

into manageable components. A

marks a significant point with no duration. The longest-duration path in a basic network schedule is the

. A project

represents uncertainty that can affect objectives. An approved reference plan is called a

. Scrum uses short fixed-length cycles called

. Responsible AI use requires human

of important outputs.

Open-Ended Tasks

Easy

Project charter exercise: Choose a small university project and create a one-page charter containing purpose, objective, sponsor, major deliverables, assumptions, constraints, and three initial risks.
Stakeholder map: Draw a stakeholder map for a campus event and explain in 250 words why different groups need different forms of engagement.
Gantt chart practice: Create a simple Gantt chart for a four-week group assignment, show dependencies and milestones, and write a short reflection on what the chart reveals.
Project manager interview: Interview a student leader, researcher, event organizer, or professional who has managed a project and summarize three practical lessons from the conversation.

Standard

Risk workshop: Facilitate a 30-minute risk-identification session for a real or simulated project, produce a risk register, and justify the three highest-priority responses.
Process video: Produce a three-minute explainer video that compares predictive, adaptive, and hybrid delivery using one concrete project example.
Kanban experiment: Manage a team assignment with a Kanban board for at least one week, limit work in progress, collect simple flow data, and evaluate whether the limit changed team behavior.
Site visit analysis: Visit a construction site, laboratory, makerspace, event venue, library service, or other project environment with permission and document visible evidence of planning, safety, coordination, quality, and stakeholder needs.

Advanced

Integrated project plan: Develop an integrated plan for a semester-long interdisciplinary project including charter, WBS, schedule, resource assumptions, budget, risk register, governance, communication, quality criteria, and change process.
Critical path scenario: Build a network schedule for a project with at least ten activities, calculate the critical path, test two delay scenarios, and recommend management action based on the results.
Project governance case study: Analyze a failed or controversial public project using reliable sources, identify governance and stakeholder problems, and propose a redesigned decision and escalation structure.
AI project management audit: Evaluate how a project team could use generative AI for planning and reporting, identify privacy, bias, verification, intellectual-property, and accountability risks, then design a human-in-the-loop governance protocol.

Learning Assessment

Project trade-off analysis: Given a sponsor request to add major scope without changing budget or deadline, analyze at least three response options and justify the most responsible recommendation.
Stakeholder conflict assessment: Compare the interests and power of five stakeholders in a contested campus project and design an engagement strategy that is both practical and ethically defensible.
Schedule recovery assessment: Diagnose a delayed project using dependency information, resource constraints, and milestone commitments, then propose a recovery plan and explain its new risks.
Risk reasoning assessment: Evaluate a risk register that contains vague or poorly prioritized entries, rewrite the risks as cause-event-effect statements, and defend revised priorities.
Method tailoring assessment: Choose predictive, adaptive, or hybrid delivery for a complex project case and justify the choice using uncertainty, feedback speed, regulation, technology, and stakeholder needs.
Closure and transfer assessment: Design a closure plan for a digital service project that addresses acceptance, operations handover, unresolved issues, lessons learned, benefit ownership, and evidence retention.

Evidence of Learning

Knowledge evidence includes accurate understanding of project purpose, life cycles, governance, scope, scheduling, cost, quality, risk, stakeholders, adaptive delivery, monitoring, change, and closure.

Skill evidence includes the ability to formulate measurable objectives, build a WBS, analyze dependencies, interpret a Gantt or network schedule, prioritize risks, design stakeholder engagement, facilitate team decisions, communicate performance, and justify tailored methods.

Product evidence can include a charter, stakeholder map, project plan, WBS, schedule, budget, risk register, Kanban board, status report, change request, closure report, or reflective portfolio.

Transfer evidence is strongest when you can apply project-management reasoning to a new domain, explain trade-offs under uncertainty, revise plans when evidence changes, and connect delivery decisions to ethics, strategy, sustainability, and long-term value.

OERs on the Topic

For an open overview, explore the English Wikipedia article on project management and follow its links to related concepts such as the Gantt chart, critical path method, risk management, Agile software development, and Scrum.

Linked Learning Areas

Project Management

aiMOOC Projects