KEVOS
ArticlesServicesCase studiesAboutContact
ArticlesServicesCase studiesAboutContact
← ArticlesAlgorithms for Decision MakingProject Delivery · RiskLesson 31/31← PrevNext →
GuidePublished 6 Jul 2026Updated 13 Aug 202610 min readBy Kevin Joginrisk managementdecision theorydecision under uncertaintyBayesian networks
On this page

Ask about this page

KEVOS AIAlgorithms for Decision Making

KEVOS knowledge first · trusted web sources when needed

KEVOS®

Project Management›Project Risk Management›Series

Algorithms for Decision Making

A risk-focused field guide to deciding well under uncertainty — twenty-six chapters across five parts, re-read for the project professional rather than the roboticist.

5 parts 26 chapters Original KEVOS® synthesis

The premise

Every risk decision is made without full knowledge

Risk management is decision-making under uncertainty. That is its entire job.

This series works through the modern computational toolkit built for exactly that problem: how a rational actor should choose when outcomes are probabilistic, information is incomplete, and the situation unfolds over time. The mathematics comes from artificial intelligence and operations research — but the reading here is deliberately practical. Less “how to fly an aircraft autonomously,” more “how to decide well when you cannot see the whole board.”

Each chapter explains one method in plain terms, then draws the line back to the work a project professional actually does: quantifying exposure, sequencing responses, learning from outcomes, acting on imperfect status, and coordinating with everyone else who is also making decisions.

How the series is organised

A ladder of uncertainty

Each part takes away one more thing you are allowed to know for certain, then asks how to decide anyway. Climb it and the problem gets harder — and closer to how real projects actually feel.

MORE UNCERTAINTY → I · Known model II · Known dynamics III · Unknown model IV · Unseen state V · Other deciders
I

You know the model

Quantify belief and pick the best single choice — probabilistic reasoning and simple decisions.

II

You know the dynamics

Decide across a whole timeline, not one moment — Markov decision processes.

III

You don’t know the model

Learn the odds while you act — reinforcement learning and exploration.

IV

You can’t see the true state

Decide on belief, not observation — partially observable problems.

V

Others are deciding too

Act strategically among many actors — multiagent systems.

The series

Twenty-six chapters, five parts

Every card names one method, a one-line synopsis, and its risk lens — what the idea means for real project decisions.

I

Probabilistic Reasoning

Quantify what you believe before you decide.

Chapter 1

Representation

Encoding beliefs as probability distributions and Bayesian networks — a shared, explicit picture of what drives uncertainty.

Risk lensOne agreed model of what actually drives project uncertainty.
→
Chapter 2

Inference

Computing the probability of outcomes given the evidence you have observed.

Risk lensUpdating likelihoods as new information arrives.
→
Chapter 3

Parameter Learning

Fitting a model’s numbers from data rather than guessing them.

Risk lensCalibrating likelihoods from historical project data.
→
Chapter 4

Structure Learning

Discovering which factors actually influence which — learning the shape of the model.

Risk lensUncovering the real drivers behind risk events.
→
Chapter 5

Simple Decisions

Turning beliefs and preferences into a single best choice, and pricing the value of more information.

Risk lensExpected-value decisions and when to pay for certainty.
→
II

Sequential Problems

Decide well over a whole timeline, not one moment.

Chapter 6

Exact Solution Methods

Optimal policies when the dynamics are known — Markov decision processes, value and policy iteration.

Risk lensSequencing decisions across a project lifecycle.
→
Chapter 7

Approximate Value Functions

Scaling to problems too large to solve exactly by approximating the value of each state.

Risk lensTractable decisions on realistically complex projects.
→
Chapter 8

Online Planning

Deciding on the fly by looking ahead from where you are now — forward search and Monte Carlo tree search.

Risk lensRolling-wave planning and just-in-time response.
→
Chapter 9

Policy Search

Searching directly for a good decision rule instead of computing values first.

Risk lensTuning response strategies without a full model.
→
Chapter 10

Policy Gradient Estimation

Measuring in which direction a decision rule should change to do better.

Risk lensLearning which levers actually move outcomes.
→
Chapter 11

Policy Gradient Optimization

Improving a decision rule stably, without lurching or over-correcting.

Risk lensSteady, controlled improvement of response strategy.
→
Chapter 12

Actor–Critic Methods

Pairing a value estimate (the critic) with a decision rule (the actor) so each improves the other.

Risk lensCoupling forecasting with action.
→
Chapter 13

Policy Validation

Testing a decision policy against many scenarios before you trust it in the real world.

Risk lensAssurance and stress-testing before roll-out.
→
III

