Yuxu Ge
Article · 2025-06-11

Project Management Fundamentals: Learning Notes L3

In actual project work, I've learned to list the key roles on a project and ask what each cares about:

Once I've identified who the stakeholders are, I dig deeper: what do they actually want, and what influence do they have? I use a stakeholder register (or analysis document) to record details about each person—their department and title, their expectations, what they prioritize, how they benefit or are affected, and their potential influence. From this register, I sort stakeholders by impact and interest, pinpointing whose support is most critical. I also note what support or resources they'll provide. This tells me where to focus effort and how to tailor communication. High-impact, high-interest stakeholders get frequent contact and priority attention; low-impact ones get regular status updates. In short, mapping stakeholder details is foundational to project communication and management. It helps me build a working relationship network, balance competing expectations, and keep the project moving.

How to Launch a Project

After identifying the main stakeholders, I move into project initiation. One key task is to appoint the project manager—clarifying who will drive the project forward. I've learned that confirming this early matters enormously, because many later decisions and conversations need the PM to decide. I confirm my authority and responsibilities with leadership—especially resource allocation power—so I have real authorization to work.

Initial project definition is also part of launch. I first clarify what pain point the project solves or what opportunity it seizes (detailed next), then give the project a simple definition: what it will do, what it won't do, and why. This usually appears in a charter document—the project's authorization to exist. A proper charter typically includes:

The sponsor drafts or approves the charter. Once signed, the project is formally approved and the PM has authorization. I see the charter doing two things: first, aligning everyone on the project's direction—what we do and why. Second, giving the PM formal standing to allocate resources and cross-functional coordination. When launching, I hold a kickoff meeting to present the charter to stakeholders. It's the opening ceremony: all parties align on vision, goals, and scope, and clarify roles. Then execution can begin.

Clarifying the Problem or Opportunity

A project exists because it solves a problem or seizes an opportunity. The instructor emphasized that nailing this down is critical—it guides every later decision. I start with a problem statement: one or two clear sentences saying "what is the specific problem we face, or what opportunity do we want to pursue?"

Writing a problem statement seems simple but is deceptively hard. I used to mistake solutions for problems. In one office-system upgrade, I wrote: "We need to develop a new system to boost employee collaboration efficiency." That's a solution (build a system), not a problem (collaboration is slow, and here's why). The course showed typical traps: "We need a new building," "We need a new website"—these jump straight to what to do without explaining why. The right move is to ask "why?" repeatedly. When I hear "upgrade the system," I now ask: "Why? What pain does that solve?" Multiple iterations of why get to the root. In the example above, digging deeper revealed the real problem: "Our collaboration platform is outdated; cross-department communication is slow, hurting delivery speed and competitive standing." That's a good problem statement—clear, focused on the current pain, not presupposing a solution.

The instructor's hotel example: nearby new hotels appeared; occupancy dropped; conference bookings fell even though citywide demand was growing. Their problem statement: "We're losing market share in a growing conference market." That one sentence captures the diagnosis—demand is up, our share is down. It points the project at its core problem.

Two things I watch when writing problem statements: be concise (one sentence if possible, never a paragraph), and keep problem separate from solution. If I'm unsure, I ask: "Does this describe the current difficulty, or does it assume a fix?" Only descriptions of current difficulty count. And I verify the statement with stakeholders: "Yes, that's what we need to solve?"—making sure everyone agrees.

Project Goals and Objectives

After clarifying the problem, I set project goals and objectives. I used to muddle these two—they seemed to mean the same thing. But they differ:

Rough way: goal points the direction, objectives mark the waypoints. I now think through the goal first, then list main objectives that define success.

Project goals and objectives are important because they shape scope, approach, and how we measure success later. Objectives come in several types, each tracking different performance:

Once I list these, I make sure each objective is well-formed. This is where the SMART principle comes in—Specific, Measurable, Achievable, Relevant, Time-bound:

After writing objectives to SMART standards, I sketch what project success looks like. I then check whether objectives align with the project's original intent (the problem statement, project goal) and with company strategy. This is a crucial step: if objectives drift from strategy, the project may need adjustment or even cancellation. If they align, I'm more confident to push forward.

Usually I write project goals and objectives in document form and confirm them with stakeholders. This creates shared expectations about what the project will achieve and lays groundwork for later scope and solution decisions. Goals and objectives give direction; with them, we know where the road leads.

Developing Strategy

Once goals and objectives are clear, I often find multiple paths to achieve them—different strategies or solutions. Which one is best? The course taught a method I've used: brainstorm + decision matrix.

