Assumption and Constraint Analysis

Goal

The analysis checks that the plan of a project rests on facts that will hold. Every project is designed on assumptions and within constraints. These are often already built into the scope baseline and the estimates. A six-week estimate for the specification assumes that three analysts are available. If only two are, the schedule has been wrong since the day it was signed.

The analysis shows which assumptions become threats and which constraints the team can renegotiate. The risk register receives one row for each threat or opportunity found. On this basis the team re-estimates, renegotiates a constraint with the sponsor or accepts a limit on the project.

The PMBOK Guide also lists the technique for planning stakeholder engagement. There the team tests its assumptions about the availability or support of a stakeholder in the same way.

Usage

When to use it

• Signed project charter or business case: test the assumptions of the mandate before the risk identification workshop.
• Estimate about to be committed: list the assumptions under each figure before promising a budget or a date.
• End of a phase: review the assumptions of the past phase before releasing the next one.
• Changing context: a law under revision or a replaced supplier reopens the assumptions that depend on it.
• Interfaces with third-party systems: check what the project assumes about the data, formats and lead times of each owner.
• Stakeholder engagement plan: test what the plan assumes about their availability and their support.
• Team spread over several sites: a shared log is enough. Each owner checks their assumptions in it without a meeting.

When not to use it

• Event that has already occurred: it is an issue. It goes into the issue log that item tracking keeps.
• Search for new ideas: to reverse an assumption and generate options, move to creative thinking.
• Quantified statement to check against data: hypothesis formulation and testing settles it on a sample.

Description

Assumption, constraint and assumption log

The PMBOK Guide defines an assumption as a factor in the planning process that is considered to be true, real or certain without proof or demonstration. A constraint is a limiting factor that affects the execution of a portfolio, programme, project or process. This definition reaches beyond the triangle of time, cost and scope. A law, a contract, a technical standard or a decision of the sponsor are constraints.

The BABOK Guide treats the same pair in the business case. It calls assumptions agreed facts that may influence the initiative. Constraints restrict the options. For the BABOK Guide, agreeing on these factors and documenting them gives stakeholders realistic expectations and a shared understanding. An agreed assumption remains unproven in the sense of the PMBOK Guide. The agreement shares the belief without verifying it.

The PMBOK Guide describes the assumption log as the project document that records all assumptions and all constraints. The team adds new ones to it. It updates the status of existing ones or closes them. Strategic and operational constraints appear in the business case before the project starts, then pass into the project charter. Detailed assumptions arise during the project when the team defines the technical specifications, the estimates, the schedule activities and the risks.

The Initiate Project or Phase process produces the log. The planning, estimating and risk management processes read it and record their updates in it.

In the traditional approach, HERMES 2022 places the estimates in the execution order and in the project management plan with their accuracy and their reserves. HERMES asks for the assumptions behind these estimates to be documented: governance demands this transparency. HERMES defines no assumption log. The log of the PMBOK Guide meets this requirement.

Where do threats and opportunities come from?

Threats can come from assumptions that are inaccurate, unstable, inconsistent or incomplete. Opportunities can come from constraints: removing or relaxing a limiting factor yields a gain. The Identify Risks process recognises negative and positive risks.

The PMBOK Guide defines the technique without giving its steps. Steps 1 to 5 apply its definition in order.

1. Gather the assumptions and constraints

The team rereads the business case, the project charter, the scope baseline and the basis of estimates. It records each assumption and each constraint in the log with its source and its owner. Many assumptions are implicit. An estimate assumes a team, a delivery date and a pace of decisions that nobody has written down. The analyst gets the person who produced the figure to state them in an interview. Document analysis finds them in contracts and minutes.

The analyst writes each assumption as a verifiable fact: who does what, in what quantity, by when. "Users will be available" cannot be tested. "The planning department releases two people two days a week for user acceptance testing (UAT) from February" can be tested.

The log separates assumptions from constraints because the next step differs: the team tests an assumption and negotiates a constraint with whoever set it. Someone imposes the constraint: the sponsor, the legislator, a contract. The team holds the assumption to be true. A date announced by the sponsor often passes for a constraint. The team asks where it comes from. A decision of the Council of State is a constraint. The hope of a head of department is an assumption to test like the others.

2. Test each assumption

The PMBOK Guide names the defects of an assumption without defining them. One question tests each defect. The questions and the failing examples are a practitioner's reading.

The analyst checks with the source. An email to the vendor settles the matter faster than an hour of discussion in a meeting room. When an assumption passes the four tests, the team closes it in the log and notes its source and the date of the check. An assumption that fails a test becomes a candidate threat.

The least tested assumption is often the one held by the most senior person. Contradicting the sponsor's date in a meeting requires a degree of psychological safety that not every team has. The analyst then asks each owner for the source line by line and in writing.

3. Write the threats into the register

The team writes each threat in the format of every register row: cause, event and consequence. The cause is the defect found. The event: the assumption turns out to be false. The consequence names the objective affected.

