Assumptions vs Constraints vs Requirements for PMP Exam
In everyday language, there is just a thin line between the meanings of assumptions, constraints and requirements. In many cases, these terms may even be used interchangeably. This is not so in the PMP® Exam and in the PMBOK® Guide. This article will try to definite the meanings of assumptions, constraints and requirements according to the PMBOK® Guide (and thus the PMP® Exam) so that Aspirants will be not confuse these terms in the exam.
Assumptions vs Constraints vs Requirements
- Assumptions: these are factors that are used in the planning process to allow plans to be created with reasonable details (since without those assumptions, forecasts and budgets cannot be made). Assumptions are reasonably believed to be true based on experience (e.g. lessons learned), knowledge or information at hand.
- Assumptions are needed for estimating the scope, schedule, costs, etc. during the project planning and are well documented in project management plans.
- The risks of false assumptions are dealt with during risk management planning. If the assumptions would adversely affect the project if found to be false, the assumptions would be documented as risks for risk management.
- After completion of the project, the project management will need to assess the accuracy of assumptions and document any findings in lessons learned.
- Constraints: these are factors that need to be taken into accounts when planning the project. Constraints are mostly restrictions imposed on the project. However, with good planning, constraints can be a real benefit to boost effectiveness and efficiency.
- Project managers and the team need to work within the constraints of the project in order to achieve project success. Managing the constraints is one core responsibility of the project manager.
- In traditional project management, there is the “triple constraint”/”iron triangle” (i.e. three most significant restrictions on any project: scope, schedule and cost). However in the PMBOK® Guide, constraints include a total of 6 competing project constraints:
- Scope – what are required/expected of the project?
- Time – when will the project need to be finished?
- Cost – how much money is provided?
- Quality – what is the expectation of the outcome? high or just okay?
- Resources – who are the working team members? what equipment/materials are provided?
- Risk – what can go wrong with the project and how to deal with them?
- These constraints on the project are interrelated, change in one constrain will affect some/all the others. For example, if one skilled team member has just resigned, more time would be needed to finish the project as members with less experience would not progress at the same rate. Likewise, the quality, cost, risk, etc. would also be affected.
- Requirements: these are features/capabilities/products/deliverables that expected to be delivered from the project as interim or end results.
- Requirements focus on the capability of the deliverable rather than the project itself.
Suppose you are just named the project manager of a new hybrid car. The sponsor requests, among others:
- a demo unit to be created by the next car show in 1.5 years’ time,
- the car to have a 0-60 mph time of 8 seconds; and
- it meets the statutory emission requirements for clean car rebate.
Which of these is assumption, constraint and requirement?
- Requirements are the easiest to spot as these are features directly related to the deliverable. So “having a 0-60 mph time of 8 seconds” is a requirement.
- How about “a demo unit to be created by the next car show in 1.5 years’ time”? In plain English, this is a requirement by the sponsor. However, in project management terms, the 1.5 year is a limiting time factor which is considered a “constraint” for the project (but not the deliverable). So, “a demo unit to be created by the next car show in 1.5 years’ time” is a constraint.
- The third one: “meets the statutory emission requirements for clean car rebate” is a requirement in itself as it is concerned about the cleanliness of the exhaust gas from the car. However, there is an underlying assumption which is the statutory emission requirement would NOT be changed during this 1.5 year as the goals are aligned to the current statutory emission requirements which is an assumption believed to be true at the beginning of the project.