Last month, we started the examination of topics to know for each of the domains on the CompTIA Project+ certification exam (PK0-004) by looking at the first domain. This month, the focus is on the second domain, Project Constraints, which is weighted at 17 percent of the exam.

While that weighting makes it the smallest of the four domains, don't let that fool you. The issues related with limitations and constraints are not confined solely to this domain and it is important to be comfortable with the topics introduced beneath both of the subdomains (2.1, and 2.2.).

Given a scenario, predict the impact of various constraint variables and influences throughout the project

The PMI Book of Knowledge (PMBOK) defines a constraint as the state, quality, or sense of being restricted to a given course of action or inaction. An applicable restriction or limitation, either internal or external to the project, that will affect the performance of the project or a process.

In other words, a constraint is anything that restricts/limits the actions of the project team members. Some of the more common of those constraints are: budget, scope, deliverables, quality, environment, resources, requirements, and scheduling.

Every project has a defined amount of funding associated with it, and costs have to be monitored throughout the duration of the project to avoid exceeding that budget. The scope outlines the deliverables (measurable outcomes or results) for the project along with the expectations that need to be met for the project to be a success.

The reason the scope is a constraint is that it limits what can be done to meeting the requirements of the deliverables — anything else is outside the scope statement.

Quality is a constraint in that deliverables are measured against it (whatever it has been defined as) and cannot be accepted until the standard of quality is met. Similarly, environmental constraints can relate to quality (air, water, waste, etc.) or be as simple as delays caused by weather and conditions.

Resources (human, equipment, funding, etc.) all have scarcity and can be a constraint if they are in short supply or not available when needed. Requirements and the deliverables (mainly, the measurable characteristics of them) that must be met in order to fulfill the project are also constraints.

Lastly, scheduling is a constraint in that it should be thought of as a sliding window of availability in which you need to complete deliverables for the project.

A number of influences impact the project and the constraints, namely: change request(s), scope creep, constraint reprioritization, interaction between constraints, stakeholders/sponsors/management, and other projects that are competing for the same resources.

The change request is a formal request to modify a project — that modification could be to something minor or something major, but it will assuredly affect either the budget, time, or scope. A change review board should examine all change requests and determine whether they will be accepted or not and weight impact/change this has on constraints.

Scope creep occurs when the project is changed and other constraints are not adjusted. As the scope of the project grows, it is bound to affect time or budget. The best way to prevent this from happening is for the projects manager to keep tight control on creep and force every change to go through a formal change request process.

Constraint reprioritization happens when the project has to (or chooses to) switch priorities from one constraint to another. An example of this would be having a single-minded focus on finishing a project on time and making scheduling the top priority. Suddenly, word comes down that funding for every project is being cut by 20 percent and now you have to reprioritize and find a way to do the project with budget now being the top priority.

Similarly, interaction between constraints can become an issue when there is a refocus or change that occurs after the planning stage. In this scenario constraints need to be reexamined and planning adjusted accordingly.

Stakeholders/sponsors/management represent those directly involved in the project scope and budget, and wield great influence over the project. They have the freedom to change their minds, their commitments, and their priorities and all can affect the success of the project.

One thing any of these parties may choose to focus on at any given time is other projects — and those other projects can steal not only attention, but resources from an existing project and greatly impact its constraints. Beneath the management section, the project manager is also included and the risk of them losing attention/commitment to the project is just as real and dangerous for them as for anyone else.

Explain the importance of risk strategies and activities

Risk is defined by PMBOK as an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives. While there are a number of ways of dealing with risk, the five strategies most relevant to project management are: accept, mitigate, transfer, avoid, and exploit.

Risk acceptance means acknowledging that the risk exists (and that you could well be affected by it) and then choosing to do nothing further about it. The fact that the risk exists does not mean that you will be affected by it, but only that you realize the possibility you could is genuine.

Quite often, this is the choice that you make when the cost of implementing any of the other choices exceeds the value of any harm that could occur if the risk comes to realization. To truly qualify as acceptance, it cannot be a risk that you are not aware of.

You must be fully away of it and understand the potential cost/damage and make an informed decision to accept it. Every firm and every project has a different level of risk tolerance/appetite that they are willing to contend with.

Risk mitigation (also known as risk reduction) occurs when you actively take steps to reduce the risk. The harm the risk holds may still occur, but you've reduced the impact it will have. Some steps that can fall into mitigating the risk include educating users about possible problems, monitoring operations, and so on.

Risk transference is when you offload some of the risk to another party. This does not mean that you are no longer exposed to risk, but rather that you have divested some of it (sharing the burden, so to speak) to the other party.

A common other party is an insurance company which insures you for a cash amount if all steps were in place to reduce risk and harm still occurred. Because the harm is being distributed, risk transference is sometimes referred to as risk sharing.

Another transference possibility involves employing external consultants for assistance with solutions in areas where internal knowledge is weak and requiring them to guarantee/warranty their work.

Risk avoidance, as opposed to the three forms of acceptance discussed thus far, involves identifying a risk and making the decision to no longer engage in actions associated with that risk. As a part of avoidance, the company takes steps that remove the risk, chooses to engage in some other activity, or puts a stop to their exposure.

Avoidance should be based on an informed decision that the best course of action is to deviate from what would/could lead to exposure to the risk. One of the biggest problems with risk avoidance is that you are steering clear of activities you may benefit from and are prevented from adding social value — not to mention monetary value — to stakeholders.

Risk exploit (or exploitation) differs from the other four risk strategies in that it spins the presence of risk from a negative into a positive and involves looking for opportunities to take advantage of the situation. Positive risks that one can benefit from include such things as finishing the project below cost, finishing it early, etc.

It can also involve taking something was created as a byproduct during one project (an app, for example) and selling it as a standalone to bring in additional/unanticipated revenue.

Regardless of the risk-related strategy employed, there are eight activities associated with risks that project managers must do: identification, quantification, planning, review, response, register, prioritization, and communication.

Most of these eight are self-explanatory but know that identification is the process of identifying potential risks associated with the project and documenting them, while various forms of analysis are then used to evaluate the severity of impact a risk could pose to the project and the likelihood of it actually occurring. Risk response involves determining what actions (if any) to take related to the risks (and documenting everything in the response plan).

Summary

This month, we looked at the second of the four domains on the CompTIA Project+ certification exam (PK0-004). In the next two months, we will look at the remaining domains individually, and then follow it up with a self-test intended to let you measure how ready you may be to start looking for a free couple of hours to work this exam into your future.