Microsoft Project

Earned-value analysis against a stored baseline: BCWS, BCWP, ACWP, schedule and cost variance, SPI, CPI, EAC and TCPI, for the whole project and optionally per top-level WBS branch, plus the tasks with the worst slippage. This is the number a project board asks for and what feeds the S-curve. Says so plainly when no baseline is stored rather than returning zeros that look real.

Tie schedule tasks to the model elements they build, matching on a shared code (HRZ_COD_PRES, a keynote, a budget code). op='suggest' proposes the mapping from an element export and separates out anything that matched only on a code prefix for you to confirm; 'set' stores it; 'get' reads it back; 'clear' removes it. The mapping lives in a sidecar next to the schedule, so re-exporting the model never touches the planner's file.

Move data across the schedule/model boundary, in either direction. direction='model_to_schedule' turns measured quantities into duration proposals at a stated productivity rate — proposals only, which you then apply with tasks_write. direction='schedule_to_model' writes one row per element carrying its task's dates and progress: that file drives 4D animation in Navisworks, element parameters in Revit, and the progress dashboard in Power BI.

Manage working calendars: create and delete them, and add non-working exceptions for holidays, site shutdowns or a rainy season. The weekly working-hours pattern itself is not editable here. Verified and dry-runnable exactly as tasks_write describes.

Read the dependency network. Almost always you want the subgraph around a few tasks rather than every link, so pass uids and a depth. drivingOnly returns just the chain that actually pushes the finish date, which is what you want when asking why the project ends when it does.

Add, remove, and change dependencies in one batch. Cycles are detected and refused before anything is applied, with the offending chain named in the rejection. Verified and dry-runnable exactly as tasks_write describes.

Export the schedule for another tool. 'mspdi' and 'mpx' write real schedule files; 'csv' and 'json' write a flat task table; 'pbip_dataset' writes the shaped dataset our Power BI report consumes — tasks, assignments, earned value and the S-curve — rather than a raw dump.

Diagnose what this server can do on this machine. Call it first in every session. Reports the active backend, runtime, whether Microsoft Project is installed AND whether its COM server actually starts, and a capability matrix the other tools honour. When something is wrong it returns the exact diagnosis and a repair path, not a stack trace. Pass deep=true to genuinely launch Microsoft Project instead of only reading its registration — slower and visible on screen, but the only way to know COM works.

Bring updates in from a CSV or JSON file — typically progress collected in the field. Runs plan-first: by default it matches rows to tasks by uid and returns the field-by-field diff without changing anything. Pass apply=true once you have read the plan, and the changes go through tasks_write so every one of them is verified by re-reading the model.

Summarise an open schedule: dates, counts, calendars, which baselines actually hold data, and the aliases of the custom fields. Read this before tasks_query — without the aliases nobody can tell what Text1 means in this particular schedule.

Open a schedule — or start a new one — and get a handle for every other tool. Reads .mpp, .mpt, .mpx, MSPDI .xml, Primavera .xer and .pmxml, Asta .pp and more, with no Microsoft Project needed. Returns a fingerprint of the file; later writes revalidate it and refuse if the file changed on disk in the meantime, so a stale handle can never overwrite somebody else's edits. Pass create=true to begin an empty schedule at that path instead of reading one.

Save or close an open schedule. Never saves on its own — closing with unsaved changes requires either saving first or passing discardChanges=true, so work is never silently lost. Note that no library can author native .mpp; use format='mspdi' for a .xml Microsoft Project opens natively.

Read resources, their assignments, and who is overbooked. Overallocation is computed day by day from the assignment spans — Microsoft Project's file format carries no such flag, so this is a real calculation rather than a field read.

Create, update, and delete resources, and assign or unassign them to tasks, in one batch. Verified and dry-runnable exactly as tasks_write describes.

Answer questions about the schedule without downloading it. Computes the critical path, the float distribution, the driving (longest) path, day-by-day resource overallocation, milestone status against deadlines and baseline, and the health of the dependency network. Ask for only the aspects you need — each one is computed independently.

Build a new schedule from an activity library produced by schedule_learn. Each activity gets the duration its history says it takes, and the dependencies that usually surround it are recreated between the activities you asked for. Returns an open handle, so run schedule_qa on it before trusting it and adjust with tasks_write — this is a first draft grounded in what actually happened on past projects, not a finished programme.

Mine finished schedules for how long each kind of activity actually takes and what usually comes before and after it. Reads any number of .mpp, MSPDI or Primavera files, normalises task names so the same activity matches across projects and units, and reports each activity's duration distribution — median, 80th percentile, range — together with its typical predecessors and successors and the lag between them. Save the result and hand it to schedule_generate to build a new schedule from experience rather than from a blank page.

Run the DCMA 14-point schedule assessment plus Horizun's own rules, and report what is wrong with the schedule. This is the industry standard for judging whether a schedule can be run on: missing logic, leads and lags, hard constraints, high float and duration, negative float, invalid dates, unresourced work, missed baseline tasks, CPLI and BEI. Checks that genuinely cannot be evaluated (no baseline stored, no scheduling engine) are reported as not evaluated with the reason — never as a pass.

Work out what is late, what it is costing the finish date, and which changes to the logic would actually recover time. Lists the late work ordered by how much of the schedule is stuck behind it, then measures recovery levers — removing lag on the driving chain, overlapping finish-to-start hand-offs, compressing the longest critical tasks. Every option is applied to a throwaway copy, rescheduled, and reported with the finish date it genuinely produces; an option that recovers nothing says so rather than being offered as advice. Nothing is written to the open document.

Recover the logic a schedule is missing by reading the order its own dates already state. A schedule whose work was laid out in the right order but never linked is a bar chart, not a network: nothing moves when anything slips, float reads as enormous, and any target date computed over it is arithmetic. This finds the repeating groups — apartments, floors, spans, wells, whatever the work repeats over — reads the order each one runs in, keeps only the orderings the repetitions agree on, and proposes the missing links. It never invents an order the dates do not state and never proposes a link where a path already exists. Defaults to proposing only; pass apply=true to write them, verified.

Test a schedule against a date you have been given. Reports whether the target is achievable, how many working days short it falls, the driving chain with the dates each task would have to hit, and every task the network does not actually hold in place — work with no predecessor or no successor, which never moves when its neighbours do and makes any target date arithmetic rather than a plan. Read-only.

Engine-level operations that take no per-task payload: save or clear a baseline, set the status date, reschedule incomplete work, level resources, or force a recalculation. Levelling and rescheduling are the two that do the most damage by accident, so they require a dry run to be seen first. Operations that need Microsoft Project's scheduling engine are refused outright on the MPXJ backend rather than approximated.

The workhorse read. Filter, sort, and page through tasks without pulling the whole schedule into context. Every task is identified by its stable uid — the id field is the row number and shifts when tasks are inserted, so never use it to address a task in a write. Defaults to a compact field set and 50 rows; ask for more only when you need it.

Create, update, delete and re-outline tasks in one batch. Progress (percentComplete, actual dates) is an ordinary update. Tasks are addressed by their stable uid — never by row id. Every change is re-read from the model after the write and only then counted as applied; anything the schedule refused comes back under 'rejected' with the reason and what the value actually became. Pass dryRun=true to run the whole batch against a throwaway copy and see the impact — how many tasks move, how far the finish date shifts, whether the critical path changes — without touching the open document.

Work or cost spread over time — the S-curve. Kept separate from the other reads because it is the expensive one: it refuses ranges that would generate an unreasonable number of buckets and tells you to coarsen the granularity instead of quietly returning tens of thousands of rows.