Many people find quality management to be one of the more difficult project management processes to implement. This is because quality is hard to define, and formal quality management requires you to collect metrics to validate the state of quality. The following process will help create a framework for the quality management process.

1. Create a Quality Management Plan

Develop a Quality Management Plan to identify the major deliverables, completeness and correctness criteria, quality control activities and quality assurance activities. The Quality Management Plan also describes how you will ensure that the client’s quality requirements are achieved. It is the place to describe the processes and activities that will be put into place to ensure that quality deliverables are produced.

2. Determine the customer requirements for quality

Work with your customer to determine their requirements for quality. The high-level characteristics of quality can be uncovered during the project definition process. The detailed quality requirements should be uncovered when you gather business requirements.

3. Define a set of metrics to validate quality requirements are met

Identify a set of metrics that will provide insight into the quality of the deliverables. The project manager should already be capturing overall financial and duration metrics. The quality-related metrics need to be more sophisticated. There are two areas where you are trying to manage quality – in your project work processes and in the actual deliverables you are building. You should try to capture metrics that will measure each.

4. Execute quality control activities

Quality control refers to activities that validate the quality of your deliverables. It is also referred to as “inspection”. Ensure that the quality control activities for every deliverable are performed while the project is underway.

5. Execute quality assurance activities

Quality assurance refers to the processes used to build deliverables. It is also referred to as “prevention”. Having good processes should results in good quality deliverables.

6. Monitor and resolve deliverable quality

You need to validate the quality of your deliverables on an ongoing basis. When quality problems are found, implement a process to determine the cause and to make improvements in the process.

Using this process will help you understand, plan for and manage the state of quality on your project.

Have you ever been asked how far along you were on a project? Of course you have. If you do not have a valid schedule, or if you are not keeping the schedule up-to-date, you know that your answer is pretty much a guess. If you have a good schedule and you are keeping it up-to-date, you should have a sense for how much work is remaining and what the projected end-date is. But are you 50% complete? Or 90% complete? It is not always easy to know.

Earned value metrics were established to remove the guess work from determining where you are at in relation to a baseline. Using it allows a project manager to know precisely how far along he is, how much work is remaining, what the expected cost will be, and all sorts of other interesting information.

Are you using earned value on your project today? Probably not. You are not using earned value because your organization has not adopted it. Implementing earned value on your project requires a tremendous level of discipline and a common set of processes. It is hard to apply earned value one project at a time, since no one else would understand what you are doing and why. It required an organization focus.

History

Earned value has not been around for hundreds of years. You can actually trace its beginning to the late 1800s and early 1900s, as managers attempted to make the factory floor and the production line as efficient as possible. The drive for efficiency requires a foundation in metrics and earned value was a way to measure things more precisely.

In the 1960s, the US Department of Defense began to mandate the use of earned value on defense related projects. As you might expect, if the government is contracting out projects worth hundreds of millions or billions of dollars, they want project progress updates to consist of more than “we seem to be on target.” Earned value calculations can provide a better sense for exactly where the project is against the baseline and provide an early warning if the trends indicate that the project would be overbudget or over its deadline.

EVM is based on just three core values.

• Actual cost (AC). The actual cost of work completed as of a point in time.
• Planned Value (PV). The budgeted cost of work you planned to complete as of the same point in time.
• Earned Value (EV). The budgeted cost of the work actually completed as of the same point in time.

Earned Value is calculated by adding up the budgeted cost of every activity that has been completed. (Remember, this is not the actual cost of the work activities. This is thebudgeted cost.) Look at the following example:

 Today’s Date is March 31

Let’s say that as of March 31 you have actually completed activity A, B, C and D. Let’s calculate AC, PV and EV.

• AC is the actual cost of the work completed. This is 55 (20 + 5 + 20 + 10).
• PV is the budgeted cost of the work planned to be completed. This is 45 (20 + 10 + 15). Note that Activity D is not counted since it was not planned to be completed as of March 31.
• EV is the budgeted cost of the work completed. This is 50 (20 + 10 + 15 + 5).

