Written by Marijn Overvest | Reviewed by Sjoerd Goedhart | Fact Checked by Ruud Emonds | Our editorial policy

One Project Per What, The Scoping Question

The scoping question matters because projects’ compound context over time. A Project set up at the right scope becomes increasingly useful every time the procurement team works inside it. A Project set up at the wrong scope produces context friction instead of context leverage.

The scoping pattern that works for most procurement teams.

One Project per strategic category. The category Project holds the spend overview, the supplier list, the market brief, and accumulates conversation history around category-level work, strategy refreshes, supplier reviews, consolidation analyses, and risk assessments. This is the most common Project type and usually the most valuable.

One Project per active supplier renewal. When a strategic supplier renewal is in flight, a dedicated Project keeps the renewal-specific context together, the current contract, the performance history, the negotiation prep, and the renewal correspondence. The Project retires when the renewal completes.

One Project per major initiative. Consolidation programmes, supplier rationalisation efforts, ESG transition programmes, anything that touches multiple suppliers, categories, or stakeholders, and runs for a defined period. The initiative Project consolidates the cross-cutting context that would otherwise get lost.

A procurement function of twelve to fifteen people typically runs five to fifteen active Projects at any time. Below five, the Project mechanism is underused. Above twenty, Projects usually start duplicating each other, and the context is harder to maintain. The exact number depends on the procurement team’s structure and the number of strategic categories.

Projects vs Memory vs Cowork, How They Work Together

The three-layer context model for Claude in procurement work combines Memory, Projects, and Cowork. Each does something the others do not.

Memory provides the always-on organisational baseline, the user’s role, the company’s fiscal calendar, and the standard frameworks the team uses. Memory applies to every Claude conversation, inside Projects and outside them.

Projects provide the work-specific context, the files, the conversation history, and the custom instructions scoped to one piece of work. Project context layers on top of the memory inside that Project.

Cowork provides the file-level working capability, Claude reading, writing, and producing files directly on the user’s computer. Cowork mode is a way of working inside a Project, not a replacement for it.

The full setup for an effective procurement Claude user looks like this: Memory configured with the always-on context (ten minutes, once); a Project per strategic area of work (fifteen minutes each, whenever a new one is needed); Cowork mode enabled for the file-intensive work. The compound effect is what separates procurement teams getting real value from Claude from teams treating it as a chatbot.

Setting Up Your First Procurement Project in 15 Minutes

The sequence that works for the first Project.

Step 1, Pick a real piece of work, not an experimental one.

The first Project should support the work the procurement professional is actually doing, not a “let me see if Claude can do this” test. A current category the procurement team manages, an upcoming supplier renewal, or an active initiative. The first Project that supports real work pays back within days.

Step 2, Draft the briefing document.

Using the seven-field template. Two or three pages. This is the reusable component, once drafted, it can be copied into every subsequent Project with only field three (category-specific scope) changing.

Step 3, Gather the Project files.

The spend overview for the category. The active supplier list with performance data. The relevant market intelligence. The current contracts. Usually four to six files, nothing more.

Step 4, Create the Project in Claude.

Upload the files. Paste the briefing document content into the custom instructions field (or upload it as a file and reference it in the instructions). Name the Project with a clear convention, “Packaging Category 2026” works better than “Work Stuff”.

Step 5, Test with a real question.

Ask Claude a question that should be informed by the Project context. “Given our packaging category profile, what would a reasonable supplier risk assessment look like?” The answer should be specific to the category, not generic. If the answer is generic, the briefing document or the files need adjustment.

Step 6, Use the Project for the next two weeks of real work.

Every time a packaging-related question comes up, ask it inside the Project rather than starting a new chat. The Project compounds context across the two weeks; by the end, the quality of the output is significantly better than the first answer.

After the first Project, each subsequent Project takes five to ten minutes to set up because the briefing document is already written. The procurement team’s library of Projects builds quickly once the first one is in place.

For procurement teams rolling Claude out across the function, not just to individual pilot users, the Project setup is usually part of the onboarding. The AI Fundamentals for Procurement Teams program includes the briefing document template and the Project setup sequence as part of its team enablement module.

Governance and Sharing, Who Sees What

Projects scope context, which also means project scope governance. The governance questions are straightforward.

Which Projects are personal and which are shared? On the Claude Team and Enterprise plans, Projects can be shared with other users. Category Projects are usually appropriate to share with the category team. Supplier-specific renewal Projects may be more sensitive, share with the negotiation team, not the whole procurement function. The policy should specify the defaults.

What data is appropriate to upload into a Project? The same governance applied to file sharing in other systems applies here. Confidential commercial terms in a supplier-specific Project are usually appropriate if the plan has the right data-handling terms. Broad commercial information scattered across many Projects is a governance question worth thinking through.

When does a Project retire? Renewal Projects retire when the renewal completes. Initiative Projects retire when the initiative ends. Category Projects are usually long-lived but should be reviewed annually. Stale Projects accumulate outdated context and gradually degrade Claude’s output; a regular review prevents this.

Related resource: The Claude Memory Guide, The 10-minute Memory setup for procurement, with the 6-category template and the common pitfalls to avoid.

Related resource: Building Custom Claude Skills for Procurement Teams, The complete playbook for turning procurement SOPs into reusable Claude Skills, SKILL.md anatomy, 5 complete examples, design best practices, rollout approach, and the Skill-chaining pattern.

Conclusion

Claude projects are ultimately less about technology and more about continuity. Procurement work rarely happens in a single conversation or a single day. Supplier negotiations stretch across months, category strategies evolve over quarters, and risk assessments continuously change as markets shift. A project gives procurement teams a way to keep that context together instead of restarting from zero every time work resumes.

That continuity has a practical impact on the quality of procurement work. Instead of spending time repeatedly explaining the same supplier background, category structure, or internal constraints, procurement professionals can focus on higher-value thinking, challenging assumptions, exploring scenarios, and making better commercial decisions. The AI becomes more useful because the procurement team has invested in creating the right environment around it.

The teams seeing the strongest results are not necessarily using more advanced prompts than everyone else. They are simply building better foundations. A well-structured project, a clear briefing document, and consistent use over time create an environment where Claude can support procurement work in a way that feels far more practical and relevant to the realities of the function.

In many ways, projects are what turn Claude from a general AI assistant into something that feels much closer to a procurement analyst working alongside the team every day.