The history of tech industry association CompTIA's project management certification exam is an interesting one. At times, it has had “IT” in the title, and at times it has not; at times, it has focused more on generic principles of project management, and at times it has required considerable knowledge of software development. Once certified, regardless of the exam version or topics focused on at the time, you have the certification for life and it does not need to be renewed.

The single exam required to obtain the Project+ certification is now being updated to its fifth iteration (exam number PK0-005) by the end of the year — and the new exam differs substantially from its predecessor. A change in domain names and weighting reveals the swing to test more on software development knowledge and the “Recommended Experience” hints further at this.

The recommended experience for exam 004 read “Minimum of one year of managing, directing or participating in small- to medium-scale projects” while for exam 005 it reads “6-to-12 months of hands-on experience managing projects in an IT environment.”

Aside from this change, there is the usual moving of topics around within domains and wordsmithing seen with most exam updates. The following table lists the top-level domains and their weighting on each exam:

In the discussion that follows, we will look at the first of the four domains on the new exam and some selected topics that appear beneath the subdomains. One other area to note differences on as you prepare for the exam, is the Acronym List accompanying the exam objectives. A great many acronyms that were listed as encouraged knowledge for the previous iteration have gone away (CPM, EAC, ISO, etc.) and been replaced by others, with many of the newer ones being related to cloud computing and software-related topics.

Project Management Concepts

It is worth noting that the previous iteration of the exam had five subdomains that began with “Given a scenario” and there are six of them just in this one domain. That is important because it can indicate that the exam questions are less focused on rote memorization and testing more on the application of principles. While the test details from CompTIA state that the questions are in multiple-choice format (as opposed to ordering, hot spot-based, etc.), they can require you to synthesize information and come to the right answer based on the situation presented.

1.1 Explain the basic characteristics of a project and various methodologies and frameworks used in IT projects.

There are a number of frameworks that you are expected to be familiar with and two of the additions to the newer set of objectives are Kanban and PRINCE2. Kanban uses real-time communication and full transparency of work as precepts: It is big on visualization and one of the distinguishing features of this approach is the use of a Kanban board which is a bulletin board where every task is posted for view by all at any time. PRINCE2 (cobbling letters from “PRojects IN Controlled Environments”) is popular in the United Kingdom and is known for dividing projects into smaller, controllable stages. There are seven key principles to the PRINCE2 methodology:

1. Continued Business Justification
2. Learn From Experience
3. Defined Roles and Responsibilities
4. Manage by Stages
5. Manage by Exception
6. Focus on Products
7. Tailor to Suit Project Environment

1.2 Compare and contrast Agile vs. Waterfall concepts

Both Agile and Waterfall project methodologies and concepts weigh in here, while the previous exam was more focused on Agile. When comparing the two, know that with the Agile approach, phases can be worked on simultaneously. Waterfall approaches consider everything sequentially — you need to plan to finish one phase before starting another.

1.3 Given a scenario, apply the change control process throughout the project life cycle

The key items to know for this objective are that numerous influences impact the project and the constraints associated with it, namely: change request(s), scope creep, constraint reprioritization, interaction between constraints, stakeholders/sponsors/management, and other projects that are competing for the same resources.

A 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 weigh the impact/change this has on constraints.

The ever-bothersome scope creep occurs whenever 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 project manager to keep tight control on creep and force every change to go through a formal change request process.

1.4 Given a scenario, perform risk management activities

A key distinction when evaluating risk (an uncertain event or condition) is to know that it can be either a positive or a negative — and that can change the way you choose to deal with it. The most common strategy employed with negative risk is to accept, avoid, mitigate, or transfer it. The most common strategies used with positive risk are to accept, enhance, exploit, or share it.

Accepting risk (an option for both positive and negative risk) implies 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.

Avoiding risk 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.

When choosing to mitigate risk, the harm the risk holds may still occur, but you’ve reduced the impact it will have. Some steps that can fall under mitigating the risk include educating users about possible problems, monitoring operations, and so on.

Transferring the risk involves offloading 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.

Enhancing the risk (done with positive risk) requires finding a way to benefit the most from it and is very closely aligned with exploiting the risk — which also involves looking for opportunities to take advantage of the situation but is more proactive. The project team actively looks for a way to ensure that the opportunity occurs (such as finishing the project below cost, finishing it early, etc.).

Lastly, sharing the risk is also associated with positive risks and involves the team allowing a third party to benefit from the opportunity presented. An example of this might involve taking something that was created as a byproduct during one project (an app, for example) and allowing another group to sell it as a standalone to bring in additional/unanticipated revenue.

1.5 Given a scenario, perform issue management activities

Managing issues often involves discovering their root cause and then determining where to go from there. A root cause analysis (RCA) focuses on detecting what the main reasons are for a problem and then identifying/prioritizing the order in which to approach the issue(s). The root cause may be a risk, a variance, or a defect, but identifying it and removing it should not only fix the problem but also insure that it does not occur again.

1.6 Given a scenario, apply schedule development and management activities and techniques

