Full-kit management, in one idea

Why kit isn't just predecessors in your schedule

A Task is work your team performs — it consumes your resources, sits on the network, and its duration is something you control.

A Kit task is a readiness condition supplied from outside the task's execution — a PO another department must land, an approval a government office must grant, drawings a supplier must deliver. You don't perform it; you wait on it.

Same words on paper — “get water board approval” — but two fundamentally different management objects. Putting the second inside the first breaks both.

Why modeling kit as predecessors / milestones actively fails

1. It destroys the schedule as a management instrument. A 40-task plan with 12 kit elements each becomes a 500-line network where the critical chain drowns in procurement noise. The scheduler ends up owning data they don't control and can't verify — PO statuses, approval stages — so the plan is either perpetually stale or the scheduler becomes a data-entry clerk for other departments.
2. Predecessors carry the wrong semantics. A dependency says “B follows A by this offset” — a sequencing claim. Kit is an AND-gate: all of it, binary, or no start. Modelled as milestones, MS Project shows the task starting when dates line up whether or not anything is actually done — because % complete on a milestone is a typed number, not a verified state. No ownership, no closure discipline, no difference between “PO at negotiation” and “PO placed.” Kit tasks carry what dependencies can't: an owning function that alone can close them, weighted stages, quantity rates, and an auditable gate.
3. The signal system is impossible in-plan. A milestone is on-time or late — binary, and you learn it when it's already true. A Kit task carries a fever chart: buffer derived from touch-time, penetration against the baselined commitment, a colour that degrades automatically when nobody reports anything. It warns you a PO is eating buffer weeks before the plan would show a slipped milestone.
4. Wrong granularity of commitment. A kit template — “Casting Procurement Kit”, reused across 30 tasks and 5 projects, feeding cross-project owner worklists sorted by buffer colour — has no equivalent in a plan. Copy-pasting milestone blocks loses all cross-project comparability, exactly the portfolio view a multi-project rollout depends on.

Predecessors give you an obituary. The kit engine gives you a prognosis.

The one deliberate connection

Kit does drive the schedule — but through exactly one Start-No-Earlier-Than constraint per gated task. The entire kit reality is compressed into the single fact the scheduling engine needs — “not before this date” — leaving the network clean while the database carries the truth. That compression is the architecture.

Getting started

1. Sync from MS Project. In your plan, run KitSyncNow (the add-in). Your tasks appear here in plan order under Tasks & kits.
2. Add kit. Click ➕ Add kit on a Task — Quick add a one-off kit task (Rate or Stage), pick & mix from the Library, or attach a reusable Kit Bundle. Its kit tasks show below, editable in place.
3. Report progress. Each owner sets Your function (top bar) and clicks Report on their kit tasks — a stage (for Stage tasks) or a quantity (for Rate tasks). Only the owning function can close a kit task.
4. Write back to the plan. Run KitWritebackNow in MS Project. A late kit pushes the task out (one SNET constraint); a recovered kit pulls it back. The Kit Gate / Status / Blocking / Ready columns update in the plan.
5. Manage templates. Use Templates (top bar) to define Kit Bundle templates and Stage templates (stages + weights) — no SQL needed.
6. Sign in (when your server has login). Your tenant admin adds your e-mail under Settings → People; the first time, choose Create account on the sign-in screen to set your password. Once signed in, Your function is filled in for you and everything you do is recorded under your name. Settings → Account gives you a personal key for the MS Project add-in. What you may do, and on which projects, comes from your roles; you design and report kit only for the functions assigned to you (Settings → People).

Who does what — roles

Roles follow Rules of Flow: the people who know the work define its full kit; the people who do the work perform and report it; the plan's owner assembles the kit onto Tasks; the portfolio governs the flow. Each role is a bundle of four fixed permissions — View a project · Report kit progress · Plan the kit · Control commitments and settings — on chosen projects or all of them. Your tenant admin assigns roles under Settings → Roles; a person may hold several.

Above the roles sit two admin levels. The Tenant Admin (a flag on a person, Settings → People) manages people, functions and roles and may do everything in the tenant. The Super Admin runs the platform: creates tenants and appoints their first admin, and has no access inside a tenant's data.

