Context Management: The AI Skill Most Project Managers Haven't Built Yet
Two project managers. Same model. Same task - a stakeholder communication plan for a product launch. One gets a useful first draft. The other gets something so generic it reads like it was written for a hypothetical project in a textbook.
The difference isn’t the prompt. It’s the context.
Most PMs who have been using AI for a while have hit this: the outputs are inconsistent. Sometimes excellent. More often, frustratingly close to what you needed but not quite there. The natural response is to spend more time on the prompt - adding structure, being more specific, trying different phrasing. Sometimes that helps. Often it doesn’t.
What’s actually happening is simpler. The model is doing its best with what it’s been given. And what it’s been given isn’t enough.
Context Is the Input - Are You Managing It?
Here’s the thing most AI guidance doesn’t say plainly: the model has no memory of your project. Every session starts from scratch. Unless you bring the context in - deliberately, specifically - the model is working from general knowledge and whatever fragment of information you dropped into the prompt.
That’s why outputs are inconsistent. Not because the model is unreliable. Because the input varies every time.
Think about what actually affects whether a stakeholder communication plan is any good: who the stakeholders are and what they care about. The project’s current status and what’s changed recently. What decisions have been made and which ones are still open. The political context - who’s on side, who’s sceptical, what went wrong last time. Any of that missing, and the output defaults to the generic version.
A thoughtful junior colleague would ask for all of that before they started writing. The model doesn’t ask - it uses what you give it and fills in the rest. The fills are what make it generic.
What Deliberate Context Management Actually Looks Like
The PMs getting consistent, useful AI outputs aren’t necessarily using better models or writing better prompts. They’re building context as a managed asset.
That means a few specific things.
A project context document. A single reference file covering the essentials - project objective, current status, key decisions, stakeholder map, known risks and constraints. Short enough to paste into any session. Specific enough to give the model something real to work with.
The act of writing it is as valuable as using it. You can’t fill in “key decisions made” without confirming you actually know what they are. The document is a diagnostic as much as it’s a reference.
Feeding context before asking for output. Start every AI session for a given project by loading the context document - not the full project history, just the two-page reference that captures what matters. In practice, most people open a chat window, paste in whatever’s closest, and ask the question. The result reflects that.
Knowing what the model doesn’t have. Every AI session has a knowledge boundary. There’s what the model knows from training. There’s what you’ve provided in the session. And there’s what’s missing. The quality gap almost always lives in the third category.
Getting deliberate about context means being explicit about that boundary. “The model doesn’t know about the scope change from last Tuesday - I need to include that.” “It doesn’t know that the exec sponsor changed three weeks ago - that affects the tone of everything.” That awareness is the skill.
Why This Is Harder Than It Sounds
The friction isn’t technical. Most PMs understand the principle immediately. The friction is the same as any discipline that has to happen before the visible work: it’s invisible, it takes time, and the benefit is a downstream output that’s better in ways that are hard to attribute.
No one sees the context document. No one sees the session setup. They see the stakeholder communication plan that landed well, and assume you wrote a good prompt.
There’s also a learning dimension. The right level of context isn’t the same across different types of tasks. A risk synthesis needs the current risk register and recent status data. A retrospective facilitation plan needs team dynamics and what’s come up in previous retros. A stakeholder briefing needs the political map. Building the instinct for what context a given task actually requires - not too much, not too little - takes deliberate practice.
That’s why it’s a skill, not just a tip.
The Compounding Advantage
Here’s what changes once context management becomes a habit.
The context document improves with each project. The stakeholder map gets richer. The decision log gets longer. The risk history accumulates. By the end of a project, you have a working knowledge base that can answer questions faster than you could by rereading documents, that feeds the next project retrospective, and that makes AI-assisted work on the next project immediately more grounded than it was on this one.
The PMs who get the most from AI aren’t just using it more. They’re building something with each session - a body of structured project knowledge that compounds over time. The model is the same for everyone. What’s different is what they bring to it.
That advantage is available to any PM willing to treat context as something that gets managed deliberately rather than assembled on the fly.
The next piece goes deeper - what project context actually contains, three scenarios where it changes the output entirely, and how to structure documents so AI tools can use them properly.
What does your current project context look like, sitting in a file you could paste into an AI session right now? If you’d have to say “it doesn’t exist yet” - that might be the most valuable hour you spend this week.
Yes, AI helped me to write this :)