Yuxu Ge
Article · 2025-06-12

Project Management Fundamentals Learning Notes L4

A WBS contains two types of tasks: summary tasks and work packages. Summary tasks occupy the higher levels and group the project's major components. Planning a large event, for example, might yield summary tasks like "venue setup," "catering," and "program design," each of which can be subdivided further. Summary tasks can nest several levels deep—small projects may need two or three, while large ones require many more. Work packages sit at the WBS's lowest tier: they represent the smallest units of work that cannot be broken down further. Each work package corresponds to a specific deliverable and the detailed work needed to complete it. In an IT project, "deploy new system" might be a summary task that breaks into work packages such as "install servers," "configure network," and "run functional tests"—the concrete tasks the team actually executes.

Creating a WBS showed me its multiple benefits: smaller units are easier to estimate for time and cost; task assignment to team members becomes clearer; and small, discrete chunks let you place checkpoints throughout the project to measure progress. A WBS cuts the elephant down into slices. It is the foundation of project planning. The course itself states it well: "Breaking the project into manageable pieces helps you plan and manage the work effectively."

Defining Work Packages

Once you have a WBS, knowing the task names alone is not enough—team members need to understand exactly what each task involves. This is where work package documentation comes in. To ensure shared understanding, write a work package document for each item, describing its scope in detail. The document is like a task instruction manual, and its depth depends on who will execute it. Less experienced people need step-by-step guidance; experienced staff may only need a checklist reminder. If task details are already recorded elsewhere—technical specs, process guides—the work package document can reference those materials.

A work package document describes not just "what to do" but also "what standard marks completion." The course recommends recording the deliverable and acceptance criteria: something like "server runs normally and passes all test cases." This way the team knows when the task is truly done. As a project manager, I often don't have deep expertise in every domain, so when writing these descriptions, I should ask subject matter experts or task owners to fill in details. The course made this point stick: "If the project manager cannot write a detailed task description, ask the people who helped you build the WBS." Clear work package definitions make sure the team delivers what we expect. Next time I plan a project, I intend to prepare this kind of "instruction sheet" for important tasks, so misunderstandings don't waste time.

Estimating Time and Cost

Time and cost estimation has always been the trickiest part of planning for me. This course stressed how accuracy determines project success. Underestimate and the project gets wrongly green-lit but fails to deliver; overestimate and a viable project gets canceled, or wastes resources because the budget feels loose. Precision matters for both schedule and cost.

What relieved me was learning that estimates need not be exact at the start. Early in a project, such as during approval decisions, a range of ±75% is acceptable. At that stage you can only give a rough "range estimate"—the project might take two to four months, cost around 500,000 yuan, and so forth. As planning advances and you understand more, you refine and narrow the estimate, ideally reaching ±10% precision by the end. This progression from "rough guess" to "precise calculation" mirrors the project becoming clearer. Many projects do start with a ballpark number that tightens over time; the course explained this error-range convergence well.

The course introduced several estimation methods, opening my eyes to a toolkit:

While estimating, the course flagged practical tips: for large complex projects, remember to account for communication, coordination, travel, and management time—hidden work that's easy to overlook. Watch out for "safety padding" stacking up—people add buffer to their own piece, but if everyone does it, the project's overall estimate balloons. Instead, set project-level contingency buffers that everyone shares; don't let every subtask carry its own safety margin. Have the team estimate together—people executing the tasks know best how long the work takes, and they are more motivated to hit estimates they set themselves.

Creating a Resource Management Plan

