Bent Flyvbjerg studied 258 projects across 20 nations over 70 years. 9 out of 10 ran over budget. On average, costs ran 28% above forecast.
The cause wasn’t bad execution, but how teams treated the plan. They wrote it once, got it approved, and then stopped using it. When things changed, the plan didn’t.
Most plans get dropped by week three. They were built to be approved, not used. They mix up planning (what to do and why) with scheduling (when to do it). And they have no clear way to handle a scope change without breaking.
This guide shows how to write a project plan in seven steps that work in any tool. You’ll also see real-world examples across Waterfall, Agile, marketing, and construction. Plus a side-by-side look at where plans actually live: spreadsheets, shared Docs, and dedicated PM tools.
How To Write a Project Plan in 2026 (+ Examples)
- What Is a Project Plan?
- Why Is a Project Plan Important?
- The Plan Is a Baseline, Not a Blueprint
- Key Components of a Project Plan
- How to Write a Project Plan in 7 Steps
- Project Plan Examples
- Where Should Project Plans Live?
- 6 Reasons Why a Project Plan Fails
- How We Create and Manage Project Plans in ClickUp
- Build a Project Plan Your Team Will Use
- Frequently Asked Questions About Project Plans
TL;DR
A project plan is the document that turns scope, schedule, and resources into a baseline your team can act on. The best plans separate planning from scheduling. They route every change through the baseline. And they get reviewed at every milestone.
This guide shows how to build one that holds up when scope shifts, dependencies break, and people get pulled to other work.
Summarize this article for me pleaseWhat Is a Project Plan?
A project plan is a formal document that maps how a project will be executed, monitored, and closed. It covers scope, schedule, resources, risks, and communication protocols, and serves as the baseline the team works from once execution starts.
What a project plan isn’t
A project plan isn’t a project charter. The charter authorizes the project and grants the project manager authority. It answers “should we do this, and who is in charge?” The plan picks up where the charter ends, and answers “how, when, by whom, and at what cost?”
A project plan also isn’t a scope statement. A scope statement defines what the project will deliver and what it will not. It tells you what “done” looks like. The project plan covers the scope statement plus the schedule, resources, risks, communication, and change control. It tells you how the team will get there, who is doing what, and what happens when something changes.
The 5 phases of a project plan
A project plan covers the five phases the Project Management Institute (PMI) defines as the project lifecycle: initiation, planning, execution, monitoring and controlling, and closure.
- Initiation: Define the project’s purpose, identify stakeholders, and get the charter approved. The plan doesn’t exist yet, but the conditions for writing it do
- Planning: Build the scope, schedule, resource plan, risk register, and communication plan. This is the phase the rest of this guide is about
- Execution: The team does the work. The plan becomes the reference document for who is doing what, when
- Monitoring and controlling: Track progress against the baseline. Route every change request through the change control process you defined in the plan
- Closure: Confirm deliverables are accepted, document lessons learned, and release the team. The plan is archived, not deleted: the next similar project starts from it instead of a blank page
The plan itself sits in the Planning phase, but it stays in active use through Execution and Monitoring. A plan that closes when Planning ends is the plan that gets abandoned early.
Summarize this article for me pleaseWhy Is a Project Plan Important?
Skip the plan, and the same problems keep showing up. Scope creep, because nobody defined boundaries, resource conflicts, because two workstreams claimed the same engineer, and missed deadlines, because hidden dependencies showed up late.
A project plan prevents those failures by making the work visible before execution starts.
- Alignment across stakeholders. Sponsors, team leads, and contributors agree on what success looks like before work begins. Without a plan, every person operates with a slightly different definition of “done”
- Visibility into dependencies. The plan surfaces which tasks block others. This prevents the “I did not know you were waiting on me” problem that stalls projects mid-stream
- Realistic resource allocation. It forces the team to match available people and budget to actual scope. No more discovering the gap mid-project when it is too expensive to fix
- Better decision-making. When new requests appear, the plan provides a baseline for evaluating trade-offs. Without that baseline, every request feels equally urgent
- Accountability without micromanagement. With documented roles, owners, and deadlines, you can track progress without chasing updates
PMI’s Maximizing Project Success report found that projects that define success criteria upfront and put in place a well-established performance measurement system have success rates nearly 2x higher.
Summarize this article for me pleaseThe Plan Is a Baseline, Not a Blueprint
Most project managers treat the plan as a delivery document. You write it to show stakeholders what you’ll build, then update it only when forced to. That leaves you with a snapshot, not a decision tool.
The real job of a project plan is to give you something concrete to push back against when the future arrives differently than expected. Scope change requests get evaluated against the baseline, not against a feeling. Timeline slips get measured against a plan, not a memory. The plan that wins is the one that gets updated at every milestone.
Two rules follow from this, and the rest of this guide is built on them:
- Plan first, schedule second. Planning is deciding what to do and why. Scheduling is deciding when. Mix them up, and timelines start driving scope
- Review at every milestone. A plan built in week one and untouched by week eight gives false confidence. Update it on purpose, so the team works from accurate information
This approach addresses what Flyvbjerg called the optimism bias: the systematic tendency for planners to underestimate costs, timelines, and risks while overestimating benefits. Plans built as static predictions inherit that bias on day one and never correct for it.
Summarize this article for me pleaseKey Components of a Project Plan
Every project plan, whether high-level or deeply detailed, draws from the same core components. The list below covers each one and what it should address.
- Project scope statement. The boundaries of the project: what’s included, what’s explicitly excluded, and the criteria for completion
- Objectives and success metrics. Specific, measurable outcomes the project must deliver (not vague aspirations like “improve customer experience”)
- Work breakdown structure (WBS). All deliverables structured into manageable tasks and subtasks
- Schedule and milestones. Timeline with key dates, phase gates, and the critical path that determines the earliest possible completion
- Resource plan. Who is assigned to what, at what capacity, and what tools or budget they need
- Risk register. Identified risks, their likelihood and impact, and the mitigation or contingency strategy for each
- Communication plan. Who gets updated, how often, through what channel, and what triggers an escalation
- Change control process. How scope changes get requested, evaluated, and approved (or rejected) against the baseline
However, not every project needs all eight sections at the same depth. A two-week internal project might collapse several into a single page. A regulated industry project, say a pharmaceutical compliance initiative, might expand each into its own sub-document with formal approval gates.
Summarize this article for me pleaseHow to Write a Project Plan in 7 Steps
These seven steps work regardless of methodology: Waterfall, Agile, or hybrid. The order matters because each step feeds the next. Skipping ahead creates rework that is more expensive than planning the first time properly.
Step 1: Define your goals and identify stakeholders
Start with your goals. The most common planning mistake is jumping straight to “what do we need to do?” before answering “what does success look like?” Tie each goal to a measurable outcome and a deadline.
For example, “Redesign the website” is a task. “Increase conversion rate on the pricing page by 15% before Q3” is a goal that shapes every downstream decision.
Next, list everyone who has authority, influence, or a dependency on the project. Categorize them by role. The sponsor approves budget and scope changes, contributors do the work, and informed parties need updates but don’t make decisions. A simple stakeholder map keeps this organized.
| Name | Role | Authority level | Update frequency |
| VP of Product | Sponsor | Approves scope changes and budget | Biweekly |
| Lead Engineer | Contributor | Technical decisions within scope | Weekly |
| Legal Counsel | Consulted | Reviews compliance requirements | At milestones |
| Sales Director | Informed | No decision authority | Monthly summary |
Step 2: Set the project scope and deliverables
Scope is the boundary line. Everything inside gets resourced and scheduled; everything outside is explicitly deferred or declined. A two-column “in scope/out of scope” list prevents the ambiguity that causes scope creep later.
Distinguish project deliverables from tasks. A deliverable is a tangible output the stakeholder receives: “migrated database,” “approved design mockup,” “published API documentation.” Tasks are the work required to produce it. This distinction matters because stakeholders care about deliverables; your team cares about tasks.
The most common scope failure? Writing boundaries so broadly that they can’t be used to say “no” to additions.
“Improve the user experience” could mean anything. “Redesign the checkout flow for mobile browsers, excluding tablet layouts and payment provider changes” gives you a documented reason to push back when someone requests tablet support mid-project.
Step 3: Create a work breakdown structure
Take each deliverable from Step 2 and break it into the smallest tasks that can be individually assigned, estimated, and tracked. This hierarchy, project -> deliverable -> work package -> task, is your work breakdown structure (WBS).
A useful rule of thumb: if a task takes longer than a few days, it can probably be broken down further.
The WBS is the foundation for the schedule and resource plan. If it is incomplete, everything downstream is unreliable. Your timeline will be wrong because you missed work, and your resource plan will have gaps.
For example, here is how that would look in ClickUp:
Step 4: Build the project schedule and milestones
Take your WBS tasks and sequence them: which tasks depend on others finishing first (dependencies), and which can run in parallel.
Project milestones mark the completion of major phases or deliverables. They are checkpoints: “design phase complete” or “UAT sign-off received.” Use them to create natural review points with stakeholders. For complex projects, visualize the schedule as a Gantt chart to make dependencies and the critical path clear.
Build a buffer into the schedule for realistic unknowns. Then, add contingency within phases, especially testing and review, rather than as a lump at the end that gets cut when pressure mounts.
Step 5: Assign roles and allocate resources
Map each task from the WBS to a specific owner. Shared ownership means no ownership. Resource allocation means confirming that the people assigned have capacity during the scheduled timeframe.
This is where plans collide with reality. Your lead developer might be allocated to three projects simultaneously. The plan forces that conflict into the open before it causes a missed deadline.
The RACI framework (Responsible, Accountable, Consulted, Informed) clarifies who does what without over-documenting. If the project requires new software or a contractor, that gets approved alongside the plan.
Step 6: Assess risks and plan for communication
Identify what could go wrong, assess the likelihood and impact of each risk, and document a response for each.
Document common project risks in a risk register so they are visible and owned. Here’s an example.
| Risk | Likelihood | Impact | Mitigation strategy | Owner |
| Lead developer leaves mid-project | Medium | High | Cross-train a second engineer on critical modules | Engineering Manager |
| Vendor delivers API two weeks late | High | Medium | Build a two-week buffer into the integration phase | Project Manager |
| Scope change requested after design phase | High | High | Define a change request process upfront | Sponsor |
| Budget reduced by 15% in Q3 | Low | High | Identify deferrable deliverables in advance | Project Manager |
Pro Tip: Define the cadence and channel for status updates, such as a weekly standup or biweekly written report. Also, list who receives them, and what triggers an escalation. A project communication plan prevents the ‘I assumed someone told you’ problem.
Step 7: Get stakeholder sign-off and set a baseline
The plan is not final until the sponsor and key stakeholders formally approve it. This sign-off creates the project baseline: the agreed-upon scope, schedule, and budget against which all future changes are measured.
Without a baseline, there is no way to distinguish a legitimate change from the original agreement.
Once set, any change to scope, timeline, or budget goes through the change management process you defined in the plan. Share the approved plan with all stakeholders. Store it in a shared, version-controlled location that’s always accessible. Not buried in an email thread from three months ago.
The baseline does not mean the plan is frozen. It means changes are deliberate and documented. When someone submits a change request like “can we add this feature?” you compare it against the baseline, then decide together with full visibility into the cost, schedule impact, and trade-offs.
If your project plan lives across spreadsheets, chats, and emails, it’s not a system — it’s friction. A project management database brings everything into one structured, searchable place. Whether you’re managing one project or many, this walkthrough shows how to build a database that keeps work aligned and progress visible.
Summarize this article for me pleaseProject Plan Examples
The examples below show how the same core components adapt to different contexts. Each describes the structure, what makes it distinct, and when to use it.
Waterfall project plan example
A Waterfall plan moves in order: requirements, design, build, test, deploy. Each phase ends with a formal gate. Stakeholders review the work and approve the next stage. Nothing moves forward until the prior phase is signed off on.
Sample sequence:
- Requirements doc (signed off by the sponsor)
- Design phase, then a design review gate
- Build phase, then a code review gate
- Test phase (unit, integration, UAT), then a QA sign-off gate
- Deploy, then a post-launch review
What makes it distinct: The full scope is locked at the requirements gate. The Gantt chart is the main artifact, showing each phase in sequence. Change requests are formal and costly. Waterfall trades flexibility for predictability.
Best for: Projects with fixed requirements, rules, and regulations, or outside teams that need a locked scope. Government contracts, compliance work, and manufacturing fit well.
Not ideal if: You can’t define “done” at kickoff with high confidence. Locking the scope you don’t understand costs more than iterating.
Agile project plan example
An Agile plan sets the product vision, a ranked backlog, a sprint pace (usually two weeks), and team roles. The detailed plan grows sprint by sprint. The team learns from each round and adjusts.
Sample sequence:
- Product vision and success metrics (locked in a Doc at kickoff)
- Ranked backlog (refined each week)
- Sprint 1 plan: stories, owners, capacity check
- Sprint 1 retro, then re-rank the backlog
- Sprint 2 plan…
What makes it distinct: The plan doesn’t lock scope past the next sprint. Stakeholders see a roadmap of themes by quarter, not a list of deliverables by sprint. The retro is the feedback loop. Without it, Agile turns into scope creep with extra steps.
Best for: Projects where needs change, customer feedback drives the work, or the team ships in small batches. Agile is common in software, product design, and internal tools.
Skip it if: stakeholders need a fixed scope and date up front. Agile’s flexibility hurts you when the contract is rigid.
Marketing campaign project plan example
A multi-channel marketing campaign pulls together content, paid media, email, and events. It produces creative deliverables with review cycles, coordinates outside vendors (agencies, freelancers), and lands all channels on one launch date.
Sample sequence:
- Campaign brief: objective, audience, message, KPIs (locked at kickoff)
- Content calendar with deliverables, owners, and review dates
- Channel-specific timelines (content, paid, email, events) mapped backward from launch
- Creative review and approval gates per asset
- Launch day, then a post-campaign performance review
What makes it distinct: Marketing plans have more stakeholders with opinions than with decision rights. Without a clear approval workflow, every asset gets dragged through five rounds of edits, and the launch date slips. A RACI matrix isn’t optional here. It’s what protects the launch date.
The other distinct risk: Channels converge on one date, but each has a different lead time. Print needs six weeks. Paid social needs two. Email needs one. If you plan forward from kickoff instead of backward from launch, the long-lead channels are already late on day one.
Best for: Product launches, seasonal campaigns, rebrands, or any work that ships across more than two channels on a shared date.
Skip it if: You’re running a single-channel always-on program (just a blog, just a paid account). A content calendar and a weekly check-in cover it. A full campaign plan is overhead you won’t use.
Construction project plan example
Construction projects run under strict rules (permits, inspections) and hard physical dependencies. You can’t install electrical before the framing is up.
Sample sequence:
- Project charter and permits timeline (locked before any work starts)
- Site prep and foundation (weather-dependent)
- Framing, then a framing inspection gate
- Mechanical, electrical, and plumbing in a set sequence
- Drywall, finishing, final inspection, handover
What makes it distinct: The schedule is the main risk, not the scope. A delay in one phase impacts every phase that follows. If framing slips a week, electrical, plumbing, and HVAC all shift. Construction plans build a buffer inside each phase, not at the end. Why? The end-of-project buffer always gets eaten by steps that ran late earlier.
Best for: Any work with physical dependencies, weather risk, or several trades to coordinate.
Skip it if: You’re running knowledge work. Borrowing construction’s heavy gates for a marketing campaign adds overhead with no real protection.
Don’t start your next project from a blank page. ClickUp’s High Level Project Plan Template gives you a ready-to-use structure with task statuses, custom fields for tracking approvals and team assignments, and five built-in views, including a Timeline and Deliverables List.
Summarize this article for me pleaseWhere Should Project Plans Live?
The method decides how you sequence work. The tool decides whether the plan survives past week three. You have three options.
Spreadsheets (Google Sheets, Excel)
These are the default tools for teams that have always used spreadsheets. One sheet for tasks, one for the timeline, one for the risk register. Everyone can edit. Nothing breaks if someone is offline.
What works
- Flexibility. You can model any structure in a few hours
- Filters and pivots are strong once set up
- Almost no learning curve
Where it breaks
- Dependencies are manual. When a task slips, you update every later date by hand
- Version control is whoever saved last
- Past 15 to 20 tasks with cross-team dependencies, the upkeep costs more than the plan is worth.
Best for: Single-team projects under 20 tasks, with one clear owner and no nested dependencies.
Skip it if: More than two teams need to coordinate, or the timeline shifts more than once a week.
Shared Docs (Google Docs, Notion, Confluence, ClickUp Docs)
A Doc-based plan works when the plan is mostly written prose: scope statement, stakeholder map, success criteria, and a risk register. Tasks sit in bulleted lists with owners and dates.
What works
- The plan reads like a document, not a database. Stakeholders actually open it
- Comments and review history sit next to the content
- The scope statement and the risk register live in one place
Where it breaks
- No live status. The Doc says “Build API integration: in progress” forever unless someone updates it by hand
- No dependency tracking or Gantt view. The plan and the work drift apart fast
Best for: Short projects (under a month), narrative-heavy plans, or as the front end to a task tracker. The scope and stakeholders live in the Doc. The tasks live elsewhere.
Skip it if: You need to see who is blocked on what, today.
Dedicated PM tools (ClickUp, Asana, Jira, Monday)
Purpose-built systems where tasks, dependencies, owners, and timelines share one data model. The plan and the work are the same object.
What works
- Dependencies are live. When a task slips, later tasks shift on their own, and the team sees it in a dashboard
- Gantt views show the critical path without manual rework
- Status reports come from the same data the team works in, not a parallel doc that goes stale
Where it breaks
- Setup takes time
- A two-week internal project doesn’t need custom statuses, fields, and a Gantt view
- The plan and the work also need to live in the same tool to get the live-data benefit
Best for: Projects that span teams, have dependencies that shift, and need a baseline that survives scope changes.
Skip it if: It’s a simple project with one owner, one team, fixed scope, and a duration under three weeks. A Doc is faster.
Summarize this article for me please6 Reasons Why a Project Plan Fails
Most project plans lose momentum for predictable reasons.
1. Writing scope so broadly that it can’t say no
Scope is only useful when it gives you a documented reason to decline additions. If you can’t point to the scope document and say, “That is outside it,” the scope is too vague to protect the project.
Write every scope boundary as a testable statement. “Redesign the checkout flow for mobile browsers, excluding tablet layouts and payment provider changes” is a boundary. “Improve the experience” is not.
2. Getting estimates from managers
Top-down estimates are consistently optimistic. This is the optimism bias from earlier, applied to estimates. The person assigning the work almost always underestimates it compared to the person doing it.
The developer who’s doing the work knows where the friction actually lives. Build the WBS collaboratively or expect rework.
3. Stacking all your buffer at the end
A schedule that adds a two-week “contingency” at the end of a four-month project is a schedule with no real contingency. That buffer gets cut first when pressure mounts.
Add contingency time within phases, especially testing and review, where it is usually consumed. The buffer that lives inside the work survives. One that lives at the end disappears before the project needs it.
4. Leaving “done” undefined
When completion criteria are not specified, “done” means something different to every stakeholder:
- The developer considers it done when the code ships
- The product manager considers it done when QA signs off
- The client considers it done when they feel satisfied
Write what done means for every deliverable. Note what criteria it should meet, what format it’ll be in, and who will approve it. Ambiguous criteria are the leading cause of rework late in a project.
5. Letting the plan live in an email attachment
A plan nobody can find is functionally the same as no plan.
If the team has to ask where the current version is, they won’t consult it for decisions, or notice when it’s outdated, or update it when reality changes.
Store the plan where the team works, and keep it version-controlled and linked to the tasks it governs. The plan should be two clicks from any team member’s workspace.
6. Treating the plan as a one-time artifact
The fastest tell: The plan’s last-modified date is older than the most recent task you added. If the work has moved and the plan hasn’t, the plan stopped governing the project some time ago, and nobody noticed.
Block a 15-minute plan review into every milestone, and any time a change request gets approved. The point isn’t to rewrite the plan from scratch. It’s to confirm the baseline still reflects reality, or to document where it doesn’t.
Summarize this article for me pleaseHow We Create and Manage Project Plans in ClickUp
We don’t write project plans in a Google Doc and hope for the best. Our plans live inside ClickUp, right next to the work they describe. That way, the plan never goes stale.
Docs for scope and the stakeholder map (Steps 1 and 2)
ClickUp Docs holds the scope statement, success metrics, and the stakeholder table. Because the Doc sits in the same workspace as the tasks, the “is this in scope?” question is easy to answer. When someone proposes a change, we point them at the same Doc the sponsor signed off on, not a Google Doc from three months ago.
Tasks and Subtasks for the WBS (Step 3)
Each deliverable becomes a List, and each work package becomes a task with subtasks for the actual work. Custom Fields track priority, owner, effort, and acceptance criteria, so “done” is defined per task instead of left to interpretation.
ClickUp Brain drafts the first pass when we have a scope statement and a deadline; we edit, prune, and assign from there. The first version is faster, but a human still owns the structure.
Gantt View for dependencies and the critical path (Step 4)
Drag a line between tasks in ClickUp Gantt View to set a dependency. The critical path is visible, and when a task slips, downstream tasks shift with it. The schedule stays realistic without anyone rebuilding it by hand. This is the piece that fails fastest in a spreadsheet, and that earns PM tools their place.
Dashboards for the baseline (Step 7)
Once the sponsor approves the plan, ClickUp Dashboards pull live data on completion rates, overdue tasks, and workload. The “where are we?” answer comes from the same data the team is working on, not a parallel status doc. Stakeholders check the Dashboard instead of asking for a status meeting.
Where ClickUp isn’t the right fit
ClickUp earns its keep when projects involve multiple people, moving timelines, and cross-functional handoffs. The more connected your work needs to be, the more value you get.
Skip it if: You’re a freelancer tracking a handful of deliverables, or a team that needs complex financial models and pivot tables. A simple doc or spreadsheet would be better here.
How RevPartners cut planning time by 83%
RevPartners, a HubSpot solutions agency managing remote client delivery, ran into the same problem most growing services teams hit: project planning that worked with five clients fell apart at 15. The team had been juggling Notion, Trello, and Asana, with no single source for what was scoped, who owned it, or what “done” meant.
They rebuilt their delivery playbooks as ClickUp Templates, so each new client engagement starts from a baseline plan instead of a blank Doc. Project planning time dropped from 30 minutes per project to 5 minutes, an 83% decrease, and overall service delivery sped up by 64%.
Matt Bolian, Co-Founder of RevPartners, on the shift:
Summarize this article for me pleaseBuild a Project Plan Your Team Will Use
A project plan only works when it captures the full picture: every deliverable, owner, dependency, and risk in one place. Also, it has to be referenced during the work, not forgotten by the time the first milestone hits.
Across hundreds of projects, the teams that ship consistently treat their plans as living documents. They review at every milestone, update assumptions when conditions change, and route every scope request through a documented change process. That is what keeps projects on track.
If your team has outgrown shared docs and basic spreadsheets, it’s worth trying a tool like ClickUp. You can keep scope, tasks, dependencies, owners, and dashboards in one place, with views that stay in sync as the plan evolves.
Sign up for ClickUp today!
Summarize this article for me pleaseFrequently Asked Questions About Project Plans
What’s the difference between a project plan and a project management plan?
A project plan focuses on the specific deliverables, schedule, and resources for a single project. A project management plan (a PMI term) is broader, including the change management, risk, communication, and procurement subsidiary plans that govern how the project is managed. For most teams outside formal PMI environments, “project plan” covers both.
Can you create a project plan without project management software?
Yes, for short projects with one owner and fewer than about 20 tasks. A shared Doc with a scope statement, stakeholder list, and a simple table of owners and due dates is faster than setting up a PM tool. The breakpoint is usually cross-team dependencies: when more than two teams need to coordinate, the spreadsheet starts to lose fidelity.
What is the critical path in a project plan?
The critical path is the longest chain of dependent tasks in your schedule, which determines the earliest possible project completion date. Any delay on a critical-path task delays the entire project; delays on non-critical tasks may be absorbed into float. Gantt charts visualize the critical path so PMs know which slips actually matter and which do not.
Who is responsible for creating the project plan?
The project manager owns the plan, but they shouldn’t write it alone. Subject-matter experts provide task estimates, the sponsor approves the scope and budget, and contributors validate dependencies. Top-down plans written without input from the people doing the work consistently underestimate effort, a pattern Bent Flyvbjerg’s research has documented across thousands of projects.
What is the difference between a project plan and a project schedule?
A project plan defines what will be done, by whom, at what cost, and how risks will be managed. A project schedule is one component of the plan that maps when tasks happen and in what sequence. Conflating the two leads to timelines driving scope instead of the other way around, which is one of the most common planning failures.
How often should you update a project plan?
You should update a project plan at every major milestone, and whenever a change request is approved. A plan that reflects week-one assumptions in month three gives false confidence. The PMI recommends formal plan reviews at each phase gate, with ad-hoc updates when risks materialize or scope changes are approved through the change control process.
Everything you need to stay organized and get work done.
Recent Articles
Website Project Management: Plan, Build, Launch on Time 
Website Project Management: Plan, Build, Launch on Time