Model Uncertainty

Decide well even when you don’t know the odds.

Chapter 14

Exploration & Exploitation

Balancing learning something new against acting on what you already know pays off.

Risk lensPilot versus commit: when to trial, when to scale.
→
Chapter 15

Model-Based Methods

Learning a model of the world from experience, then planning against it.

Risk lensBuilding a project model as you go.
→
Chapter 16

Model-Free Methods

Learning good actions directly from outcomes, without ever building an explicit model.

Risk lensImproving from results when no model exists.
→
Chapter 17

Imitation Learning

Learning a policy by watching an expert rather than by trial and error.

Risk lensCodifying hard-won practitioner judgement.
→
IV

State Uncertainty

Decide well when you can’t even see the true situation.

Chapter 18

Beliefs

Tracking a probability distribution over hidden states as evidence trickles in.

Risk lensReasoning about status you can’t directly observe.
→
Chapter 19

Exact Belief-State Planning

Optimal decisions under partial observation — the partially observable Markov decision process.

Risk lensActing on imperfect status information.
→
Chapter 20

Offline Belief-State Planning

Pre-computing a robust policy in advance so you’re ready whatever you observe.

Risk lensContingency plans prepared before they’re needed.
→
Chapter 21

Online Belief-State Planning

Planning under partial information in real time, from your current belief.

Risk lensLive decisions with incomplete visibility.
→
Chapter 22

Controller Abstractions

Compact, executable decision policies simple enough to run and audit.

Risk lensSimple, auditable rules teams can actually follow.
→
V

Multiagent Systems

Decide well when others are deciding too.

Chapter 23

Multiagent Reasoning

Game-theoretic reasoning about actors whose choices affect yours.

Risk lensAnticipating contractors, regulators, competitors.
→
Chapter 24

Sequential Problems

Decisions taken over time among many interacting actors.

Risk lensMulti-party negotiation and coordination over a project.
→
Chapter 25

State Uncertainty

Partial information shared unevenly among many actors, each holding private knowledge.

Risk lensActing when stakeholders hold private information.
→
Chapter 26

Collaborative Agents

Aligning independent decision-makers toward a genuinely shared objective.

Risk lensAligning teams and partners on shared goals.
→

Where to start

Three ways through

You don’t have to read all twenty-six in order. Pick the route that matches the decision in front of you.

Route A

The essentials

Enough to quantify exposure and sequence decisions well. The backbone every risk practitioner should hold.

Part I → Ch 5 → Part II (6, 8)
Route B

The uncertainty track

For work where the model is unknown or the true state is hidden — the hard, realistic middle of most projects.

Ch 14 → Part III → Part IV
Route C

The full path

The complete ladder, bottom to top, as the field itself builds it. Best read over time, one part per sitting.

Parts I → II → III → IV → V

About this series

Original synthesis, plainly stated

Every explanation, diagram, and risk lens in this series is original KEVOS® work. Nothing is reproduced verbatim. The subject matter is the established field of computational decision-making — probabilistic graphical models, Markov decision processes, reinforcement learning, partially observable problems, and multiagent systems — as consolidated in the standard graduate text by Kochenderfer, Wheeler and Wray. The value KEVOS® adds is the translation: taking a rigorous but abstract body of theory and reading it through the single question a project professional keeps asking — how do I decide well when I cannot see the whole board?

Each chapter page stands on its own, favours intuition over notation, and closes with what the method means in practice. Where theory would help but isn’t essential, it’s noted, not dumped.

KEVOS® — Engineering & Project Consultancy © KEVOS®. All rights reserved.

Handbook application: from concept to controlled practice

Purpose. This expanded section turns the original page into a practical handbook. It preserves the supplied material and adds a repeatable way to apply, check and review Algorithms for Decision Making. It does not replace a contract, legislation, a controlled standard, competent engineering judgement or specialist advice.

The operating aim is to convert the subject into a governed decision, owned work, usable evidence and a reviewable outcome. Read the original explanation first, then use the workflow and checks below to convert knowledge into evidence.

Use Algorithms for Decision Making as a decision instrument rather than an administrative form. The subject terms—decision, uncertainty, multiagent, chapters, five—need an explicit connection to the project objective, business value and stakeholder commitments. Before completing the artefact, write one sentence stating who will use it, what decision it supports and when that decision is required.

Apply a disciplined information model. Separate facts supported by evidence, forecasts derived from a method, assumptions awaiting validation, constraints that limit choice, risks that may occur, issues that already exist and actions assigned to people. Each material entry should have an owner, date, status and next review point. Where probability or impact scores are used, define the scale so different reviewers interpret it consistently.

