When Automation Just Automates Bad Controls

I am a strong believer in automating project controls. A rules-based engine that scores every P6 submission the same way, every cycle, does something a human team cannot do reliably at scale — it removes inconsistency, and it frees expert attention for the things that actually need judgement. But automation has a failure mode that is easy to miss precisely because it looks like progress.

Automation does not make a control good. It makes it consistent. If the control is sound, consistency is exactly what you want. If the control is flawed, you have just industrialised the flaw.

Automating a good control. The right things to automate are the checks that should be identical every time and gain nothing from human variation — logic integrity, constraint counts, float distribution, the DCMA-type structural checks, the comparison of one update against the last. These are objective, repeatable, and better done by a machine that never gets tired or inconsistent. Here automation genuinely raises the floor: the assurance is applied the same way to every submission, and the exceptions surface for a human to judge.

Automating a flawed process. The danger is automating a check that was wrong to begin with — a progress rule that was never valid, a scoring weight that rewards the wrong thing, a “green” threshold that lets an unreliable programme pass. Now the flaw is applied consistently and at speed, wrapped in the authority of a system. A bad manual judgement gets questioned; a bad automated one gets trusted, because it came from the engine. Automation does not just repeat the error — it lends it credibility.

Automation cannot supply judgement. There is a whole class of questions a rules engine cannot answer, and should not be asked to. Does this critical path make engineering sense, beyond passing the structural checks? Is this recovery achievable, given what this specific team has actually delivered? Is this delay event genuinely Employer-risk in these contractual circumstances? A programme can pass every automated check and still be quietly unbuildable — because the checks test structure, and judgement tests reality.

The right division of labour. So I treat automation and judgement as doing different jobs. The engine does the consistent, objective, high-volume work and surfaces the exceptions. The professional does the interpretation — deciding what the exceptions mean, catching what the rules cannot, and making the call the data alone cannot make. The engine raises the floor; the judgement is freed for the ceiling. Get that division wrong — ask the engine to judge, or ask the human to do what the engine does better — and you lose the benefit of both.

The test I apply before automating anything is simple: would this check be right if a good practitioner did it by hand, every time? If yes, automate it and gain consistency. If no, automating it does not fix it — it scales it. And a controls function that has automated its way to fast, consistent, confidently-wrong output is worse off than one that was slow and occasionally right, because it has stopped looking.

The takeaway: automate the controls that are sound and repetitive, and keep judgement for what rules cannot catch. Automation raises the floor — it does not replace the thinking, and it will faithfully scale a bad control if you let it. This is the philosophy behind Digital Project Controls and the Director’s Playbook.