Skip to content

Lab 04 — Identifying Project Constraints and Assumptions

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Convert a project brief into an explicit list of constraints, classified by how negotiable each one is.
  2. Write an assumptions log, and rate each assumption by the damage if it turns out false.
  3. Identify the binding constraint — the one that governs every other decision.
  4. Explain why an unrecorded assumption is a risk that has not been priced.

Scenario

A national bank has approved a mobile banking application for retail customers: balances, transaction history, fund transfers between the customer's own accounts, bill payment, and card blocking. The existing service is a web portal that requires a browser and a card reader, and customers have complained that it does not work on phones.

The programme brief states:

Item Statement in the brief
Launch "Available to customers before the end of the financial year."
Budget "Fixed at the approved figure. No supplementary budget will be requested."
Team "Two experienced mobile developers, one backend developer, a tester at 50%, and a security specialist shared with another programme."
Regulation "The application will meet the bank's information-security policy and the regulator's requirements for customer authentication."
Existing systems "The core banking system provides a transaction API. The programme will not change the core system."
Testing "No release will be made without the security specialist's approval."
Customers "The target is 60% of active web portal users to have installed the application within six months of launch."
Support "The call centre will handle enquiries arising from the new application, using existing staff."

Additional facts from conversations, not in the brief:

  • The core banking transaction API is documented, but the documentation is four years old and two endpoints are listed as "subject to change".
  • The security specialist is committed to the other programme for two days a week.
  • The regulator's authentication requirements were revised in the past year; nobody on the team has read the current version.
  • The call centre manager was not consulted about the support statement.
  • The bank's brand team requires all customer-facing text to be approved on two languages.
  • The tester at 50% is currently the only person who knows how the bill-payment service is configured.

Your role

You are the project manager, appointed two weeks after the brief was approved. Your first task is to find out what the project is actually constrained by, as distinct from what the brief asserts.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

Work with the brief and the additional facts exactly as given. Where you need more information to classify something, do not invent a fact — record it as an open question and state who could answer it.

Tasks

Task 1 — Split constraints from assumptions

Sort every statement above into one of three buckets:

  • Constraint — a limitation the project must work within.
  • Assumption — a belief that is taken as true but has not been confirmed.
  • Open question — a decision or fact that is not yet known.

A single statement from the brief may produce entries in more than one bucket. Say so when it does.

Task 2 — Classify each constraint

For each constraint, record:

Field Meaning
Type Time, cost, scope, quality, regulatory, technical, or resource
Flexibility Fixed, negotiable with approval, or influenceable
Evidence Why you classified it that way — from the brief or from a conversation
Consequence if breached What actually happens

Do not assume the brief is accurate about flexibility. "Fixed" in a brief often means "nobody has asked yet".

Task 3 — Build the assumptions log

For each assumption, record:

Field Meaning
Assumption Stated so it could be shown false
Owner Who can confirm or refute it
Cost if false In time, money, or quality
Warning sign What you would notice first if it were wrong

Then rate each assumption high / medium / low for damage if false, and sort the log by that rating.

Task 4 — Name the binding constraint

Identify the single constraint that governs most of the others and explain your reasoning. Then answer: if that constraint were relaxed, what would become the new binding constraint?

Task 5 — Find the unpriced risk

At least three statements in the brief are assumptions presented as facts, in that they sound like commitments but depend on someone else's action or agreement. Identify them and write one sentence each explaining what would have to happen for the statement to become true.

Task 6 — Ask for what you need

Write four questions for the programme steering committee, ordered by how much they change your plan if answered unfavourably. For each, state the answer you expect and what you would do if you are wrong.

Deliverable

  1. A categorisation table (constraints / assumptions / open questions).
  2. A constraint register with type, flexibility, evidence, and consequence.
  3. An assumptions log sorted by damage if false, with owner, cost if false, and warning sign.
  4. One paragraph naming the binding constraint.
  5. Three unpriced risks identified from the brief.
  6. Four questions for the steering committee, ordered by consequence.

Hints and guidance

  • "Fixed" is a claim, not a fact. A fixed budget is fixed until someone with authority changes it. Your job is to record who has that authority, not to treat the claim as law.
  • An assumption is only useful if it could be false. "The sky is blue" is not worth logging.
  • Look for assumptions hidden as commitments. "The call centre will handle enquiries using existing staff" is an assumption about capacity made by someone who did not consult the call centre manager.
  • Regulatory statements deserve special suspicion. "Will meet the regulator's requirements" is meaningful only when the current version of those requirements has been read.

Self-check criteria

Check How to verify it
Every brief statement is classified Count the statements; none is unaddressed
Flexibility ratings are evidenced Each one cites the brief or a conversation, not intuition
Assumptions are falsifiable Each is written so you could imagine it being wrong
Log is sorted by consequence The riskiest assumptions are at the top, not in brief order
Binding constraint is argued Task 4 gives reasoning, not just a name
Questions are ordered by impact The first question is the one that would most change your plan

Reflection

  1. Which constraint did you initialy want to treat as fixed, and what made you reconsider?
  2. The target of 60% adoption within six months is in the brief. Is it a constraint, a target, or an outcome? What difference does the label make?
  3. Who should own the assumption that the core banking API documentation is accurate?
  4. What is the cost of not logging the assumption that the call centre can absorb the support load?
Model discussion points
  1. Most students initially treat the end-of-financial-year date as fixed. The correct treatment is usually "negotiable with approval", because a date set in a brief has an owner who can change it — and treating it as immovable removes your ability to trade it against quality or scope when reality arrives.
  2. It is an outcome, not a constraint. Outcomes are the responsibility of the adopting business and depend on adoption that the project cannot compel; that distinction determines who is accountable when it is not met.
  3. The application owner, not the project manager — the project can only detect and report that the documentation is stale.
  4. It is discovered late, in the call centre, as an operational failure after launch, and by then it is not a project problem that can be solved with project resources. Logging it early converts it into a decision the business can make before launch.

Extension challenge

Take the constraint you classified as fixed and write the business case for relaxing it: what the project would gain, what it would cost, and who must approve. Then state, in one sentence, why a project manager who never asks for a constraint to be relaxed is not doing the job well.