Next I learned how to build a resource management plan. Project resources aren't just people; they include necessary equipment and materials. Here I'll focus mainly on human resources. The plan has several key parts:

  1. Define roles and responsibilities using a RACI matrix: R stands for Responsible—the person or group actually doing the work. A is Accountable—the person ultimately answerable for the result, usually with decision authority. C is Consulted—people whose input you need on the decision. I is Informed—people who need to know about progress. For a team-building event, I'd be Accountable as the project manager, the staff member executing tasks is Responsible, the department leader needs to know (Informed), and experienced colleagues offer advice (Consulted). Map out every major task's R, A, C, I roles and the structure becomes clear. Review this matrix with key stakeholders to spot gaps. If no one is assigned a task, arrange with the sponsor to designate someone. If external partners or contractors are involved, mark their responsibility boundaries. Clear accountability prevents finger-pointing or work falling through cracks.

  2. Draw an organizational structure chart: Show who reports to whom on the project. In large projects with people from different departments, a clear reporting line matters—when I need to escalate an issue or request support, I need to know who has authority. The chart functions like a project "contact list plus org hierarchy."

  3. Identify required skills and resource quantities: What skills are needed to do each WBS item, and how many people with each skill? The course recommends a skills matrix: rows are skill types, columns are project tasks, and you mark which task needs which skill. Then estimate how many people each skill requires (if two concurrent tasks both need electrical engineers, you might need two). Multiply by the hourly rate for each skill to get labor cost. The course noted that personnel costs often dominate project costs, so get full figures including salary plus benefits from Finance or HR.

  4. Develop a staffing plan: With the resource needs and cost estimates in hand, decide how to staff the project. Where will you source people—internal reallocation, hiring, outsourcing? When must they arrive—some specialists may only be needed late in the project? Do they need training? What are the onboarding and offboarding processes? These details matter in practice. With a staffing plan, you know who you need, when they arrive, how you manage them, and when they leave.

A resource management plan brings together who is responsible for each work item, reporting relationships, the quantity and sources of resources, and how to obtain and manage them. It is your project's people map. Going forward, I plan to sketch out a RACI matrix and confirm key roles before laying out staffing details, even for small projects. Success depends on everyone filling their role and working together.

Creating a Project Schedule

With the task list (WBS), estimates, and resource plan in place, I began drafting the project schedule. The schedule sequences tasks in time: their order and duration. The WBS tells us what to do but not when or how long. You need a time-based plan that shows when the project ends and what happens at each point.

Building a schedule follows roughly these steps:

Step one: Sequence tasks and clarify dependencies. Like stacking blocks, some must go underneath while others can go in parallel. In a project, some tasks can only start after another finishes; others can run concurrently. List all WBS work packages and map their relationships (dependencies). The most common type is "finish-to-start": the prior task must complete before the next one starts. Installing cables and equipment might both finish before you can connect the network—a typical dependency. Other relationships exist (start-to-start, finish-to-finish, milestones), though the course defers those details. Dependencies are crucial; they define the critical path—the chain of tasks that sets the project's end date.

Step two: Estimate duration for each task. You already did this during time estimation. Now populate the schedule with those durations. The course warns that precision matters: overestimates invite delays, underestimates create delivery pressure. This step also tests your earlier estimation quality.

Step three: Assign resources and adjust durations. Once people are assigned to tasks, see if that affects duration. A five-day task with only half a person (part-time) might stretch longer; two people full-time might finish sooner. Combine task estimates and resource allocation to get realistic durations. Don't create a Gantt chart that looks good on paper but has one person juggling three simultaneous tasks.

