High Level Project Plan: How to Make One (With Examples)

10 min read · 2026-10-31

A high level project plan is a short document that shows a project's goal, scope, main phases, key milestones, owners, timeline and biggest risks. It leaves out task-level detail. It answers four questions: what are we doing, by when, who owns each part, and what could stop us. It usually fits on one or two pages.

You build it at the start of a project, before the detailed schedule exists. Its job is to get the sponsor and stakeholders to agree on direction, so the team can plan the details without having to redo them later. This guide covers the steps in order, how to tell if your plan is too detailed or too vague, three filled-in examples, and a one-page template you can copy.

The roadmap at a glance

Goal: Produce a signed-off high-level project plan your team can turn into a detailed schedule. Duration: 2 weeks

  1. Frame the goal (Days 1-2)

    Agree on why the project exists and what success looks like before you talk about dates.

    • Write the problem the project solves in two sentences.
    • Turn it into one measurable objective with a target date.
    • List 2 or 3 success measures the sponsor will actually check.
    • Confirm who the sponsor is and who makes the final decision.

    Milestone: The sponsor confirms the objective and success measures in writing.

  2. Set scope and deliverables (Days 2-4)

    Draw the boundary so everyone knows what is in and what is out.

    • List the main deliverables as nouns: a launched page, a migrated system, a trained team.
    • Write an "out of scope" list just as long as the "in scope" list.
    • Split the high-level requirements into business needs (what people must be able to do) and technical needs (how it will be done).
    • Note the fixed constraints: budget ceiling, hard deadlines, tools you must use.

    Milestone: The sponsor has reviewed the in-scope and out-of-scope lists.

  3. Map phases and milestones (Days 4-6)

    Group the work into 4 to 6 phases, each ending with a milestone anyone can check.

    • Name each phase after the outcome it produces.
    • Give each phase a duration range, not just one date.
    • Put one milestone at the end of each phase, written as a finished state.
    • Sequence the phases and mark the ones that can overlap.

    Milestone: A phase timeline on one page, with one milestone per phase.

  4. Assign owners and resources (Days 6-7)

    Put a single name on each phase and milestone.

    • Assign one accountable owner per phase, not a team name.
    • List the roles and people each phase needs, and when.
    • Flag anyone shared with another project.
    • Add the budget estimate per phase if your organization tracks it.

    Milestone: Every phase and milestone has one named owner who has accepted it.

  5. Surface risks, assumptions and dependencies (Days 7-8)

    Write down what could break the plan while changing it is still cheap.

    • List the top 5 risks with an owner and a response for each.
    • Write the assumptions the dates rely on, such as vendor availability or approval times.
    • Map dependencies on other teams, systems or decisions.
    • Add buffer to the phases with the most risk.

    Milestone: A risk, assumption and dependency list attached to the plan.

  6. Review and sign off (Days 9-10)

    Present the plan, collect objections and lock the baseline.

    • Walk the sponsor and key stakeholders through the one-page version.
    • Record every change requested and decide each one in the meeting.
    • Agree on the rhythm and format of status updates.
    • Save the approved version as the baseline you will measure against.

    Milestone: Sponsor sign-off on version 1.0 of the plan.

What is a high level project plan?

It is the strategic view of a project. It describes the big phases, milestones, deliverables and dependencies without breaking the work down into tasks for each person. Think of it as the agreement on direction that comes before the detailed schedule.

In project management, "high level" means you describe outcomes and checkpoints, not activities. "Run user testing" is a task. "Beta approved by product lead" is a high-level milestone. If a line in your plan would change because someone was out sick for a day, it is too detailed for this document.

What the plan is not:

  • Not a Gantt chart with hundreds of rows.
  • Not a list of who does what each day.
  • Not a product roadmap. A roadmap shows direction across several projects or releases over time. This plan covers one project with a clear start and end.
  • Not a contract. It is a baseline that you update when facts change.

Signs your plan is too detailed

A high-level plan can fail in two opposite ways. Run both checks before you show it to anyone.

