Questions to Ask About a Project
Questions for a project kickoff or handover, whether you are joining the team, taking it over, or being asked to deliver it. They cover scope, ownership, dependencies, and the things that usually go wrong quietly.
The questions
Open any question for the note
What problem is this project supposed to solve?
Why ask it
Ask about the problem rather than the deliverable. A team that can only describe what it is building has inherited a solution someone else chose.
Who asked for it, and who signs off when it is done?
Why ask it
Requester and approver are sometimes different people with different definitions of finished. If nobody can name the approver, expect the scope to move late.
What does done look like, concretely?
Why ask it
Push until you get something observable: a number, a shipped feature, a report accepted by a named person. Anything softer will be reinterpreted at the end.
What is explicitly not part of this?
Why ask it
Written exclusions are the only defense against gradual expansion. A project with no stated boundaries has an unlimited one.
When is the deadline, and what is driving that date?
Why ask it
A date tied to a regulation, a contract, or a conference is real. A date tied to the end of a quarter usually has more room than anyone admits, which is worth knowing before you plan around it.
Which milestones matter to people outside the team?
Why ask it
Internal checkpoints slip without consequence; external commitments do not. Sorting them tells you where to put the buffer.
Who is on the team, and what is each person actually responsible for?
Why ask it
Named owners for each piece of work is the point. Where two people are jointly responsible for something, in practice nobody is.
Who decides when there is a disagreement?
Why ask it
Every project reaches a technical or scope dispute. Knowing in advance whether that goes to a lead, a committee, or the loudest stakeholder saves a week of stalemate.
What is the budget, and who controls it?
Why ask it
The person who releases spending sets the real pace. If approvals route through someone outside the team, that route is a dependency like any other.
What has already been tried here, and why did it stop?
Why ask it
Most projects are second or third attempts. The reason the earlier one ended is usually still present, and nobody volunteers it unless asked.
What is the thing most likely to derail this?
Why ask it
Asked as a single question rather than a risk register, it gets the honest answer. Note whether people name a technical risk or a person.
What are we depending on from other teams or vendors?
Why ask it
External dependencies are where schedules actually fail, because you carry the deadline without any control. Ask what has been agreed and by whom.
How will we know early if we are off track?
Why ask it
A project that only reports progress as a percentage complete has no early signal. Look for a measurable output that appears in the first few weeks.
How does work get reviewed before it ships?
Why ask it
Review that happens at the end is a bottleneck disguised as a quality process. Ask who reviews, how long it takes, and what has been sent back recently.
How do change requests get handled once we have started?
Why ask it
A route for changes protects the schedule; the absence of one means each request is negotiated personally, and the schedule absorbs all of them.
What compliance, legal, or privacy constraints apply?
Why ask it
These arrive late and cannot be argued with. Ask which team must sign off and how long their review usually takes, since that is schedule, not paperwork.
What tools and systems will we work in?
Why ask it
Access requests and unfamiliar systems eat the first two weeks. Ask what needs provisioning and who grants it before day one rather than after.
Where does project knowledge get written down?
Why ask it
If the answer is a chat channel, decisions will be irrecoverable in three months. One agreed place for decisions is worth more than a comprehensive plan.
Who has to be trained or handed this at the end?
Why ask it
Handover is the most commonly forgotten phase, and it is work. Naming the receiving team early usually changes how the thing gets built.
What would make you call this a failure even if we delivered on time?
Why ask it
The most useful question in the set, because it surfaces the unstated quality bar, the political stake, or the outcome the deliverable is only a proxy for.
Getting Briefed on a Project
Practical guidance for the conversation itself
At kickoff or handover
Ask for the original request
The email, ticket, or slide that started the project usually states the problem more plainly than any later document. Read it before you accept anyone's summary.
Write the answers down and send them back
A short note saying what you understood, sent to the people who briefed you, converts assumptions into corrections. The corrections arrive within a day.
Find the person who was here for the last attempt
On any project that has been tried before, one person remembers why it stopped. Twenty minutes with them is worth more than a week of reading.
What the answers tell you
Vague success criteria predict a moving target
If nobody can state what done looks like in observable terms, the definition will be supplied later by whoever is least satisfied.
Missing owners predict delay
Work assigned to a team rather than a person tends to wait. Note every item where you could not get a name.
A confident answer on dependencies is worth checking
Commitments from other teams are often reported second hand. Confirm directly with the team you are depending on, not with the person relying on them.
Common mistakes
Asking only the sponsor
Sponsors describe the intent; the people doing adjacent work describe the constraints. Ask both, and note where the two accounts differ.
Accepting a deadline without its reason
Dates with no stated cause are usually negotiable, and dates with a legal or contractual cause are not. Treating them the same way wastes either flexibility or credibility.
Leaving handover until the end
Documentation, training, and support arrangements are work that has to be scheduled. Discovering that in the final week is how projects finish late after delivering on time.