Project Planning Survey Template

Use this project planning survey template when a project has more than a handful of stakeholders and you suspect they are not describing the same project. It is built for project and program managers, product leads, and PMO teams who need the disagreement written down while the plan is still editable.

A planning survey is not a status report and not a requirements document. It is a structured way to collect what people actually believe about scope, sequence, capacity, and risk — in a format you can compare side by side.

What a project plan survey is really measuring

Three things, in order of how often they sink a project:

1. Divergent definitions of done. Everyone agrees on the goal at the level of a slide title and disagrees the moment you ask them to write a sentence.
2. Dependencies known to exactly one person. The ones that never make it onto a Gantt chart because the person who knows about them was never asked in writing.
3. Confidence that differs by seniority. Sponsors are usually more confident about the date than the people who have to hit it. That gap is the most useful number this survey produces.

The question set

Group the survey into six blocks. Use a consistent 1–5 agreement scale for the rated items and a short free-text box for the written ones. Set up the rated blocks as matrix questions so the page stays short, and use free text questions for the written items — they are where the real content is.

Block 1 — Definition of done

• In one sentence, what has to be true for this project to be considered successful? (free text, required)
• I can explain this project’s objective to someone outside the team. (1–5)
• The success criteria are measurable, not just descriptive. (1–5)

What a bad answer looks like: three respondents write three different sentences, and one of them describes a deliverable rather than an outcome. That is not a data quality problem — that is the finding. Put the three sentences side by side in the first planning workshop.

Block 2 — Scope boundaries

• Name one thing people assume is in scope that you believe is out of scope. (free text)
• The boundary between this project and adjacent work is clear to me. (1–5)
• I know who decides when something is added to scope. (1–5)

What a bad answer looks like: the out-of-scope item that one team names is the same item another team named as their main deliverable.

Block 3 — Sequence and dependencies

• What has to be finished by another team before your part can start? (free text)
• What are you delivering that another team is waiting on? (free text)
• The sequence of work is realistic given the dependencies I know about. (1–5)

What a bad answer looks like: a dependency mentioned by exactly one respondent. Single-mention dependencies are the ones nobody has scheduled.

Block 4 — Capacity and ownership

• The time I am expected to spend on this project is compatible with my other commitments. (1–5)
• The people who need to approve decisions are available on the cadence this plan assumes. (1–5)
• Which role on this project currently has no named owner? (free text)

What a bad answer looks like: high agreement on ownership, low agreement on availability. It means the names exist on the RACI and the hours do not.

Block 5 — Risk and confidence

• How confident are you that this project will deliver on the current date? (0–10)
• How confident are you that the current budget is sufficient? (0–10)
• What is the single most likely reason this project slips? (free text)

Use a 0–10 numerical scale question here rather than 1–5 — you want enough range to see a gap between groups.

What a bad answer looks like: everyone rates confidence 7 or 8. Uniform moderate confidence usually means people are answering politely; pair it with the free-text risk question and read the text instead.

Block 6 — Communication and escalation

• I know where to find the current version of the plan. (1–5)
• I know how to escalate a blocker and how fast I will get an answer. (1–5)
• What update cadence would actually be useful to you? (single choice: weekly written, biweekly written, monthly review, on exception only)

How to read the results

Planning surveys are small. With 8–25 respondents you are running a census of a known group, so ignore margin-of-error arithmetic — it belongs to customer-facing studies, where the sample size calculator is the right tool. Read these four things instead:

The confidence gap. Split the 0–10 confidence scores into sponsors/steering group versus delivery contributors. If sponsors average 8 and contributors average 5, you do not have a communication problem, you have a plan that only one group believes. Segment cleanly by tagging each invite with hidden variables for role, function, and whether the person is accountable for a deliverable.

Variance, not average. On every rated item, look at the spread before the mean. High spread on “the success criteria are measurable” is worth more of your attention than a low mean on “I know where to find the plan.”

Single-mention items. Any dependency, risk, or missing owner named by one person only. These are candidates for a 15-minute verification call, not for the risk register straight away.

Wording overlap in the free text. With more than about 20 respondents, reading verbatims by hand starts to miss patterns. Athena, Responsly’s AI agent, clusters open-ended answers into themes and flags where the same risk is described in different words — useful when engineering calls it “migration scope” and finance calls it “vendor lead time.”

The trap specific to planning surveys

People answer planning surveys as a negotiation, not as a measurement. A contributor who rates the timeline 3 is partly reporting belief and partly lobbying for more time; a sponsor who rates it 9 is partly reporting belief and partly signalling that the date is not up for discussion.

You cannot remove that, but you can make it visible: always pair a rated item with the free-text question that forces a reason. A score without a reason is a vote. A score with a reason is evidence.

When a project planning survey is the wrong tool

Be honest about this — it saves more credibility than any well-designed question set.

• The decision is already made. If the date and scope are contractually fixed, asking people for input creates the expectation that input changes something. Run a risk workshop instead and say plainly what is fixed.
• You have fewer than six stakeholders. Six conversations take an afternoon and give you tone, hesitation, and follow-up questions that a form cannot.
• There is an unresolved conflict between two leaders. A survey lets both of them submit their position anonymously and go home. Surveys are bad at conflict resolution; they are good at discovering that a conflict exists.
• You need a RACI. Ownership is assigned by a decision-maker, not discovered by averaging opinions. Use the survey to find the gaps, then assign.
• You are mid-crisis. During a live incident or a recovery plan, the cycle time of a survey is longer than the cycle time of the problem.

How teams actually use it

• B2B SaaS, platform migration. Engineering, support, and customer success answer the same dependency block. The migration date moved by three weeks because support was the only group that flagged a training dependency on the new admin console.
• E-commerce, replatform before peak season. The confidence gap between the steering group and the warehouse operations lead was the argument that moved the cutover out of Q4.
• Healthcare, clinical system rollout. Clinical stakeholders and IT answer separate variants using skip logic, so clinicians never see infrastructure questions and IT never guesses at workflow impact.
• HR, HRIS implementation. The “which role has no named owner” question consistently returns data migration and post-go-live support — the two roles projects assume someone will absorb.

Running it in Responsly

Build it in the survey maker, send it as a link or an email to a named stakeholder list, and keep every wave in the same project so the stage-gate re-runs sit next to the original. Response rate matters more here than in customer research, because a missing stakeholder is a missing dependency — the practical levers are in how to improve survey response rate, and the wording levers are in how to ask good survey questions.

Once the project is running, this template stops being the right instrument. Switch to the team management survey template for how the work is being run day to day, the meeting feedback survey template if the ceremony load is the complaint, and the digital transformation survey template for multi-year change programs where adoption, not delivery, is the risk. For recurring delivery quality reviews, the framing in quality management pairs well with a fixed quarterly version of this survey.