A common trap is going too deep too early. Check each line. If one of these is true, the line belongs in the detailed plan, not the high-level one:

  • The item lasts less than a week.
  • The sponsor would never ask about it.
  • It names a person for a single task rather than an owner for a phase.
  • It depends on information you do not have yet.
  • Changing it would not move a milestone.

Signs your plan is too vague

The opposite problem is a plan so loose that nobody can be held to it. Each sign below comes with its fix:

  • Milestones you cannot verify. "Design mostly done" can't be checked. Rewrite each one as a finished state with a yes or no answer: "Prototype approved by the design lead."
  • No owner. A phase that says "Marketing" or "the team" has no one accountable. Put one person's name on it and get them to accept it.
  • No out-of-scope list. If you only say what is included, everyone fills the gaps with their own wishes. Write what the project will not do, line by line.
  • Dates with no assumptions. "Live by June" means nothing if it depends on a vendor contract nobody has signed. Write each assumption next to the date it supports.
  • Success with no measure. "Improve onboarding" can't be checked at the end. Name the result the sponsor will look at and the date it is due.

How far ahead to plan precisely

For projects longer than a quarter, plan with less precision the further out you go. A method you will often see in IT roadmap guides is the 3-12-24 model: plan the near term in detail, the next year at medium precision, and anything beyond that as a sketch. Adapt the horizons to your project. Switch to the detailed plan once the sponsor signs off and the team needs to know what to do on Monday.

What a high level project plan should include

Whatever the project, the plan needs these parts:

  • Objective: one sentence with a measurable result and a date.
  • Scope: what is in, and what is explicitly out.
  • Deliverables: the concrete things the project hands over.
  • Phases and milestones: 4 to 6 phases, one checkable milestone each.
  • Timeline: duration ranges per phase and the target end date.
  • Owners and resources: one accountable name per phase, plus the roles needed.
  • Risks: the top few, each with an owner and a response.
  • Assumptions and constraints: what the dates depend on and what cannot change.
  • Dependencies: other teams, systems, vendors or decisions you are waiting on.

High level project plan example 1: SaaS feature launch (10 to 12 weeks)

These three examples show the level of detail to aim for. Durations are illustrative, so adjust them to your team and context.

Objective: launch the new reporting feature to all paying customers by end of quarter.

Top risk: a key engineer is shared with another team. Response: confirm availability in writing before the build phase starts.

  • Discovery (2 weeks), owner product manager. Milestone: requirements approved.
  • Design (2 weeks), owner design lead. Milestone: prototype tested with 5 customers.
  • Build (4 to 5 weeks), owner engineering lead. Milestone: feature complete in staging.
  • Beta (2 weeks), owner product manager. Milestone: beta feedback reviewed, go decision made.
  • Launch (1 week), owner marketing lead. Milestone: feature live, announcement sent, support trained.

High level project plan example 2: IT migration to a new CRM (4 to 6 months)

Objective: move sales and support to the new CRM with no lost customer records.

Key dependency: vendor contract signed before configuration starts.

  • Assessment (3 to 4 weeks), owner IT manager. Milestone: data map and cleanup list approved.
  • Configuration (6 to 8 weeks), owner CRM administrator. Milestone: system configured and tested.
  • Data migration (3 to 4 weeks), owner data lead. Milestone: test migration passes the record check.
  • Training (2 weeks), owner sales operations. Milestone: all users trained.
  • Cutover and support (2 to 4 weeks), owner IT manager. Milestone: old system switched to read-only.

High level project plan example 3: HR rollout of a new performance review process (3 months)

Objective: run the first review cycle with the new process across all departments.

Key assumption: managers have time for reviews outside peak season.

  • Design (3 weeks), owner HR business partner. Milestone: process and forms approved by leadership.
  • Pilot (4 weeks), owner HR manager. Milestone: pilot team completes reviews, feedback logged.
  • Manager training (2 weeks), owner learning lead. Milestone: every manager attends a session.
  • Company rollout (3 weeks), owner HR director. Milestone: review cycle opened for all employees.

One-page high level project plan template for leadership

