The TenStep

Project Management MiniBook

100 Quick Tips and Techniques to make you a
Better Project Manager
The TenStep Project Management MiniBook
Copyright ©2009 by Tom Mochal
Reviewer: Ashley Mochal, Lindsay Hendrix
Library of Congress Cataloging-in-Publication Data
Mochal, Tom, 1957–
The TenStep Project Management MiniBook / Tom Mochal.
p. cm.
ISBN 1-4196-0854-1
1. Management. I. Mochal, Tom 1957 -
All rights reserved. No part of this work may be reproduced or transmitted in any
form or by any means, electronic or mechanical, including photocopying,
recording, or by any information storage or retrieval system, without the prior
written permission of the copyright owner.
1. The Value of Project Management
• Completing projects more quickly and cheaply
• Saving effort and cost with proactive scope management
• Better solution “fit” the first time through better planning
• Resolving problems more quickly
• Resolving future risk before the problems occur
• Communicating and managing expectations
• Building a higher quality product the first time
• Improved financial management
• Stopping “bad” projects more quickly
2. Not Using Project Management Effectively Results in:
• Projects completed late, over-budget or not meeting requirements
• Weak standard processes and techniques used inconsistently by project
managers
• Project management reactive and not seen as providing value
• Time to manage projects proactively not built into the schedule
• Projects may be 'successful' through heavy stress and overtime by “heroes”
3. Why Doesn’t Everyone Practice Project Management?

• It requires an upfront investment of time and effort.

• Your organization is not committed.
• You don't have the right skills.
• Senior managers think that project management is a tool.
• You may have been burned (or buried) in the past.
• There is a fear of control from team members.
• There is a fear of the loss of control from management
4. TenStep Project Management Process
There are a number of key points to the TenStep Process Model.
• Project management is defined in terms of ten essential “steps”
• The "steps" do not imply a sequential order. Steps 1-2 tend to come first,
and steps 3-10 happen continually throughout the project
• Step 3 is the key step for integrating all of the
processes
• The higher steps do imply more project
management sophistication.
• Larger projects typically need all ten steps.
Smaller projects only need the lower steps.
5. TenStep Project Management Process – Process View
The TenStep process contains all of the information necessary to manage a
project from beginning to end.
6. TenStep Project Management Guiding Principles
• Manage projects using scalable processes. Use simple processes for small
projects and more rigorous processes for large projects.
• Use project management on all projects
• Manage proactively
• Develop project team – client partnership
• Establish project management processes
up-front
• Grant sufficient authority to the project
manager
7. Size Projects into Small, Medium or Large Category
The TenStep Project Management Process is scalable based on the size of the
project. There are three basic criteria for determining overall project size.
1) The estimated effort hours of the project.

Size Effort Hours

Small 1-250 hours
Medium 250 - 2500 hours
Large over 2500 hours

2) The experience level of the project manager. If the project manager has
done this kind of project before, perhaps less structure is needed
3) The complexity and business criticality of the project. If the project is
business critical, perhaps more structure is needed.
8. What is a Project?
• Temporary endeavors with a start and end date
• Results in the creation of one or more deliverables.
• Assigned resources
• Defined scope of work
• Unique
9. Project Management and Product Management

“Projects” are the way that new work gets

delivered. “Project management” refers to the
application of knowledge, skills, tools and
techniques to project activities to meet project
i t ”

“Products” are tangible items that are produced by a project.