First step: brainstorm options. I gather people familiar with the project and have them think of possible implementation strategies based on our problem statement, goals, and objectives. Brainstorming avoids filters: I say "don't worry about feasibility right now, just throw out ideas." That atmosphere brings creative options. For "increase conference center competitiveness," people might suggest "upgrade all equipment," "push high-tech conference packages," or "partner with large trade shows for bundled promotion." The goal is to list as many ideas as possible before evaluating.

Second step: use a decision matrix to evaluate. Once I have candidate strategies, I evaluate and filter them. The course recommends a decision matrix—a table of options and criteria, scored to compare approaches. My team usually poses key questions as evaluation criteria:

Through this multi-dimensional evaluation, I find the best strategy more objectively. Usually the highest-scoring option that also passes feasibility, risk, and culture checks is the winner. Sometimes two or three strategies score similarly, requiring further discussion, leadership input, or resource availability to decide. But the process ensures we think carefully rather than guessing.

Once the strategy is set, the project enters a new phase. We now have a clear blueprint for what to do and how. Concrete details (task breakdown, resource allocation) follow. The course encouraged applying this decision-matrix tool to our own projects, and I found it works well. I'll keep using this rational approach to strategy, because getting the path right early makes execution smoother.

Discovering Requirements

With strategy clear, I move to requirements. The course said: "Project purpose, goals, and solution tell us what to complete and roughly how; requirements detail exactly what the final deliverable must do and what conditions it must meet." Requirements answer "what exactly should the deliverable be?" This is critical work: wrong requirements mean the stakeholder won't be satisfied; unnecessary requirements bloat time and cost.

To clarify, I'll use an example. In the conference center upgrade, one goal is "use latest computers and audiovisual equipment to enhance the meeting experience." Specific requirements supporting that might be: "Install 4K displays in all presentation rooms," or "Provide high-speed 802.11n wireless coverage across the hotel and conference areas." These are more concrete than the goal—they say what equipment and what standard. The goal says use new tech; requirements say which tech and how capable.

Common challenges in gathering requirements:

I tackle discovery in three steps:

First step: gather requirement information. I use several methods:

Second step: analyze and clarify requirements. After the first round, the real work begins. I organize and analyze the raw requirements. First, I check for contradictions, vagueness, or gaps. I mark unclear points and ask follow-up questions. I look for duplicates or related requirements and consolidate them. This iterates—back-and-forth over several rounds until requirements stabilize. The course said we often need several cycles to truly understand the real needs. I've found this true: I think I'm done, show the client, and they spot new ideas or reverse prior direction. Patience matters; refinement through dialogue is normal.

Third step: document and confirm requirements. Once requirements are stable and coherent, I write requirement documentation. I follow principles: use clear, unambiguous language—avoid jargon and vague terms so different readers understand the same thing. Organize by category (functional, performance, interface, training, etc.) for completeness and easy lookup. Note the source and priority of each requirement for later trade-offs. After drafting, I have stakeholders review and sign off: "Yes, these are what we need." Only then does the project have a real blueprint. Design, development, and testing follow these requirements exactly.

Requirements are one of the hardest parts of project planning, but they decide success or failure. I've learned it's worth the time: catching misalignment early beats discovering mid-project that you built the wrong thing. Everything the project delivers is defined in the requirements—only with solid requirements can the team hit the target and avoid wasted or rework.

Clarifying Deliverables and Success Criteria

It's reassuring to know what a project should deliver and how to measure success. The course discussed deliverables and success criteria—I find these concepts practical. Deliverables are concrete project results: could be physical (a building, software) or intangible (a service, a business metric like "sales up 15%"). Success criteria judge whether deliverables meet expectations.

A few points from the course stuck with me:

I often summarize deliverables and success criteria in a table or checklist:

This checklist makes clear what's to be delivered and how to measure it. It's easy to communicate with stakeholders about results they care about. During execution, we deliver and verify each item. Each completed deliverable is one step closer to success. It's like defining the "finish line" conditions; my job is to lead the team to satisfy each one.

Clarifying Assumptions and Risks

At planning, I also note project assumptions and risks carefully. At first I thought this was overcautious. But mistakes taught me that overlooked assumptions and risks can blindside a project. The course stressed that clarifying them early is key to success. I've applied this and seen it work well.

Assumptions are things I provisionally take as true. Projects start with uncertainty, so I assume certain conditions to plan. Examples: "Key staff will stay available," "vendors will deliver on time," "market conditions stay stable." But assumptions are subjective, unverified—if they don't hold, the project suffers. Example: I assume "the equipment vendor handles wiring," they assume "your IT department does wiring." Neither side speaks up, wiring never happens, walls close before discovery. I've seen this. The lesson: make hidden assumptions explicit. People don't realize what they're assuming, so I ask like a detective: "Who exactly owns this task?" "You expect X to do Y, right?" I don't mind repeating; I ask until alignment is clear. Airing assumptions and discussing publicly lets us catch misalignment before damage occurs.

