IFI 8410 — Session 4: Functions and Decomposition

Decomposition

Breaking a large problem into smaller pieces

The problem

Why large goals feel hard

"Organize an event." "Complete a study." "Improve a service."

A large goal is hard not because it is big, but because many things are mixed together:

• decisions that have not been made yet
• dependencies — what has to happen first
• uncertainty about what "done" even looks like

You cannot act on a goal. You can only act on a next step.

Definition

Decomposition

Taking a large goal and dividing it into smaller, understandable tasks and steps.

It does not make the goal less important or change its purpose.

It makes the work visible — people can see:

• what needs to happen
• in what order
• who is responsible
• how each completed piece contributes to the whole

Structure

Goal → tasks → steps

Focus on one meaningful task at a time — while keeping sight of the overall outcome.

Why break work down?

Not a longer to-do list

The goal is a plan people can understand, use, inspect, and improve.

Payoff 1 of 4

Clarity

Each task has a recognizable purpose; each step moves the work forward.

• Separates what is done from what is still uncertain
• Reveals dependencies

Payoff 2 of 4

Reuse

Many large efforts contain tasks you will need again:

• planning a meeting
• reviewing information
• approving a request
• preparing materials

Reuse is not repeating work without thought.
It is preserving a proven approach so people can adapt it rather than start from nothing.

Payoff 3 of 4

Checking

Small tasks can be reviewed before the whole effort is complete — so a serious problem does not surface at the very end.

At each piece, ask:

• Is this step complete?
• Does it meet the expected standard?
• Is important information missing?
• Does the next task have what it needs to begin?

Payoff 4 of 4

Collaboration

Works best when each task has a clear outcome, a responsible owner, and a known connection to other tasks.

Fewer duplicated efforts, missed handoffs, and "who acts next?" moments.

How to do it

A practical process

1. Describe the final outcome clearly — start there, not with activities.
2. Identify the major tasks needed to produce that outcome.
3. Divide each task into steps — only until the next action is clear.
4. Put tasks in order and mark dependencies.
5. Assign responsibility and agree how each result will be checked.
6. Review the plan as work progresses; adjust when new information appears.

How far to go?

The right level of detail

Stop dividing when the next action is obvious.

Example 1 — simple

Hosting a dinner

Host a dinner for several friends on Saturday evening.

Avoids: buying ingredients too late · more food than fits on the stove · learning about a dietary restriction after choosing the menu.

Example 1 — simple

Dinner: the four payoffs

• Clarity "Host a dinner" is planning, preparation, and serving — not one undefined activity.
• Reuse Keep a meal-planning checklist and adapt it for the next dinner.
• Checking Review the guest list, shopping list, and table before cooking begins.
• Collaboration One person shops, another prepares a dish, another sets the table.

Example 2 — medium

Organizing a student workshop

Example 2 — medium

The same plan as a flow of results

Tasks have dependencies: each stage produces what the next one needs.

A tree shows what the work is. A flow shows what each piece hands to the next.

Example 2 — medium

Workshop: the four payoffs

• Clarity Not just "an event to schedule": purpose, logistics, communication, materials, and review are separate work.
• Reuse The plan becomes a template — registration messages, accessibility checks, feedback questions, timeline.
• Checking Confirm the room, match materials to learning goals, verify participants got the details, examine feedback.
• Collaboration Content, registration, and room/equipment can each go to a different group — with clear handoffs.

Example 3 — complex

Improving community flood preparedness

Example 3 — complex

Different timing, still connected

Several inputs converge; real events feed a loop that updates the plan.

Example 3 — complex

Flood plan: the four payoffs

• Clarity "Be better prepared" is too broad to guide decisions; the tasks separate risk, priorities, readiness, communication, response, and learning.
• Reuse Warning messages, contact lists, shelter procedures, and assessment forms are maintained — not recreated mid-emergency.
• Checking Verify risk data, inspect repairs, test warnings, review drills, update after every event.
• Collaboration Leaders, emergency services, infrastructure, health, schools, residents, businesses — each owns a part and a handoff.

Example 4 — working backward

Start from the finish line

Examples 1–3 went top-down: name the goal, split it into tasks.

Step 1 of our process said: describe the final outcome clearly — start there, not with activities. Now take that literally.

Your turn — Example 4

Plan a quarterly insights brief — backward

Your team publishes a quarterly industry insights brief: an analysis of the latest industry data, written up for stakeholders.

1. Start from done. Ask: what had to be finished just before this? Repeat until you reach the start.
2. Name the major tasks you found — and who would own each.
3. Break each task into steps, stopping when the next action is clear.
4. Mark one checkpoint and one handoff between people.

LiveSythesis · 10 minutes

Example 4 — working backward

The quarterly insights brief

First, define success in plain language:

Not "write a report." A description of the finished state that anyone can check against.

Example 4 — Level 1: major tasks

Walk backward from the outcome

Ask repeatedly: what had to be finished just before this?

Planned right to left — executed left to right.

Example 4 — Level 2: smaller steps

One level further: next actions

Detailed enough to act on — not bogged down in tiny actions like "open the spreadsheet."

Example 4 — comparing the two levels

Brief: the four payoffs at two levels

Each level adds detail — and each piece still points at the same outcome. That is the final check.

Final review

Keeping the pieces connected

Understandable without becoming fragmented.

From plans to programs

In Python, the pieces are functions

def load_sales(path):        ...   # one task, one responsibility
def clean(rows):             ...
def summarize(rows):         ...
def format_report(summary):  ...

report = format_report(summarize(clean(load_sales("sales.csv"))))

• Clarity a name and a docstring that state one job
• Reuse call it again with different inputs
• Checking test each piece with assert
• Collaboration a contract: parameters in, return value out

Takeaway

Small enough to guide action.
Connected enough to produce one result.

Next: Python functions and scripts

Reading: Decomposition: Breaking a Large Problem into Smaller Pieces