4squareviews

This post covers the inputs of the first process in the resource management knowledge area, process 9.1 Plan Resource Management.

9.1.1 Plan Resource Management:  Inputs

9.1.1.1 Project Charter

The project charter, the output of process 4.1 Develop Project Charter, contains the high-level description of the end product or result of the project and the requirements that this will have to fulfill.   It also contains a list of key stakeholders and occasionally can be used to list any pre-approved resources for the project.   So, a project sponsor can specify, besides the project manager, specific project team members that the sponsor thinks would work well on the project.    This gives the project manager a lot of leverage in obtaining those resources in process 4.3 Acquire Resources.

9.1.1.2 Project Management Plan

The elements of the project management plan that are potential inputs to this process include the following:

• Quality management plan–helps define the level of resources that will be required to achieve and maintain the quality metrics for the project.
• Scope baseline–identifies the deliverables that will require the resources to be managed in this knowledge area

9.1.1.3 Project Documents

• Project schedule–this show the timeline on the project where resources will be needed
• Requirements documentation–the requirements will drive the need for the type and amount of resources needed for the project
• Risk register–threats and opportunities may impact resource planning
• Stakeholder register–Identifies those stakeholders with a particular interest or impact on the resources needed for the project.

9.1.1.4 Enterprise Environmental Factors

• Organizational culture and structure (functional, project-oriented, or a matrix organization somewhere in between)
• Marketplace conditions and geographical distribution of facilities and resource
• Existing resources competencies and availability

9.1.1.5 Organizational Process Assets

• Human resource policies and procedures
• Physical resource management policies, procedures, and templates
• Safety and security policies
• Historical information from previous, similar projects

The next post will cover the tools and techniques of this process.

Filed under: Uncategorized | Leave a comment »

This post is an introduction to the discussion of the project management processes in Chapter 9 which covers project resource management.   It is focuses on the changes that have occurred in the world of project management since the publication of the last edition of the PMBOK® Guide.

1. We’re all resources now–in the past, the people on the project were managed through “human resources management”.  In the 6th Edition, physical resources and human resources are dealt with in the same knowledge area.   However, the skills and competencies needed to deal with human resources are different than the ones needed to handle physical resources.   Although process 9.3 Acquire Resources deals with both types of resources, process 9.4 Develop Team and process 9.5 Manage Team focus primarily on human resources.
2. Resource management methods–because critical resources are scarce, there has been a proliferation of methods for managing them effectively such as lean management, just-in-time manufacturing (JIT), kaizen (continuous improvement), etc.   The project manager needs to learn to use those tools which are used by the organization.
3. Emotional intelligence–people have different emotional maturity levels, different needs and motivations, and different personality types.   It is important to develop the team’s emotional intelligence or sensitivity to these variations, and a project manager needs to develop skillful means in order to communicate to different team members by taking consideration of the variables mentioned above.
4. Self-organizing teams–these are teams where the project manager provides the environment and support needed for the team, but where the team organizes the work to get the project done.   This requires the development of team members who act more like generalists, rather than subject matter experts in specific fields.  These were used at first in agile approaches for the execution of IT projects, but are becoming used more in other applications as well.   It is important than the project manager learn about agile approaches as well as the traditional approaches to project management.
5. Virtual teams–with the globalization of projects, there is a need for teams to work virtually, i.e., not co-located physically at the same site.   This provides advantages of drawing on a larger geographic pool of talent, but the project manager needs to be aware of the disadvantages of virtual teams.   Communication is more complicated and requires more attention, not just in terms of logistics of tracking progress and productivity in several locations, but also in terms of awareness of cultural differences.

So there’s a lot more for a project manager to know nowadays in the domain of human resources!   As an aside for those studying for the PMP exam, there are questions on the exam that include knowledge of human resource management theory which are NOT contained in the PMBOK® Guide itself.   For a review of this material, see my post from the series of blog posts I did on the 5th Edition.

https://4squareviews.com/2013/06/29/5th-edition-pmbok-guide-chapter-9 : theories-of-motivation/

In the next post, I will go through the inputs to the first process, 9.1 Plan Resource Management.

Filed under: Uncategorized | Leave a comment »

Here are the outputs of the Control Quality process.

8.3.3 Control Quality:  Outputs

8.3.3.1 Quality Control Measurements

Quality control measurements are the documented results of the activities done in the Control Quality process (data gathering, inspection, testing/product evaluations).

8.3.3.2 Verified Deliverables

The goal of the control quality process is to determine the correctness of the deliverables, with “correctness” meaning whether they conform or not to the requirements set out at the beginning of the project.   If they are not in conformance, there must be changes made to make them so (see Change Requests paragraph 8.3.3.4 below).   If they are in conformance, this is documented, because the next step after they are verified internally is to have them validated externally by the customer in the process 5.5 Validate Scope.

