PMI-PMP Preparation

PMI defines two key components of successful project management: the first is these process groups and the other important component is the knowledge areas (which will also be covered later in this course).

But for now our focus is on the process groups – the principles that you need to apply to be a successful project manager.

The focus of each process group is on the PM principles that we apply to every project and every phase of the project. It's not a lifecycle; it's the principles that we do to keep our projects alive, well and healthy.

In this topic, our focus is on initiating. It's the upfront validation of the Eureka moment and making sure that our organization is taking on the right projects and the projects that don't have the cost benefit or the strategic alignment or resources should be deferred and or denied. Initiating is critical to ensure that our rare and scarce organizational resources (people and money) are invested in the projects that best support our organizational goals.

With Project initiation complete i.e. the Eureka moment has been validated or to use the proper PMI term the project charter has been reviewed and approved by organizational management confirming that this is the right project for our organization to invest its rare and scarce resources, we move into Planning where we develop the project details.

The project charter defined our project only a 50,000 feet level. Now we're will move down to the details and develop a complete and full project schedule, a complete and full project budget and a whole lot more as you will experience in this topic.

The project management plan has been completed and presented to management for review and approval and they said yes absolutely this is what we want. Let's deliver it.

Which takes us into this and probably the most important of our process groups and that's executing.

This is where the project is delivering the results, and interestingly enough, we as project managers have a limited involvement in execution. Executing is when the team does the work to deliver the results to the business, while we as project managers facilitate the team’s work.

As project managers, our main role in executing is what I call removing the roadblocks. You will never see that term in the PMP exam

but I really consider my role in executing is removing the roadblocks by doing what I can do to make sure my team has everything they need to complete their project deliverables.

This topic is all about keeping the project on track.

WE will roll up our sleeves as the project managers and keep things on track by monitoring that the team members are doing the right things at the right time. And we control the work by taking any corrective actions needed to bring the project back on track and ensure that we always know exactly what's going on all points in the project.

The key input, in my humble opinion, is that work performance information. That's the facts mam, just the facts, from the project team

Members. We compare the current status to the project management plan.

We take appropriate corrective actions, we produce a project status reports and we perform any appropriate changes that we need correct identified variances.

The final process group is closing which is very self explanatory.

This is where you close out the project or the phase and that's probably the “trick question” that you see in your exam.

You may get questions on closing that are specifically referencing activities that happen at the end of the phase. It is still Closing. You're may only be at the end of analysis, but you're still need to go through 100% of the processes defined in this process group. Doesn’t matter if it only the analysis, design, construction, testing or for true full project closure, the same activities must take place, which in a nutshell are getting formal acceptance from the project acceptor and ensuring lessons learned are documented for organizational process improvement.

We're turning a corner in our course. We're leaving the process groups behind and we're moving into the knowledge areas. It's not a hard corner; as all of the activities defined in the process groups are described in the knowledge areas. So perhaps instead of saying we’re turning a corner, perhaps it would be more descriptive to say we're peeling the onion little bit more.

The first of our 10 knowledge areas is project integration management. I believe that Project Integration Management is a bit of an anomaly, as it defines the overall project management approach while the other 9 knowledge areas have specific focuses, scope, schedule, cost, etc.

Integration management is really the glue that holds all of the other components: the scope, the schedule, the cost together and results in a cohesive project management discipline.

I feel like we needed a big drum roll or something to celebrate the fact that we're now in the absolute weeds and that our onion is fully peeled. Develop the Project Charter is the first process in project integration management and the focus is the development of that all important project charter. The Project Charter is the foundation that defines the overall project objectives and scope.

Our next detailed process is the project management plan.

It is the combination of all of the other management plans; the scope, the schedule, the cost management plans, etc.

I know we haven't talked about those yet but we will. Now is as good a time as any, the PMBOK is not a sequential process guide, it is a cyclical or evolutionally guide that progressively builds to a well defined project management discipline. So, this is only the first of many times that we will be referencing a component we haven’t addressed yet – but we will! The project management plan is the summarization of everything we do in planning and it defines the total approach of how our project will be delivered. The what’s the when’s the where’s and the how’s of our project

This topic is all about getting the work done. This is where the team does the work to complete the project and we as project managers will direct and manage the work, remove the

