01 · What Is Project Management?¶
A project is a temporary endeavor with a defined start and end, undertaken to create a unique product, service, or result. That's the whole definition, and every word in it matters: "temporary" rules out ongoing operations (running a factory floor is not a project; installing a new production line is), "unique" rules out repetitive output (a bakery's daily bread run is not a project; designing a new product line for that bakery is), and "defined start and end" is what separates a project from a program or a portfolio, which you'll meet in Level 3. Project management is the discipline of applying knowledge, skills, tools, and techniques to project activities to meet the project's requirements — on scope, on time, on budget, and to the stakeholders' satisfaction. This module sets the frame for the entire course: what a project manager actually does day to day, how that differs from neighboring roles, and the major frameworks the profession has converged on.
What a project manager actually does¶
Strip away the job-title mystique and the core job is five repeating activities, in this order, for every project:
| Activity | Plain-language version |
|---|---|
| Define | What are we building, and what does "done" look like? |
| Plan | Who does what, by when, for how much? |
| Execute | Get the work done, coordinate the people doing it |
| Monitor & Control | Is it still on scope, on schedule, on budget? Course-correct early |
| Close | Confirm it's actually done, capture lessons, release the team |
Everything else in this course — scope statements, Gantt charts, budgets, risk registers, stakeholder maps, status reports — is a tool that supports one of those five activities. If you ever feel lost in PM jargon, ask which of the five activities the tool in front of you is serving.
Project manager vs. product manager¶
These two titles get confused constantly, including inside companies that employ both, because the words sound alike and the roles do overlap at the edges. The cleanest way to separate them is by the question each role is principally accountable for answering.
| Project Manager | Product Manager | |
|---|---|---|
| Core question | How and when will this get delivered? | What should we build, and why? |
| Time horizon | Bounded — has a start and an end | Ongoing — a product usually outlives any single project |
| Success measure | On time, on budget, on scope | Adoption, revenue, customer/user outcomes |
| Owns | The schedule, the budget, the delivery plan | The roadmap, the backlog priorities, the business case |
| Typical artifact | Project charter, Gantt chart, RAID log | Product roadmap, PRD, user research findings |
| Reports on | Delivery progress and risk | Product-market fit and metrics |
A useful shorthand: a product manager decides what ships and why it matters; a project manager makes sure it actually ships, on the terms that were promised. In practice a single person sometimes wears both hats on a small team, and on a large program the two roles work in constant partnership — the PM turns the PdM's roadmap decisions into a funded, scheduled, staffed plan of execution.
Where PMI and PMBOK fit in¶
The Project Management Institute (PMI) is the field's largest professional body, and its flagship publication, the PMBOK Guide (A Guide to the Project Management Body of Knowledge), is the closest thing the profession has to a shared reference vocabulary. You do not need to memorize the PMBOK or hold the PMP certification to be an effective PM — plenty of excellent PMs have never opened it — but you will constantly run into its terminology in job postings, in other PMs' vocabulary, and in enterprise process documents, so it's worth knowing the shape of it.
The current PMBOK (7th edition) organizes project management work around eight performance domains rather than the older, more rigid "process groups":
| Performance domain | What it covers |
|---|---|
| Stakeholders | Identifying and engaging everyone with a stake in the outcome |
| Team | Building and leading the people who do the work |
| Development approach & life cycle | Choosing predictive, agile, or hybrid delivery |
| Planning | Turning goals into a workable, resourced plan |
| Project work | Coordinating the actual execution activities |
| Delivery | Producing the scope, quality, and value promised |
| Measurement | Tracking performance and taking corrective action |
| Uncertainty | Managing risk and ambiguity throughout |
Earlier PMBOK editions (up through the 6th) instead organized the same material into five process groups — Initiating, Planning, Executing, Monitoring & Controlling, and Closing — which map almost one-to-one onto the five activities in the table above, and which you'll still see referenced constantly in industry, in this course, and in most PM software. Both framings describe the same underlying work; the 7th edition simply emphasizes outcomes and adaptability over rigid sequencing, reflecting how much project delivery has shifted toward agile and hybrid approaches since PMBOK 6 was written.
A worked example: two projects, two very different shapes¶
Consider two projects at the same mid-size retail company:
Project A — "Migrate the e-commerce site to a new hosting provider." Scope is well-understood up front (the current site's feature set, just on new infrastructure), the sequence of work is largely fixed (provision infrastructure → migrate data → cut over DNS → decommission old hosting), and the business needs a hard go-live date because the old contract expires. This project suits a predictive (waterfall) approach: define the full scope and schedule up front, then execute against that plan.
Project B — "Build a new customer loyalty program." Nobody is fully sure yet what features will actually drive engagement, the team wants to release something small to real customers and adjust based on what they see, and the business is comfortable trading a fixed scope for the ability to pivot. This project suits an agile approach: plan in short iterations, ship incrementally, and let real feedback shape what gets built next (fully covered in Level 2, Module 1).
Same underlying discipline — define, plan, execute, monitor, close — applied with a different rhythm because the two projects have fundamentally different levels of upfront certainty. Recognizing which shape a project has before you commit to a delivery approach is one of the highest-leverage judgment calls a PM makes, and it's a theme this course returns to repeatedly.
How It Actually Works¶
The "triple constraint" isn't a diagram, it's a constraint-satisfaction
relationship: Cost = f(Scope, Time, Quality) where tightening any one
variable forces at least one other to move, because labor hours are the
common currency underneath all three. If scope grows by X story points and
your team's throughput is fixed, either time must grow by X/throughput, or
you add cost (more people — subject to Brooks's Law, below), or quality
drops (defects rise because verification steps get compressed under the same
schedule). PMBOK's five process groups (Initiating, Planning, Executing,
Monitoring & Controlling, Closing) are not a waterfall sequence despite how
they're drawn — they're concurrent state machines that overlap for the
whole project lifetime: Monitoring & Controlling runs continuously from day
one, and re-Planning fires as an event triggered by variance crossing a
threshold, not on a calendar. Brooks's Law itself has a mechanism, not just a
slogan: adding a person to a late project adds n(n-1)/2 new communication
pathways (5 people = 10 links, 9 people = 36 links) and consumes ramp-up time
from the existing team who must train them — so the short-term effect of
adding headcount is negative until the new person's net output exceeds their
communication overhead plus their trainers' lost time.
Exercise¶
Pick two initiatives you know about — from your own work, school, a volunteer group, or even planning a family event — and classify each one as a "project" or "not a project" using the temporary/unique/defined-end-point test above. For the one that is a project, write two or three sentences identifying: (1) whether it's closer to Project A's shape (well-understood scope, fixed sequence) or Project B's shape (uncertain scope, room to iterate), and (2) who is principally accountable for the "what and why" versus the "how and when" — even if, on a small initiative, both questions land on the same person.