Saturday, July 19, 2014

Project Management 101: Project Constraints

Every project has constraints. Understanding each constraint and the relationship between the constraints will allow for more effective management of a project. The primary constraints of a project are risks, resources, budget, schedule, quality, and scope.

Constraint
Definition from the Project Management Body of Knowledge (PMBOK)
Huh? What does that mean?!
Risk
An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives
What might affect the project and result in a pro or con
Resource
Skilled human resources (specific disciplines either individually or in crews or teams), equipment, services, supplies, commodities, material, budgets, or funds
Who and what is needed to complete the project
Budget
The approved estimate for the project or any work breakdown structure component or any schedule activity
How much money is available
Schedule
An output of a schedule model (a representation of the plan for executing the project’s activities including durations, dependencies, and other planning information, used to produce a project schedule along with other scheduling artifacts) that presents linked activities with planned dates, durations, milestones, and resources
How much time is planned (for each part and the whole of the project)
Quality
The degree to which a set of inherent characteristics fulfills requirements
How well something fits outlined specifications
Scope
The sum of the products, services, and results to be provided as a project
What’s the desired outcome & how will it be accomplished

Since constraints exist for every project, it is important to understand the relationship of project constraints. The relationship of project constraints is if any one of the constraints changes, then one or more other constraints is likely to be affected. If converted to a representative mathematical equation, then the relationship of constraints would be similar to below:

Project Outcome = Risks + Resources + Budget + Schedule + Quality + Scope

The relationship can also be thought of in terms of a pizza (just because I love pizza and am currently craving it) where each constraint is a slice of the whole project, but if one slice is larger, then the other slices will be affected.
For example in a project to implement new accounting software for a customer, the customer approaches you and insists that it is necessary to add a procurement module in addition to the account modules. Accepting the customer’s change request would mean a change in scope since instead of implementing only new accounting software, now the project will implement new accounting and procurement software. By allowing this change to scope (a constraint) other constraints are likely to be affected i.e. quality may decrease if the project remains on the same schedule and budget then some of the specifications may need to be sacrificed to accommodate the scope change, risks may increase since additional work is added to the project will provide more opportunities for uncertainty.


Planning is key to a project’s success, but projects are rarely static. Change happens and when change happens, constraints shift. To adapt to the natural flow of a project, planning should happen frequently and be progressively elaborated as constraints change. Many details and information are not known upon initial planning of a project; progressive elaboration allows for increased detail, accuracy of estimates, and accommodating for changing constraints.  

Disclaimer: The views and opinions expressed are those of the blogger and are not necessarily those of the Federal Reserve Bank of Dallas or the Federal Reserve System.

No comments:

Post a Comment