You wrote a careful prompt, and the answer still came back polished and slightly wrong. It ignored a decision the steering committee made last month, used a date that has since moved, or proposed an option the contract rules out.

The wording was not the problem. The model was working without the project.

In my previous article, Prompt Engineering for Project Managers: Treat the Prompt as a Requirement, the point was that a clear requirement produces better work. This one is about what comes next: what the AI needs to know about the project before it can answer well. That is context engineering. For a project manager, it is the deliberate selection, structuring, and control of the information an AI uses for a project task. It does not have to start with building an AI system. It starts with a few decisions: what the AI should see, how to structure it, and what it should not assume. You already make these decisions whenever you prepare a briefing pack.

Prompt vs. Context

Context is whatever the model has in front of it when it answers: your instructions, the project information you give it, and the conversation so far. If something important is missing, the model cannot account for it, and it may fill the gap with something that sounds reasonable but does not fit your project.

Working with AI comes down to four questions:

• Prompt: What do I want AI to do?
• Context: What does AI need to know?
• Evaluation: How do I verify the output?
• Decision: What remains my responsibility?

A good prompt can produce a good answer. Good context makes useful answers more consistent.

What to Put In

Take only what the question needs from this list:

• Objective and scope, including what is out of scope
• Constraints: fixed dates, contract terms, capacity, fixed suppliers
• Current status, with the date each figure was true
• Relevant risks or issues, as an extract
• Decisions already made, with owner and date
• Baseline and approved changes
• Lessons learned from similar work
• Who will read the output

More Context Is Not Better Context

The shortcut is to upload every file, and it usually backfires. Old versions compete with new ones, and the facts that matter get buried.

Conflict is the bigger problem in real projects. The schedule says June 15, the change log says June 30, and the steering committee decision says July 15. Give a model all three and it may answer confidently from the wrong one. Providing sources is not enough. Decide which source has authority, and say so in the prompt.

For every item you include, know where it came from, when it was true, how much authority it has, and what it supports. That also makes checking quick, because every claim in the answer traces back to something you can open.

Three Ways to Use It

Replace the placeholders with your own project data. Each example closes with what to check and what stays your decision.

1. Risk Analysis

Situation. One supplier is late on a critical component, integration testing is close, and the delivery date is contractual.

Context. The baseline, approved changes, the supplier’s commitment, the contract milestone, the current register entry, earlier mitigation, and the decision log. Leave the rest of the register out.

Act as a senior project risk manager.

CONTEXT: [contract milestone + clause], [supplier history + date], [schedule extract + version], [earlier decisions + dates]

TASK: State the main risk as cause, event, impact. List early warning indicators, response options, and what needs sponsor input.

RULES: Use only this context. Mark assumptions. List what is missing.

Check. Read every assumption the model marked, and ask whether probability and impact fit your organization. Then ask it: “What am I missing before I present this to the steering committee?”

Your decision. The model analyzes and compares. You rate the risk, approve the register entry, and decide what gets escalated.

2. Executive Reporting

Situation. You have the data and ninety seconds of the sponsor’s attention. Writing the report is rarely the hard part. The hard part is deciding what deserves the sponsor’s attention and what does not.

Context. Keep a stable block you reuse every week (scope, baseline, audience, format) and add a weekly block (progress, milestones, new risks, decisions), all dated.

Prepare the weekly status report for [project].

STABLE: [scope], [baseline + approval date], [audience], [format: 200 words, fixed sections]

THIS WEEK (as of [date]): [progress], [milestones], [risks], [decisions]

Use only this information. If something is missing, ask me.

Check. Trace each figure to the data block and confirm the date. Then check the status color yourself, because a polished summary should never override the project’s actual status.

Your decision. The status rating and what the sponsor hears. Try one more step: “Read this as the sponsor. What five questions would you ask me?”

3. Change Request Analysis

Situation. A change would add about six weeks. Go-live is fixed, the team is near capacity, and testing sits on the critical path.

Context. The baseline, the change request, resource loading, the critical path, and earlier scope decisions.

Prepare a change request analysis.

CONTEXT: [baseline + version], [change request ID], [capacity + date], [critical path], [earlier scope decisions]

Compare: A. Add it, keep the deadline. B. Add it, move the deadline.

C. Defer to a later release. For each, assess scope, schedule, resources, quality, delivery risk, stakeholders. Name the trade-offs and missing information. Do not make the decision for me.

Check. Make sure each option respects your constraints and that no impact is stated without a basis in the context.

Your decision. The recommendation to the change control board. Perform Integrated Change Control still runs through people. The model only lays out the trade-offs.

Before You Give AI Your Project Data, Ask Five Questions

The working sequence is select, structure, establish authority, set boundaries, verify. These five questions cover it:

1. What decision am I preparing, and who will read it?
2. Which documents are authoritative for it? Am I giving extracts, not whole files?
3. Does every item carry a source and a date?
4. If two sources disagree, have I told the AI which one is authoritative?
5. Have I told it what not to assume, and to ask when something is missing?

This also strengthens the loop from the first article: prompt, review, challenge, refine, validate, decide. Review goes faster because claims trace to named sources, and when an answer is off, fix the context before you rewrite the question.

Your Role

Better context makes a useful answer more likely, but it does not make it correct. Check the output against the plan, the contract, policy, and the people who own the work.

Everything you put in context is information you share with a tool. Know your organization’s AI policy before including confidential customer, financial, contractual, or personnel data, and leave out anything the task does not need. Professional accountability remains with the project manager.

Conclusion

Prompt engineering taught us how to state the requirement. Context engineering gives the AI the project that requirement belongs to. Treat what the model sees like any other project input: chosen on purpose, dated, sourced, and current.

Next in This Series: Loop Engineering

Prompt engineering is about asking the right question. Context engineering is about giving AI the information it needs to understand that question in its project setting. Loop engineering takes the next step: designing how we review, challenge, refine, and validate AI output consistently over time, with the decision kept with the project manager.