Map Commitments, Dependencies and Decision Assumptions for One Project

Most projects don't fail suddenly. A supplier delay or a change in a customer's plans usually exists for weeks before anyone at the top hears about it. The cause is rarely that people hide it. Nobody is asked, on a regular schedule, to check whether the things the project relies on are still on track.

Look at a typical status pack. It reports on work: tasks completed, percentage done, a red-amber-green colour. It rarely asks whether the legal sign-off you need in May is still coming, or whether the customer you built the plan around still intends to sign. Those are the conditions the work relies on. They can go wrong while every task still shows green.

This course closes that gap with a weekly review. Over six lessons you'll set up an AI agent to check those conditions each week and draft follow-ups for you to approve. An AI agent here means an AI tool given a standing task, instructions and information to work from. You start with a short written map of one project, because the agent can only check what you've written down.

We'll use one example project throughout this lesson. Your company is launching a new subscription service for business customers, planned to go live on 1 July.

The first thing to map is commitments. A commitment is something a named person has agreed to deliver by a date. For example:

• Finance closes the pricing model by 14 March.
• The Head of Sales delivers the launch sales plan by 1 June.

A commitment has three parts: who (a person who said yes), what (a specific deliverable) and by when (a date). If any part is missing, you have a hope, not a commitment.

Commitments are usually the easiest items to find. They show up in plans, meeting notes and trackers. The hard part is making sure each one names a person and a real date, not "Finance, soon".

As you read, think of one live project of your own. What has someone agreed to deliver to you, and by when?

A dependency is something your commitment needs from another person, team or outside party before it can be delivered. Dependencies are where projects quietly stall, because the work sits with someone outside your direct line of sight.

In the subscription launch, going live on 1 July depends on:

• A supplier contract. The billing provider must sign before integration can start.
• An IT integration. The new service must connect to your billing system.
• A legal sign-off. Legal must approve the customer terms before anyone can sell.

The same item can look different depending on where you stand. For the Head of Legal, "approve customer terms by 30 May" is their own commitment. For the launch, it is a dependency. In your register, label items from the project's point of view: if the project needs it from someone else, call it a dependency.

To find dependencies, take each commitment and ask: what has to arrive from someone else before this can be done?

A decision assumption is a condition you treated as true when you approved the project. Nobody delivers it. It is the ground the decision stands on. For the subscription launch, you might have approved the budget on the basis that:

• The anchor customer will sign the pilot in Q2.
• The new product lead starts in April.

If one of these stops being true, the decision itself may need revisiting, not just the timeline. Without the anchor customer, the revenue case behind the launch may no longer hold. Without the product lead, the July date may not be realistic.

Assumptions are the items leaders most often leave unwritten. They live in your head or in a slide from the approval meeting. To find them, ask: what did I believe was true when I said yes to this project? What would make me reconsider?

You don't deliver an assumption. You check it, which is why assumptions get a review date rather than a due date. More on that shortly.

Telling the three types apart matters because each one gets checked differently later in the course.

• Commitment: a named person agreed to deliver something by a date. You ask, "Is it done?"
• Dependency: something the project needs from another person, team or outside party. You ask, "Is it still coming in time?"
• Decision assumption: a condition you treated as true when approving the project. You ask, "Is it still true?"

A quick test for any item: Did someone agree to deliver it? If so, it's a commitment, or a dependency when the project needs it from someone else. Is it a condition nobody delivers, but which your decision relied on? Then it's an assumption.

Try sorting the launch items in the exercise. Then do the same with three items from your own project, one of each type.

Every item in your register needs two things.

One named owner: a person, not a team. "IT" can't reply to a follow-up. "Daniel Okafor, IT integration lead" can. When the agent later drafts a follow-up, it needs a name to address it to. For an outside party such as a supplier, the owner is the person in your organisation who manages that relationship.

One date:

• Commitments and dependencies get a due date, the date by which they should be delivered.
• Assumptions get a review date, the date by which someone confirms the condition still holds. For "the anchor customer signs the pilot in Q2", you might set a review date of 15 April, with the account director as owner, so you hear early if the customer is wavering.

If you can't name an owner, that's a finding in itself. An unowned item is one nobody will check.

A checkable item states what "done" or "still true" looks like. On the due or review date, someone should be able to answer yes or no without a debate.

"Integration progressing" can't be checked. Progressing compared with what? It could read the same for months while the launch slips. "Integration passes user testing by 30 April" can be checked: on 30 April it either has or hasn't.

A quick test: if you asked the owner about this item on its date, could they give a clear yes or no? If the honest answer is "it depends" or "we're getting there", rewrite it.

Common signs of a vague item:

• Words like progressing, on track, working on or positive
• No visible outcome, such as signed, approved, passed or started
• No date

Go through your own list now and rewrite any item that fails the test. This is the most useful ten minutes of the lesson, because the agent can only flag what it can check.

Start with one project and keep the register short. Don't list everything. List the items that would cost the most if they slipped or stopped being true. A short register you keep up to date is far more useful than a long one nobody reads. You can add items later.

A table or simple document is enough. It only has to be clear, so that an AI agent can read it in a later lesson. Use one row per item and these columns:

Item (checkable)	Type	Owner	Due or review date
Finance closes pricing model	Commitment	Priya Shah	14 March
Billing supplier signs contract	Dependency	Procurement lead	15 April
Anchor customer signs pilot in Q2	Assumption	Account director	Review 15 April

Before moving on, build this table for your own project, with at least one commitment, one dependency and one assumption. You'll use it in the next lesson.