Projects — User Guide

Projects works best when roles are clearly separated.

• Projects Admin
• Controls module structure and governance.
• Defines status rules, templates, Task Type standards, customer-visibility rules, and closeout discipline.
• Approves structural changes to milestone templates, task standards, or project rules.
• Should not casually interfere with day-to-day delivery notes unless governance intervention is needed.

• Project Manager
• Owns project execution.
• Creates new project records, defines milestones and phases, assigns Project Owners or acts as owner directly.
• Monitors progress, updates major statuses, reviews blockers, and controls closure readiness.
• Reviews overdue work, dependency risk, milestone movement, and time-entry completeness on a recurring cadence.
• Should not bypass template rules or closure requirements without governance approval.

• Team Member
• Updates assigned work inside the project record.
• Updates task status, attaches files, adds execution notes, replies to project discussions, and logs time against real project or task work.
• Should not change milestone structures, customer-visibility settings, or core ownership rules unless authorized.

• Timesheet Reviewer
• Reviews recorded effort quality.
• Checks whether time entries are linked to the correct project or task, whether descriptions are useful enough for review, and whether weekly cutoffs are respected.
• Is not responsible for rewriting project scope or task design.

• Customer Viewer
• When customer access is enabled, sees only approved customer-facing content.
• Can view selected progress updates, approved files, and customer-safe notes such as Public Notes.
• Should not see unrestricted internal notes, private comments, or internal execution discussions.

A good governance model usually keeps template structure with Projects Admin, milestone baseline and major scope change control with Project Manager plus Projects Admin when needed, customer visibility with Projects Admin and Project Manager, and project closure approval with the Project Manager under a defined closeout rule.

Before using Projects live, complete setup in a controlled way:

1. Define project statuses and status-transition rules.
2. Configure milestone templates for recurring project patterns.
3. Define mandatory task rules (owner, due date, priority, and status discipline).
4. Configure Task Type values for classification, filtering, governance, and reporting.
5. Define Task Dependency rules for Waiting for, Blocking, Reference, and Linked Tasks.
6. Define notes and file governance (internal notes vs Public Notes, pinning rules, naming/versioning).
7. Define timesheet policy (project-level, task-level, or both; description quality; weekly cutoff; reviewer ownership).
8. Publish customer-visibility rules (who can enable access, what can be shared, and how private notes remain private).
9. Agree on a weekly review cadence (milestones, overdue/blocked tasks, and time-entry completeness).
10. Publish a closeout checklist.
11. Test core scenarios before go-live: project creation, milestone assignment, task assignment, dependency linking, blocker escalation, time logging, customer-safe sharing, and controlled project closure.

1) Create a project

Create a project record when work needs a controlled delivery space. The record should include project name, scope, start date, target end date, status, members, and the primary Project Owner. Do not create a project without ownership and basic scope.

After creating the record, add core team members and confirm visibility levels (full execution access vs review-only access).

2) Define milestones and phases

Divide the project into milestones or phases with target dates and expected outcomes. Each milestone should have a responsible owner or reviewer. If milestones depend on each other, define those dependencies early.

3) Create and assign tasks

Create tasks under the project or milestone based on team structure. Each task should have an owner, due date, priority, and current status. When Task Types are used, classify each relevant task.

Keep attachments, notes, comments, and files inside the task/project record instead of separate chat threads.

4) Set and manage dependencies

Use dependency relationships to expose risk and protect timelines:

• Waiting for: completion depends on other task work.
• Blocking: current task is preventing another task from progressing.
• Reference: context-related link without strict blocking.
• Linked Tasks: closely connected tasks with partial status synchronization.

Use dependencies for critical work, inter-team handoffs, and milestone-sensitive sequences. Respect system warnings for blocked tasks, incomplete waiting tasks, duplicate dependencies, and circular dependencies.

5) Manage notes, Public Notes, and pinned notes

Use internal notes for delivery discussions and decisions. Use Public Notes for customer-safe updates. Use pinned notes only for high-impact decisions and references the team must see quickly.

6) Track files, discussions, and activity history

Keep important attachments in the project workspace (deliverables, references, requirement documents, approvals, customer-facing artifacts). Use activity history for change traceability and review.

7) Log time and review effort

Log time against real project/task work with meaningful descriptions. Review effort by project, task, user, and period to improve execution visibility and cost awareness.

8) Use customer visibility carefully

When customer access is enabled, share only selected files and approved updates. Keep internal notes and private execution context hidden. The project record should remain the source of truth for customer-safe status communication.

9) Close the project properly

Before closure, verify milestones are complete, remaining tasks are closed or cancelled with rationale, final deliverables are attached, unresolved items are documented, and a closure summary is recorded. Move to closed status only under the defined governance rule.

A good closure summary includes final outcome, completion date, handover notes, remaining risks (if any), and where final references are stored.

Projects supports management outputs that should be reviewed regularly:

• Project progress summary: status, completion trend, owner, and key updates.
• Tasks by status: open, in-progress, overdue, and completed work by owner and priority.
• Overdue list: past-due tasks, owners, delay duration, and blocker context.
• Milestone review: milestone dates, completion state, and slippage indicators.
• Time spent by project: effort by project, task, team member, and period.
• Delivery closure summary: final outcomes, unresolved items, deliverables, and close date.

• Always assign one clearly accountable Project Owner.
• Every active task should have an owner, due date, and meaningful status.
• Standardize Task Types across teams.
• Use dependencies for critical sequencing before delays appear.
• Use Public Notes intentionally for customer-safe communication; keep internal notes for operational context.
• Log time continuously, not retroactively at week end.
• Require a documented closure summary and deliverable check before closing a project.

Project statuses are inconsistent across teams

Standardize status vocabulary and restrict who can change the status framework.

Milestones are not being updated

Assign milestone review owners and include milestone review in weekly cadence.

Tasks are created without owners or due dates

Make those fields mandatory and prevent incomplete tasks from moving into active execution.

Hidden blockers keep appearing

Enforce Task Dependencies for critical work and review Waiting for and Blocking relationships weekly.

Timesheets are incomplete

Tie review to a weekly cutoff and require each entry to link to a project/task with a useful description.

Customers see too much or too little

Define customer visibility per project, use Public Notes for approved communication, and keep internal notes private.

Projects are closed without clean handover

Enforce a closeout checklist, require final deliverables, and make closure-summary approval mandatory.

Teams confuse Projects with Workload Planner

Reinforce module boundaries: Projects is for execution, milestones, tasks, dependencies, and closure. Workload Planner is for capacity balancing and load planning.