“Product management” is an approach for centrally coordinating
the activities surrounding the inception, business case,
development and the long-term support and enhancement of a
d t
10. Before Project Execution
Before the actual execution of the project begins, a number of items need to
be in place.
• Project is formally defined
• A Project Charter is created
• The project schedule is built
• The estimated budget is allocated
• Project management procedures are defined
• Project team resources are assigned
• The Sponsor gives approval to begin project
11. Project Kickoff
The purpose of the kickoff meeting is to formally notify all stakeholders that the
project has begun. The agenda should include the following:
• Introduce the people at the meeting
• Recap the information in the Project Charter
• Discuss the important roles and responsibilities of the project team, clients
and stakeholders
• Go over the general approach and timeline of the project
• Confirm that the project is now underway
12. Project Start Dates
One of the characteristics of a project is that there is a definite start
and end-date. Here are some of the options for identifying the
project start-date.
• The initial idea is generated (very early)
• The project budget is approved
• The project manager is assigned (the TenStep definition for the start)
• The Project Charter is approved by the sponsor
• The project kickoff meeting is held
13. Project End-dates
There are a number of events that could signify that a project has ended.
• Implementation or deployment of the solution
• Implementation plus one (or two) production cycles
• Acceptance by the sponsor
• Turnover to support
• An end-of-project meeting
• The money runs out
14. Examples of Small Projects
Much of the work in your organization is small projects. These are unique work
efforts but have short durations and low number of effort hours. For example:
• Enhancements to existing production processes and systems
• Bugs and errors in production processes that are nuisances,
but can be scheduled for resolution at a later time
• Small process improvements
• Discovery work that may or may not lead to a larger project
• Small changes to production processes that are the result of
legal, tax or auditing requirements
Small projects such as these can be documented, evaluated and prioritized
through a Service Request form and process.
15. Use the Service Request Process for Small Projects
In a small project, you can define the work using a one or two page document
called a Service Request. The following process can be used.
1 Client submits a Service Request
2 The project manager reviews the request, clarifies what is needed and
creates an estimate of effort, cost and duration.
3 The work is assigned to the Service Request backlog
4 The project manager and client management periodically
review and prioritize the backlogged work
5 When staff is available the highest priority work is assigned
6 The person that is responsible for the service request validates all the
information and the estimates. Questions and concerns are resolved.
7 The Service Request is ready to begin
16. Define the Work for Large Projects
With a large project, there is more information to define, and the length of time
required to complete the definition process is longer and more complex.
1 Determine the approval process for the Project Charter
2 Meet with the sponsor and stakeholders to define the work
3 Create and circulate your first draft of the Project Charter
4 Update the documents based on accumulated feedback
5 Get the Project Charter approved by the sponsor
6 Create project management plan (Communication Plan, Risk Management
Plan, Cost Management Plan, etc.)
7 The large-sized project is ready to begin
17. The Project Manager – Process Responsibilities
The project manager is responsible for the overall success of the project. The
project manager must first define the project and build the schedule and
budget.
Once the project starts, the project manager must successfully manage and
control the work, including:
• Managing the overall schedule
• Identifying, managing and resolving project issues
• Proactively managing scope
• Proactively disseminating project information to all
stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
18. The Project Manager – People Responsibilities
• Having the discipline and management skills to make sure that everyone
follows the standard processes and procedures
• Leading people so that they willingly follow your
direction
• Setting reasonable, challenging and clear expectations
• Holding people accountable for meeting the
expectations
• Possessing team-building skills so that the people are
motivated and work together well
• Communicating proactively
19. The Multiple Roles of a Project Manager
Depending on the size of your projects and the way your company is
organized, a project manager’s time may be allocated in a number of ways.
• A full-time role on a large project
• Project management responsibilities for multiple projects,
each of which is less than full time, but the combination of
which adds up to a full-time role
• Multiple roles on one or more projects, each of which
requires a certain level of skill and responsibility. On one
project, for instance, the project manager may be both a
project manager and an analyst.
• The project manager could be working on projects and non-project work,
such as support, management or operations
20. How Many Projects can a Project Manager Manage?
• Assume 15% of project effort hours for project management
• Spread the hours over the length of the project
• Determine mix of projects to fill the project manager schedule
Example #1. Project A is 10,000 hours and 12 months. The
project management time is 1,500 hours (15%). Over one-year,
this is a more-or-less a full-time job.
Example #2. Project B is 3,000 hours and six months. The project
management time is 450 hours (15%) – an average of 17 hours per week over
the six months. A project manager could manage two projects of this size at
one time.
Project management time does not occur in a straight average, but this model
is a starting point for how to determine project manager workload.
21. Break Large Projects into Smaller Pieces
• The days of the mega-project are over.
• Very large efforts are much too difficult and complex
to manage as a single project
• The better technique is to break the work down into
more manageable chunks, each of which is
considered its own project
• Each team will work to complete its smaller project,
but all the work would be coordinated so that the
entire effort is successful
22. Programs Coordinate a Set of Related Projects
If you break a large project into smaller pieces you need to maintain overall
coordination. This is the purpose of setting up a program.
A program is the umbrella structure established to manage a series of related
projects.
The program does not produce any project deliverables itself;
the project teams produce them all. The purpose of the program
is to:
• Provide overall direction, guidance and leadership for the
projects
• Make sure the related projects are communicating effectively
• Provide a central point of contact and focus
• Determine how individual projects should be defined to ensure all the work
gets completed
23. Portfolios - Structures to Organize and Manage Work
Portfolios are ways to organize work. They have the following features.
• Work is usually related
• Typically includes projects but can also include support, enhancements,
etc.
• Work is selected, prioritized, authorized
based on:
– Most value to the business
– Best alignment to the business
strategies
• Usually an ongoing organizational entities, like a department
24. Write the Project Charter to Define the Project
The Project Charter holds the information that you
uncovered in the project definition process. The Project
Charter is written by the project manager and approved by
the project sponsor to show that there is an agreement on
the work to be completed. The information in the Project
Charter typically includes:
• Executive summary • Dependencies
• Overview • Risks
• Scope deliverables and boundaries • Organization
• Estimated effort, cost, duration • Approach
• Constraints • Approvals
25. Establish Triple Constraint
The work to be completed (scope), the cost (time), and the duration are
combined to form the “triple constraint”. If one changes, at least one of the
others needs to change as well.