While successor/predecessor relationships appeared in the acronym lists of previous exam versions, they weren’t specifically spelled out in the objectives until now. Know that there are four types of relationships possible and the traits of each of them:

Start-to-start (SS): With this type of relationship, the successor activity cannot start until the predecessor has also started. (You can’t, for example, start beta testing until you compile the latest code.)

Start-to-finish (SF): In this relationship, the successor cannot finish until the predecessor has started. For example, you have to start the new server before you can shut down the old one. (And for a while they will both run while you transfer data from the old to the new.)

Finish-to-finish (FF): The successor cannot finish until after the predecessor has finished.

Finish-to-start (FS): The successor cannot start until after the predecessor has finished.

1.7 Compare and contrast quality management concepts and performance management concepts

In addition to user acceptance testing, performance testing, and stress testing, three others to know are smoke testing, unit testing, and regression testing.

Smoke testing involves manually double-checking tests that are otherwise automated just to make certain that everything is working as expected and there are no surprises (sending errors to null where they are never noticed, etc.).

With unit testing, you take the smallest component — whether it is a physical product or a snippet of code — and you test that unit.

As opposed to unit testing, regression testing tests the entire item (product, code, etc.) from start to finish using various inputs and comparing them to the outputs.

1.8 Compare and contrast communication management concepts

Lack of sufficient communication is one of the biggest reasons any project can fail. That communication needs to be present throughout the project and can be done through a plethora of mediums: E-mail, fax, instant messaging, video conferencing, voice conferencing, face-to-face, text messaging, social media, or the distribution of printed media.

Each of these offer their own set of pros and cons: With face-to-face, for example, it is easy to address multiple issues at one time and add in topics that may not have been thought of beforehand — but this can be the costliest form of communication in terms of travel and time.

A number of issues can influence whatever communication method is ultimately employed. These include language barriers, time zones/geographical factors, technological factors, cultural differences, interorganizational differences, intraorganizational differences, and personal preferences.

Some individuals may thrive communicating by telephone, for example, while others prefer to have any other form of communication but the telephone. There are also a wide range of disabilities that can factor in and make it difficult for some individuals to use certain devices. Learning the preferred communication styles and accommodating them can help you build rapport and relationships with team members.

Regardless of the preferred communication method, however, the content of the message must always be a consideration. As much as a team member may prefer to communicate via text messaging, for example, this would not be an appropriate medium to use to inform them of layoffs or other negative information of a similar weight. Criticality and timeliness should also be considered in the dissemination of information regarding the project.

1.9 Given a scenario, apply effective meeting management techniques

Meetings should be used to obtain continuous feedback and can be held in many different formats. Standup and Scrum meetings, for example, can be held daily to check on project progress and should be limited to 15 minutes. Attendance at meetings can be either virtual or in-person, but need all relevant parties must participate.

The agenda is traditionally created before the meeting and outlines what will be discussed during it. The minutes are a summary of what was discussed during the meeting and includes a synopsis of actions taken. Minutes should also include when the meeting began and when it was adjourned as well as the outcome of motions (accepted, rejected, tabled, etc.). Action items are things that need to be done, such as work assigned at the end of a meeting. Every action item should have a person responsible for its completion and a due date assigned to it.

1.10 Given a scenario, perform basic activities related to team and resource management

You should be familiar with the following three organizational structures before attempting the exam.

Matrix: There are multiple types of matrix organizations with balanced, weak, and strong being the three most common as the projects manager’s authority ranges from weak to strong. In this type of structure, authority is shared between functional managers and project managers, and resources are assigned from the functional area to the project.

Projectized: As the name implies, this type of organization is built around the project and project managers are placed at the top of this organization in terms of the amount of authority they have (full). The resources report to the project manager.

Functional: A functional organization is built around filling needs and project managers exists to help fill those needs. As a result of this type of view, the amount of authority project managers are given in this type of organization is less than in either of the other two types. The resources, instead, report to the functional manager and the project manager has either limited or no authority.

1.11 Explain important project procurement and vendor selection concepts

Most projects have one or more exploratory documents associated with them. While these can come in many different forms, the document types CompTIA wants you to be familiar with here are the following:

Request for information (RFI): This is used to gather information about those items (services, products) that you need to procure. The RFI is commonly used to gather specific data — one of which can be price — BUT the RFQ is often used if that is the only data you are wanting to gather.

Request for quote (RFQ): As the name implies, the RFQ is used to solicit estimates. The RFI and RFQ can serve the same purpose, but the RFI can ask for more than just price. Organizations that include a dollar amount in their RFI typically do not use an RFQ at all.

Request for proposal (RFP): When you are ready to start a project (not just gathering information as with the RFI), then an RFP is used. With the RFP, you are inviting vendors and suppliers to submit bids which can then be evaluated and selections made.

Request for bid (RFB): Closely related to an RFQ, a request for bid invites interested parties to submit bids to perform (whether that performing is the providing of services, goods, or labor) and set forth any specific terms and/or limitations that may apply.

‍