Risks are uncertain events that could affect project targets—both threats and opportunities, though I focus mostly on threats. Risk is uncertain: it may or may not happen, but if it does, it damages goals. Early risk identification serves two purposes: first, it informs leadership. If a project has major risks, they may decide not to fund it—better than mid-project failure. Second, for projects that continue, knowing risks upfront lets us plan mitigation and add buffers, hardening the project. The course advised spending early effort on likely risks affecting the project. I agree, especially for fatal risks—policy changes, funding loss. Caught early, they inform charter decisions.

In practice, I add a section to the charter or scope statement listing key assumptions and risks:

When I listed assumptions and risks for my projects, I realized each had many I'd overlooked. Now that I track them, the uncertainty actually goes down. I make it a habit to revisit these lists periodically. If an assumption later proves false, I adjust the plan. If a risk approaches likelihood, I activate the response. Continuous monitoring keeps assumptions and risks within control.

In sum, assumption and risk management clarifies the project's unknown terrain. Surfacing assumptions prevents miscommunication; surfacing risks lets me prepare. I can't eliminate all uncertainty, but I can anticipate and ready myself. Project management is largely about managing uncertainty, and assumptions and risks are two faces of it. Handle them well, and project success is much more likely.

Writing the Scope Statement

After the steps above (stakeholders, goals, requirements, deliverables, success criteria, assumptions, risks), the final key work is to write the scope statement. The project scope statement clearly describes project boundaries: what's included, what's not. It marks the project's territory, telling the team and stakeholders "our accountability ends here; beyond that isn't our job." I believe a scope statement is invaluable for controlling boundaries and preventing scope creep.

When writing the scope statement, I distill earlier decisions:

  1. What's included: Based on confirmed requirements and deliverables, I list the main work and outputs the team will complete. This is the "scope in" section. For the conference center upgrade: "This project includes multimedia equipment upgrade in meeting rooms, network infrastructure upgrade, conference booking system software update, and staff training." These are the team's responsibilities, within scope.

  2. What's excluded: This is critical and often overlooked. I explicitly state what's not in scope. Why? Some things look relevant but aren't; saying so upfront avoids misunderstanding later. The course example: in the hotel conference center upgrade, hotel room furniture isn't in scope—it was refreshed a few years ago, not part of this tech refresh. Or: "This project doesn't handle post-completion marketing promotion; that's a separate project run by Marketing." Excluding items prevents the assumption "they'll do it." I try to exclude things that could reasonably seem in scope but aren't, or are at the boundary. For instance, in a software system project, "does not include historical data cleanup" is worth stating.

  3. Scope overview: Sometimes I start the scope statement with one or two sentences summarizing the overall scope—a summary of inclusions and exclusions. Example: "This project upgrades the conference center's hardware and software to enhance customer experience. It focuses on technology refresh, not building expansion or marketing operations." That's clear at a glance.

When writing, I check prior assumptions. If I've assumed furniture can work with new tech, furniture updates are out of scope. If marketing is handled separately, it's excluded. Reviewing assumptions ensures the scope statement catches key points.

After drafting, I have main stakeholders review and confirm the scope statement. It's like drawing a line everyone can see: once confirmed, nobody can easily cross it. If new needs arise later, I can reference the scope statement: "That's on our exclusion list; if we must do it, we need a formal scope change." This makes requirements and scope discussions evidence-based, preventing creep.

The scope statement defines the project's frontier. With a clear boundary, I can judge whether the project stays on track, overshoots, or undershoots. When disputes arise during execution, I refer to the scope statement to check if the issue is in scope. If not, it goes through formal change process, not ad-hoc addition. The statement protects the team from over-commitment and ensures the customer gets what was promised, nothing less.

In sum, the scope statement is the last step that consolidates all planning into one clear definition. After writing it, the project framework feels solid: stakeholder list, goals, requirements, deliverables, success criteria, assumptions, risks, and scope boundaries—all connected, forming a unified blueprint. Presenting this blueprint to leadership and stakeholders, they quickly grasp what the project does and doesn't do. As PM, I have confidence to move into execution.

Looking back at Lesson 3, this series of steps taught me that solid front-end planning—getting the path right and articulated clearly—lets execution run smoothly.

© 2026 Yuxu Ge ·