Think of the triple constraint as a triangle, with

the sides representing cost, duration and scope of
work.

For example - if the scope of work increases, the

cost and / or deadline must increase as well.
26. Business Goals
• Goals are at the organization level. Objectives are at
the project level.
• Goals are high-level statements that provide the
overall context for what the project is trying to
accomplish.
• It may take multiple projects to achieve a goal.
• The goal should reference the business benefit in terms of cost, speed and
/ or quality.
• If you can measure the achievement of your goal, it is probably written at
too low a level and is more of an objective.
• If your goal is not achievable through any combination of projects, it is
probably written at too high a level.
27. Use the SMART Technique to Write Objectives
• The objective is much more concrete and specific than the goal
statement.
• The objective is measurable.
• You can assume that the objective is achievable (or attainable)
• The objective must be realistic (or relevant).
• The objective should be is time-bound.
28. Project Scope
Scope is the term used to describe the totality of the work that is of interest to
the project teams. There are two aspects of scope
1. Deliverables. Describing the deliverables of the project goes a long way
toward defining the work of the project
2. Boundaries. Boundaries describe the totality of the work and contrast
areas that are in scope versus areas that are out of scope. Examples
include:
• The deliverables that are in and out of scope
• The types of data that are in and out of scope
• The organizations that are in and out of scope
29. Project Roles
Projects of different sizes have different ways and
requirements for how the people are organized. You
should determine the various roles needed for the
project, and identify the actual person (persons) that will
fill the role. Examples of roles include:
• Clients • Quality Manager
• Functional Manager • Sponsor
• Program Manager • Stakeholder
• Project Director • Steering Committee
• Project Manager • Suppliers / Vendors
• Project Team • Users
30. Collect Initial High-Level Requirements
The project manager needs an understanding of the high-level requirements of
the project before he can even begin to define the work.
• Project requirements include understanding deliverables, scope, costs,
deadlines, etc.

• Product requirements need to be understood at a

high-level to assist with the cost and schedule
estimates, and to understand the types of project
resources required.
At the beginning of a project, you do not have enough
time to uncover the detailed product requirements at this
time. The detailed requirements will be further defined as
once the project begins executing.
31. Requirements Gathering Techniques
Once the project starts executing you must typically gather detailed
requirements. Gathering requirements starts with elicitation. There are a
number of techniques that can help you elicit requirements.
• One-on-one interviews
• Group interviews
• Facilitated sessions
• Questionnaires
• Prototypes
• Following people around
32. Create a Project Management Plan
The Project Management Plan contains the Project Charter
and the subsidiary plans that are needed to manage the
project.
The Project Management Plan can include the following:

• Project Charter • Communications Plan

• Project Schedule • Quality Plan
• Schedule Management Plan • Scope Management Plan
• Cost Management Plan • Procurement Management Plan
• Risk Plan • Any other deliverable to plan or
manage a project
33. Project Procurement Planning
Procurement refers to the aspects of project management related to obtaining
goods and services from outside companies. The PMBOK® Guide describes
four processes within the Project Procurement Management knowledge area.
1. Plan Procurement
2. Conduct Procurement
3. Administer Procurements
4. Close Procurements
34. Vendor Selection
Plan Contracting

1 Gather and rank business needs

Request Seller Response

Send Request for Information (RFI) to vendor long list (all

2
possible vendors)
Send Request for Proposal (RFP) to vendor short list (the vendors
3
with the best chance)

Select Sellers

4 Evaluate vendors that respond to RFP

5 Make final selection and negotiate contract
35. Building a Schedule from Scratch

If you cannot find a prior schedule to reuse, you may need to build one from
scratch. The following high-level process can be used.
1. Create a Work Breakdown Structure (WBS)
2. Estimate the effort
3. Sequence the activities
4. Assign resources
5. Estimate duration
6. Estimate cost
7. Adjust schedule and add milestones
36. Create a Work Breakdown Structure (WBS)

The WBS captures all the detailed elements of work required to complete the
project. This process of breaking larger work components into smaller work
components is called “decomposition”.
1. Break the project into lower level “chunks of work”
2. Evaluate each lower element of the WBS
3. If you understand the nature of the
lower element of work and if the
estimated effort is smaller than the
estimating threshold (say 80 hours) you
do not need to break the component
down further. Otherwise continue to
break down each component as needed.
37. Estimating Effort
1 Determine how accurate your estimate needs to be
2 Break work down into smaller pieces that can be more easily estimated
3 Create the initial estimate of effort hours
4 Add specialist resource hours
5 Add project management time (15%)
6 Add contingency hours
7 Calculate the total effort
8 Review and adjust as necessary
9 Document all assumptions
38. Estimating Duration
Convert effort hours to duration activities using the following process.
1 Estimate the productive hours per day (6.5 per day for employees)
2 Determine how many resources will be applied to each activity
3 Factor in available workdays (remove vacations, holiday, etc.)
4 Take into account any resources that are not full-time
5 Factor in multi-tasking productivity loss for part-time resources (10%)
6 Calculate delays and lag-times
7 Identify resource constraints (The same person
working on parallel activities. These activities may need
to be worked on sequentially.)
8 Document all scheduling assumptions
39. Estimating Costs
You can estimate costs after you have assigned your resources.
• Estimate labor costs. You should know your resources and the costs of
those resources.
• Estimate non-labor costs. Non-labor expenses include all costs not
directly related to salary and contractor costs.
o Supplies
o Equipment
o Hardware, software
o Training, team building
• Document all assumptions
40. The Critical Path is the Longest Path
The critical path is the longest path from beginning to end in the schedule. It
represents the sequence of activities that must be completed on schedule for
the entire project to be completed on schedule.

