A Dependency Type the Critical Path Ignores
A task dependency here carries a type. The critical path calculation never reads it, and treats every link as finish-to-start. It also counts in day offsets rather than dates, so it has never heard of a weekend.
A critical path is the most confident-looking output a project tool produces. It is a chain of tasks with no slack, drawn in a strong colour, and it invites you to believe the tool understands your schedule.
What it understands is a graph. Everything else — what kind of link this is, what day it lands on, whether anybody is available — is an assumption, and the assumptions are worth knowing.
The type nothing reads
A dependency between two tasks stores a type. The column is there, it is on the model, and it is part of what gets written when a link is created.
The critical path calculation loads dependencies by their two task identifiers and nothing else. It never looks at the type. Every link is treated as finish-to-start: this one ends, then that one starts.
So if a link is recorded as anything else — two tasks that must start together, two that must finish together, one that starts partway through another — the schedule is computed as though it were finish-to-start anyway.
What the four dependency kinds mean
- Finish to start: the common one, and the only one modelled
- Start to start: pour the slab and run the conduit together
- Finish to finish: snagging finishes when handover finishes
- Start to finish: rare, and usually a mistake
What the calculation does
- Reads the two task ids
- Ignores the type column entirely
- Assumes finish to start for all of them
- Produces one confident answer
The schedule is not wrong about your dependencies. It is right about a different set of dependencies that happen to share your task names.
The calendar it has never heard of
The second assumption is stated openly in the code, which is to its credit. The units are relative day offsets from the earliest task — not calendar dates. Task four starts on day twelve, not on the fourteenth of March.
The comment says why: it is enough to highlight the critical path and the slack. That is an honest scoping decision and it is the right one for the job the feature does.
It also means the chain has no idea whether day twelve is a Sunday, a public holiday, or in the middle of the two weeks your site is closed. A fourteen-day chain is fourteen days of the kind that do not exist in a calendar.
What makes this notable rather than merely a limitation is that the same product has a working-calendar service that answers exactly this question, and uses it for leave arithmetic, workflow due dates and business-hours support deadlines. The capability is present three modules away and the critical path does not consult it.
A ten-task chain of five days each
Illustrative, and the direction is always the same: an offset-based chain is shorter than a calendar one, never longer. Read it as an ordering, not as a date.
How to use it well anyway
-
Read the critical path as an ordering, not a date
Which tasks have no slack is the genuinely useful output, and it is correct. Where the chain lands on a calendar is not what this is telling you.
-
Model everything as finish to start
Since the type is ignored, recording anything else creates a difference between what the plan says and what the tool computes. Pick the representation the tool actually reads.
-
Inflate durations if you want dates
A crude but honest fix: if you need the chain to approximate calendar time, put working-day-adjusted durations on the tasks. It is a fudge and it is visible, which is better than an invisible one.
-
Set a baseline once the plan is agreed
Baseline dates are a real, wired feature here — the timeline compares current dates against them and shows the variance. That is where calendar reality actually shows up.
Four questions about a critical path
Which dependency types does the calculation honour?
A good answer sounds like
A list.
What it actually means
Ours honours one and stores four. Ask this before modelling a plan.
Does it use a calendar or elapsed days?
A good answer sounds like
A direct answer.
What it actually means
Offsets are legitimate and much easier. They are also always shorter than reality.
Does it know who is available?
A good answer sounds like
An honest no, usually.
What it actually means
Resource levelling is a different and much larger feature. Very few tools in this bracket have it.
What happens to a cancelled task?
A good answer sounds like
It is excluded.
What it actually means
Ours excludes them, which is right — a cancelled task should not hold up a chain.
What AWRA OpsHub does today
- Critical path over a task dependency graph, with a forward and backward pass producing earliest and latest start and finish, slack, and the zero-slack chain.
- Cancelled tasks excluded from the calculation.
- Task baselines that can be snapshotted, with the timeline showing variance against them.
- Milestones, subtasks, sprints and story points as first-class structures.
- A working-calendar service used elsewhere in the product for leave, workflow dates and support deadlines.
What it does not do
- Any handling of dependency type — the column is stored and the calculation never reads it.
- Lag or lead time on a dependency.
- Calendar dates in the critical path. Output is relative day offsets.
- Any use of the working calendar by the scheduling graph.
- Resource levelling or availability-aware scheduling of any kind.
- Automatic rescheduling when a task slips.
Not ours, by choice
- The day-offset scoping is stated openly in the code with its reason, and we would defend it as a decision. What is worth flagging is that a reader of the output cannot tell, and nothing on the screen says so.
- The dependency type being stored and ignored is the more awkward one. It is the tenth surface found in this codebase that exists as structure with nothing consuming it.
- Nothing here is Senegalese, Ivorian or Malian. Francophone West Africa is here because construction and infrastructure delivery are major activities there, and those are the projects where a schedule is a contract rather than an intention.
What is not built for the CFA franc zone today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in the CFA franc zone. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a national e-invoicing pipeline, a French interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
National tax pipelines and a clean handoff to your ledger
Electronic invoicing against your administration's published interface, and a defined monthly export mapped to your expert-comptable's chart of accounts — with retries, a failure queue and a reconciliation report rather than a black box. The statutory ledger itself stays with them, by design; what we build is the pipe to it.
Mobile money, banks and French interface
Wave, Orange Money and bank statement feeds into the Payments Register, plus French interface text and document templates.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
National income tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Use the critical path for what it is good at — telling you which tasks have no slack — and do not read dates off it. Model every dependency as finish to start, because that is what will be computed regardless, and put your calendar reality into task durations and baselines instead. If you need calendar-aware scheduling with real dependency types, say so early: it is a different feature rather than a setting.
Ask which type the algorithm reads
In any project tool, ask how many dependency kinds it stores and how many it computes with. When the two numbers differ, the plan on screen is not the plan being calculated.
Talk about project schedulingFrequently asked questions
Should I record dependency types anyway?
Only as documentation for people, and knowing the tool will ignore them. If a link is genuinely start-to-start, the honest options are to model it as finish-to-start and accept the distortion, or to split the task so that finish-to-start is true.
Can I get calendar dates for the chain?
Not from the critical path calculation. Tasks carry real start and due dates that you set, and the timeline draws those against the baseline — so calendar reality lives on the tasks rather than in the computed chain.
Does a slipped task move the ones after it?
No. There is no automatic rescheduling — dates are what somebody set, and the critical path recomputes from durations rather than pushing dates along. Slippage shows up as baseline variance rather than as a moved plan.
