Questions from Beginners
Most people become a project manager by being handed a project, not by training for one. These are the questions that come up in the first few weeks — including the ones people are slightly reluctant to ask out loud.
In short
- The job is mostly decisions and unblocking, not planning and reporting. That surprises nearly everyone.
- You will not have authority over most of the people involved. That’s normal and it is not a mistake.
- Asking “obvious” questions early is the highest-value thing a new project manager does.
- Nobody feels qualified in their first project. The ones who do it well simply write more things down.
What does a project manager actually do all day?
I’ve just been given a project. What do I do first?
Six things, in about two hours, before touching a plan:
- Find out who decides. Ask directly: if we have to choose between the deadline and half the features, who makes that call? A vague answer is your most important early finding.
- Write the problem in one sentence — the problem, not the solution. “Sales call the same lead twice”, not “build a CRM”.
- Write four things the project is not doing. Keep going until one surprises somebody.
- Read the last two similar projects’ notes. Ten minutes, and it usually hands you the risk that actually materialises.
- Book the slow external thing now — the security review, the legal check, the environment. Whatever has a queue.
- Agree what “done” means for the first two deliverables.
That’s covered properly in 2.1 Initiation and 8.1.
I don’t have authority over these people. How am I supposed to manage them?
You mostly won’t, and this is the normal condition rather than a mistake in your appointment. Project teams are usually borrowed from managers who still own the people’s objectives and reviews.
What works instead of authority: make the point of the work visible, give people real ownership of an outcome rather than a task list, remove obstacles fast enough that they notice, and tell their actual manager when they did well. That last one costs a message and lands where their career is decided.
When a genuine priority conflict appears, it is resolved with the person’s manager, not with the person. Putting someone in the position of choosing between you and their boss is unfair and doesn’t work.
How detailed should my plan be?
Detailed enough for the next few weeks, coarse beyond that. Tasks of a few days each near term; blocks of work further out, refined as they approach.
A useful stopping rule: if knowing whether a distant task takes three days or four wouldn’t change anything you do this month, don’t estimate it yet. See 2.2 Planning.
Everyone says the deadline is impossible. What do I do?
First, find out whether it is. Estimate from the bottom up — break the work into pieces and add them — and compare that to the date. Now you have a number rather than a mood.
Then present the gap with options: move the date, cut this specific scope, or add these specific people (noting that adding people to a short project usually makes it slower before it makes it faster). Take that to the sponsor as a decision, not a complaint.
What doesn’t work is accepting the date privately, hoping, and reporting green. That is the failure pattern in 8.2.
Am I supposed to know how the work is done?
No, and trying to is a common early mistake. You need to understand enough to tell whether an estimate is plausible and to ask a useful second question — not enough to do the work.
“I don’t know how that works — what makes it hard?” is a strong question, not a weak one. It gets you the actual risk, and it signals that you would rather be accurate than look knowledgeable, which is exactly the culture you want when something goes wrong later.
How do I run a meeting that isn’t a waste of time?
Decide what the meeting is for and cut everything else. There are only three good reasons to gather people: to make a decision that needs several of them, to resolve a disagreement, or to build shared understanding.
Collecting status is not one of them — a tool does it better and asynchronously. If your meeting consists of people reading out what a board already shows, the meeting is compensating for a board nobody trusts, and that’s the thing to fix. See 4.3.
Somebody on the team isn’t delivering. What do I do?
Start by assuming it isn’t about them, because it usually isn’t. In order: are they blocked and haven’t said? Are they actually available, or committed to two other things? Was the task ambiguous? Was the estimate somebody else’s?
Ask, privately and without an audience: “what’s making this hard?” In most cases you get a real answer and something you can act on. If it genuinely is a performance matter, that belongs with their manager — it is not a project-management problem and treating it as one damages both.
I feel like I’m just chasing people all day.
Two possible causes, with different fixes. If you are chasing for status, the tool isn’t trusted or isn’t quick to update — fix that and the chasing disappears. If you are chasing for decisions and approvals, that’s not chasing, that’s the job; the improvement available is making each ask smaller and more decidable.
“Can you approve the design?” is a big ask. “Can you confirm we can drop multi-language from phase 1, by Friday? Default is yes if I don’t hear” is a small one, and it usually gets answered.
Do I need a certification?
Not to do the job. They help in job markets where they’re used as a filter, and they give you a shared vocabulary, which is genuinely useful in large organisations. They do not teach the parts that decide outcomes — noticing early and getting decisions made. See 10.2.
How do I know if I’m doing it well?
Not by whether the project is on track this week — that depends on things outside your control. Four better signals:
- People bring you problems early. The single strongest indicator. It means the last three times somebody did, it went well for them.
- Decisions get made in days, not weeks. Whether you make them or route them, the queue is short.
- Nobody asks you what the status is. They can see it.
- Surprises are small. Not absent — small, because they surfaced while they still were.
Everyone else seems to know what they’re doing. Is it just me?
No. Project management looks like confidence from outside and feels like partial information from inside, permanently. The experienced people are not more certain; they have simply seen enough projects to recognise which uncertainties matter.
The one habit that closes most of the gap is unglamorous: write things down. What was decided, what was assumed, what somebody promised. Almost everything that separates a well-run project from a chaotic one is a written sentence that took thirty seconds.
How this looks in AB
For a first project, the useful advice about AB Projects is mostly about restraint. Use four fields — title, owner, status, due date — and add more only when a specific question keeps going unanswered. An elaborate configuration on day one is a set of fields somebody has to fill in forever.
Three habits worth having from the start:
- The project description is the purpose. If it names a solution rather than a problem, rewrite it. You will point at it repeatedly.
- Decisions go in comments on the task they concern. Thirty seconds now, and it answers “why did we do it that way?” in month five.
- One pinned Wiki page for scope and exclusions. It is the thing you point at when someone asks “didn’t you also handle X?”
Terms used on this page
- Sponsor
- The person who funds the project and decides trade-offs the team cannot. Finding out who this is comes before everything else. More →
- Matrix organisation
- A structure where people report to a line manager while working on projects led by someone else. Why you have responsibility without authority. More →
- Blocker
- Anything preventing work continuing that the person doing it cannot resolve alone. Removing them is most of the job. More →
- Bottom-up estimating
- Estimating each small piece and summing, so the total is a consequence rather than a target the parts were forced to fit. More →
- Rolling wave planning
- Planning near-term work in detail and distant work in blocks, refining as it approaches. The answer to “how detailed should my plan be?” More →
- Escalation
- Passing a decision to someone with the authority to make it. Doing this early is a sign of competence, not of struggling. More →
Related reading
9.2 Practical Advice
Small habits with disproportionate returns, once the basics are in place.
2.1 Project Initiation
The first-two-hours list, with the reasoning behind each item.
4.0 Team Management
Working with people you don’t manage, which is nearly everyone on a project.