If you are using a project management scheduling tool, the activities on the
critical path are sometimes designated with a red bar for ease of viewing.
41. The Critical Path Has no Slack (Float)
The critical path has no slack or float in the timeline. If the end-date for the
project has slipped, it is because at least one activity on the critical path did not
complete on time.
In this chart, Path B (red) is
the critical path. All of the
activities bump up against a
predecessor. If any activities
on the path are delayed, then
entire project will be delayed.
42. Estimating Techniques
These techniques can be used at the project level (macro) or activity level
(micro)
• Previous History
• Analogy
• Ratio
• Expert Opinion
• Delphi
• Work Breakdown Structure
• PERT
• Parametric Modeling
• Timeboxing
• Function Points
43. Beware These Common Estimating Errors
The estimation process is an art and a science. You can get better and better
at estimating, but by nature you can never be perfect. Here is a list of common
estimating problems that should be avoided.
• Not taking all the work into account
• Wishful thinking
• Committing to best-case scenario
• Assuming higher quality work than can deliver
• Committing based on available budget
• Not recognizing estimating biases
44. Assigning Work to Team Members
When you assign work to team members, be clear about the following:
• Activity name(s)
• An explanation
• Start-date and estimates end-date
• Estimated effort hours (optional)
• Estimated costs (optional)
• Deliverable due
• Dependencies
• Other resources needed or involved
45. Techniques to Get a Project Back on Schedule
If you discover that your project is trending over its deadline date, the first
obligation of the project manager is to try to determine the cause. The next
obligation of the project manager and team is to make corrections to get the
project back on track again.
• Work overtime
• Reallocate resources onto the critical path
• Swap resources on the critical path
• Double-check all schedule dependencies
• Check time-constrained activities
• Provide performance incentives
46. Additional Techniques to Get Project Back on Schedule
• “Crash” the schedule - adding resources to the
critical path
• Fast Tracking - performing sequential activities
partially in parallel
• Improve processes - perform project work
processes more efficiently
• Regain commitments - ask team members to recommit to
meeting their end dates
• Add resources, scope back the work or push back the deadline date - the
last choices when all else fails
47. Techniques to Get a Project Back on Budget
If you notice you are trending over your budget
• Work unpaid overtime
• Swap contractors (more expensive for less expensive)
• Eliminate or replace non-labor costs
• Use budget contingency (if you have it)
• Re-bid or renegotiate contracts
• Set up more detailed cost accounts for better cost tracking
• Add budget or scope back the work - the last choices when all else fails
48. Phase-Gate Reviews to Validate Readiness to Proceed
At the completion of a major project milestone or phase, the team should take
a short pause to look backward and forward
Backward looking
• Deliverable approvals
• Budget and schedule review
• Review project issues and risks
Forward looking
• Validate remaining schedule and budget estimates
• Validate the Business Case
• Check that resources are available
• Validate sponsorship
49. Manage Issues
An issue is a formally-defined problem that will impede the progress of the
project and cannot be totally resolved by the project manager and project team
without outside help.
• “formally-defined” – you need to be able to write the problem down. If you
cannot document the problem, you can’t solve the problem.
• “impede the progress of the project” - if the
problem does not impede your project it is not
elevated to the level of an issue.
• “cannot be totally resolved” – problems that are
within your control to resolve are not elevated to
the level of an issue. Issues require outside help.
50. Pareto Analysis
Pareto analysis can be used when you encounter multiple
problems and they are frequent enough that you can count
them. Pareto Analysis is based on the classic 80/20 rule. That is,
20% of the problems cause 80% of the occurrences.
The Pareto Diagram provides information on which problems
occur most frequently and the impact of solving each problem.

Developing a Pareto Diagram