This topic is all about keeping the project on track. It’s us, the project managers who keep our projects on track by monitoring that our team members are doing the right things at the right time and we control the work by taking corrective actions needed to bring the project back on track.

In other words, we ensure that we always know exactly what's going on in the project and are proactively addressing any variances as early as possible while corrective actions are still possible.

The secret to understanding this topic is one word – Integrated. PMI adds INTEGRATED at the beginning of Change Control for reason, and it’s so important to them, that I expect there will be specific questions on the exam to ensure you understand what Integrated Change Control is.

So, what is integrated change control?

Every time we process a project change it has to be integrated with all the knowledge areas. So when we're doing a change, PMI ensures that we not only define the scope and the time and the cost; we also have to do the full integration against all of the knowledge areas and be concerned with what impact that has on the team, whether it changes our procurement plans and so on

That's the focus of this particular topic that all change control has to be integrated across everything we do to keep our projects alive and well and healthy.

And our last process for integration management and that's close the project, or the phase.

The key is it's not just a one time thing that we do when closing out the project. We absolutely have to ensure that were also closing each phase and that when analysis is done we do everything defined in this process to make sure that we put the analysis phase to bed before we start the design phase and so on as we complete PHASE of the project.

If you're looking for an exam tip, it's that PMI is focused on closing both the phases and the project.

Project Scope Management is the second of the 10 knowledge areas. It is focused on defining exactly what we need to do to satisfy the requirements of the project but also equally important is focused on defining what is not in the scope. It is often it's easier to clearly say this is not in the scope than it is to clearly say this is the scope. So, while we obviously need to say we are doing an end to end inventory management system it's equally important to say the inventory management system will have no consideration for replenishing the inventory or for paying for the vendors or x, y and Z. I believe this helps clarify that our inventory management system is focused exclusively on managing the inventory inside the four walls of the business.

With the scope fully defined, the remaining focus of this knowledge area is ensuring that the project delivers exactly to the scope statement and ONLY what the scope statement defines.

Our first process in scope management is to define the scope management plan itself. This is important because it documents how the project will define, validate and control the project’s scope.

This is important because the more upfront definition we can do, a term you going to hear me say it over and over and over again is in the calm and quiet of planning we can define the validation and control process for the scope so that in the heat of delivery we can simply execute against that pre defined plan.

Before we can truly define the scope we need to first understand exactly what it is the business wants. This process is focused on collecting the requirements. In this process we document and manage the stakeholders needs so that we can understand what their requirements are and use the requirements to define the scope of our project.

So, with the requirements gathered now it's time to formally define the scope - what's in and what's not in scope for the project.

Just a reminder, we're still in the planning stage and this is where we truly defined the scope of the project. This involves both defining the
scope as well as defining the acceptance criteria, now in the calm and quiet of planning, to ensure everyone agrees on the what and how of ensuring this project is a success.

This topic is focused on creating the project WBS and for those of you don't understand what the WBS stands for this is a core principle

from PMI. WBS stands for the Work Breakdown structure an acronym worth memorizing.

The WBS identifies all of the work and only the work required to satisfy the project's requirements.

I find that this is the one process inside the scope management knowledge area that causes newcomers a little confusion as they associate work breakdown structure with the schedule and think that it should exist inside the schedule management knowledge area. I am going to say it does – sort of!. Its a layered process. Here in scope management we document the high level WBS which identifies all of the work packages and then in schedule management we further decompose the work packages to a level that we can actually assign resources and schedule the work.

We've now moved into the actual execution phase of our project. We're now in the monitoring and controlling process group still within the scope management knowledge area of course and our focus in this topic is to talk about validating the scope and if there's one problematic process in the entire project management body of knowledge I would suggest it’s this one of validating the scope. A lot of folks new to the PMBOK believe this is reviewing and validating that the scope and managing change control against it. That's not what validating the scope is all about. Validating the scope is all about obtaining acceptance of the deliverables and by obtaining acceptance of the deliverables we are in fact validating that our scope matches the business expectations.

This topic is all about controlling the scope. This is where we ensure we are delivering what was defined in the Project Management Plan and we process change requests anytime there's a formal change to any of the previously approved project conditions.

We find new requirements, we modify a requirement, we modify previously accepted document, we need to control the scope and process of formal change order to change the definition of our project to reflect the new reality.

