CompTIA Project+ Certification Guide

Learn project management best practices and successfully pass the CompTIA Project+ PK0-004 exam

J. Ashley Hunt

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781789532340
• Edition: 1
• Topic: Computer Science
• Subtopic: Certification Guides in Computer Science
• Index: Computer Science

Your perfect companion to prepare for and pass the CompTIA Project+ PK0-004 exam

Key Features

• Manage project changes and deliver desired project outcomes
• Gain confidence in passing the PK0-004 exam with the help of practice questions
• Obtain insight from J. Ashley Hunt, an accomplished subject matter expert

Book Description

The CompTIA Project+ exam is designed for IT professionals who want to improve their career trajectory by gaining certification in project management specific to their industry. This guide covers everything necessary to pass the current iteration of the Project+ PK0-004 exam.

The CompTIA Project+ Certification Guide starts by covering project initiation best practices, including an understanding of organizational structures, team roles, and responsibilities. You'll then study best practices for developing a project charter and the scope of work to produce deliverables necessary to obtain formal approval of the end result. The ability to monitor your project work and make changes as necessary to bring performance back in line with the plan is the difference between a successful and unsuccessful project. The concluding chapters of the book provide best practices to help keep an eye on your projects and close them out successfully. The guide also includes practice questions created to mirror the exam experience and help solidify your understanding of core project management concepts.

By the end of this book, you will be able to develop creative solutions for complex issues faced in project management.

What you will learn

• Develop a project charter and define team roles and responsibilities
• Plan the project scope, schedule, budget, and risks
• Process change requests and work with procurement documents
• Close a formal project or phase and get an overview of Agile Project Management principles
• Create a work breakdown structure (WBS) and dictionary
• Discover best practices for identifying, analyzing, and responding to risk
• Gain important exam information and discover the next steps

Who this book is for

The CompTIA Project+ Certification Guide is for entry-level project managers who are looking for a common language and best practices in the IT project management space as well as a certification to excel in their career.

Developing a Project Schedule

In this chapter, we will review schedule management in the planning process group. We will begin with the schedule management plan, which describes how to manage your schedule, from creation to monitoring and controlling. Then, we will review how to define and sequence tasks in a logical order, to best estimate durations, as well as the creation of the project schedule and the schedule's baseline.

The following topics will be covered in this chapter:

• Developing a schedule management plan
• Defining tasks
• Sequencing tasks
• Estimating task durations
• Creating the project schedule

Developing a schedule management plan

As with any other management plan, a schedule management plan is a how-to guide. While this plan helps you get your schedule priorities in gear, it may be a plan that you wouldn't use in the real world, because those who schedule, schedule. They already understand how to put together a schedule baseline and the rules of the organization. But what if you are new to scheduling? What if your customer needs more clarity on how the schedules will be created and updated? What if you don’t have a schedule coordinator? Oh, the horror! I mean, you can do this! Now, it may be realistic to at least get everyone on the same page about the rules and how changes will be managed.

You probably will not be tested on the value of the schedule management plan, but it is considered part of the integrated project management plan.

The high-level overview of what may be included in the schedule management plan allows for several schedule management best practices to be addressed in one place.

Schedule management plan considerations

Being able to answer the following questions will help guide you as to whether you need a schedule management plan. Remember to ask yourself the questions from the perspective of your team and other key stakeholders as well. Just because you know the answers doesn't mean they know the answers. Remember, schedule changes can impact everything else, so knowing how to manage changes is a big consideration.

The questions that can be answered with a schedule management plan are as follows:

• How will you monitor and control the overall schedule?
• What are the approved schedule development tools and techniques?
• How will changes to the schedule baseline be managed?
• Who is responsible for developing and maintaining the project schedules? (Please say a schedule coordinator!)
• How and when will schedule performance be reported?

You will see as you move through this guide that we spend less and less time on management plans. There are a few exceptions though, and they are communication management and risk management, which we will go into in more depth in Chapter 7, Resource Management Planning and Communication Considerations and Chapter 8, Budget and Contingency Plans for Risk, but until then it’s time to move on to the what of schedule management.

The completed schedule will be a major constraint, so it’s important to have a management plan that can address some of the challenges of scheduling. All constraints, not just the schedule, are competing constraints. This is because they not only affect one another, but some constraints are more important than others to customers and stakeholders. Does your organization care more about time, scope of work, or money? You may have heard the saying, you can have it fast, good, or cheap, but you can’t have all three. This is because they are competing. How long will this take, and how much will it cost? Did we build the right thing, and did we build the thing right? These are questions that will be asked and need to be answered as you progress through the project. By planning effectively, you will be able to answer those questions.

Defining tasks