1 Create a table listing all problems and the frequency of their occurrence
2 Order table rows from highest to lowest, based on frequency of
occurrences.
3 Create a column for the cumulative total so that you can see the impact of
each problem and the ones before it.
51. The Essence of Scope Change
Project managers don’t have to agonize on whether they should say yes or no
to scope change requests.
Managing scope on a project is all about getting the sponsor to make
the decisions that will result in changes to project scope.
52. Manage Small Change Requests
All changes to scope must be managed on the project – even small changes.
All changes to scope should be documented – even small changes.
The most common technique for managing small scope change requests is
“batching”. Batching means that you document the small changes on a log
ands take them to the sponsor for approval when they hit some threshold such
as.
• When the number of small change requests exceed some
number
• When the effort hours of the changes reaches some threshold
• When the dollar value of the changes reaches some threshold
53. Reporting Status.
Providing Status Reports are the minimum expectation for communication from
project managers.
• Report on project progress against the schedule
• Report project management status
o Schedule
o Budget
o Issues
o Scope change
o Risks
• Manage expectations
54. Communication Plans
If your project is more sophisticated or will result in culture change, Status
Reports are still required but are not nearly enough. A broader Communication
Plan is needed.
• Determine the project stakeholders and their communication needs
• For each stakeholder, brainstorm how to fulfill the communication need
• Prioritize the communication options
• Implement any communications that are
mandatory
• Implement high value communication options
• Add the resulting activities to the schedule
55. Manage Communication - Branding a Project
The purpose of branding a project is to associate a positive image and emotion
when a person hears of your project. The project will be much more successful
if people have a positive feeling of the project and the change you introduce.
There following activities can help with the branding campaign:
• Circulate positive testimonials and establish a positive image

• Establish a positive project name

• Distribute branded “trinkets”

• Communicate positive messages early and often

• Hold simple contests to build enthusiasm

• Create periodic newsletters

56. Managing Expectations
Managing expectations means keeping the sponsor and management
stakeholders informed as to how the project is progressing and the changes, if
any, that are made to previous agreements and understandings. Managing
expectations means to.
1 Establish an agreement
2 Manage change
3 Communicate proactively
4 Periodically assess performance
5 Deliver against the expectations
6 Reset expectations if necessary
7 Complete the agreement
57. Manage Documents – Basics
Document management is an approach and set of techniques for
managing documents. The larger the project, the more rigor and
structure is needed to manage documents. The following areas
should be considered part of an overall document management
plan.
• Determine where to store documents
• Define naming standards
• Determine if some documents need versioning
• Determine if (and how) you will track document approval status
• Define standard document formats
• Identify standard document tools (optional)
58. Structured and Unstructured Data
Project data can be stored in one of two states –
structured or unstructured. Structured data refers to
information that is stored in repetitive and structured
format. Unstructured data is typically easier for a human
to understand but harder to manipulate automatically.
Structured Data Unstructured Data
• Fields, records, files, tables • Documents, pictures, graphics,
text, video, chat
• Code, models, scripts
• Difficult to find tools, although
• Rely on tools, databases
more exist today
• Source code management tools
• Document management tools
• Need tools or structures
• Can organize without tools
59. Document Life Cycle
Documents have a lifecycle just as other project deliverables.
1 (analysis) Understand the purpose of the document and what you are
trying to accomplish
2 (design) Plan the format and content of the document
3 (construct) Write the initial draft of the document
4 (test) Circulate document for feedback
and modify as appropriate
5 (implement) Gain document approval
Like all completed (production) deliverables there may be subsequent updates
or enhancements that may require their own mini-document life cycle as well.
60. Document Management – Document Approval Process
The update and approval process for documents is as follows:
1 A document is created and edited in the author’s work area
2 After the initial draft is completed, the document is
moved from the work area to the project draft library
3 When the document is in the draft library, it can be
circulated for review and input
4 If the draft copy needs to be updated again, the document is copied back
to the work area for updating, leaving a copy in the draft library
5 This process is repeated until the document is totally complete. Then the
document can be moved from the draft library to its final location in the
approved document repository
61. Sample Directory Structure
At a high level, you should organize the documents on your project into three
areas - project deliverables, project management deliverables and reference. A
fourth area can also be defined for the work area. A simple way to do this is to
create a main folder for your project with four subfolders.
• Project deliverables: Directory for storing all project-related deliverables.
• Project management deliverables: Directory for storing all project
management-related deliverables.
• Reference: Directory for any documents that add
value and are used as input to the project, such as
architecture definition, client organization charts,
training material, graphics, etc.
• Work area (optional): Directory for each team
member to use to create work products
62. Effective Meetings
• All meetings need an agenda (ongoing meetings have a standing agenda)
• Assign a meeting facilitator if there is a large group of people
• Notify the participants of any advance preparation
• Only invite the people that need to be there
• Start on time, with some allowance for those
coming from another meeting
• The meeting requestor should explain the purpose and expected outcome
• The facilitator follows the agenda and make sure everything gets covered
• The scribe or facilitator should recap any decisions that were made and
document them in an email (or other project communication mode as
appropriate)
63. Risk Management Process

Risk refers to future conditions or circumstances that exist outside of the