We're now into the third of the knowledge areas and this one is schedule management. I'm probably going to slip up a couple of times in this topic and call it time management because that's what this used to be called in prior editions of the PMBOK.

Schedule management is all about developing the project schedule and then ensuring that we follow the project schedule in its entirety to successful project conclusion.

Our first step in every knowledge area is to develop the appropriate plan, so here we are, and we are going to develop the schedule management plan. It is important that that we develop these proactively plans in the calm and quiet of planning. Here we define the strategy for how we are going to develop and maintain the project schedule for the life of the project: how frequently it’s updated, how project status is collected and most importantly what’s the tolerances for project schedule slippage.

Planning is the process of establishing the policies and procedures and the documentation for actually delivering the project.

Defining activities is all about taking the pre-defined work breakdown structure that we developed in the scope knowledge area and decomposing that into the schedulable activities. These activities are used to create the project schedule. SO, in essence, we are taking a high level WBS and decomposing it into a lower lever WBS that can be used to create the project schedule.

Continuing the development of the project schedule, this topic focus on developing the estimates for how long each activity will take to complete. These estimates should be a realistic estimate for each activity, based both on the skills and experience of the resources who will complete the activity as well as the complexity of the task.

While it is critical that realistic estimates are developed for each activity, as this is what determines the project schedule, it also must be recognized that these are only estimates and you should ensure that you define the level of accuracy of these estimates. For example, early estimates may be ball-park only with an accuracy of +/- 100%, while detailed estimates for the tasks in the next project phase are much more accurate with a range of only +/- 10%.

Developing the Schedule is the final step in the Planning component of Schedule Management. In essence, we take the activity list, dependencies and estimates and plug it all into a piece of project scheduling software and out pops the project schedule. And while that statement is an over simplification of this topic, as developing the schedule is often iterative and will require many reviews and adjustments of the resources, dependencies and resource commitments before the final project schedule which satisfies any business date constraints is finalized it truly described what is required to develop a realistic project schedule.

While PMI endorses using project management software to develop the project schedule, I will go one step further and suggest due to the complexities of developing a project schedule you should ALWAYS use software to complete this work. That doesn’t change the required inputs, it just simplified the mechanics of developing the schedule.

Controlling the schedule is all about ongoing, typically weekly, updating the project schedule to reflect work completed, updating the estimates for work remaining on activities and then most importantly reviewing and correcting any deviations to the planned dates to, hopefully, continue to deliver the project on schedule.

At times, these deviations may be so significant that corrective actions will not recover any schedule slippages, in which case, we need to present the deliver challenges to the project stakeholders and either adjust the scope to deliver less functionality on schedule or adjust the schedule to deliver the fill scope later than planned.

We're now into the fourth of the knowledge areas and this one is cost management, which includes both cost and budget management. To ensure clarity of terms, PMI refers to the overall project expenditure as the Project Budget and the specific expenditures on a project activity as a cost. In essence all the costs add up to the project budget (with the possible addition of a contingency fund on top of the costs to determine the approved budget).

So, Project Cost Management in a nutshell involves determining the total costs for each activity. This will include the total costs of ALL the resources required to complete the activity, human resources, materials, third party vendor costs, training, travel and living, etc. Then we simply add all the activity costs together, plus any required contingencies and determine to the overall project budget. The project budget is submitted for approval at the completion of planning and, hopefully, approved. During project delivery, we then monitor and control the project costs to hopefully deliver the project on or under budget.

Another Knowledge Area, another Management Plan – this time it’s the Cost Management Plan. And while there is a degree of repetition on each management plan there is enough uniqueness to warrant a separate topic for each. In fact, I believe the Cost Management Plan is one of the more unique in that we will define how the project integrates with the organizational finance department in this plan.

While, it may be that you aren’t responsible for managing project budgets in your organization, I can assure you that this subject will definitely be covered in your PMP exam, so don’t let your focus drop as you review the topics in this Knowledge area, there will be some questions on your exam independent of whether or how this aspect of project management is done in your organization.