Step four: Account for constraints and refine the plan. Real projects face other constraints: hard deadlines (a task must finish by a certain date) or resource availability (a key person doesn't start for another month). Mark these limits and check if your preliminary schedule meets project requirements. If the timeline is too long or resources clash, you need to compress or optimize. You might add resources to crash the schedule, run some tasks in parallel instead of serial, or rebalance assignments to prevent someone from overloading. These are schedule optimization tricks that deserve more detail in later course sections. Schedules usually need multiple iterations before they're final.

The project schedule is one of the most important project outputs. It tells you how long the entire project runs, when each task starts and finishes, and when team members are needed. Once approved, it becomes the schedule baseline—your yardstick for comparing actual progress against the plan during execution. I personally enjoy building Gantt charts; seeing tasks lined up on a timeline is intuitive. This course helped me think through logic and resource allocation before drawing the chart, so my schedules should be more realistic.

Developing a Project Budget

Now for project costs. The saying goes, "feed the army before the battle." Money is often the lifeblood of a project. Whether your goal is profit, cost saving, or living within a fixed budget, spending demands close attention. Scope, schedule, and cost form the project management "iron triangle," and cost is one corner. A project budget is a reasonable estimate of all costs needed to complete the WBS work. It cannot be inflated—people won't approve a losing proposition—nor unrealistically low, or returns suffer even if you execute it. The course stressed that budgets must be realistic and are the starting point for cost management.

To estimate total project cost, include every expense tied to project work:

Early in a project, you often estimate only the top WBS tier costs for a rough total. Later, you refine each line item, improving precision. This mirrors the iterative time-estimation process.

Cash flow is an overlooked scheduling issue. The course posed an interesting question: have you had money in the bank but couldn't access it when you needed it? Projects face the same timing problem. Even if the total budget suffices, if spending concentrates in one phase but funding arrives late, the project stalls. Forecast project cash flow by matching expenses to the schedule: state how much you need to pay in each time window. This lets you alert Finance early so funds arrive when due. Next time I budget, I'll add a "forecast payment date" column to avoid funding-timing problems.

Once you have a total project cost, compare it to your funding cap. Often leadership has already allocated a sum; if your estimate exceeds that, you need to cut costs or the budget won't be approved. The course offered several cost-control ideas: eliminate less critical spending (nice-to-haves go first); source cheaper resources (compare vendors, find the best value); or shrink the scope (deliver fewer outcomes, saving from the start). These adjustments must weigh impact on project goals; you can't cut so much that the project loses its value. The course gave an example: a conference center renovation budgeted at 1.5 million dollars, and the estimate came to roughly the same figure, so the project looked viable. If it had estimated 2 million, the project manager would need to make hard cuts.

A project budget is the cost target you work toward during execution. I learned that sound budgets require upfront, thorough estimation and building in a contingency reserve to handle unknowns. Going forward, I'll draft budgets with Finance in the room to avoid missing cost buckets. The course also recommended further study—Bob McGannon's "Manage Project Budgets" course. When time allows, I'd like to deepen my knowledge of project financial management, because running a project well means balancing the books.

Creating a Risk Management Plan

"A project without risk is a fantasy." The course opened this section with that reminder: every project faces risk. The real question is whether you've planned your response beforehand. Without a plan, when risk becomes reality, you're scrambling—wasting time and money, and demoralizing the team. The wiser approach is to plan risk management up front. A risk management plan ensures that if a risk materializes, you've already decided how to respond—you can think clearly instead of panicking.

Step one: Risk identification. Brainstorm with the team to find potential project risks. Risk includes both threats with negative impact and opportunities with positive impact (though the course focused on threats). Risks you already know about—"known unknowns"—might include supply delays or bad weather extending the timeline. The course listed examples that stuck with me: new technology might not work; costs could exceed estimates or funding might not arrive; distributed teams might struggle with time zones or language barriers; unclear requirements could trigger scope creep; limited key staff means no one to cover if someone leaves. These examples show risks are everywhere. Cast a wide net in identification—consult domain experts about their concerns, review what went wrong on similar past projects. Document each risk: its description, which project goals it threatens, severity of consequences. Many teams create a "risk register" to organize this information.

Of course, brainstorming never uncovers every surprise—there will always be "unknown unknowns," the unexpected. For those, set aside a contingency reserve (like keeping a "house repair fund" in case something breaks). How much contingency is reasonable? Many organizations hold back a percentage of budget based on experience. Better to have it and not need it. If a risk materializes, you have ammunition and don't freeze. Identifying risk is the starting move; you can't assess impact or plan response until you know what threatens you.

Step two: Risk analysis and prioritization. Once you have a list, you can't manage every risk intensively, so analyze each one's probability and impact. Use qualitative methods (high/medium/low) or quantitative ones, answering two questions: "What's the chance this risk occurs?" and "How bad is it if it does?" Untested technology usually has high failure probability (new tech is immature and bug-prone), and a conference system failure would be severe—that's high probability, high impact. Ordinary weather changes might have small impact, a low-impact risk. Have your domain experts rate each risk's likelihood and consequence. Then prioritize by focusing on high-probability, high-impact risks, or medium-probability, high-impact ones. Low-probability, low-impact risks deserve less effort (time is limited).

Step three: Develop risk response strategies. This is the heart of the plan: for each significant risk, decide your approach. The course categorized strategies, and several stuck with me:

Weigh cost against benefit when choosing a strategy—don't spend five thousand to prevent a five-hundred-dollar loss. The course's example stuck with me and taught me to manage risks proportionally: spend money to stop disasters, not prevent inconveniences.

Step four: Build the plan and monitor. Record your response decisions in a risk register (risk log). It typically lists each high-priority risk's details: description, triggers (what causes it), potential impacts, intended response, owner, and expected result. For "new technology fails," the log notes: trigger is test failure; response is "prototype building plus two-week buffer for technology switch"; owner is the tech lead; expected outcome is early detection with a backup plan. Prepare the risk management plan (risk list, analysis, and responses) during project planning so when execution starts, you have a "risk playbook." During the project, monitor regularly: watch for triggers appearing, check if risk status changes, adjust strategy as needed. When a risk actually occurs, execute your planned response. If new risks surface during execution, add them to the log.

This course reinforced a lesson: risk management is not pessimism—it's foresight. Spot and think about risks early, and you gain composure and lose panic. Afterward I plan to run a "risk brainstorm" for my projects, even small ones—list the risks and think through responses. As the instructor said, you may never fully eliminate risk, but you can minimize negative impact and seize positive opportunities. The risk management plan itself reassures the team.

Setting Up a Change Management Plan

You finish the project plan, but plans never survive contact with reality. The course used tax law as an example: it started simple but accumulated additions until it became a bloated mess. Projects do the same—without control, growing requirements and scope run amok, derailing the effort. Change is inevitable, and the only answer is to manage it well. A change management plan lets you evaluate and handle change requests: admit good changes and block bad ones.

Building the plan, I learned these points:

  1. Define baselines and control scope. Decide what needs formal change control. Usually, core documents—the scope statement, requirements list, overall plan—become "baselines." Once approved, they don't shift without permission. If stakeholders sign off on a requirements list, that's your requirements baseline. Any new request must go through change process to be considered. The concept reminds me to lock the plan into a version once approved; after that, every change gets scrutiny.

  2. Establish a Change Control Board (CCB). Processing changes needs an authorized group to review and decide. The course calls it a change review board, typically made up of key stakeholders: customer rep, executives, affected department heads, team leads, and the project manager. With a board, I don't solo every change decision—we think together and share responsibility. The board also ensures transparency—multiple voices weigh in, and one person can't grant strange changes on a whim. Small projects might not have a formal board, but at minimum, make clear who has authority to approve changes so anyone can't just alter the project.

  3. Define the change process. Details vary by company, but most change processes include basic steps:

The course also noted that not every change requires the full process. You can set thresholds—the team can absorb minor changes if they stay below a cost limit or don't affect the critical path. The project manager can decide, then report back at the meeting. This speeds things. For emergencies, have a fast track: the board convenes urgently to decide without waiting for the next regular meeting. Build this flexibility into the change plan.

Change management is about balancing change and stability. Good changes make the project fit requirements better and add value, so you can't flatly reject them. But if you change everything, scope and goals spin out of control. The plan provides a gate: worthwhile changes come in, frivolous ones stay out. Later I'll brief stakeholders on these rules so they understand change isn't forbidden—it's organized. The course summed it well: change management ensures necessary changes are adopted while protecting the project from needless ones.

Planning the Procurement Process

This section taught me how to plan project procurement. The course opened with a cooking metaphor: even if you make chicken soup yourself, you don't produce every ingredient—you don't raise chickens, grow vegetables, and grind flour, then spend days making broth and noodles from scratch. You buy what you need, saving time and effort. Projects work the same way—what you need isn't always worth making. If a project requires products, services, or skills from outside, plan the procurement early. That's what a procurement management plan does.

I'll sum up the key planning points:

  1. Identify procurement needs. First, figure out what the project must buy. For labor, if the project needs a rare skill and your company lacks that expert, hire outside. If you need more people than you have, consider temps or outsourcing. For materials, you might need hardware, raw materials, software tools, and more. This step flows from your WBS and resource plan: list the items you don't have or don't have enough of. That's your procurement backlog.

  2. Document procurement process and roles. Next, clarify who runs procurement. Some companies have a procurement department; the project works with them. Others have the project team handle it. Maybe you split it—technical staff pick the option, procurement does the contract. Lay this out in the plan. Also describe supplier selection criteria, selection process, contract types, and contract management methods. What evaluation method picks the vendor? Fixed price or time-and-materials contracts? Who monitors the contract later? I've sat on selection panels; having criteria set upfront is crucial, or you bicker later and invite disputes.

  3. Decide make-or-buy. That is, internal build or external purchase. Wise decisions need clear requirements. So step one is making sure needs are clear and ranked. Then you can judge whether off-the-shelf products or services fit, and which needs are must-haves versus flexible. If suitable market options exist, evaluate them against requirements. Before you decide, weigh the pros and cons of internal build versus purchase. If speed is critical, buying usually wins—vendors often have stock faster than you develop from scratch. If cost matters and you can build, making might be cheaper. The course notes: "If quick completion is critical, purchase is usually preferred." That reminds me of software projects deciding between a third-party component or coding it ourselves—a classic make-or-buy call that balances speed, cost, and risk.

  4. List potential vendors. The procurement plan should include a roster of potential suppliers or contractors: what they provide, why you shortlisted them (price, reputation, past work). When procurement is official, you contact these candidates directly, saving time. This step asks the project to scout the market early, getting a sense of what's out there. If I need a video-conferencing system, I'd list three well-known vendors in my plan along with their strengths and estimated costs, ready to go.

Procurement planning taught me that it's not a last-minute scramble but a strategic choice made upfront. A procurement plan ensures you decide wisely about what to buy and makes procurement smooth. Personally, I used to focus on internal resources; now I see the value of leveraging external talent and goods. Sometimes an outside boost gets results faster, so why struggle alone? Next project, I'll include "what to outsource/procure" in my charter planning and prep vendor options early. That's forward thinking—a modern project manager shouldn't just marshal internal effort but integrate outside strengths.

Getting Approval to Execute

When planning is complete, the last big step is securing formal stakeholder approval to enter execution. Plainly, we need our boss or client to sign off: "The plan looks good; let's proceed." The course stressed that approval matters—it grants the authority and backing you need. Without leadership and client buy-in, execution lacks support and risks conflict.

At first I thought: write a thick plan document, email it out for signatures, collect sign-offs, done. The course disagreed. Emailed documents often get a cursory skim and a rubber-stamp. Later, if someone finds something in the plan they dislike, they might renege on their approval, and you rebuild everything. That's painful. Face-to-face approval is much more effective.

The course recommends a formal plan review meeting. Walk stakeholders through the plan section by section—scope, schedule, cost, risk, change process, everything—so no one has doubts. If questions arise, discuss them on the spot. If a big issue emerges, you might pause, revise, and reconvene later. The goal is to find and fix all the problems before everyone signs. Once all agree, have them sign a cover page to show approval. It feels like signing a battle order—everyone signs and pledges to uphold the plan. I think that ritual matters.

In practice, you can't always gather everyone in one room. The course offered alternatives: hold a video or phone conference so people join remotely. If someone can't make it, they can fax or email a signed page afterward. Use whatever means you have—the goal is collecting all key signatures. But the instructor noted that a plan signature isn't a legal contract; you can't later point to a signature and say "you agreed, so you must obey." The deeper point is that the review process itself builds stakeholder understanding and buy-in. The meeting is a chance to align. I found this reminder important: don't treat stakeholder signatures as leverage; treat the process as something that builds their confidence and backing.

Looking back, I've seen cases where leadership gave a verbal "okay" and rushed on, then later popped in with new demands and second-guessed the plan. If they'd sat down to review it carefully and hash things out, a lot of later friction might never have happened. Going forward, I'll insist on a real review meeting, even thirty minutes of walking through a slide deck beats email circulation. Let people talk face-to-face, raise concerns, get answers, and sign with genuine commitment. That's how a project truly launches in sync.

Putting It All Together

Completing this course gave me a panoramic grasp of project planning. From WBS and work packages through schedule, budget, risk, change, and procurement—the pieces fit together like a puzzle forming a complete planning picture. What excites me most is how these methods apply directly to real work. My next department activity, for instance, I want to plan using WBS—break it into layers, make sure I think of everything. I'm also preparing a simple RACI matrix showing which leaders, team leads, and doers own what, so no one later says "I didn't know this was my job" and we avoid finger-pointing. On risk, I'll list potential problems and plan responses—maybe just a few backup plans beats scrambling later. In short, this course taught me that "plan well and you'll prosper" is key to project success. I don't have all the experience, and things will surprise me, but these methods give me a toolkit to plan more thoughtfully and solidly. When I run real projects, I'll keep applying and adapting these tools, building my own experience library. Project management is a journey, and I'm glad I started with this solid foundation. I'm eager to try these ideas on a real project.

© 2026 Yuxu Ge ·