control of the project team that will have an adverse impact on the project if
they occur. A reactive project manager tries to resolve issues when they occur.
A proactive project manager tries to resolve potential problems before they
occur. This is the art of risk management.
1. Identifying risks
2. Analyzing the risk – qualitative
3. Analyzing the risk – quantitative (optional)
4. Responding to the risk
5. Monitoring known risks and looking for new risks
64. Opportunity Risk
Risk is usually associated with potential events that have a negative impact on
the project. However, there is also a concept of opportunity risk or positive risk.
In these instances, the project manager or project team may introduce risk to
try to gain a benefit. For instance, a team
may decide to utilize a new technology on its
project because they think it will result in
dramatic effort and cost savings. Of course,
there is also a chance the new technology
will not work. However, the team introduces
the risk because the potential for gain
65. Distinguish Between Causes, Risks and Effects
There is a cause for every risk and an effect if the risk occurs.
• The cause is a situation that exists that sets up a potential risk. In general,
the cause is a fact or a certainty for the project.
• The risk is an event or condition that may have a
negative impact on the project. The risk event is not
certain. There is a probability of occurrence.
• The effect is the likely outcome if the risk occurs.
66. Risk Response
There are a number of options that the project manager should consider to
respond to a risk.
• Leave the risk
• Monitor the risk
• Avoid the risk
• Move the risk
• Mitigate the risk
67. Human Resources Processes
There are four main aspects of managing human resources
• Human Resources Planning
• Develop Project Team
• Acquire Project Team
• Manage Project Team
68. Provide Meaningful Performance Feedback
The role of the project manager normally does not include providing formal
performance reviews to team members. However, the project manager does
need to provide performance feedback to team members to let them know how
they are doing and whether they are meeting performance expectations.
• Plan the review session
• Sandwich any negative feedback between positive feedback at the
beginning and the end
• Provide examples of the behavior (good and bad)
• Allow time for feedback from the team member
• Motivate the team member to improve
• Set a timeframe for action and follow-up
69. The Nature of Technical Staff
You can make some general assumptions about technical people, but this does
not mean that the assumptions apply to everyone. Some generalizations
include:
• They tend to be introverts
• They process information internally before speaking
• They like to solve problems
• They are creative in technical solutions
• They think more logically than emotionally
• They want to understand any work processes and rules
70. Manage Technical Staff
Once you begin to understand how people work and how they are motivated,
you can start to think of the best way to manage them. Remember the
following when managing your technical staff.
• Create an environment conducive to performing well
• Allow them time to talk even if they do
not speak up right away
• Make sure people have the skills
needed to do their jobs
• Allow opportunities for the staff to
grow into new technical areas
• Technical staff may like to work alone. Make sure that the team continues
to think of itself as a cohesive group
71. Manage All Team Members
• Establish an environment where people feel they have what they need to
do their jobs.
• Give people as much information as they need to do their jobs.
• Shield the team from office politics and all of the distractions that can
abound in a large company.
• Give people continuous opportunities to learn.
• Be available when team members need you
• Respond to problems and concerns
72. Do You Need Full-Time or Contract Resources?
Organizations have many options today when determining how to staff a
project team. You can use existing employees, hire a new
employee, use contract resources, or you may just decide to
outsource all or portions of the project.
When looking to use contractors or hire employees, consider
the following criteria and general guidelines:
• Length of the need (longer needs use employees)
• Strategic (employees) vs. non-strategic (contractors)
• Skills and knowledge needed (if you need skills long-term use employees)
• Confidentiality (more confidential use employees)
• Cost (contractors will be higher cost)
73. Interview New Team Members
When hiring new employees or contractors, the interview process is important
– even more so if the person will be a full-time employee. Here are a few
simple rules to remember before your interview.
• Understand the job opening
• Understand your role on the interview team
• Be prepared
• Clear your mind
• Ask and listen
• Don’t ask inappropriate questions
• Compare candidates on consistent criteria
74. Develop Project Team
The project manager needs to make sure that the team members have the
right skills to complete their assigned tasks. In addition to formal classes, there
are many other learning events that can help employees gain skills.
• Magazines and books
• Seminars and webinars
• Mentoring
• Night classes
• Professional associations
• Self-teach classes and Computer-Based Training (CBTs)
There are other opportunities for personal development. People just need to
use their imagination.
75. Tuckman Model for Team Development
There are many aspects of building a high-performance team that require a
long period of time to bring to fruition. You will find that teams that have not
worked together before usually go through four stages of team development,
as defined in the Tuckman model. They are:
• Forming. The team is first meeting and getting to know each other.
• Storming. The team struggles through understanding roles and
responsibilities.
• Norming. The team starts getting used to each
other’s strengths and weaknesses.
• Performing. At this stage the team strives toward
common objectives – written or unwritten. Not all
teams reach this level.
76. Strive to Create High-Performance Teams
Use the following techniques to facilitate a team’s growth toward the high-
performing vision.