Assumption H-01 becomes threat R-15: "Because vendor C has made no written commitment, its interface specification may arrive after 30 September, which would delay integration testing by six weeks." Copying the assumption into the register is not enough. "The vendor delivers by 30 September" describes the plan. The register row describes the event that contradicts the plan. The threat takes the date of the assumption as its trigger. The owner of R-15 acts if the specification of vendor C is missing on 30 September.

The two rows cite each other. When the vendor confirms its date, the team closes both together. Probability and impact belong to risk analysis and to the probability and impact matrix. The team chooses the response with the risk response strategies.

4. Question each constraint

For each constraint, the team asks one question: can the limit be removed or relaxed? Only the person or body that set a constraint can remove it. So the team notes who set it and for what reason. The sponsor decided that all municipalities would switch on the same day to avoid two parallel channels. The team can discuss this with the sponsor. A ceiling voted with the cantonal budget does not move before the next budget.

If the answer is yes, the team writes an opportunity into the register: what the project would gain if the limit fell. Constraint C-01 becomes opportunity R-19: "Since 9 municipalities already receive plans as PDF, they can open the digital file three months before the others if the sponsor relaxes the single date, which would give three months of user feedback before go-live in the other 12 municipalities." Opportunity analysis takes over. If the answer is no, the constraint stays in the log as a limit on the project.

A team that treats every constraint as untouchable applies half the technique.

5. Keep the log current

According to the PMBOK Guide, risk identification is iterative because some risks only appear during the project. The Monitor Risks process also updates the assumption log. Each row of the log carries the status "open" or "closed". The team reviews the log at each risk review and at the end of each phase. It adds new assumptions, closes the confirmed ones and tests again those whose context has changed.

When an assumption turns out to be false, the team closes its row in the log. The register row moves to the status "occurred". The team opens an issue in the issue log. An assumption with no owner and no check date stays open until the project closes. Nobody tests it. At closure, the log goes to lessons learned: the assumptions that fell show what the next project must check first.

Neighbouring techniques

A statistical hypothesis is a quantified statement. Hypothesis formulation and testing confronts it with a sample of data. The analyst checks a planning assumption with its source: a vendor, a department, a contract.

Creative thinking includes assumption reversal. It also starts from a list of assumptions, inverts each one and discusses the ideas that the inversion produces. Assumption and constraint analysis asks whether an assumption will hold and what risk follows if it falls.

The PMBOK Guide places the technique in the Identify Risks process alongside SWOT analysis, root cause analysis, brainstorming and checklists. Brainstorming produces risks from the experience of the participants. Assumption and constraint analysis draws them from the plan.

AI considerations

A language model reads a project charter, a business case and the basis of estimates. It extracts the implicit assumptions: verbs in the future tense, dates without a source, resources assumed to be available. It rewrites them as verifiable facts and asks the four defect questions of each one. It compares the documents and flags inconsistencies, for example a number of analysts that differs between the charter and the estimate. From an assumption that fails, it drafts a threat as cause, event and consequence.

The model does not know whether an assumption is true. It does not know what the vendor promised on the phone or what the Grand Council will vote. The analyst checks accuracy with the source and assesses stability with the people who know the context. The model also produces plausible and generic assumptions that inflate the log. A proposed row goes into the log when an owner recognises it. The log names suppliers, people and contractual commitments. It goes to an external AI service if the organisation allows it. In a Swiss administration, the applicable data protection law and the hosting location decide.

Examples

A French-speaking canton digitises building permit applications. The team analyses the assumption log at the end of Initiation. The extract shows the log after the analysis.

H-05 and C-02 produce no row in the register. The team closes H-05 in the log with its source and its date. C-02 stays open because it limits costs until the next budget. An analysed log keeps these rows: they show what the team checked and what it chose not to renegotiate.

Visualisations

The assumption log is a table: one row per assumption or constraint with its source, the analysis result, the register row it produced and its status. A diagram follows the two paths of the technique: from assumptions to threats and from constraints to opportunities. A second diagram shows the statuses of a log row up to its closure. The defects table gives one question per defect.

Cost

Tooling

A spreadsheet is enough for a log of a few dozen rows: one column per defect tested, a drop-down list for the status ("open", "closed"), a column for the register reference. A tracking tool such as Jira or Azure DevOps handles assumptions and risks as two linked ticket types. It records each status change and notifies the owner. Many teams keep a single log for risks, assumptions, issues and dependencies. It is often called a RAID log. This format keeps the assumption row and the threat row in the same file. For a Swiss administration, the hosting location of the data guides the choice once the log names suppliers or people.

Sources

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: the Identify Risks process and its tools (§2.7.2.2, Figure 2-49); the tools for planning stakeholder engagement (§2.5.2.2, Figure 2-34); the assumption log (Section 4, entry Assumption log); the definition of the technique (Section 5, entry Assumption and constraint analysis); the definitions of assumption and constraint (Glossary).
• International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.7 Business Cases: the element Assumptions, Risks, and Constraints.
• Federal Chancellery, HERMES 2022, Project Management Reference Manual: the assumptions behind the estimates (7.4.5.3 Planning in traditional solution development, passage "Planning accuracy over the course of the project").