The function rule. A kit task belongs to an owner function (Procurement, Approvals, Engineering-Mech…), and the functions ticked against you decide what you may touch: you design kit (Kit Designer) and report kit (Kit Owner) only for your own functions. A Project Manager with no function can attach a Procurement bundle to a Task but can neither define what is in it nor report it — that is Procurement's word. Assembly — attaching bundles, links and gaps between kit tasks, sync and writeback — is not function-scoped.

Roles are seeded per tenant and can be renamed, adjusted or extended. A Team Member role (Project Server's term) is deliberately not seeded: kit is reported by function, not by task assignment. It would return if MS Project task progress were ever reported through this app.

Reading the dashboard

Gate — OPEN / CLOSED

Is the kit done? Open only when every kit task is Complete. Purely a completion check — no dates. A closed gate blocks starting the task in MS Project.

WIP cap (under the gate pill; Portfolio in the menu)

Each business unit may carry a cap on projects in Execution. A project is released the moment work behind its release gate (the 🚦 task, else its earliest gated task) has an Actual Start in MS Project. While the cap is reached, the release gate and the tasks right behind it are held — the MS Project gate blocks the start with the usual logged override — even if the kit is complete. WIP never moves dates. Stages (Pipeline → Kitting → Execution → Closed) are derived from the plan, never typed.

⛓ Kit Chain (under the gate pill)

Preparation tasks that live in the plan (flag them Kit Chain = Flag2 in MS Project) and feed a gate — usually a ◆ milestone — by a finish-to-start link. The gate also stays closed until every flagged predecessor is 100%. They are real project work, so MS Project keeps scheduling them; the chain only adds the completion check a link cannot express. It never adds a push: the SNET is driven by the task's own kit only.

Baseline Start, Baseline Finish, Start, Finish (kit rows — MS Project's terms)

Kit tasks use the same four date words as MS Project.
Baseline Start / Baseline Finish are the kit task's commitment. They are not typed and not copied from anywhere: the system works them out backwards from the Task's own Baseline Start in MS Project (synced by the add‑in). A kit task that feeds the Task has Baseline Finish = the Task's Baseline Start − its lead days, and Baseline Start = Baseline Finish − its lead time. A kit task linked to a successor has Baseline Finish = that successor's Baseline Start − the lag, and so on up the chain. So they move only when the Task is re‑baselined in MS Project or when a lead time, lead days or link is edited (each audited) — never with progress. If the Task has no baseline yet, its live start is frozen once and used instead; the ⚓ icon on the Task row says so.
Start / Finish are the current schedule, actual once it has happened and projected until then. Start: the date of the owner's first progress report once started; before that, the Baseline Start when on plan, or a late predecessor kit task's Finish plus the lag when it is being pushed (never before today). Finish: the actual completion date once complete; otherwise the owner's date if given, else Start + remaining lead (Rem. lead if reported, else lead × (1 − % complete)), so an untouched long‑lead item stops pretending it will hit a near deadline. Red = later than baseline. The Task's kit gate date is the latest Finish among its open kit tasks.

Kit rows, Columns and the detail drawer

Kit rows are compact; pick which columns to show with Columns (remembered in this browser). Stage / Qty is editable on the row: pick the stage reached (Stage tasks) or type completed / planned quantity (Rate tasks) — only the owning function can save. Rem. lead is editable on the row too, and again in the Report progress tab (saved with the report); Detail shows it read-only. Click a kit task's name or the › at the end of its row to open the detail drawer with three tabs: Detail (name, owner, predecessors, lead time, lead days, touch %, remaining lead, remove), Report progress (the full report: stage or quantity, touch time remaining, remaining lead, remarks, progress history) and Actions (the expediting log). Escape or clicking outside closes it.

Date kit tasks (external date, no progress — use sparingly)

The third completion type, shown with 📅. Use it only when an outside party has named a date and nothing can be reported until the day: a regulator's hearing, a utility shutdown window, a customer's board meeting, a vessel ETA, a weather window. The test: between now and the day it is ready, is there anything its owner could truthfully report as having moved? If yes, it is a Stage, Rate or Yes / No item — a PO, an approval or a set of drawings is never a Date, however firmly the delivery date was promised.

A Date kit task needs a basis (what the event is, who sets its date). It is a milestone in the kit network — it links to other kit tasks in its bundle or feeds the Task directly — so it has no lead time, and its expected date is its Start and Finish: change the expected date and Start / Finish change with it (linked to a predecessor, Finish is the later of the expected date and that predecessor's Finish plus the lag). Set kit baseline freezes the expected date as its Baseline Start / Finish, so later changes show as variance; the date it is needed by — the Task's baseline start, or its successor's start minus the lag — stays visible as Late Finish (and is what Baseline Finish shows until a kit baseline is set). It is coloured by the same fever rule as every kit task: buffer used against the green and yellow lines, BLACK at 100%. Its buffer is the slack its baselined date held against the needed‑by date, plus the lag on the link to what it feeds (3+2d, or Task+2d). On or before its baseline it is GREEN; a slip eats the slack, yellow then red quickly; it is BLACK when the slack is gone — the point where it reaches, and then pushes, what it feeds. Baselined on the very day it is needed, it has no buffer at all. On top of that it has floors, because its date is the one thing that can go quiet: never better than RED with no date, a passed date, a date after the Task's baseline start, or a confirmation older than twice the interval; never better than YELLOW when late or when the confirmation is older than the interval (Settings → General, default 10 days). The owner keeps re‑confirming the date with its source — in the row's date box or in Report progress. The chip shows buffer used %, or stale / no date / overdue when that is what set the colour. When the event has happened, tick "It has happened" in Report progress.

Why sparingly: a Date kit task gives no lead indicator — it can only say the date is still believed. A plan full of them is a list of promises, and you learn of each failure on the day. The plan shows a warning when more than a fifth of its open kit is Date‑typed.

Kit baseline (the bar above the plan)

Until you set it, a kit task's Baseline Start / Finish are worked out live, so editing a lead time or a link quietly moves the commitment — and a red kit task can turn green with nothing real improved. Set kit baseline, in the bar above the task list, freezes Baseline Start, Baseline Finish and lead time, the way Set Baseline does in MS Project — for the entire project, or, if you tick kit tasks first (the checkbox at the start of each kit row; the one in the header ticks all of a Task's kit), for the selected kit tasks only. The tag beside the button reads no kit baseline, kit baseline on 2 of 4, or the date it was set. After that, buffer and colour measure against the frozen dates; a lead or link edit changes only the current schedule and shows up in the optional Start Var. / Finish Var. columns (working days later + or earlier −). The lead time is frozen too: the optional Baseline Lead and Lead Var. columns (and the drawer's Detail tab) show the lead as baselined and how far the current lead has moved from it — the buffer stays measured on the baselined lead. The optional Late Start / Late Finish columns show the live backward pass — the latest dates that still protect the Task. Kit added after the project was baselined gets no baseline automatically, exactly as a task added to a baselined MS Project plan has none: it stays derived live while you set its real lead, links and gap, and the tag reads kit baseline on 4 of 6 meanwhile. When it is planned, tick it and press Set kit baseline — no reason is asked for a first baseline, and it is marked ＋ as added after the project baseline. Clear baseline appears when a ticked kit task has a baseline; it removes it (with a reason) so the kit task derives live again. Re‑baselining a kit task that already has a baseline asks for a reason and is logged; re‑baselining a Task in MS Project still carries its kit's baseline with it. Set it once the kit for your baselined plan is complete.

Status date (the bar above the plan, or MS Project)

MS Project's as‑of date, default today. Every “today” in the kit and Task calculations is this date: remaining lead runs from it, an unstarted kit task that is overdue is rescheduled to start on it, and buffer is measured at it — the same as Update Project → Reschedule uncompleted work to start after the status date. What is done stays where it happened; what remains moves after the status date. If the plan has a Status Date in MS Project the add‑in sends it on sync; you can also set or clear it in the Status date box above the task list (blank = today; the box turns amber while a date is set). The timeline's red as‑of line sits on it.

MS Project: synced / written back (the bar above the plan)

The two halves of the round trip. Synced is when the add‑in last sent the plan here (KitSyncNow, and the sync at the start of KitWritebackNow) — the Task dates, baselines and actuals on screen are as of then; it turns red after 36 hours. Written back is when the add‑in last pulled kit health and constraints to stamp into the plan (KitWritebackNow), with who ran it; it turns red when it is older than the last sync, meaning the plan has been sent here since but not yet updated from here. Nothing on the web changes the MS Project file: until a writeback runs, a Task pushed by its kit shows the red “kit gate dd‑mm” line under Start.

Timeline (kit rows)

The dashed box is the kit task's baseline window (Baseline Start → Baseline Finish). A kit task that is on plan shows its bar there; a late one shows a solid bar from its Start to its Finish, and red arrows join a late predecessor's Finish to the Start of what it pushes. The diamond is the kit task's Finish.

Linking kit tasks (predecessors and successors)

Kit tasks in the same bundle can be linked finish‑to‑start with a lag in working days, using the kit row # as in MS Project: 2, 3+1d. Type predecessors in the Preds box on the kit row (the small text beside it shows what the kit task feeds). Set successors in the drawer's Detail tab. A kit task feeds either other kit tasks (3, 4+2d) or the Task itself: Task, or Task+3d for a gap of three working days between the kit task being ready and the Task's baseline start (material that must sit on site before work starts). That gap used to be a separate field called “Lead days”; it is simply the lag on the link to the Task, so it now lives here. Blank means Task. Either way the whole chain is reverse‑scheduled from the Task's baseline start, and a late kit task pushes the projected dates of everything after it. Links never cross bundles and never touch the MS Project plan.

Yes / No kit items

A yes/no readiness item (site access granted, customer sign‑off, funding released) is a Stage task on the seeded Yes / No template: Requested (30%) then Confirmed (100%). Pick it in Quick add or on a bundle template. It has two stages on purpose — with a single stage the fever would sit at 0% complete and turn red after a sixth of the lead had passed, however well things were going.

Early kit start (project setting)

Early kit start is a per‑project policy, set under Settings → Project (also a column on the Portfolio page); the plan header shows a 🔒 tag while it is off. On (default): a kit task whose planned start is still ahead is shown muted but can be reported early. Off: such a kit task is locked — 🔒 in Progress, Stage / Qty and Rem. lead disabled, Report progress refused (the server rejects it too, KM50068) until its planned start arrives. Planning edits in the drawer's Detail tab stay open, and the engine is unchanged: the locked task keeps its window and projection, so upstream kit delays and plan changes still cascade through it.

Progress (kit rows)

One cell for status and completion: starts in N wd (not yet due — the row is muted, but reporting early is welcome), 0% (due, not started), 0% · started (in progress, nothing measurable yet), a bar with the percent, or ✓ Done.

Priority (kit rows)

The fever colour of the kit task with its buffer penetration % as the text. Colour comes from both axes: penetration against the FEVER lines at the task's % complete, so progress earns tolerance. Hover for the numbers and any overrun.

Buffer used & colour (RAG)

How much of the kit task's protective buffer has been consumed, measured against the baselined commitment. GREEN on track · YELLOW watch · RED at risk · BLACK buffer blown. Rollups are worst-of-children at every level.

Fever chart

Buffer consumed (y) vs % complete (x). Dots below the green line are safe; climbing into the red zone means the item is burning buffer faster than it's progressing — the early warning a milestone can't give you.

Preds (kit rows)

Finish‑to‑start links between kit tasks in the same bundle, typed by the kit row # with an optional lag: 2, 3+1d. Blank means the kit task feeds the task directly. The chain is reverse‑scheduled from the task's baseline start (a linked kit task's due date is its successor's planned start minus the lag), and a late predecessor pushes its successors' projected‑ready dates, so the gate follows the end of the chain. Links never cross bundles and never enter the MS Project network.

Rem. lead (kit rows)

Remaining lead time — the whole elapsed working days still needed until the kit task is ready (waiting + hands‑on), not remaining touch time (that is the separate “Touch time remaining” field in Report progress, high‑touch Stage tasks only). Owner override: “I still need N working days.” Blank = auto (derived from % complete). This is the honest signal that feeds Projected ready → the gate. On a kit task that has not started it re‑estimates the lead time instead (the window and any predecessor chain re‑plan). Once started, a figure that no longer fits in the days left also eats buffer (overrun), so the Priority colour and the projected date agree. It stays as reported until you change it — a stale figure slides the projection by a day each day, on purpose; the box turns amber after 5 days.

How priority is calculated

Every kit task gets a fever-chart position from two numbers: % complete (x-axis) and buffer used (y-axis). Here's the chain — all in working days.

Lead vs touch

Lead time = total elapsed days to ready (waiting + hands-on). Touch % = the hands-on slice; the rest is waiting. A high-touch Stage task (touch ≥ the Touch-Time-Limit, default 20%) protects only the waiting part:

Buffer = LeadTime × (1 − Touch%)     (high-touch)
       = LeadTime                    (low-touch — includes every Rate task)

What's left, right now

LeadTimeRemaining  = working days(today → Required-by)          [clamped]
TouchTimeRemaining = (1 − %Complete) × LeadTime × Touch%       (or owner-reported)
BufferRemaining    = LeadTimeRemaining − TouchTimeRemaining    (high-touch)
Buffer used        = (Buffer − BufferRemaining) / Buffer       ← the y-axis

The colour

Green line  = 0.675 × %Complete + 0.05
Yellow line = 0.775 × %Complete + 0.15

GREEN below the green line · YELLOW between the lines · RED above the yellow line · BLACK once buffer used reaches 100%. Rollups (Kit Bundle, Task) are worst-of-children.

Worked example — 90% done, buffer blown

Lead 5, touch 20%, % complete = 90% (a Raw Material WO task at its “In‑Transit” stage — that stage's cumulative weight is 90%), Required‑by in 3 working days, owner reports 5 touch‑days remaining:

Buffer             = 5 × 0.8       = 4.0
LeadTimeRemaining  =                 3.0
TouchTimeRemaining = 5 (reported)
BufferRemaining    = 3 − 5         = −2.0
Buffer used        = (4 − −2) / 4  = 150%   →  BLACK   at (90%, 150%)

Leave touch-time-remaining blank and it derives to 0.1 day → buffer used = 27.5% → GREEN. Same 90% complete; only the reported number moved the dot.

Touch time = hands-on work only. Waiting or transit is lead, not touch — leave Touch-time-remaining blank for it (or use Rem. lead). Over-stating it blows the buffer and turns the task black for no real reason.

Full reference — projections, gate/SNET, Task Priority — in docs/Kit_Priority_Formulas.md.

Task Priority — the same fever chart for MS Project Tasks

The Priority chip on a Task row (and Text3 in MS Project after a writeback) is the Task's own fever position: buffer consumed (y) against % complete (x), on the same green and yellow lines as kit tasks. It has nothing to do with kit; a Task with no kit still gets one.

The one assumption: safety in the estimate

A kit task has a real buffer — most of its lead is waiting. A plan Task has none; its whole baseline duration is work. So the fever needs an assumed buffer, and Critical Chain supplies the assumption: a duration estimate carries safety, about half of it. That share is the setting Safety share in Task estimates (Settings → General), default 50%. It is not touch time, and MS Project's Type column (Fixed Duration / Work / Units) has no bearing on it — Type says what MS Project holds constant when you edit a Task, not how much of its estimate is padding.

The chain

D            = working days(Baseline Start → Baseline Finish)
Buffer       = D × SafetyShare
Runway       = working days(today → Baseline Finish)          [0 once passed]
Need         = Remaining Duration from MS Project              (else (1 − %Complete) × D)
BufferRem    = Runway − Need × (1 − SafetyShare)
Buffer used  = (Buffer − BufferRem) / Buffer                   ← y-axis; x = %Complete

Remaining Duration is the honest "what is left". For a fixed‑duration Task the PM types it; for an effort‑driven Task MS Project derives it from Remaining Work and the assignment units. Either way the add‑in syncs it, and a re‑estimate upwards eats buffer at once. GREY for a milestone or a Task with no baseline; GREEN at 100%; BLACK once buffer used reaches 100%.

Worked example — a 20‑day Task at its midpoint

Baseline 20 working days, safety share 50% → Buffer 10. Today is day 10 (Runway 10) and the Task is 50% complete. Three versions of "what is left":

On pace     Remaining Duration 10 → Need×0.5 = 5  → BufferRem 10 − 5 = 5 → used  50% → YELLOW
Ahead       Remaining Duration  6 → Need×0.5 = 3  → BufferRem 10 − 3 = 7 → used  30% → GREEN
Re-estimated up  Remaining Duration 14 → Need×0.5 = 7 → BufferRem 10 − 7 = 3 → used  70% → RED
Past baseline finish, 2 days left: Runway 0, BufferRem −1 → used 110% → BLACK

(At 50% complete the green line sits at 39% and the yellow line at 54%.) Same 50% complete in every row — only the PM's Remaining Duration moved the dot. That is the point: progress alone cannot show a slipping Task; the re‑estimate can.

Why on‑pace is YELLOW, not GREEN. The FEVER lines expect buffer to be consumed slower than progress is made — the same rule that colours kit tasks. A Task that merely keeps pace is spending its safety exactly as fast as it earns progress, which the chart flags as "watch". Well ahead is GREEN; behind is RED.