• Set common objectives • Maintain a high level of motivation

• Keep organized • Establish good work processes
• Instill good work ethic • Strive toward a balanced set of skills
• Foster mutual respect • Build comradery among team members
77. Be Diligent in Managing Marginal Performers
You should look at a number of possible causes of poor performance.
• Does the person have the right skills and experience?
• Do they understand your expectations?
• Are there extenuating circumstances?
Some poor performers are willing to do the work but
need coaching, training or a better understanding of
expectations. You should invest management time in
these people.
Other poor performers are not willing to do the job, or they cannot do the job
even with better training. These people should be treated fairly but ultimately
moved to jobs where they can be more successful …. or terminated.
78. Exhibit Leadership on Challenging Projects
Project managers need to be leaders. When times are tough, leadership can be
hard, but it is also more vital than ever. Keep the following things in mind to
lead your team through the difficulty.
• Keep your eyes on the big picture
• Keep positive
• Be the first to sacrifice
• Remain calm
• Motivate
• Create small wins
• Keep a sense of humor
79. Attack a Team Morale Problem on Many Fronts
Morale problems don’t happen overnight, and they cannot be resolved
overnight. Once you understand the cause, there are usually multiple ways to
help. Here are some examples:
• Be a good listener
• Say “thank you”
• Assign more challenging work
• Provide opportunities to learn new technologies
• Make sure people know what is expected of them
• Offer more flexibility
• Look for opportunities to have fun
• Solicit opinions and ideas from employees
80. Turning Around a Dysfunctional Project Team
Many teams have some personality conflicts among team members. However,
on some teams the personal animosity is so great that the team has a hard
time functioning together. There are a number of areas that require your
attention.
• Don’t be part of the problem. Model good behavior.
• Deal with troublesome personalities. They may have to be replaced.
• Try to build comradery among team members
• Get team members to set aside personal conflicts
• Praise and compliment for work well done
• Set clear expectations
• Win small battles to get people used to success
81. Openly Address Issues that You Cause
No one is perfect. There are times when issues arise because of a mistake that
you make. When you make the problem it can be difficult to address the
problem openly and in a timely manner. Remember the following.
1. Don’t wait for others to blame you - admit your mistake
2. Own the problem and the resolution
3. Communicate openly
4. Resolve the problem coolly and calmly
5. Learn from the mistake
82. Be Sensitive to Differences on a Diverse Staff
When we talk about diversity we are usually referring to having a team with
diverse cultures, ethnicity and racial backgrounds. These diverse groups of
people need to come together on some set of common objectives. Managers
should consider managing diversity from a number of angles.
• Look for the strengths of each team member
• Take advantage of the each team member’s
different perspectives
• Don’t tolerate prejudice or harassment
• Be aware of the differences in culture and be
supportive of the differences when possible
• Help everyone grow
83. Use Performance Plan for Poor Performers
A good performance plan sets clear expectations for the employee so they
know the consequences of meeting and missing performance targets. Include
the following items in your performance plan:
• Length of the performance plan
• Specific performance expectations and
milestones
• Consequences of successful and
unsuccessful completion of the plan
• Employee reporting requirements
• Manager reporting requirements
• Signature of employee and manager (for acknowledgement not approval)
84. The Definition of Quality
Quality is ultimately defined by the client and represents how close the project
and deliverables come to meeting the client’s requirements and expectations.

• It is not up to the project team to define quality – it is up to the customer

• The team should strive to understand quality expectations and meet them
85. Find Errors Early in your Project

On many projects, the burden of finding errors occurs during the later project
phases of testing and product maintenance

The better approach is to perform quality control and quality assurance

throughout the project. The earlier errors are found, the easier and less costly
they are to fix.
86. Quality Control and Quality Assurance

Quality control (QC) refers to the activities associated with the

validating the quality of deliverables. It is used to verify that
deliverables are of acceptable quality and that they meet the
completeness and correctness criteria established in the quality
planning process.

Quality assurance (QA) refers to the process used

to create the deliverables. Quality assurance
activities focus on the processes used to manage and
deliver the solution, and can be performed by a
manager, client or a third-party reviewer.
87. Use Quality Control to Validate Deliverable Quality
Quality control focuses on the quality of the deliverables. It is also referred to
as inspection. The following are examples of quality control activities.
• Deliverable reviews / peer reviews / technical reviews / code reviews.
• Checklists to ensure that deliverables are consistent and contain all
necessary information.
• Reuse of proven software
• Standards to ensure consistency
• Structured methods to ensure standard, proven processes are
used
• Thorough testing (unit, system, integration, acceptance).
88. Quality Assurance Validates the Processes Used to
Build Deliverables
Quality assurance is associated with the processes used to create the
deliverables. It is also referred to as prevention. Good processes endure that
errors are not introduced into the deliverables, or that errors are kept to a
minimum. Examples of quality assurance activities are:
• Quality assurance audits that ensure good project management processes
are defined and followed
• Checklists that validate correct processes are followed
• Standard policies
89. Conducting a Deliverable Review
Deliverable reviews (also called walkthroughs or product inspections) can be
applied to many of the deliverables produced by the project.

