Running the Project: Execution, Risk, and Stakeholders

Lesson 2 built the plan. This lesson is about what happens when the project meets reality, and reality always diverges from the plan. Tasks take longer than estimated, people get sick, requirements change, suppliers slip, surprises appear. The mark of a good project manager is not a plan that comes true; it is steering the project to success despite the plan not coming true.

This phase, often called execution and control, is where most of a PM's time goes and where projects are actually won or lost. It has two intertwined activities:

• Execution: the team does the work; the PM coordinates, unblocks, and keeps things moving.
• Control (monitoring): the PM continuously compares reality against the plan, catches deviations early, and steers back on course.

The plan from Lesson 2 is what makes control possible: it is the baseline you measure against. Without it you cannot even tell you are off track. With it, control becomes a steering loop, check where you are versus where you should be, and correct.

Three things dominate this phase and this lesson: tracking progress, managing risks and issues, and managing stakeholders and communication. Master these and you can deliver a project through the inevitable turbulence, which is the whole job.

You cannot steer what you do not measure. Tracking is the routine of comparing actual progress against the plan often enough to catch problems while they are still small and fixable.

In practice, a PM keeps a live read on a few questions:

• Schedule: are tasks finishing on time? Which are behind? Is anything on the critical path slipping (which threatens the end date directly)?
• Scope: is the work being completed actually what was defined, at the expected quality? Has anything crept in?
• Budget: is spending tracking with the plan, or burning faster than expected?

The tools are lightweight and routine: a short regular check-in or stand-up with the team, an updated task board or schedule, and a periodic status review. The point is not bureaucracy; it is early warning. A task one day late, caught today, is a small adjustment. The same slippage discovered a month later, when it has cascaded through dependent tasks, is a crisis.

This is why the discipline is to track continuously and act on small deviations, not to wait and hope. The most dangerous project is not the one that is visibly behind; it is the one that looks fine because no one is really tracking, right up until the deadline it cannot meet. A good PM would always rather know bad news early, when there are still cheap options, than late, when there are only expensive ones.

The activity that most separates a professional PM from an amateur is risk management: dealing with what might go wrong before it does, rather than only reacting to problems after they hit. A risk is a potential future problem; an issue is a risk that has already happened.

Risk management is a simple, proactive loop:

• Identify. At the start and throughout, brainstorm what could go wrong: a key person leaving, a vendor slipping, a technical unknown, a dependency on another team. Naming risks strips them of their power to blindside you.
• Assess. For each, judge how likely it is and how bad the impact would be. This ranks them, so you focus on the high-likelihood, high-impact risks and do not waste effort on trivial ones.
• Plan a response. For the important risks, decide in advance: avoid (change the plan to remove it), mitigate (reduce its likelihood or impact), transfer (shift it, for example via a contract or insurance), or accept (acknowledge it and prepare a contingency).
• Monitor. Keep watching the risk list as the project evolves; new risks appear, old ones fade.

The payoff is enormous. When a risk you anticipated materializes, you already have a response ready, so it is a managed bump, not a derailment. Teams without risk management lurch from fire to fire, always surprised. A PM who manages risk makes their projects look calm and lucky, when really they simply saw the problems coming.

Change is inevitable, a stakeholder wants a new feature, a priority shifts, an assumption proves wrong. The danger is not change itself but uncontrolled change, which is how scope creep (Lesson 2) silently wrecks a project. The answer is a lightweight change-control process.

The principle: a requested change is neither automatically refused nor automatically accepted. It is evaluated for its impact on the iron triangle, then decided deliberately. The steps:

• Capture the request so it is visible, not an informal "can you just also..." that slips in unnoticed.
• Assess its impact on scope, schedule, and cost. What would this add, and what does it push out?
• Decide with the right people, usually including whoever owns the budget and priorities. Approve it (and adjust the plan and expectations accordingly), defer it, or decline it.
• Update the plan and communicate if it is approved, so the baseline stays honest.

The key mental move, again, is the iron triangle: "Yes, we can add that, and it means either two more weeks, more budget, or dropping something else, which do you prefer?" This turns change from a silent killer into an explicit, shared choice. It also protects the team, who otherwise absorb endless additions with no adjustment to time or resources until they burn out and the project fails. Controlling change is not being rigid; it is making sure every change is a conscious trade-off rather than an accident.

A stakeholder is anyone with an interest in the project, the client or sponsor paying for it, the users who will use the result, the team building it, executives, and other affected departments. Managing stakeholders well is often what determines whether a project is judged a success, and it is largely a communication task, which is why communication is the biggest part of a PM's job.

Good stakeholder management runs on a few practices:

• Identify them and understand their interests. Different stakeholders care about different things, cost, features, timing, quality. Knowing what each wants lets you manage expectations and reconcile conflicts.
• Communicate proactively and appropriately. Keep people informed on a cadence that fits their stake: an executive sponsor may want a brief periodic status; the team needs daily coordination. Do not make people chase you for information.
• Manage expectations honestly. A project delivered exactly as promised is a success; the same project is a "failure" if stakeholders expected more or sooner. Aligning expectations to reality, early and continuously, is half the battle.
• Deliver bad news early and straight. Hiding a slip until it is undeniable destroys trust and removes options. Raising it early, with a plan, builds credibility even when the news is bad.

The throughline of this whole lesson is communication. Tracking is communication about progress; risk and change management are communication about what might and will change; stakeholder management is communication about expectations. A PM who communicates clearly, proactively, and honestly can hold a project together through almost anything, which is exactly why the role rewards people skills over technical ones.

See execution and control work together on a realistic bump. A PM is running the website project from Lesson 2, with a fixed launch date.

1. A risk was identified during planning: "the visual design could take longer than estimated," assessed as fairly likely, high impact (design is on the critical path). Response planned: line up a second designer who could help if needed.
2. Tracking catches the slip early. Two weeks in, a stand-up reveals design is running about a week behind. Because design is on the critical path, this threatens the launch date, and it is caught now, not at the deadline.
3. The risk response kicks in. The PM brings in the pre-arranged second designer to parallelize the remaining design work, pulling the schedule back toward the plan, a managed bump, because the response was ready.
4. A change request arrives mid-stream: a stakeholder wants an extra animated homepage. The PM assesses it against the iron triangle, it would add a week the critical path cannot absorb, and presents the trade-off. The stakeholder agrees to defer it to a later phase rather than move the launch.
5. Communication throughout: the sponsor gets a short status noting the design slip and the mitigation, so there is no surprise, only confidence that it is handled.

Result: the project lands on time despite a real setback, because the PM tracked closely, had a risk response ready, controlled change deliberately, and kept stakeholders informed. That is the everyday craft of execution, and it is the heart of what a project manager does.

Here is the execution-and-control toolkit in one view.

The unifying idea for a career switcher: execution is a steering loop, not a one-time push. You check where you are against the plan, spot deviations, and correct, over and over, until delivery. The plan from Lesson 2 gives you the reference; the skills here, tracking, risk, change control, and above all communication, are how you use it to actually reach the finish line through real-world turbulence.

Notice how little of this is technical and how much is disciplined attention and clear communication, exactly the transferable strengths that make project management such an accessible switch. You now have the core operating skills of the role.

One piece remains: how teams organize this work differs by methodology. The website example ran in a fairly traditional, plan-first style, but much modern work runs in agile and Scrum, with a different rhythm. Understanding those methodologies, and how to choose between them, is Lesson 4, along with how to break into the field.

Execution is a continuous loop: the team does the work while the project manager tracks progress against the plan, responds to risks and change requests via the iron triangle, communicates with stakeholders, and corrects course, repeating until delivery.