Leadership wants three things: what is happening, by when, and where the risk is. Put the blocks on the page in this order, top to bottom, and fill each one in.

Ending on decisions means the meeting produces approvals, not just comments.

  • 1. Objective: one sentence with the result, how it is measured and the date. Example: "All paying customers can use the new reporting feature by the end of the quarter."
  • 2. Success measures: two or three results the sponsor will check at the end. Example: "Feature live for all plans. Support team trained. No open critical bugs at launch."
  • 3. Phases and milestones: a horizontal timeline. One bar per phase, one marker per milestone, with the milestone written under the marker.
  • 4. Owners: one name under each phase bar, matching the timeline above.
  • 5. Top 3 risks: three lines, each in the same form: risk, owner, response. Example: "Shared engineer unavailable. Owner: engineering lead. Response: written confirmation before build."
  • 6. Decisions needed: what you need the room to approve today, with a date for each. Example: "Approve beta with 5 customers by the 15th. Confirm launch budget by the 20th."

How to draw the timeline in swimlanes in PowerPoint

Swimlanes give each team its own row, so everyone sees their part and the handoffs between teams. In PowerPoint:

  • Draw a row of month or week labels across the top of the slide.
  • Add one long, thin rectangle per team down the left side, each with the team name. These are the lanes.
  • In each lane, place a rounded rectangle for each phase, stretched from its start to its end. Write the phase name and owner inside.
  • Mark each milestone with a small diamond shape at the end of its phase, with a short label under it.
  • Draw arrows between bars in different lanes where one team waits on another.

How to draw the timeline in swimlanes in Excel

The same layout works in a spreadsheet. Keep colors for status only (on track, at risk, late), so the page shows where the risk is at a glance.

  • Put team names in column A, one row per team.
  • Put weeks or months across row 1, one column each.
  • Fill the cells from start to end of each phase with a color, and type the phase name in the first cell.
  • Type a ◆ symbol in the cell where each milestone falls.
  • Narrow the columns so the whole timeline fits on one printed page.

Turning it into a detailed plan and keeping it current

Once the plan is signed off, each phase owner breaks their phase into tasks, estimates and dependencies. The milestones stay fixed and the tasks fill the space between them. If the detailed estimates do not fit inside a phase, go back to the sponsor early rather than quietly squeezing the work.

Keep the high-level version alive as the way you communicate. Update it on a fixed rhythm, weekly for short projects or every two weeks for long ones, and mark each milestone as on track, at risk or late. Save scope changes as new versions so anyone can see what changed and why.

Common mistakes to avoid

  • Listing tasks instead of outcomes. Cut anything shorter than a week and keep it for the detailed plan.
  • Leaving milestones without an owner. Put one accepted name on every checkpoint.
  • Setting dates with no margin. Give duration ranges and add buffer to the riskiest phases.
  • Skipping the out-of-scope list. Write it alongside the in-scope list to stop scope creep from day one.
  • Hiding assumptions. Write down what the dates depend on and review it at each update.
  • Presenting it once and never updating it. Set the update rhythm during sign-off.

Frequently asked questions

How long should a high-level project plan be?

One page for leadership, and two to three pages at most if you add the risk list and assumptions. If it runs longer, you are probably including tasks that belong in the detailed plan.

What is the difference between a high-level plan and a detailed project plan?

The high-level plan shows phases, milestones, owners and risks so stakeholders can agree on direction. The detailed plan breaks each phase into tasks, estimates and daily assignments for the people doing the work. You build the high-level one first.

How do you write a high-level project description?

Use three sentences: the problem, the objective with a measurable result and a date, and the main deliverables. Leave out methods and tools unless they are a fixed constraint.

What are the steps of high-level project planning?

Frame the goal, set scope and deliverables, map phases and milestones, assign owners and resources, list risks, assumptions and dependencies, then review and sign off. Allow one to two weeks, depending on how many stakeholders need to review it.

Who should approve a high-level project plan?

The project sponsor, meaning the person who owns the budget and the final decision. Key stakeholders review it before sign-off, so their objections come up before the detailed work starts.

Generate this roadmap with AI