How to Set Up a Project Workspace

Information only — not legal advice.

Set up a project workspace around the work people need to complete. Before building folders or inviting everyone, agree the project's purpose, participants, deliverables and information boundaries.

1. Write a short workspace brief

Record the project name, sponsor, workspace owner, expected finish date and principal outputs. State what belongs here and what belongs in another controlled system. For example, a project may need staff availability but not medical details or payroll records.

Fictional example: a library refurbishment team needs drawings, meeting minutes, procurement decisions, site logs and handover evidence. HR case files remain outside the project workspace.

2. Choose a small structure

• Project administration: the brief, roles, contacts and agreed working rules.
• Working information: drafts, calculations, surveys and coordination material.
• Issued information: outputs released for a stated purpose, with revision and issue history.
• Decisions and actions: meeting minutes, decisions, risks and follow-up registers.
• Delivery evidence: inspections, daily logs, photographs and acceptance records.
• Handover: as-built information, manuals, warranties and outstanding obligations.

These are example categories, not a universal folder standard. Adapt them to the project and avoid empty layers that nobody understands.

3. Define the minimum information for each record

Start with an identifier, title, type, owner, status, revision where relevant, date and links to related work. Add fields only when somebody uses them. For a drawing, include issue purpose; for an action, include one accountable owner and a due date; for equipment, include an asset identifier and location.

Write one completed example of each important record type. Examples make naming and status rules easier to follow than a long abstract policy.

4. Assign access and responsibilities

Distinguish administration, contribution, review and receipt of issued outputs. External contributors should receive the relevant project area, with an owner and review date for their access. Use named accounts where accountability is needed.

Test access with representative roles before adding sensitive information. Check shared links, inherited permissions and downloaded copies as well as the main interface. Identify who removes access when a person leaves or a supplier finishes work.

5. Connect decisions to delivery

In the library example, decision DEC-012 accepts a revised shelving layout. Action ACT-034 asks the designer to issue drawing D-028. The action closes only when the agreed issue exists and the reviewer confirms it. A comment saying “done” is not sufficient evidence by itself.

6. Run a small pilot

Ask a contributor to create a draft, a reviewer to return comments and an authorized person to issue the corrected output. Then ask someone unfamiliar with the process to find the latest issue and its decision history. Record misunderstandings and simplify the guidance before expanding use.

7. Establish a review rhythm

At a regular project review, check overdue actions, blocked work, pending approvals, expired links and superseded information. Assign each correction to a person and date. Separately test recovery and review access at a frequency suited to the project's risks.

8. Plan closeout now

Agree the recipient, required formats, export contents, acceptance checks and retention responsibilities. Ensure important links still work for the recipient. Remove temporary access when appropriate, while preserving records that must be retained. An archive nobody can search or open is a poor handover.

Related reading: Digital Workspaces, Common Data Environments, Meeting Minutes and Action Registers and GDPR and Collaboration Platforms.

Important information

This article provides general information and does not constitute legal advice or replace a qualified professional's assessment of your circumstances. Laws, official guidance, standards and product features can change. Check current primary sources and the requirements applicable to your jurisdiction, contract and project before making decisions. Examples illustrate the discussion; they are not official rulings or instructions for a particular case. For legal decisions, consult a qualified lawyer; for technical or other specialist matters, consult the responsible professional.