8.3.3.3 Work Performance Information

The work performance data that is an input to this process is compared during this process to the quality metrics and if there is a variance, the causes of these variances, the recommendations for corrective actions, etc., are examples of work performance information that is an important output of this process.   The recommendations for corrective actions, for example, will lead to change requests (see paragraph 8.3.3.4 below).

8.3.3.4 Change Requests

If changes are recommended as a result of the Control Quality process that affect either the components of the project itself, these are made into change requests which then are inputs to the process 4.6 Perform Integrated Change Control, where they are analyzed, and either approved or rejected.   Occasionally, there may be changes recommended for components of the project management plan itself and/or the project documents, and these changes too are requested through the same process (see paragraphs 8.3.3.5 and 8.3.3.6 below)

8.3.3.5 Project Management Plan Updates

Any change to the components of the project management plan, especially to the quality management plan, cause that plan to be updated after it is approved.

8.3.3.6 Project Documents Updates

Project documents that are updated as a result of this process include the following:

• Issue log–if a deliverable does not meet the quality requirements, this is documented as an issue to be resolved in the issue log.
• Lessons learned register–the lessons learned register is updated with information on the source of quality defects (see paragraph 8.3.3.3 above on “Work Performance Information”), as well as approaches that worked well during the process.
• Risk register–if there are new risks identified during this process, especially causes of quality variance, these are recorded in the risk register and managed using the risk management process.
• Test and evaluation documents–these documents are prepared during the Plan Quality Management process.   If as a result of the Control Quality process, modifications to these documents are recommended to make future tests more effective, then these documents are updated.

This concludes chapter 8 on quality management.   The next post will cover project resource management, which starts chapter 9 in the PMBOK® Guide.

Filed under: Uncategorized | Leave a comment »

This post lists the tools and techniques that are used in this process.   It is a process in the monitoring and controlling group, and its main purpose is monitoring and controlling the quality of the results of the project, namely, the deliverables to make sure they are correct in the sense that they conform with the requirements set out with the input of the stakeholders at the beginning of the project.   That is why it is called quality control.  The review of the quality of the processes on the project is what is referred to quality assurance–it is taken care of in the previous process 8.2 Manage Quality.

Here are the tools and techniques of this process.

8.3.2.1 Data Gathering

• Checklists–these show the standard operating procedure for quality control activities to make sure they are performed in a uniform manner.   In that way, if there is a defect that shows up, it cannot be traced to a variance in the way in which the quality control activity was done, because the checklist insures that it is done the same way every time.
• Check sheets–for gathering data on attributes and any defects that are found, check sheets are invaluable.   They tell for example, the number of defects, the specific type of defects, and even the date the defects occurred.   So if a number of defects start occurring, check sheets can help pinpoint their source.
• Statistical sampling–this is where you take a part of a population of components being produced by a process.   This sample is then measured and compared to quality metrics in order to verify quality.  The frequency of such sampling and the size of the sample (is only one part taken at a time for measuring or are several taken?) are determined ahead of time in the process 8.1 Plan Quality Management.
• Questionnaires and surveys–after the product is released to the customer, questionnaires and surveys can help gather data about customer satisfaction with the deployment of the product or service.

8.3.2.2 Data Analysis

• Performance reviews–this is a measure of the performance quality on the project by measuring, comparing, and analyzing any variances seen between the actual results and the quality metrics set up during the Plan Quality Measurement process.
• Root cause analysis (RCA)–this is used to identify the source of defects.

8.3.2.3 Inspection

This is the physical examination of the work product to determine if its conforms to documented standards.   It can be the results of a single activity, or at the end of the product it can be an inspection of the final product of the project.   It is important that the quality of the final product be verified internally before it gets sent to the next process which is the process 5.5 Validate Scope where the quality and scope of the final product are validated externally by the customer.

8.3.2.4 Testing/Product Evaluations

This is an organized investigation conducted to provide objective information about the quality of the product or service.   It is tested in accordance with the project requirements.   Tests can be done throughout the project on different components of the project, and at the end of the project on the final deliverables.

8.3.2.5 Data Representation

• Cause-and-effect diagrams–Also known as Ishikawa (for the Japanese person who developed them) or fishbone diagrams, based on the shape of the diagram.  The problem (or “special variation” in quality management terms) is placed at the “head” of the fishbone and the various “bones” that come off of the “spine” of the fishbone represent some possible source of the problem.
• Control charts–these are used to see whether a process is stable, that is, has predictable performance and will always produce the same outcome.   There is a control limit that is established exists so that the process stays within the specification limit.    The analogy that comes to mind is that of the lane marker on a highway and the guard rail at the side of the road.    The guard rail is like the specification limit, in that if you go outside that limit, you are definitely “off road” and this is definitely a situation to avoid.    But in order to stay within these outer limits, the control limits in this case are like the lane markers, assuming that there is some sort of shoulder between the lane marker and the guard rail.    If you can steer your car so that you are within the lane markers (control limits), you will never have to worry about hitting the guard rails (specification limits).   For more information on control charts, see my blog post I did for the 5th Edition PMBOK Guide