Remember when we discussed the work breakdown structure (WBS) and you reviewed how to decompose large deliverables down to the work package level? Now, we will take those work packages and decompose them to the task level. This is where the WBS begins to influence the schedule but is still not a schedule. We will use the WBS to get to the task level, and once that occurs we will have a task list and milestones that will guide the creation of the actual schedule and the baseline. I realize that for the most part I’m writing philosophy here. We are involved in the realm of easier said than done right now. This piece can be very time consuming especially if you have never done a project before or you are working on something totally new. For the sake of the exam, the defining of tasks process is self-explanatory, meaning you don’t need to know a whole lot about the process to answer questions because it just is what it is. This is generally because CompTIA and PMI^® could never say specifically, this is how you define activities on your projects. Every project is unique, and every project will have differing levels of task decomposition.

Suffice it to say that every project is different, and you will have to decide how far down you want to take your tasks. It’s probably not a great idea to take them down to the nth degree. Nobody, and I mean nobody, wants an eight-thousand-line item schedule when all is said and done, except for maybe NASA, because it’s necessary. For the rest of us, the more concise we can be, the better we will manage things. This comes with a caveat though: make sure you have enough information so that nothing is missed. Even though the scope of the work may not be 100 percent clear right now, it will be progressively elaborated on throughout the project. This would lead to updates to the scope statement and the WBS through formal change control, and that could/will drive changes to your task list and milestones. That is why the WBS and the currently approved scope statement are the biggest influencing factors right now. Couple that with the process of breaking deliverables down to the task level, and it's probably best to call in reinforcements. Remember, even though project management is a big job, you are not working in a vacuum by yourself. It is assumed that you are in a strong matrix organization on the exam, unless otherwise stated in the question. That would mean you have a core team of people to help you plan. The best advice on the work breakdown to the task level is from the people who do the work, because they know the work and can help with this process.

Expert judgment is the number one tool or technique in project management.

Now, you have large deliverables and work packages that need to become tasks. The best practice is to break them down to the level where everyone understands the work to be done and assumptions are clearly documented and discussed. It's always a bit of a guessing game to determine how far the work packages should be broken down. Some project managers like to stick to the heuristic or rule of thumb that each work package be no larger than 80 hours’ worth of work and at least eight hours. This can vary from project to project, but it is easier to plan one day or two weeks’ worth tasks than a month or greater. The difference could very well be a concise task list versus an 8,000-line-item project plan. I know from experience that that type of task list leads my software to fight back and become an unmanageable list of work. I realize when you are first starting out, you don't want to miss anything, and I totally get that, but try to balance both sides as much as possible. It will help you in the end. Plus, if you have resources who understand the work they are going to do, it becomes unnecessary to break it down any further than their understanding.

Install software for HR doesn't need to be documented as follows go to HR, turn on computers, wait for them to boot up, put software in the computer, and so on. That is too much information for your task list, and your resources already know how to do the work and what the work entails. Unless you have contracts that force you to document every single item for the purposes of compliance, try to keep it simple and executable.

Once you have completed the process, you will have a task list. This process is iterative as well because it is dependent on the currently approved scope baseline. If scope changes, so will the tasks to complete the work. Progressive elaboration and rolling wave planning are very typical when defining the tasks and putting together a schedule you can probably meet.

The other main output of the defining tasks process will be milestones. The origin of the word milestone takes us back to the third century, when Romans were building their network of 53 thousand miles of roads. Every one-thousand paces or so a stone marker would be placed so travelers knew how far they had traveled. Granted, most of the milestones had names of Roman emperors on them, and you won’t see that in your schedules, although it would be interesting in a meeting: We have reached the Marcus Aurelius milestone and plan to catch up to Commodus by next week. It stands to reason that using milestones lets you know how far you need to go and how far you have traveled through your project.

Typically, there are two types of milestones: mandatory and discretionary. Mandatory are the ones we are used to. Those dictated by the project charter, the customer, the sponsor, and those that may act like Roman emperors. Discretionary milestones are typically used by project managers to set goals for their team. This allows for checkpoints of successes without all the pressure.

Once you have your task list and any additional information or attributes you can use to help you plan as well as milestones documented, you now have a skeleton of your project. Now, it is time to put the sequence together. The knee bone is connected to the shin bone.

In Figure 6.1, you can see the WBS and how it influences the task definition process:

Figure 6.1 WBS

This is also why the WBS isn't a schedule, because you will need to break it down from the work package level to the task level in a progressive way as new scope is determined. Then, you'll need to sequence those tasks and estimate durations and resources, before you can even think about what your schedule will be.

Sequencing tasks

I find sequencing tasks to be the most stressful piece of project management, because if you get the order incorrect, the entire project goes sideways. That’s a lot of pressure! Still, others love this piece and are exceptionally good at putting the puzzle together. If you have never done this before, it can be a bit daunting, especially if you are using scheduling software for the first, or even the one hundredth time. It isn’t unusual to see (me) project managers gesticulating wildly at their computer screens and asking why the finish date just jumped out four thousand days into the future. This is because of several reasons. First, the order in which things occur will affect the dates, and then the resources...