These three numbers seem to be interesting, but by themselves they do not tell you too much. So, we need to combine and compare the values to determine our status against schedule and budget. Sorry, but this next bit of information must wait until next week’s email.

Procurement refers to obtaining goods and services from outside companies. This specifically refers to vendors and suppliers. It does not refer to other internal organizations within your own company. (For the purposes of this discussion, “purchasing” and “procurement” are equivalent terms.) This is an area that project managers definitely need to understand at some level, and it is an area into which the project manager will give input. However, in many, and perhaps most companies, procurement is an area that the project manager does not own. The project manager normally does not have the authority to enter into contracts on behalf of the company, and he normally is not asked to administer the contracts once they are in place. (In some organizations the project managers have this authority, but my perception is that in most organizations they don’t.) 

If you are purchasing goods or services on your project, you should determine whether you will simply follow the procurement contracts and plans that are already established by your company or your organization.

Examples

• You may purchase hardware from companies using a pre-existing company contract.
• You may acquire contactors using a pre-selected preferred vendor list.

In some cases, the vendor identification and selection processes occur at an organization level.

For instance, your company may purchase a Customer Relationship Management (CRM) system based on high-level management requirements. This CRM system would then be used on all subsequent projects – regardless of the specific needs of each individual project.

If your project team is actually conducting the vendor identification and selection process, you have some flexibility on when it is done. Many project teams perform the vendor identification and selection processes during the project Analysis Phase. This would be the case if you need to better understand your business requirements before you determine the vendor that can best meet the requirements.

Once the vendor is chosen, there are many procurement processes that are part of project management monitoring and control. This includes monitoring the vendor progress, answering questions, validating invoices, paying invoices, managing contractual issues, etc. Ultimately the procurement process concludes when the project is completed and all project contracts are closed.

In general the processes and techniques for procurement are not so hard, but it is an area where many project managers don’t have a lot of experience. In fact, many project managers only acquire procurement knowledge as a way to pass the PMP Exam.  

Document management is a part of communication management. It is important for the project manager to recognize the stages that a document must go through from creation to completion. This knowledge allows the project manager to understand the overall status of a document at any given time and helps ensure adequate time is allocated for the completion of the document. For instance, when a team member says they can complete a document in two weeks, are they saying that the document will be ready to circulate in two weeks or that the document will be completed and totally approved in two weeks? Not all documents need to go through all the stages of document creation and approval. However, depending on the document, one or more of the steps will be required.

Plan the document

Sometimes you can sit down and immediately start writing your document. Other times you need to think, prepare and plan first. This is especially true as your document gets larger and more complex. Preparation and planning, which includes outlining the content and structuring the sections, will help you get started.

Create the initial document draft

In this step, the document draft is created. If there are no subsequent reviews and approvals, this step results in the creation of the final deliverable. Most of the effort associated with the document is used in this step. Subsequent steps may take a long duration, but they do not take nearly as much effort.

Circulate document for feedback
Modify as appropriate

These two steps involve circulating the document for initial review and feedback. The document is updated based on the review comments. Depending on the particular document, this may be an iterative step. A document may have an internal review, followed by a stakeholder review, followed by a management review. After each of these reviews, the document is subsequently modified based in the feedback and sent to the next step.

Gain document approval

When the document has been circulated for feedback and subsequently updated, it will be ready for final approval. Some documents should be formally approved in writing. Others are simply considered complete after the final round of feedback is received.

Like all completed deliverables there may be subsequent updates or enhancements that may require their own mini-document life cycle as well.

The Procurement Management Plan is a part of the overall Project Management Plan. The document describes how items will be procured during the project and the approach you will use to managing vendors on the project. Specific areas to describe include:

Procurement process. This section provides a brief overview of the process requirements necessary to manage procurement of the identified needs. This process should include:

• Initiating a request
• Development of requirements (technical, timing, quality, constraints)
• Request approval
• Purchasing authority
• Bid / proposal review
• Contract management responsibility
• Contract closure requirements
• Procurement process flowchart