I am going to go out on a limb and say that Estimating Costs can be both the simplest process in the PMBOK while simultaneously also being one of the hardest processes. At the most simplistic level, estimating costs may be automatic and occurs within your project scheduling software where the hours of work per resource are multiplied by the hour rate to determine the costs for each activity which are automatically summed to determine the project budget. BUT, this is based on all project costs being human resources, which is often not the case. So, if you also have material costs, these have to be factored into each activity based on rates for materials that need to be negotiated in procurement. The same would apply for third party products and services that may require significant procurement support through to overhead costs for travel and living, office rental etc. Therefore, depending on organizational financial policies and project specifics, you need to develop and accurate and realistic project budget.

My biggest piece of advice to you is to find a friend in finance and work with them to develop your project detailed costs and budget as required to support organizational policies.

Determine the project budget is technically as simple as adding together all the activity costs to determine the budget. However, if often a little more complex than that as a contingency or buffer is often included to deal with project risks or any other unplanned cost variances. As well, the project budget may need to be time based to support organizational cash flow planning, especially when projects have large budgets, with substantial spikes and valleys in terms of project expenses.

Controlling project costs, I like to say is simply putting the Cost Management plan into action. So, based on the processes defined in the Cost Management plan, you collect the actual costs, update the project, adjust revised estimates to complete, and take appropriate corrective actions to deal with any cost/budget variances.

We're now into the fifth of the knowledge areas and this one is quality management. Quality management is focused on ensuring that the project is delivering the quality expectations of the project. As many organizations have established quality departments, PMI recognizes that much of the work in support of Quality Management may in fact be delivered by the quality department rather than directly by the project team. This does not in any way change the focus of Quality Management, it simply changes who does the work. Therefore, in terms of the PMP exam, it is important to ensure that you understand all the processes in this area while also recognizing the work may be performed by a separate department. This does not change the responsibility for quality for the project – this is still 100% the responsibility of the Project Manager.

The Quality Management plan identifies the quality requirements and standards for the project’s deliverables as well as defining what the project will do to ensure the project delivers to the quality expected by the business. The key is the quality expected by the business, as not all projects, in fact, require the “highest” quality. Projects developing mission critical and life critical applications definitely will require the highest levels of quality, but perhaps an internal system to manage conference room booking may be acceptable even if a unexpected sequence of booking, time changes and then cancellations in rapid sequence inadvertently leaves a room reserved.

Once the quality expectations are know, the quality plan defines that actions the project will follow to ensure all deliverables will meet expectations.

While in many organizations, managing the quality happens outside the project in the quality department, it doesn’t change PMIs expectations of what is required to manage the project’s quality. And that’s basically that the Quality Management is fully executed. All the quality activities defined in the plan are managed and fully executed to deliver the expected levels of quality to the business. At the same time, it is also important we continuously validate the effectiveness of the quality processes with the focus on implementing any improvements to our organizational quality process. If you are familiar with the terms Quality Assurance and Quality Control – Manage Quality is similar to Quality Assurance or in other words ensuring you are doing all the right things.

Controlling the project’s quality is focused on ensuring that the project deliverables satisfy to business objectives for the project – ie that the Analysis document accurately reflects the business requirements for the project. In essence it is recording the results of all the quality activities defined in the quality management plan as proof that the deliverables are complete, correct and meet the business expectations. If you are familiar with the terms Quality Assurance and Quality Control – Control Quality is similar to Quality Control, or in other words doing things right.

We're now into the sixth of the knowledge areas and this one is resource management. Identifying, acquiring and then managing the effective use of the resources the project requires is the focus of Project Resource management. And the key nuance added by PMI this time is the focus on ALL resources, not just Human resources. While managing the team (the human resources) will always be a focus of this knowledge area, we must ensure we’re effectively using all resources, whether that means not wasting materials or most effectively deploying third party products and services, all project resources must be effectively managed.

Another key concept in this knowledge area is that the project resources are never static. We change team members based on the skills required at different project phases, analysis versus design versus development. Similarly, we need to purchase and use different materials and services depending on project phase.

Like just about everything else in Project Management, effective resource management does not happen by accident. The Resource Management Plan defines how, when and in what quantity the project needs to acquire the resources needed. Now, that sounds rather harsh and in-personal considering typically a significant amount of every project’s resources are human and should be treated differently than buying a box of paper for the printer. And in fact, the PMBOK does clearly define the importance of effective resource management to maximize the full potential of every team member. And that is all documented in the Resource Management plan – how we acquire new team members and the actions necessary to make (and keep them) as highly effective team members as well as the processes for acquiring commodities such as printer paper or highly

