Please login or join to subscribe to this thread
Lisa, to me a constraint represents boundaries to the project. These can be imposed by management and are therefore somewhat negotiable or they could be more physical in nature and therefore more uncontrollable. Constraints can increase or reduce risk depending on their specific nature. Some constraints might limit the team’s ability to perform while others actually improve that ability.
Risk on the other hand has to do with the probability of experiencing failure. Failure to complete the project and failure for the project to deliver what it promises once completed are two areas of risk that should be evaluated on every project. If that risk can be correlated to constraints then the team should determine whether the constraint is controllable or not.
In the project management world, one often hears of the "triple constraint" of scope/quality, time/schedule, and money/budget. The fulfillment of these are what I tend to think of as "necessary conditions" of project success. To the extent that there are limitations on time or money (beyond the simplistic "as soon as possible" or "as cheap as possible") either of these two could be considered a constraint upon delivering the benefits associated with the scope.
Constraints are usually thought of as limitations on the ability of a system in its effort to acheive its goal. The project management realm can be thought of as consisting of two levels of systems. First, there is the system that is the project, and around that is the system that is the organization that needs to deliver a number of projects.
For the system that is the project, the goal should probably considered to be the benefits that will be accrued to the project owner upon its completion. Given an agreed upon scope that will deliver those benefits, there is often the opportunity to maximize those benefits either by delivering it sooner or at least by a certain point in time with reliability. If the goal is limited by when the project is complete, I would suggest that the primary constraint on a project is the time it takes to execute the project. As a second level constraint, if that time is prevented from being shortened by lack of resources or budget, those aspects become the pieces of the system that can be actionable stand-ins for the constraint.
Keep in mind that it is not only the pure number of resources that will influence goal reaching, but how those resources are used. Most apparent "physical constraints" are actually symptoms of "policy constraints," i.e., practices and procedures that limit the effectiveness of the given resources in the effort of delivering project benefits as soon as possible.
When we talk about a system that is a multi-project organization, like and IT shop or R&D department, the goal is not to maximize the benefit from any single project but from the entire portfolio. If the determining factor of goal attainment for a single project is velocity, then for a multi-project system, you might consider it momentum -- velocity times mass (of project benefits).
As in the single project environment, while one might be tempted to look to a particular resource as the limitation (constraint) to achieving more benefit, those pesky policies, practices, and perceptions about how those resources should be used are very often the real culprit.
The importance of defining the system and goal before looking for constraints cannot be stressed too much. Before you can ask what is blocking success, you have to be clear about what success is. What are you trying to accomplish? That's the goal. What is keeping you from doing so? That's the constraint.
Make sure you have the first question answered appropriately. Then be careful not to jump at the first answer that comes to mind when answering that second question.
Please login or join to reply