A baseline is useful only when changes are visible. Give the artefact an identifier, version, approval state and effective date. Define which changes require reapproval, how superseded versions are retained and where supporting evidence is stored. During reviews, focus on exceptions, decisions and trends rather than reading every field aloud. Record the decision and rationale, not merely that a meeting occurred.

Close the loop beyond delivery. Confirm acceptance criteria, unresolved items, transferred responsibilities and operational ownership. Where benefits are expected, identify the outcome measure, baseline, target, observation period and owner who remains accountable after the project team disbands. Lessons should describe the condition, consequence and reusable action; a generic statement such as “communicate better” cannot improve the next project.

Step-by-step operating method

  1. Clarify the decision. Name the outcome, sponsor, affected stakeholders and decision that this work must enable.
  2. Set boundaries. Record scope, assumptions, constraints, dependencies, tolerances and escalation conditions.
  3. Plan the evidence. Define deliverables, measures, owners, due dates and acceptance criteria before execution.
  4. Control delivery. Compare actual performance with the baseline, assess changes and manage risks and issues explicitly.
  5. Close the loop. Confirm acceptance, transfer ownership, capture lessons and track benefits beyond handover.

Completion and governance protocol

Start with a short drafting workshop involving the accountable owner and the people who hold the evidence. Complete high-consequence fields first: objective, scope, owner, baseline, acceptance, dependencies and escalation. Mark unknowns as assumptions or actions rather than hiding them behind vague prose. Circulate a review draft, resolve conflicting interpretations, baseline the approved version and place the next review date in an owned schedule.

Information typeMinimum useful contentReview test
OutcomeObservable change and intended recipientNot merely a deliverable or activity
MeasureDefinition, baseline, target, frequency and sourceTwo reviewers would calculate it the same way
OwnershipOne accountable role plus contributors and approverAuthority matches responsibility
UncertaintyAssumption, risk or issue with response and triggerStatus reflects current reality
ControlVersion, approval, review date and change ruleCurrent baseline is identifiable

Common failure modes and recovery actions

1. Watch for

Producing a document with no named decision or accountable owner.

Recovery: Return to the governing definition or requirement and restate the decision in one sentence.

2. Watch for

Mixing risks, current issues, assumptions and actions in one unstructured list.

Recovery: Separate evidence from assumption, assign an owner and set a date for validation.

3. Watch for

Measuring activity or output while leaving the intended outcome undefined.

Recovery: Run a small counterexample, boundary test, pilot or independent check before proceeding.

4. Watch for

Accepting changes without evaluating effects on value, scope, schedule, cost and risk.

Recovery: Record the consequence, decision and rationale, then update the controlled baseline.

5. Watch for

Closing the project at delivery even though benefit ownership has not transferred.

Recovery: Escalate when the issue affects safety, compliance, acceptance, material value or an agreed tolerance.

Review checklist

  • Which decision or commitment does this artefact support?
  • Who owns each action, risk, acceptance and post-project benefit?
  • What is the baseline and what variance triggers escalation?
  • Where is the evidence that the result was accepted and transferred?
  • Are mandatory requirements distinguished from recommendations and illustrative values?
  • Are sources, assumptions, units, dates and versions recorded closely enough to reproduce the decision?
  • Have safety, legal, ethical, stakeholder and operational consequences been considered at the appropriate level?
  • Is there a named owner and a trigger for review, escalation, change or retirement?

Questions for deeper application

What is the most important distinction a practitioner must preserve when applying Algorithms for Decision Making?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which assumption about decision would change the result most if it proved false?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What evidence would allow an independent reviewer to reproduce or challenge the conclusion?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which boundary, exception or failure case has not yet been tested?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What must be handed over, monitored or reviewed after the immediate work is complete?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Authoritative references and use notes

The sources below were selected as institutional or primary guidance for the broader practice. They support the handbook method; they do not imply that every statement or clause in a source applies to every project. Confirm the current edition, jurisdiction, contract and application before treating any requirement as mandatory.

  • Risk Management in Portfolios, Programs, and Projects: A Practice Guide — Project Management Institute. Used for risk practices across portfolios, programs and projects. Accessed 2026-08-13.
  • ISO 31000 family — Risk management — International Organization for Standardization. Used for principles and guidance for enterprise risk management. Accessed 2026-08-13.

Continue learning

Collaborative AgentsGuide · RiskState UncertaintyGuide · RiskSequential ProblemsGuide · RiskMultiagent ReasoningGuide · Risk
KEVOS · Engineering, manufacturing and project improvement
ArticlesServicesCase studiesAboutContact
© 2026 KEVOS®