Estimating the Activity Resources is all about estimating the NUMBER of resources required to complete the project activities. Other processes estimated the amount of time each activity takes to be completed. This process is focused on estimating how many resources are required to complete the activities in an appropriate timeframe. For example, if there is 1000 hours of work for an analyst, 1 analyst could complete this work in 125 days, while 2 could do it in 62.5 and so on. The goal is to identify the optimal number of resources that allows the project to meet the business timelines while minimizing the size of the team in support of effective team dynamics and good communication.

Similarly, this process determines how many boxes of printer paper to be purchased and so on for all resources of all types.

Acquiring Resources is focused on obtaining the appropriate resources for the project. For team members, this would involve working with human resources or team leaders to assign team members to the project. For commodity purchases it is likely as simply as issuing a purchase order to a preferred vendor and for complex resources it may involve working with the procurement department to create and execute Requests for Proposals and create purchase contracts.

Unlike most of the processes in this Knowledge Area which treats all resources, human, material, equipment or vendors the same; Developing the Team is focused exclusively on the human resources who be assigned to the project. Therefore, our focus is on ensuring optimal team interaction and performance. This is especially challenging in a project environment as the team assignment is temporary and typically changes as the project moves through it’s life cycle. But in essence it involves taking a group of individuals who may never have worked together before and making them a highly performing team as quickly as possible. And then, repeating that several times as the team composition changes as skills needed changes based on project phase.

Control Resources is focused on ensuring ALL resources; team, material, equipment are available to the project as planned and then on ensuring each resource is delivering based on the approved plan. This means that team members are completing activity assignment as planned, materials are being consumed as planned, etc. In a nutshell, it’s all about measuring the work completed with team member timesheets, material acquisition forms, etc, comparing the actual usage to the plan and then taking the appropriate corrective actions to deal with all variances. As well, we will also ensure that our resources, specifically team members and equipment/facilities are returned back to the appropriate organizational pools on schedule based on the project plan.

We're now into the seventh of the knowledge areas and this one is communications management. Communicate, communicate, communicate, and if you’re not sure the message has been received, communicate one more time. Effective communications to all project stakeholders is key, because stakeholders who are up-to-date on the project are engaged and ready to help. Stakeholders who are in the dark, add no value to your project. While communications does not directly complete project deliverables, it is the single most important thing you can do to ensure overall project success. Knowledgeable stakeholders help projects deliver successfully.

And effective communications does not happen by accident. And that’s why this knowledge area has been defined by PMI.

Developing the Communications Management plan is very important as it identifies who wants what information in what format in what timeframe. Ie the project sponsor wants status of milestones on a weekly basis in a word table while senior management wants a trend diagram of budget and schedule variances on a quarterly basis.

With the communications requirements identified, the communications management plan identifies the source for all the information and the summarizations needed to allow you to ensure all the necessary data is collected and available for reporting. This way you ensure you have the information needed on a quarterly basis as opposed to having to go back and “re-write” the history books to find the data needed to satisfy senior management reporting requirements.

Good project communications is not because the project manager is a naturally gifted orator or award winning novelist. Good project communications is the result of managing that all communications takes place based on the established communications management plan.

Managing communications is ensuring the timely collection, creation, distribution and management of all the information required by the project stakeholders.

Key to managing effective communications is ensuring all the data is accurate and consistent – ie weekly reports shouldn’t report the project is in trouble while the summarized monthly or quarterly reports indicate the project is on track. Similarly, all project communications needs to be carefully produced to not contain format, grammatical and spelling errors. A project sponsor is likely to dismiss a status report that is poorly written before they even determine whether the project is on track or in trouble.

You just delivered a project status report that is BAD news. Should you hope that no one reads it, or should you proactively reach out to the key stakeholders and help them understand the status and help them work towards a solution. I hope everyone answered proactively reach out. That’s what Monitor Communications is all about. We need to ensure that the information needs of the stakeholders is being satisfied and to be available to help them understand the current status.

Monitoring communications is also about validating the communications process is in fact working and that the information flow (independent of whether it’s good or bad news) is working, and making any necessary changes to improve the communications process on a continual basis.