Deliverable Review
1 Determine the appropriate review participants
2 (Optional) Define completeness and correctness criteria for the review
3 Send out the review material prior to the meeting
4 Conduct the review. Review the deliverable (QC) and the processes used
to build the deliverable (QA)
5 Conclude the review. Determine if the deliverable “passed” or “needs
more work”
6 If more work needed, schedule another review when work is completed
90. Resolving Quality Problems
Quality problems need to be resolved before the project ends. You want to
understand the problem with enough clarity so that you can identify the root
cause and ensure that the quality problem does not occur again.

Dealing with Quality Problems

1 Describe the problem or symptom
2 Identify the root cause
3 Determine alternatives and impacts to solve the root cause if
possible
4 Select the best alternative
5 Resolve the problem
6 Validate that the solution worked
91. Building Quality in Your Project
Project quality starts with planning but the execution of quality must be carried
out throughout the project. A multifaceted approach to quality will include the
following items:
• Establishing a Quality Plan early in the project
• Building quality into the team (training,
communication …)
• Building quality into the work processes
(analysis, design, …)
• Building quality into project management
deliverables
• Building quality into project deliverables
92. Identify and Minimize Rework
Even if you have a sound quality plan in place, you may still have rework.
• Rework is not the same as gathering initial feedback on draft
deliverables
• Rework is not the same as testing and fixing errors
• Rework is not the same as a scope change
• Rework is effort associated with fixing deliverables that you
thought were already completed
• You can track rework to determine how much of your project time is spent
“thrashing” or working on the same problems twice
• The project manager and project team should strive to eliminate rework by
utilizing good and sound processes
93. The Cost of Quality
Building quality activities in the schedule adds a certain amount of effort and
cost to the project. However, these incremental costs will be rewarded with
shorter timelines and reduced costs throughout the life cycle of the solution.
Examples of the cost of quality include:
• Creation of the Quality Plan
• Deliverable reviews
• Testing
• Audits
• Checklists
• Quality Control and Quality Assurance groups
• Gathering metrics
94. The Benefits of Quality
The costs of quality must be weighed against the benefits of providing a quality
solution. Whereas many of the costs of quality show up in the project, many of
the benefits of quality show up over the entire life cycle of the solution. The
benefits of quality include:
• Increased client satisfaction
• Higher productivity
• Lower costs / shorter duration
• Higher project team morale
• Fewer errors / defects
95. The Cost of Poor Quality
It is important to recognize that there is also a cost to having poor quality.
These costs may not be apparent when the project is progressing, but should
definitely be taken into account as part of the full life cycle cost of the solution
being delivered. Examples of the cost of poor quality include:
• Warranty work
• Repairs / maintenance
• Client dissatisfaction
• Help desk
• Support staff
• Poor morale
96. Statistical Process Control
Statistical Process Control (SPC) techniques provide a data-based, objective
way to determine whether your project is producing products within acceptable
levels of quality. SPC also helps you determine if your processes are “in
control”. This approach helps project teams and companies to:
• Identify critical problem areas early in a process
• Reduce product variability
• Determine the capability of a process
• Optimize a process
• Determine the reliability of the product
97. Goldplating
Managing quality means to understand the customer expectations and deliver a
solution that meets expectations
Goldplating means that you deliver more than the customer requested
The implication is that the customer expectations could
have been met quicker and for less cost
Goldplating is considered a bad practice
98. Establishing a Project Scorecard
A Project Scorecard can be used to measure the success of the project. The
Scorecard must be established early in the project so the team knows how
success will be measured and can focus their work accordingly.
1. Identify criteria for success
2. Assign potential metrics to validate the criteria are achieved
3. Look for a balanced set of metrics
4. Prioritize the balanced list of metrics to focus on five
to eight total
5. Set targets for each metric that indicate success
6. Add activities to the schedule to ensure metrics are collected and reported
99. Make Sure Your Measures Add Value
Identifying, gathering and leveraging the right mix of metrics are ways to add
value to a project. The value can be quantified in a number of areas including:
• Declaring success
o Validation of duration, cost, effort and quality objectives for the project
o Provide objective feedback on whether the project met its objectives
• Performance improvement
o More efficient and effective project work process
o Improved estimating for future projects
o Identification and communication of best practices
o Improved client satisfaction
100. Project Closure
When the project schedule is created, think about the activities that need to be
performed to appropriately close the project. It is the responsibility of the
project manager to build project closure activities into the project schedule.
These activities include:
• Hold project conclusion meeting
• Declare success or failure
• Transition the solution to support
(if applicable)
• Turn over project files
• Conduct performance reviews
• Reassign the remaining project team