Roles and responsibilities. This section describes the various roles on the project that have some connection to procurement. This section should describe who can request outside resources, who can approve the requests, any secondary approvers, etc.

Identified procurement needs. This section details the material, products or services identified for outside procurement.  Each listed item should include a justification statement explaining why this should be an outside purchase if there is the possibility of inside sourcing (make vs. buy decision).

Timing. This section will describe the timeframe that resources are needed. This will provide a better sense for when the procurement process needs to be started for each item.

Change review and approval process. Describe how changes are made to procurement documents to ensure the changes are valid, understood and approved by the appropriate people.

Vendor processes. Describe the processes that the vendors should use for timesheet approval, invoice processing, contract renegotiation, status reporting, scope change requests, etc.

There may be additional information in the plan as well to ensure the procurement process is understood and managed effectively.

Issues are more than just common problems. They are problems that meet specific criteria. An issue is a formally-defined problem that willimpede the progress of the project and cannot be totally resolved by the project manager and project team without outside help. The processes used to manage issues can be simpler or more rigorous depending on the size of the project. Use the following process to manage issues on large projects.

1. Identify the problem and document on the Issues FormSolicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
2. Determine if the problem is really an issueThe project manager determines whether the problem can be resolved or whether it should be classified as an issue.
3. Enter the issue into the Issues LogIf it is an issue, the project manager enters the issue into the Issues Log.
4. Determine who needs to be involved in resolving the issueThe project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
5. Assign to team member for analysis and alternativesThe project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
6. Gain agreement on resolutionThe various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the appropriate stakeholders (from step 6 above) for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
7. Close the Issues LogThe project manager documents the resolution or course of action on the Issues Log.
8. Close the Issues FormThe project manager documents the issue resolution on the Issues Form and then closes and files this document.
9. Add action plan to the scheduleOnce a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
10. Communicate through the Status ReportThe project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.

Smaller projects do not need all of these steps. For instance, the issue can be documented directly in the Issues Log without the need for the separate Issues Form.

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.

All projects need a schedule. If you have a small project perhaps the schedule is a simple checklist or Excel spreadsheet. As projects get larger they need more formal scheduling templates and tools.

The processes you use to manage a schedule also vary depending on the size of the project. Large projects need a lot of schedule management rigor. Small projects can use a lighter process. The following steps can be used to mage the schedule of a small project.

Review the schedule on a weekly basis.

Identify activities that have been completed during the previous week and update the schedule to show they are finished.

Determine whether there are activities that should be completed, but are not. Work with the individual that is assigned to the work see what is going on. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.

Evaluate the remaining work to see if the project will be completed within the original duration. You may find that even though some activities may be completing later than planned, other activities may be completing early and the overall schedule may still be okay.

If your project is trending behind schedule, think of schedule management techniques you can apply to get back on schedule. Raise a schedule risk in your status report if the original deadline appears to be in jeopardy.

Adjust the schedule so that it reflects the remaining work to be completed, and is as accurate as possible.

Since this is a process for a small project, it would be unusual to have major problems with the schedule. The consequences of problems on small projects are generally small as well.

Define the Objectives of Your Project

Objectives are concrete statements that describe the things the project is trying to achieve. They are included in your Project Charter. An objective should be written in a way that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to “upgrade the customer service telephone system by December 31 to achieve average client wait times of no more than two minutes“.

• Note that the objective is specific.
• The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
• You can assume that the objective is achievable and realistic.
• The objective is time-bound, and should be completed by December 31.

Objectives should infer the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements – not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. For example, the specific deliverables of an IT project may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals and strategies

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives. A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

1. Hold Everyone Accountable for Scope Management

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, your customer may try to go directly to team members for changes.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. Your customer  must also understand the process and its importance. Don’t consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

2. Use a Change Control Board for Large Projects

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

3. Make Sure the Right Person Approves Scope Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, customer and end users in the area of change management. In general, the project sponsor is the person who is funding the project. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. 

The people that the project team tends to work with most often are normal customers and end users. End users are the people that use the solution that the project is building.

It doesn’t matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. The sponsor (or designee) must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and cannot know if the project impact is acceptable.