Questions to Ask About a Project
Questions to ask about a project when you are starting it, joining it, taking it over, being asked to deliver it or sitting in a status review. The 62 questions are grouped into basics, scope, team, schedule, risks and wrap-up: basics and scope are the questions to ask when starting a project, and the project planning questions follow under team and schedule. The last few also work when someone is telling you about a project they have finished. With only ten minutes, ask the first six.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Basics
What problem is this project supposed to solve?
Why ask it
Ask about the problem before the deliverable. If all you get back is a description of the thing being built, ask what goes wrong today without it: a team that cannot say 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 leaves room for it to be reinterpreted at the end.
What is out of scope for this project?
Why ask it
Ask for two or three things people might assume are included and are not, and get them written down. When an extra request turns up in the third month, that list lets you call it new work without making it personal.
When is the deadline, and what is driving that date?
Why ask it
A date tied to a regulation, a contract or a booked event is unlikely to move. A date tied to the end of a quarter may have more room than anyone has said, so ask what would actually happen if it slipped by two weeks.
What is the budget, and who controls it?
Why ask it
The person who releases the money sets the pace. If approvals go through someone outside the team, treat that route as a dependency, and ask whether the figure covers running the thing after launch or only building it.
Why is this being done now?
Why ask it
Something set this off: a contract up for renewal, a system losing support, a new boss with a view. That trigger is what the project is really racing against, and it is often a better guide to the true deadline than the date in the plan.
What happens if this project never gets done?
Why ask it
The cost of doing nothing is the plainest measure of how much this matters. A fine, a lost customer or a system that stops working gives you an argument to reuse each time the project competes for people. A long pause before the answer is worth noting too.
Who will use the result, and has anyone asked them what they need?
Why ask it
Projects are often specified by people who will never touch the finished thing. If the eventual users have not been consulted, put that conversation near the start, while changing course is still cheap.
How does this fit with what the organization is trying to do this year?
Why ask it
A project tied to a named goal tends to keep its people when priorities are reshuffled. One that connects to nothing is an easy one to pause, so find out where it ranks and who ranked it.
How will success be measured, and what is that number today?
Why ask it
A target means little without its starting point. If nobody knows the current figure, measuring it becomes the first task, because otherwise any result at all can be presented as an improvement.
What would make you call this a failure even if we delivered on time?
Why ask it
It brings out what the deliverable is standing in for: a quality bar nobody wrote down, a customer who must not be upset, a promise the sponsor made to their own boss. Keep the answer next to the success measure, since the two do not always match.
What will it cost in total, counting the hours of people who are not on the budget line?
Why ask it
A figure made of invoices and licences leaves out staff who are already on the payroll, and their time can be the larger share. Ask for a rough count of those hours too, so the benefit is weighed against the whole price.
What else could the same people and money do instead?
Why ask it
Evaluating a project on its own makes almost anything look worthwhile. Set it beside the next two things waiting for the same team, and ask whoever approves it to say which of them will now wait.
Is there a smaller or cheaper way to get most of the result?
Why ask it
A changed process, a tool the organization already pays for or a short pilot sometimes gets most of the way there. If nobody has looked, that is a few days of work to do before the full plan is approved.
When should the benefit start to show, and who outside the team has agreed to that estimate?
Why ask it
A saving or a sales figure promised by the project team carries less weight than one accepted by the department that has to produce it. Until the head of that department has put a name to the number, treat the case for the project as a draft.
Scope
What exactly are the deliverables: a working product, a report, a recommendation?
Why ask it
One person may be picturing a finished system while another expects a slide deck proposing one. Get the deliverables listed in writing, down to the format and who receives each.
Which requirements are fixed, and which are preferences?
Why ask it
Ask for the three things that cannot be dropped. A sponsor who calls everything essential has not chosen yet, and the choosing will happen later, under deadline pressure and with less thought.
If the date, the budget and the scope cannot all hold, which one gives?
Why ask it
Most projects reach this trade at some point, and it is a far calmer conversation in the first week than in the last. Record the answer beside the name of the person who gave it.
What are we assuming that nobody has checked yet?
Why ask it
Plans rest on quiet beliefs: the data is clean, the supplier can deliver, the client will reply within a day. List them, pick the one that would hurt most if it were wrong, and test that one first.
How do change requests get handled once we have started?
Why ask it
If people simply ask whoever is doing the work, every request gets a yes and the date pays for it. Even a shared list that the sponsor reads once a week is enough of a route.
Is there a written brief or plan, and when was it last updated?
Why ask it
With nothing written, the project lives in several heads in slightly different versions. If there is a document, look at its date before its contents and ask who is allowed to change it, since people will quote it at you either way.
What standard does the work have to meet, and who judges that?
Why ask it
Good enough for a pilot and ready for every customer can be months apart. An example of past work that met the bar will settle more than any adjective, so ask to see one.
How does work get reviewed before it goes out?
Why ask it
Ask who reviews, how long it usually takes and what was last sent back. If everything is reviewed in one batch at the end, the reviewer's diary becomes part of your schedule, so find out whether early drafts can be looked at as they appear.
Team
What is my role on this, and what do you expect from me in the first month?
Why ask it
Worth asking even when it feels obvious, because a title such as lead or analyst means different things on different teams. Ask what you are expected to decide on your own and what you should take to someone else first.
Who is on the team, and what is each person actually responsible for?
Why ask it
You are listening for one name against each piece of work. Where two people share something, ask which of them would be called if it went wrong, and write that name down.
How much of each person's week is really set aside for this?
Why ask it
A team of six on paper can be a person and a half in practice. Find out what else each of them is carrying, and which job wins when both fall due on the same Friday.
What does the team need that it does not have yet?
Why ask it
This is the resources question put so that it gets a list: a missing skill, a test environment, a data set, a licence. Each item wants an owner and a date, because a gap nobody is chasing tends to come to light in the week it is needed.
Who knows the most about this subject, and can I get time with them?
Why ask it
Somebody holds the awkward details in their head, and often they are not on the team list at all. Book the hour early, because their calendar is likely to be the scarcest thing on the project.
Who decides when there is a disagreement?
Why ask it
Sooner or later two sensible people will want different things. Find out now whether that goes to a lead, a committee or whoever argues longest, and whether the decision gets written down afterwards.
Who has to be consulted before a decision, and who only needs to be told afterwards?
Why ask it
Sort the names into two piles while nothing is at stake. The awkward mistake is telling someone who expected a say, and it is easier to move a name between piles now than to apologize later.
How closely does the sponsor want to be involved?
Why ask it
Some sponsors want a monthly summary and others want to see every draft. Both are workable once you know which you have. Learning it after a decision has been reversed is the expensive way.
Who are the stakeholders, including the ones who are not in the room?
Why ask it
Support staff, finance, the people who will run the thing afterwards: whoever is left out of kickoff tends to arrive near the end with objections that are entirely fair. Finding them now costs one meeting.
What tools and systems will we work in?
Why ask it
Access is often the slow part. Ask which accounts, licences and permissions you will need and who grants each one, since how long that takes depends on the employer and is better started before your first day.
Where do decisions and project notes get written down?
Why ask it
If the answer is a chat channel, decisions get hard to find within a few months. Ask for one agreed place where each decision is recorded with its date and its reason, even if it is only a running page.
Schedule
What are the main milestones, and which ones matter to people outside the team?
Why ask it
Split the list in two. A checkpoint only the team sees can move a week with no harm done, while a date a customer or another department has planned around cannot, and that second kind is where any spare time should be kept.
Where does the project stand today against the plan?
Why ask it
Listen for what is finished as opposed to what is in progress. 'Nearly done' can describe one task for a month, so ask to see the thing itself, whether that is a draft, a demo or a signed form.
What has changed since the plan was written?
Why ask it
Ask for events: someone left, a supplier slipped, a requirement was added. Then ask whether the end date moved each time. If it did not, the difference is coming out of somewhere, often the testing or people's evenings.
What is the first thing due, and who is waiting on it?
Why ask it
The first delivery colors how the rest of the project is seen. Knowing who is waiting tells you whether a slip in the opening weeks stays inside the team or is noticed by someone who matters.
How was the timeline estimated, and by whom?
Why ask it
An estimate from the people doing the work deserves more trust than one worked backward from a promised date. If it was worked backward, say so out loud now, while the plan can still be changed.
Which tasks have to finish before others can start?
Why ask it
This chain sets the true length of the project. A delay on it moves the end date while a delay elsewhere may cost nothing, which tells you what to watch every day and what to leave alone.
How much slack is in the schedule, and where does it sit?
Why ask it
A plan with no buffer is a forecast that nothing will go wrong. Slack held at the end protects the deadline. Slack spread thinly across every task usually gets used up without anyone deciding to spend it.
How often do we report progress, and in what form?
Why ask it
Settle the rhythm and the format once: a weekly note, a demo every other week, a dashboard that somebody actually opens. An unread report is worse than none, because it lets everyone assume someone else is watching.
Which regular meetings come with this project?
Why ask it
Add up the standing hours before you accept them all. It is easier to suggest turning one into a written update at the start than three months in, when it has become somebody's meeting.
Risks
What is the single biggest risk to this project?
Why ask it
Asking for one risk tends to get a more candid answer than asking for the list, which produces the register. Notice whether people name something technical or a person, and whether the team and the sponsor name the same thing.
Has this been attempted before, and what ended that attempt?
Why ask it
Plenty of projects are a second try under a new name. Whatever ended the first one, a missing budget, a system that would not cooperate, a sponsor who moved on, may still be there, and people seldom bring it up unasked.
What are we depending on from other teams or vendors?
Why ask it
You carry the deadline for these without any control over them. For each one, ask what was agreed, who agreed it and whether it is written down anywhere.
How will we know early if we are off track?
Why ask it
A percentage complete tells you little until it stops moving. Ask for something you can look at in the first few weeks, such as a working slice, a first batch of data or an approved design, and a date by which its absence would count as a warning.
Are there legal, privacy or compliance rules this project has to meet?
Why ask it
The answer is different in every country and sector, and no list can tell you which rules are yours. Find the person at this organization who owns the question, ask how long their review normally takes, and put that in the plan as a task with a date.
What is the fallback if the riskiest part does not work?
Why ask it
'We will work it out' is a hope, not a fallback. Ask what the smaller version of the project looks like, and at what point someone would make the call to switch to it.
Who is skeptical about this project, and what is their argument?
Why ask it
The doubter has often seen a real weakness and may be the best informed person available to you. Hear the objection from them directly, since a retold version usually arrives weaker than the original.
Which person would be hardest to replace if they left halfway through?
Why ask it
There is often a task only one person can do. Spotting it early leaves time to pair someone with them or get the steps written down, before a holiday or a resignation runs the experiment for you.
If something goes wrong, who needs to hear first, and how?
Why ask it
Raise this before there is any bad news to deliver. With a named person and an ordinary channel, a slip gets mentioned while it is still small. Without them, people wait for a good moment that does not come.
What would make us stop the project altogether?
Why ask it
Stopping rules are seldom agreed in advance, which is one way a struggling project runs on long after it should have ended. Conditions set at the start, such as a cost ceiling or a test that has to pass, let someone make the call calmly.
What has turned out harder than expected so far?
Why ask it
For a project already underway, this beats asking how things are going, which only gets 'fine'. The reply points at where the original estimate was thin, and that area tends to keep producing delays.
Wrap-up
Who takes this over at the end, and what will they need from us?
Why ask it
Handover is easy to leave until last, and it is real work: training, documentation, someone to call when it breaks. Naming the receiving team early often changes how the thing gets built, because they can say what they are able to support.
After launch, who checks whether it actually worked?
Why ask it
Delivery and success fall on different dates. If the team disbands with nobody assigned to look at the result, the organization never learns whether the project was worth it, and the next one starts no wiser.
What went well that we should do the same way next time?
Why ask it
Reviews tend to drift toward what went wrong, and the good habits get lost because nobody wrote them down. Ask for something specific enough to copy: a weekly demo, a shared checklist, a supplier worth using again.
What would you do differently if you were starting this again?
Why ask it
It works at the end of a project and partway through one, and it is a fair thing to ask someone presenting their work. If the answer is a list, ask which item would have saved the most time.
What surprised you most on this project?
Why ask it
Surprises mark the places where the plan and the real work parted company, so the answer is often more specific than anything in the final report. People tend to enjoy telling this one, which makes it a good question after a presentation.
Which part of it are you proudest of?
Why ask it
For when someone is telling you about a project of theirs: a colleague, a student, a job candidate. What they pick shows what they think good work is, whether that is the clever part, the tidy part or the part that helped someone.
What was your own part in it?
Why ask it
On a group project the word 'we' can cover a lot. Asked kindly, this lets a quiet contributor claim their work. Follow it by asking about one decision they made themselves and how they reached it.
Getting Briefed on a Project
Practical guidance for the conversation itself
Using the list
Pick the group that fits the meeting
Basics and Scope belong to the first conversation. Team and Schedule suit the planning session that follows, Risks is worth repeating at every status review, and Wrap-up is for the last weeks and the review afterwards. Nobody needs the whole list in one sitting.
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, turns assumptions into corrections while they are still cheap to make.
Find the person who was here for the last attempt
On a project that has been tried before, someone usually remembers why it stopped. A short conversation with them can tell you what no document does.
Project management questions to ask the sponsor
If you are running the project, some of these go to the sponsor and not to the team: which of date, budget and scope gives first, how closely they want to be involved, who signs off, and what would make them stop. The team can only guess at those answers, and the guesses tend to come out as arguments near the deadline.
When you are evaluating a project
Asked whether a project should go ahead, or to judge one that is already running, begin with the last four questions in Basics: the full cost, what else the team could be doing, the cheaper route and who stands behind the benefit. Then turn to Risks and ask what would make everyone stop. A proposal with no answer to those is not ready for a decision yet.
When the project is someone else's
If a colleague, a student or a job candidate is describing a project to you, open with the problem it was meant to solve and then go to the Wrap-up group. One decision explored in detail shows more about how they work than the whole story told quickly.
What the answers tell you
Vague success criteria tend to mean a moving target
If nobody can state what done looks like in observable terms, the definition is likely to be supplied later by whoever is least satisfied.
Work without a named owner tends to wait
A task assigned to a team and not to a person is easy for everyone to leave to someone else. 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 often negotiable, and dates with a legal or contractual cause usually 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.
Asking once and never again
Answers about status, slack, dependencies and who is stretched go stale within weeks. Put the questions from Schedule and Risks to the team again at each milestone, and compare what you hear with what you wrote down last time.