Every container BESS job runs the same official set of sales milestones. You do not retype them — you start the job from the company standard, then work each milestone on its own page.
Start the job from the standard
- Go to Projects and choose New from copy.
- Pick the company standard — it is offered first in the list.
- Give the job its real title and set the target completion date.
- Open the new project. The official milestones are already there, fresh: renumbered, Pending, with no dates and no links.
- Set each milestone's target date from the contracted programme.
Do the dates before work starts. They drive whether the project reads On track, At risk or Overdue, and they are what triggers the overdue nudge.
The standard itself is maintained by an administrator. If it looks wrong, say so — do not compensate by editing the milestones on a live job.
Work a milestone on its own page
Click a milestone's number on the project to open it. The project page is the overview; everything that changes a milestone happens on the milestone's page.
- Start: mark work as begun.
- Delivered by → Change: give the milestone to the department that delivers it (see below).
- Tasks → New task: break the work down.
- Tasks → Link existing task: attach a task that already exists.
- Documents → Create documents folder: keep client requirements and evidence.
- Documents → Upload: add or read files.
- Sign-off: capture the client's signature on a deliverable.
- Record FAT: record the acceptance test.
- Complete: close it.
- Cancel milestone: drop it from the project.
Give each milestone to the department that delivers it
You do not have to plan every discipline yourself. Give a milestone such as Mechanical design to Mechanical Engineering with Delivered by → Change: the department gets access to the project, one of its managers names a leader, and the leader creates the milestone's tasks and gives them to their people. You still own what it delivers and by when. Until a leader is named, the milestone shows unled. See Giving a milestone to a department and Leading a milestone.
Required tasks close the milestone
Every task on a milestone is either required or optional. A required task must be done — reviewed and closed by its manager, or auto-approved after 48 hours — before the milestone can close, and when the last required task is done the milestone closes itself. An optional task is a record of the work only. You can still close a milestone by hand with Complete and a reason.
New tasks are required by default: untick Must be done before this milestone can close to make one optional, or use Make required / Make optional on a task's row later. A required task that gets cancelled can never be done, so its row shows a warning — make it optional, or link the task that replaced it.
A failed acceptance test sends it back
Recording a FAT as FAIL moves the milestone to Blocked for re-work. It never closes the project. Raise the re-work as tasks on that milestone.
Finished milestones are closed to changes
Once a milestone is Complete or Cancelled you cannot edit it, add tasks to it, or give it a documents folder. If something has to change afterwards, that is a new milestone — not a rewrite of a closed one.
Documents and client requirements
The project gets one documents folder, created the first time you ask for it (Documents → Set up project documents, or by creating a milestone's folder). Its contents are on the project's Documents tab, which works like My Documents: folders, uploads, pages, and every earlier version kept.
- Upload and New folder add files and folders where you are. The ⋮ menu on a file has Open, Download, Upload new version, Version history, Rename, Move and Move to Trash. Every folder is a link you can send to a colleague. A file you already have in My Documents comes in with Move to a project… on it there, with every version.
- New page makes a page where you are: formatted text written straight in myWork, saving itself every 30 seconds, with no versions and no approval. Use it for site-meeting minutes, a checklist or a handover. Contributors and the PM write in it; everyone who can view the project reads it. Its ⋮ menu has Open, Rename, Move and Move to Trash. A page from your My Documents comes in with Move to a project…, like a file.
- Each milestone can have its own folder for the evidence that milestone is judged on: Create documents folder on the milestone's page, which from then on shows that folder, with All project documents to go up to the rest. A milestone's folder and the top folder keep their name and place: they show a lock and can't be renamed, moved or put in the Trash.
- Anything that has to be controlled — a signed brief, client requirements, drawings, the acceptance record — is a real EDMS document, with revisions, comments, review and sharing. Start the brief with New project brief. The Documents tab lists a controlled document with its code and status (for example "Draft v1.0") and opens it in EDMS, where it is changed; it is never renamed, moved or put in the Trash from the project.
- Trash: contributors and the PM can move files and folders to the project's Trash and restore them, and it shows who moved each one. A folder that holds a milestone's folder or a controlled document can't be put in the Trash. People who can only view the project don't see the Trash.
- The project summary — what this job is, in plain words — is written on the project's own Overview tab, in the same editor tasks and documents use. It is deliberately NOT a controlled document: no type to pick, no doc code, no review, no approval and nothing to acknowledge.
A page is not a sticky note: for a reminder only you need, use My notes in the top bar. See Sticky notes: jot it, pin it, bin it.
If starting the brief says you are not authorised to create a document type, you need the QMS_CREATE permission. Ask an administrator; it is a normal part of setting up a project manager. Uploading files needs no such permission: who may upload follows the project, as described in "Who can see a project, and who can change it".
Who can see the job
A project is not visible to the whole company. Four things put somebody on it: they run it, their department runs it, they were given access on the project's Access tab, or their role lets them see every project — and each of those carries a level, view or contribute. Only the PM grants access. The detail is in "Who can see a project, and who can change it".
Who hears about what
Each milestone has its own chat channel, and its updates post there. The project's own channel carries project-level events plus one line per milestone pointing at its channel, so the project thread stays a table of contents rather than a firehose.
Follow a milestone by clicking the star on its page. There is no separate Subscribe button — the star is the control, and it cycles through All, System-only, Muted and off.
The short version
- Start from the standard. Never retype the milestones.
- Set the target dates before work starts.
- Work each milestone on its own page.
- Give each milestone to the department that delivers it; its leader plans the tasks.
- A required task closes the milestone once it is done; an optional task only records work.
- Client requirements belong in the milestone's documents folder, not an inbox.
- Files go on the project's Documents tab; a controlled document is changed in EDMS.
Process, roles and escalation: see the Container BESS Project SOP. This article covers how to use the screens.