https://4squareviews.com/2013/06/12/5th-edition-pmbok-guide-chapter-8-control-charts/

• Histograms–they are used to demonstrate the number of defects by source or by component, or sometimes by date or occurrence.   They are useful in figuring out the largest sources of variation, because these are usually prioritized as being the first problems that need to be solved in order to reduce the number of defects.
• Scatter diagrams–the planned performance can be plotted on one axis and the actual performance on the second axis.   Are they correlating, or is the actual performance show a variation from the planned performance?

8.3.2.6  Meetings

The various quality control processes can be done separately by team members, but certain decisions related to quality require a meeting of the project team.

• Approve change requests review–if there is a Change Request that is an output of this process, and it is approved in the process 4.6 Perform Integrated Change Control, then that approved change must be incorporated into the process and verified through testing or inspection to make sure it was implemented as approved.
• Retrospectives/lessons learned–the team should periodically hold a lessons learned meeting, sometimes called a retrospective in agile environments, in order to find out
  • what were the successful elements in the project or phase that occurred in the last reporting cycle
  • what elements could be improved in the next reporting cycle (to improve the ongoing project)
  • what to add to the organization process assets (for use on other future projects)

Now let’s turn our attention to the outputs of this process, which I will cover in the next post.

Filed under: Uncategorized | Leave a comment »

The quality management knowledge area consists of three processes, one in the planning process group (Plan Quality Management), one in the executing process group (Manage Quality), and one in the monitoring and controlling process group (Control Quality).   The difference between Manage Quality and Control Quality is that Manage Quality focuses on quality assurance, that is, making sure of the correctness of the processes done on the project, and Control Quality focuses on quality control, that is, making sure of the correctness of the results of those processes, i.e., the deliverables.    Specifically what do we mean by “correctness”?

In the language of project management, what constitutes correctness is the degree to which the project deliverables work the requirements specified by the stakeholders.

In this post, we will go over the inputs to this process.

8.3.1 Control Quality:  Inputsss

8.3.1.1 Project Management Plan

The component of the overall project management plan that is an input to this process is the quality management plan, the output of process 8.1 Plan Quality Management.   The specific elements of the quality management plan that may be used on this process include the following:

• The quality objectives of the project (these are what the deliverables will be compared to)
• The quality control management activities planned for the project (how will it be monitored, and how will it be controlled)
• The quality roles and responsibilities (who will conduct the quality control activities)
• Project deliverables subject to quality control
• Quality tools to be used on the project
• Procedures for dealing with non-conformance, such as defect repair and corrective actions.

8.3.1.2  Project Documents

• Lessons learned register–lessons learned during this quality control process early on in the project are put into the register so that they can be applied to later phases in the project to improve quality control
• Quality metrics–these are an output of process 8.1 Plan Quality Management.  This document tracks the attributes of a product and how the Control Quality process will verify compliance with those metrics.
• Test and evaluation documents–These documents that were created in the Manage Quality process will be used to evaluate achievement of the quality objectives during this process.

8.3.1.3 Approved Change Requests

Let’s say in the first round of this process, there are change requests that occur as an output of the process.   The change requests are evaluated in process 4.6 Perform Integrated Change Control (as are the change requests coming out of ALL of other knowledge areas as well).   They will be either approved or rejected.   If rejected, they are put into the change log together with the reasons why they were rejected.    However, if they are approved, they imply that modifications will be done on the project in the area of quality control (such as defect repairs).   The implementation of these approved changes needs to be verified.

8.3.1.4 Deliverables

Deliverables, which are the output of process 4.3 Direct and Manage Product Work, are inspected and compared to the acceptance criteria defined in the project scope statement and the quality management plan.    Scope deals with the completeness of the work; quality deals with the correctness of the work.

8.3.1.5 Work Performance Data

Data on the product status such as observations, quality metrics, and measurements for technical performance, are used in this process because these will be compared to the quality standards to see if the product conforms to those standards or not.

8.3.1.6 Enterprise Environmental Factors

• The Project Management Information System–the software used to manage the project, including aspects of quality management.   This is an EEF because the software is not something which is created by the organization itself, but a tool created by an external company used by the organization.   However, data regarding previous projects stored on that software would be considered  an organizational process asset (see paragraph 8.3.1.7 below)
• Rules, standards, and guidelines specific to the application area.

8.3.1.7 Organizational Process Assets

• Quality standards and policies (should be included in the Quality Management Plan)
• Quality templates, for example, check sheets, checklists, etc.
• Issue and defect reporting procedures and communication policies

The tools and techniques of this process will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »