Steering the Project: Priorities, Scope & Technical Debt

A project rarely fails during planning — it fails while running. This tutorial covers the three controls that keep a live project healthy: managing priorities, handling scope changes, and managing technical debt.

Table of Contents

• Managing Priorities
• Managing Scope Changes
• Managing Technical Debt

Managing Priorities

Prioritization is deciding — explicitly and repeatedly — what work gets done first and what waits. It isn't a one-time meeting; it's a weekly habit.

Why it is useful: There is always more to do than time allows. A clear priority system means you cut the right things when the schedule tightens, instead of letting everything slide together.

Frameworks That Work

• MoSCoW: Must / Should / Could / Won't (great for scoping conversations)
• Value vs Effort: a two-axis grid — high value + low effort first
• RICE: Reach × Impact × Confidence ÷ Effort (good when you have rough numbers)

Example: Weighted Scoring with RICE

def rice(reach, impact, confidence, effort):
    return (reach * impact * confidence) / effort

items = {
    "Export CSV":  rice(200, 3, 0.8, 8),
    "Dark mode":   rice(400, 2, 0.6, 12),
    "Audit log":   rice(50,  4, 0.9, 6),
}

for name, score in sorted(items.items(), key=lambda x: x[1], reverse=True):
    print(f"{name}: {score:.1f}")
# Export CSV: 60.0
# Dark mode:  40.0
# Audit log:  30.0

Simple explanation: RICE turns gut feel into a comparable number. In this example "Export CSV" wins even though "Dark mode" reaches more users, because export is more impactful and cheaper to build. The point is not the formula — it's that every feature is scored the same way.

Best Practices

• Revisit priorities every week with the customer, not just at kickoff
• Let data (usage, revenue impact, effort) drive decisions, not the loudest voice
• Keep a written "next three priorities" list that everyone on the team knows
• If everything is high priority, nothing is — force a strict ordering

Managing Scope Changes

A scope change is any addition, removal, or rewrite of agreed work. Managing it means having a process to evaluate, approve, and absorb changes — instead of silently letting them in.

Why it is useful: Unmanaged change is the number one cause of late software. A simple change-request loop lets you say yes or no deliberately, with the cost visible before anyone commits.

The Change-Request Loop

1. Log the request — always write it down
2. Assess impact: time, cost, risk, who it affects
3. Decide: accept, defer to a later version, or reject
4. Re-plan the affected milestone if accepted
5. Tell everyone what changed and why

Example: Change Log Tracker

changes = []

def submit_change(desc, impact_days, requested_by, status="open"):
    changes.append({"desc": desc, "impact_days": impact_days,
                    "requested_by": requested_by, "status": status})

submit_change("Add dark mode", 3, "Marketing")
submit_change("Switch export to XLSX", 1.5, "Ops")
submit_change("Remove audit log page", -1, "Customer")

open_days = sum(c["impact_days"] for c in changes if c["status"] == "open")
print(f"Open change backlog: {open_days} extra days")  # 3.5 extra days

Simple explanation: Every change, even a rejection, goes through the same small loop. Allowing negative impacts matters too — removing scope is also a change and should be counted when it goes through the process.

Best Practices

• Treat every meaningful request through the same small loop — no exceptions for "small" ones
• Show the impact in days (and money if possible) before deciding
• Give a clear triage: accept / defer to v2 / reject — "yes" every time is not management
• Re-plan the milestones if an accepted change shifts the schedule meaningfully

Managing Technical Debt

Technical debt is the future cost of today's shortcuts — code written fast that will need rework, missing tests, hardcoded config, unpatched dependencies.

Why it is useful: A little debt is often a smart trade. The skill is tracking it, limiting it, and paying some every iteration so it never compounds into "we can't ship anything anymore."

Where Debt Comes From

• Skipping tests to make a deadline
• Copy-pasted code that should be a shared function
• Hardcoded credentials or config values
• Old dependencies nobody has updated

Example: Debt Register

debt = [
    {"area": "export module",   "type": "no tests",         "est_h": 8,  "paid": False},
    {"area": "auth config",     "type": "hardcoded secrets", "est_h": 4,  "paid": False},
    {"area": "legacy API",      "type": "slow endpoint",    "est_h": 12, "paid": True},
]

unpaid = sum(d["est_h"] for d in debt if not d["paid"])
print(f"{unpaid} hours of unpaid debt")  # 12 hours of unpaid debt

Simple explanation: Writing debt down with a rough cost makes it visible and concrete. "We have 12 hours of known debt" beats "we should refactor someday." The register turns vague guilt into an actual number you can manage.

Best Practices

• Take debt consciously — and add a line to the register at the same time
• Budget recurring time to pay it (an "engineering" slice in every plan)
• Refactor in small, safe steps with tests protecting you from regressions
• Watch the trend: is the total debt growing or shrinking?