Organizational Planning

Change Control

Today’s world is dynamic. Few things stay the same for very long. There is only one thing that I know of that is a constant: change.

Change is inevitable and is very conspicuous in project management. Common examples of change for a project include a customer who asks for different (additional and/or modified) deliverables, a project team member who wants to make a change to a project policy, or a company executive who wants to accelerate a project’s schedule.

Drivers for change include shifts in technology, competitive pressures or a change in company direction because of a merger or acquisition.

When your project experiences unmanaged change, you miss schedules, overrun costs, undergo poor performance, and make customers unhappy. All project managers or team members must understand and effectively use the concept of project change control.

Change control helps you identify who wants to make changes, recognize what type of changes are desired, understand the nature of a requested change, and anticipate the impact of change (both favorable and unfavorable). Change control very efficiently prevents scope creep from taking place.

What is the best way to manage change?

Forecast changes for your project before they occur. Capitalize on beneficial aspects and defend against undesirable elements. Unless you own a very clear crystal ball that predicts the future, you need a model to help you anticipate and manage change.

Another name for change control is configuration management. You may work at an organization that has a change control board (CCB). If you are familiar with a CCB, think of a project change control process as a change control board adapted for project management.

Let’s turn to A Guide to the PMBOK to see what it says about change control. Refer to Sections 4-3, 5-5, 6-5, and 7-4 to read about change control, scope change control, schedule change control, and cost control.

Without an operational change control process, your project is likely to encounter severe difficulties. At times, there are multiple changes that are requested for the same part of a project. This is a case of a team member not knowing what another team member wants (the proverbial left hand not knowing what the right hand is doing). Additionally, desirable changes are often rejected without proper consideration. This happens when a project manager believes too many changes are requested and states, “That’s it. No more changes.”

Some changes may be requested and implemented that are not justified. A project team member may approve suboptimal materials from a supplier because the supplier performed a personal favor for this team member in the past.

Change Control System Objectives and Implementation

Change requests are a good way to improve projects. Create a change request committee (CRC) to evaluate proposals and to rule on their merits—accepted, rejected, or tabled (set aside for a future date).

Work toward these objectives:

·         Maintain project definition by ensuring integrity of project documentation and related materials.

·         Manage proposed changes using a professional approach. Do not rely on ad hoc (informal) methods to evaluate proposed changes.

·         Record and assimilate changes in project documentation on a timely basis.

·         Minimize adverse impact (to cost, schedule and performance) where possible.

Follow these implementation steps:

1.       Publish your project plan and all supporting documents.

Publish them to communicate your project’s objectives and create an initial project baseline.

2.       Develop a policy that describes how to initiate change requests.

Include this section in your policy:

Requestors who want to change a project’s scope, deliverables, or schedule must define the proposed change and describe anticipated benefits and costs.

It is interesting to note that when you use a formal system, frivolous suggestions for changes seem to disappear while legitimate ones remain.

3.       Address change requests in a timely way.

I am reminded of a colleague who requested a change to upgrade the central processing unit (CPU) for a computer project. By the time the change request was evaluated by the CRC, the requested CPU was obsolete technology. This was not timely.

While it is true that some changes to a project are unwarranted, many represent major improvements. If your process to review proposed changes is not performed on a timely basis, valid change requests wither away.

If your organization establishes a change request committee that agrees to meet regularly, publish a schedule, and follow it. If physical distance or a lack of time prevents your committee from meeting regularly, consider an virtual (electronic) version of your CRC to improve evaluation and response to change requests. Use a combination of e-mail and your company intranet to establish a virtual CRC.

When your CRC makes a decision, record the change request for future reference. If accepted, schedule the approved change into your project appropriately.

4.       Define the benefits and costs of approved change requests.

Complete this step as thoroughly as possible. Support this requirement with checklists and a quantitative cost-benefit analysis.

Cost-benefit analysis is a widely used technique to help you decide whether to make a change. Add up the value of the benefits of a course of action and subtract the costs associated with it. Benefits are most often received over time and are referred to as pay-back.

Cost-benefit analysis is typically implemented using only financial costs and benefits. For example, if you initiate a project to erect a bridge, a simple cost-benefit analysis would measure the cost to build the bridge and subtract it from the economic benefit of improving transportation across a river. Unfortunately, many cost-benefit studies do not measure indirect costs or benefits (such as cost to the environment).

Cost Control

A logical starting point for cost control is to begin with estimating. Many costs for your project are estimates and, by definition, have different accuracy levels.

If your estimates are as accurate as possible, your need to exercise cost control is minimized. Regardless of your perceived level of accuracy, be ready and able to control costs.

The concept of project costs is not too difficult to understand. When you present an initial project proposal, include a cost estimate. Many costs are defined with absolute certainty (for example, cost of a conference room for a meeting), but most are estimates (consulting costs to prepare training documentation).

For most projects, a project manager is under tremendous pressure to come in at or below the financial budget.

How can a project manager effectively manage costs?

1.       Create a project budget.

Use your organization’s formal budgeting mechanism (if one exists) to create a project budget. If your company’s budgeting process does not provide information on a timely basis or in a desirable format, develop a budget offline (collect data directly from informational sources and use a spreadsheet/personal finance software package).

I strongly recommend that you generate and use (only when needed) a contingency budget. A contingency budget provides an alternate direction when your original budget is no longer valid (when you experience cost overruns). Use a contingency budget to modify your project’s implementation schedule so you continue as close to your original objectives as possible.

Meet with your project team to define the nature of all expenditures. Create cost categories to input into your budget. When you spend money, review spending patterns to make sure you have not missed any project categories.

2.       Screen expenditures.

Another way to control cost is to screen expenditures before they are made. When you require that a project manager approve expenditures in advance, it certainly discourages nonessential spending.

3.       Use auditing.

Use auditing as another beneficial task to control costs. If you are experienced in managing a company budget, you may remember cases where costs are incorrectly applied. Auditing is concerned with conformance to preestablished and agreed-upon criteria and compares performance to an existing standard. Monitor actual spending and challenge expenditures that look unfamiliar or suspicious.

4.       Manage overhead allocations.

A trouble area for many projects is overhead allocations from other departments. Some departments are indifferent to budgeting and sometimes view projects as ways of dumping overhead costs.

Suppose I manage a test department that tests electrical conductivity for new products. I estimate that I will use 300 hours of test time for your new product during the next six months. However, since I am overstaffed, I charge 500 hours of test time to justify the existence of one of my lab technicians. Carefully review work performed by departments such as production, quality assurance, or marketing to make sure you do not receive an over-allocation.

5.       Manage purchased items.

Purchased items are also a major challenge for project cost control. Become familiar with various contractual agreements and terms and conditions so you do not pay for something you do not need.

For example, suppose you need to purchase 1,000 sensors for you new product project. You find a supplier who agrees to supply the sensors at a very reasonable price and with short lead time. You place an order and receive the sensors on time at the correct price. Ten months later, the supplier contacts you to ask when you will order the balance of 9,000 sensors. You are shocked to find that the terms and conditions for your original purchase order specified a minimum buy quantity of 10,000 sensors during a one-year period. Also, if you do not purchase the minimum buy quantity, your cost for any quantity purchased doubles. Read that fine print!

6.       Communicate anticipated cost overruns

If you anticipate a cost overrun for your project budget, make it visible to key stakeholders (including management). If additional resources are unavailable, you may need to change your project scope or reduce project performance.

7.       Use erned value.

Do not forget to use earned value to exercise cost control. Analyze CV and CPI variances to investigate cost over-run or under-run conditions.

Lesson 07

Chapter 1

Introduction

I hope you are enjoying the course. You have just passed the halfway point.

It’s time to reach for your calculators. In Lesson 7, I will share six data analysis tools to help you succeed with your projects. Hopefully you will be able to use a few of these tools in conjunction with the planning and control tools I presented in Lesson 6.

Today, I will discuss cost-volume analysis, a tool to help you optimize choices using costs, volume, and desired profits, and I will present Monte Carlo simulation, a sophisticated tool that helps you make decisions when you deal with random conditions. I will review force field analysis, a tool that helps you evaluate a decision based on pros and cons and discuss the Pareto Principle, a 200-year-old concept to help you focus on the vital few. I will review tree diagrams (tools that help you accomplish your project goals) and why-why diagrams (tools that uncover the root causes of problems).

Chapter 2

Cost-Volume Analysis

When I attended business school a few years ago (okay, maybe it was more than a few years ago), just about every class I took included a lesson on cost-volume analysis. I remember it from my marketing, finance, and operations management courses. I also studied CV analysis a few years later when I prepared for my professional certification in purchasing management.

I guess it must be an important subject.

CV analysis (also known as break-even analysis helps you evaluate different options. The name break-even analysis comes from the fact that this technique calculates the precise point where total revenues equal total costs and profits are zero.

CV analysis focuses on relationships between cost, revenue, and different volume of outputs. Its purpose is estimate profits or losses that occur under different conditions and pick the best choice.

Use CV analysis to generate both a mathematical and graphical solution. For an example of graphical CV analysis, please visit the Supplementary Material section.

In project management, CV analysis is very useful in the conceptualization through commercialization stages. Project managers make many decisions that have far-reaching implications. CV analysis is just the tool they need to make effective decisions.

A CV Analysis Project

Suppose you are a project manager for a project to design and produce a device to automatically clean floors at large auditoriums (movie theatres and concert halls in particular). Your research indicates that this device is more productive than human labor. It even cleans up sticky candy that you take home with you on the bottom of your shoes.

Although this cleaning device is a potential success, you have two questions regarding its sales potential. You want to know how much sales volume is needed to break even in the first year and how much sales volume is needed to make a profit of $30,000 in the second year?

First, break down costs into fixed and variable cost categories. Fixed costs do not change with output while variable costs do.

Fixed costs, as the name implies, do not change over a defined range of output. Suppose you spend $50,000 for land and a building for a new facility to build your new cleaning device. You cannot avoid this cost, regardless if you make one unit or 10,000.

Variable costs change with rates of output. If you produce one unit, you incur variable costs (usually in the form of direct labor and materials).

As a project manager, consider various options regarding the manufacture of your product. You have two different options to spend money for land and erect a building (site 1 and site 2), or you can sign a contract with a third party to manufacture your product (outsource).

You identify and quantify your choices as follows:

Fig. 7.1. Cleaning device options

In addition to this cost and revenue information, you determine that your expected annual sales volume is: 2,200 units.

To solve this problem, answer these three questions:

·         Question 1: What is the break-even volume for the two manufacturing choices?

·         Question 2: Which is the most profitable option (based on the forecast)?

·         Question 3: How many units do you need to sell (for each option) to produce a profit of $30,000?

Let’s walk through your solution together.

Note: An assumption for CV analysis is that everything that is made is sold.

Let’s develop the equations.

Total cost equals fixed cost plus the units multiplied by the variable cost, so:

TC = FC + (U × VC)

Total revenue equals the selling price multiplied by the number of units, so:

TR = SP × U

Earlier in the lesson, I stated that the break-even point occurs where total revenue equals total cost, therefore, for the break-even point TR = TC.

Substituting equations one and two into equation three gives us a break-even point of:

FC + (U × VC) = SP × U

Subtract (U × VC) from both sides of the equation:

FC = (SP × U) – (U × VC)

Simplify by factoring out U from the right side of the equation:

FC = U (SP − VC)

Divide both sides of the equation by SP − VC:

FC ÷ (SP − VC) = U

Reverse the equation:

U = FC ÷ (SP − VC)

You now have the basic equation to answer question 1.

To answer question 2, use a basic income statement formula:

(SP × U) − FC − (VC × U) = profit

To answer question 3, add the profit requirement to the fixed cost in the numerator of your CV analysis formula. View profit as a type of cost, one that ends up in management’s bank account. Let’s review the calculations for each question:

Fig. 7.2. CV analysis solution

Summary of Answers

·         Question 1: If you decide to manufacture your own devices, Site 1 is preferred over Site 2 because 1,111 units need to be produced and sold instead of 1273.

·         Question 2: If customers demand 2,200 units, outsourcing provides the highest profit ($55,000 versus $49,000 and $51,000 for Sites 1 and 2, respectively).

·         Question 3: If you expand the basic CV equation to return $30,000 profit to management, 1200 units need to be produced by the contract manufacturer. In contrast, 1,778 units need to be produced at Site 1 and 1,818 units need to be produced at Site 2.

Based on this information, outsourcing provides the optimal solution.

Chapter 3

Monte Carlo Simulation

Monte Carlo simulation is used to model uncertainty, manage business risk and simulate complex systems. Its use is not that widespread in project management, however, since A Guide to the PMBOK discusses it, I need to provide an overview.

To read PMI’s definition, refer to the glossary in A Guide to the PMBOK.

As you may guess, Monte Carlo simulation is named for the Mediterranean resort that is famous for games of chance. It is a probabilistic technique, which means that it is only used when for random processes.

As a simulation technique, Monte Carlo produces likely outcomes. Some project problems or issues are too complex to solve with pure mathematics. Their randomness cannot be quantified. These problems are well-suited for simulation.

While you can perform a simulation manually, use a computer program to increase your efficiency.

Simulations offer these advantages:

·         They do not disrupt an actual process.

·         They accelerate results.

·         They are less costly than real-time experimentation.

The disadvantage of simulations is:

·         They require expertise to develop and use models.

To use Monte Carlo simulation, follow these steps:

1.       Collect data regarding the process or problem under evaluation.

2.       Establish a probability distribution for the collected data.

3.       Assign random numbers (either from a table of random numbers or random numbers generated from a computer program).

4.       Perform the simulation.

5.       Analyze and draw conclusions from the results.

Let’s look at a simple Monte Carlo example.

Since you were so successful in earlier developing and commercializing a device to clean auditorium floors, you want to create a project to improve the reliability of your device.

When it works, your device does a fantastic job of cleaning floors. The only problem is; it is not that reliable. Your device stalls too often.

You want to determine how many product failures are expected during a 12-day period. You determine that failures are completely random and decide to use Monte Carlo simulation.

1.       Collect data.

You collect historical data from the past 180 days regarding incidences of failure.

During the past 180 days, there were only 15 days in which no failures occurred. Twenty-two of the 180 days experienced one failure. And so on.

2.       Use random numbers.

Since you are dealing with randomness, you use a table of random numbers to help you determine device failures. Review the following for an excerpt of a table of random numbers:

3.       Create a table.

From this data, you establish a discrete and a cumulative probability distribution and establish corresponding ranges for your random numbers.

You determine probabilities by dividing each failure day category by total number of days. The probability of having no device failures during the 180 is 8 percent (15 divided by 180). The probability of having one device failure during 190 days is 12 percent (22 divided by 180). And so on.

Next, you assign corresponding random numbers to your cumulative probability distribution. This statement may be a bit confusing, but I believe the example helps illustrate.

You use your table of random numbers, work your way down the first column (starting with cell B3), and load random numbers into the appropriate range of cumulative probability distribution.

For example, the first random number is 25. It belongs to the row that has two failures since 25 falls between 21 and 39. The second random number is 82. It belongs to the sixth row that has five failures since 82 falls between 74 and 89.

If you have any questions, please ask.

4.       Complete your table and interpret the data.

After you assign random numbers for 12 days, you produce a completed Monte Carlo table:

Over the next 13 days, you expect 37 device failures or an average of about three per day (37 divided by 12 for a total of 3.1).

In an actual Monte Carlo simulation, you would need a much larger sample of historical data. Remember, I wanted to keep things simple.

Force Field Analysis

Force field analysis is a technique that defines opposing forces to a particular change. It identifies variables that support and argue against a change.

Force field analysis portrays the pros and cons pertaining to a decision or planned action. If negative forces (called restrictive forces) are too strong, you tend to make one type of decision. If positive forces are overwhelming (called moving forces), you make another type of decision.

Suppose that my daughter has a decision to make regarding going away to college. As you may imagine, there are a number of forces at work.

On the positive side, moving forces include are such things as being able to claim new found independence, meeting new friends, having the experience of being in a new environment, and getting a fresh start.

Restrictive forces are costs to her parents, the fact that she will miss her old friends (and her dog), fear of a new environment, and the inability to move back home easily in the case of problems.

To construct a force field analysis, take a sheet of paper, identify the planned decision in the center, list moving forces on the left side and the restrictive forces on the right side. Take action to minimize the influence of restrictive (negative) elements.

An important aspect of force field analysis is the relationship between the forces. For example, should some of my daughter’s friends decide to go to the same out-of-area college, this factor reduces the force of missing friends.

Chapter 4

Pareto Charts

Many of you have may use or know about the Pareto Principle (perhaps without even realizing it). It is known by a number of different names, including the 80/20 rule or the ABC classification.

The term Pareto Principle was officially created in the 1950s, but the principle has existed since the early 1800s. During that time, Vilfredo Pareto, an Italian economist, observed that 20 percent of the residents in Milan possessed about 80 percent of the wealth.

Since then, the 80/20 rule has been used successfully to describe many phenomena. For example, 20 percent of processes generate 80 percent of production problems; 20 percent of customers produce 80 percent of complaints and so on. Please note that the 80/20 rule is a guideline, not a rigid rule.

Another way to look at the Pareto Principle is by understanding the phrase, “vital few and trivial many.”

In project management, spend your time managing items that are important. Time is a valuable resource, so use it wisely. You may ask, “How do I know what is important and what is not important?”

Answer this question by using the Pareto Principle and more specifically, Pareto charts.

Pareto charts are a graphical representation of what is vital and what is trivial. Recognize that vital does not always mean expensive.

For example, if you manage a segment of a space shuttle project, you might use a very inexpensive part that is difficult to make to desired specifications. Because of its low cost, this part may originally be considered trivial. However, you assign it to vital because of it significance to your project.

Let’s return to your auditorium cleaning device project. I hope that you are not getting tired of discussing this project. And by the way, are you ever going to give the device a name?

Your Monte Carlo simulation helped you improve. However, there are still problems.

When your device arrives at a customer site, there are often problems such as missing documents, inferior packaging, and delivery to the wrong location. You spring into action to address these delivery problems:

Delivered to wrong location	10
Missing owners manual	3
Damaged packaging	43
Late deliveries	55
Incorrect outer labeling	6
Incorrect item shipped	2
Incorrect quantity shipped	5
Overcharge	2

You review the information and decide to develop a Pareto chart to present to your project team.

Develop your Pareto chart by following these steps:

1.       Sort the data in descending order of incidence.

2.       Construct a chart using the incidence of the problem as the left y-axis, the cumulative probability as the right y-axis, and the label of the problem as the x-axis.

3.       Create a vertical bar for the largest incidence problem category that corresponds to the left y-axis and a point that corresponds to the right y-axis. Do the same for the second largest incidence problem. Connect the two points to form the beginning of a line.

4.       Proceed until all variables are plotted in the chart.

5.       Interpret the data.

You then create this Pareto chart:

Late Deliveries and Damaged Packaging make up the two largest categories. These two problems represent 25 percent of total line items (two out of eight) and comprise about 78 percent of total problem occurrences. You decide to place the largest amount of corrective action on these two areas.

Review the following data:

Pareto charts are easy to use and actually kind of fun. Do not forget to make it a member of your project management tool kit.

To learn more about Pareto charts, refer to Section 8.3.2 and Figure 8.5 in A Guide to the PMBOK.

Tree Diagrams

Many tools are similar to one another. Also, a tool can have different names (such as a cause and effect diagram being called a Ishikawa or fishbone diagram).

A tree diagram is very similar in appearance to a storyboard. It starts out like storyboarding (from the top) and continues through various levels.

There is an important distinction between a storyboard and a tree diagram. A tree diagram is more action-oriented. A storyboard defines what is desired while a tree diagram determines what it takes to accomplish your objective.

Tree diagrams explode through many levels. If you are familiar with a manufacturing bill of materials, you have experience with a tree diagram under a different name.

Suppose you want to assemble a lawnmower. I bet you are glad that I am not going to discuss the auditorium cleaning device project again.

Review the following:

The highest level in a tree diagram is level zero (the finished lawnmower level).

To make a lawnmower, you need one each of the level one items, which include the engine, the body and the handle final assembly. When you determine the amount of level one items needed, determine the quantity per assembly (QPA). After you identify the number of level one items needed, ask this question, “What do I need to make one engine, one body, and one handle final assembly?”

Proceed to the next level (level two) to find the answers to this question. When you look at the figure above, you see that you need one control, six screws, and one handle subassembly to make one handle final assembly. Continue for each item until you reach the lowest level of your tree diagram.

When you first begin, create a graphical version of your tree diagram:

Tree diagrams resemble a Work Breakdown Structure because they use both a graphical and indented format.

Why-Why Diagrams

A tree diagram helps you ask questions such as, “What is needed now?” until the answer is, “Nothing else.” A why-why diagram asks questions so that everyone knows why something takes place. It helps you find the root cause of a problem.

Review the following:

I constructed this why-why diagram because my favorite soccer team is losing all their games. At the first why level, I determine they are losing because the coach does not make good choices, fans do not come out to support the team, and players become overly tired at the end of the game. I decide to use a why-why diagram to probe the overly tired issue.

I ask the question, “Why are they tired?”

I find that there are eight players on the roster that over the age of 38, practically dinosaurs for playing competitive soccer. I also find that the players are out of shape.

I also learn that the players do not have a good trainer, they follow a poor diet (a great deal of fast food), and players do not get enough sleep.

I could continue to ask why again for all these reasons, but I will stop. I think you have the hang of the why-why process and how it works.

Lesson 08

Chapter 1

Introduction

Welcome to Lesson 8.

Before I go too far into this lesson, I need to share my heartfelt opinion about project management software. I believe that too many people in the project management field place too high of an emphasis on the role of project management software. While it has an important role to play as a tool, software is not a substitute for sound planning, effective implementation and control, and positive leadership.

Software is a two-edged sword. If you understand what is currently taking place and what you desire, the probability is high that you will use software effectively. Conversely, if you use a cookbook approach in applying software and do not understand what software can do and what you truly need, you will have problems.

In Lesson 8, some of you may expect an in-depth discussion of currently available project management software packages. I am sorry to disappoint you. I cannot discuss nor recommend specific project management software. However, I will discuss the nature of project management software and help you identify winning techniques and processes.

Today, I will share two case studies pertaining to software implementation and will provide an historical overview of project management software. I will identify the reasons for resistance to project management software and help you learn how to justify project management software. I will identify 19 criteria to consider when you evaluate software and discuss how to select a project management software supplier.

Chapter 2

Application of Project Management Software

Application 1: Enterprise Resource Planning (ERP) and Two Health Care Companies

In Lesson 6, I briefly discussed Enterprise Resource Planning (ERP). ERP, introduced during the mid 1990s, is considered (and advertised as) a dream come true for many organizations. It is highly integrated and has the capability to support all global company functions, including finance, human resources, engineering, customer service, and operations. Some ERP software translates languages, currencies, and converts time zones.

ERP is used by the greatest cross section of firms and is the most expensive and most popular mainstream software package. Although it is not project management software, a project management methodology is necessary to successfully implement ERP.

A benefit of ERP is its powerful functionality and user-friendly graphical user interface (GUI). To capitalize on ERP’s benefits, you must first understand your organization’s business practices thoroughly and then, model, modify, and even customize the software.

Two companies that I know of recently implemented ERP for their global sites. Both companies manufacture and distribute health care products and had many standalone (nonintegrated) systems prior to ERP implementation.

During its phase one implementation process, Company A used ERP to emulate their existing business practices for their finance and customer service functions. The old order entry processes and monthly financial closing processes for domestic and international operations were implemented, without changes, using ERP software.

The organization now used one system (ERP) instead of many different systems for finance and customer service activities. This allowed finance and customer service personnel to sing from the same song sheet. However, there were a few problems.

At Company A, employees found that they spent a huge amount of time operating the transaction-intensive, ERP software. To receive and process a customer order, 18 transactions were needed for the new ERP system instead of the five transactions that were needed on the previous system. Employees using ERP began to discover that it diverted them from an important objective: developing, delivering, and supporting high value products and services in order to satisfy customers.

When it came time to begin phase two (operations) of the ERP implementation, Company A, to comply with its standardization requirement, required nine global sites to abandon their highly-engineered production systems and adopt ERP. A few sites used legacy (mainframe) software that contained greater functionality and greater ease of use than ERP.

Company B, in contrast, used business reengineering before they implemented ERP. They used a process that identified As Is (current) and To Be (desired) information and work flows. Before they moved forward with ERP, Company B was able to truly comprehend where they were and where they wanted to go.

Company B streamlined many business practices. Also, they reviewed and updated organizational structures. Company B’s primary production operation, embarking on a lean manufacturing strategy, decided that ERP was not for them. They continued with their lean manufacturing strategy and greatly reduced cost, increased customer satisfaction, and improved profits.

Application 2: The Case of the Overly Complicated Project Management Software

A few years ago, I was involved with a sad tale of customized super-duper project management software. When it was first purchased, the software was viewed as a universal remedy to my former company’s new product introduction process. But then things changed.

When I first joined my former company, EZ Products, my boss asked for my help:

Tony, we spent about $10,000 for project management software about 18 months ago. No one can make it work. The engineer who purchased the software is no longer with the company and the documentation is either misplaced or lost. Also, the software manufacturer does not return our telephone calls. Can you please help us?

After I examined the software and finally received a call back from the software manufacturer, I realized the software was much too sophisticated and complex for EZ Products’ new products introduction process. We did not need what the software offered.

Lessons Learned from These Applications

So, what do these scenarios have to do with project management? They have everything to do with it.

Computer software is not a cure-all for an organization’s problems. You must prepare adequately by thoroughly understanding your project needs and knowing how software functionality will solve these needs. If you purchase and attempt to implement project management software without this knowledge, you run the risk of suffering the fate of Company A or EZ Products.

Before beginning the planning phase for project management software, perform a needs assessment.

If you want to buy and use project management software, create a project to determine how it may benefit your organization. When you use a project management approach to evaluate project management software, you cannot go wrong.

Chapter 3

An Overview of Project Management Software

To a large extent (aside from some internally-developed project management software solutions at governmental agencies and defense contractors), project management software follows the evolution of the personal computer, computer networks, and related software.

During the 1960s and 1970s, commercial project management software ran on mainframe computers and was only used by large companies managing large projects. Efforts to use project management software (run programs and interpret results) were extensive.

Distributed data processing, where end users enjoyed the benefits of desktop computing and networks, started to appear in the 1980s. This revolutionized the industry. Information was now available at speeds previously unimaginable.

The phrase, integrated data management, was heard in many project management circles. It was now possible to use a common database to give those with varied interests their own view of a project.

Given the globalization of business and the commensurate information technology that goes with it, project team members can now work effectively together, despite the fact that they are thousands of miles away.

This is the history so far. Where it is headed is anybody’s guess.

Project Management Software Basics

Project management software is a tool. It is not an instant cure to eliminate your project’s problems. Since project management software use is optional in many cases, it is interesting that some project managers resist using it.

The first question you need to ask is, “Do I really need project management software?” I remember a project where a project manager placed a huge computer-generated Gantt chart on a wall adjacent to the project team office. The chart had been generated earlier in the year (at the inception of the project). Six months later, the project Gantt chart was unchanged. No one ever updated it.

Some project managers do not believe in the benefits that software provides for the following reasons:

·         My project is too fast-paced to keep updated. By the time I generate a new schedule, it is already out of date.

·         I do not need computer software to identify what everyone already knows.

·         I have other documents that I generate during my team meetings that are good enough.

·         Project management software is not a good use of company money.

·         I used project management software a few years ago and it did not do what I needed it to do.

And so on.

Comments like these reflect attitudes of individuals who may not appreciate the power of software or who do not use planning and control appropriately. Use of project management software may increase the level of planning and control. Alternatively, these comments may reflect projects that succeed without software or benefit from economical, basic software (without undesired features).

Give project management software considerable thought during your conceptualization and planning phases. As you identify deliverables, develop a Work Breakdown Structure (WBS), establish schedules, and assess risks, discuss the costs and benefits of using project management software with your project team.

Follow these suggestions regarding purchase of project management software:

1.       Create a team and review characteristics.

Create a team to evaluate availability of project management software and review basic characteristics.

There are numerous project management software choices. When you apply the Pareto Principle to project management software choices, you find that there are a handful of companies who dominate the market.

During your evaluation, list the particular function that you want the software to perform and rate each supplier according to their capability to meet each function.

2.       Start small. Use the learn-by-doing approach.

You may discover that your organization maintains project management software on their local area network (LAN). Investigate this software. Use it for a small project. After you finish your investigation, you will have additional knowledge of what you like and what you do not. This knowledge helps you make future decisions regarding project management software purchases.

If you do not have project management software at your organization, download trial versions. Also, consider buying a no-frills version for a few hundred dollars to increase your familiarity of project management software functionality.

3.       Justify project management software based on current and future needs.

If your organization plans on working on a large number of projects in the future, justify the purchase of software today using today’s and tomorrow’s needs. Select software that accomplishes your purposes in the present and also in the future. If you wait until a big project is assigned before you locate, purchase, and learn project management software, you add an unnecessary difficulty factor to your project.

Chapter 4

Project Management Software Functionality

Evaluate potential project management software functionality using these criteria:

1.       Ease of installation and operation.

In today’s environment, this is less of a problem than it used to be. Installation relates to intended use of the software (does it run on a standalone PC, on a LAN, or on a wide area network [WAN] ). I identified this criterion as number one to make sure that you clearly identify and address the technical aspects of software installation. Involve your information technology department in your decision.

2.       Different users, different views.

It is probable, especially for a large project, that many employees in your organization look at a project in different ways.

Your CEO may want to review progress once a month while your project manager wants to evaluate progress, make changes, and analyze all reports daily.

Make sure your project management software has the right degrees of user-friendliness and online views for different levels of interest and sophistication.

3.       Data security foolproofing capabilities.

There are two aspects to foolproofing data security. The first restricts access to enter data or make changes. The second is software functionality that provides prompts (feedback) when employees (or hackers) try to enter information that is not desired.

4.       Work Breakdown Structure (WBS).

Make sure your project management software is capable of developing and storing a WBS and carrying it forward into other project applications.

5.       Resource requirements spreadsheet

Determine if your project management software identifies all resources needed for your project, along with affiliated activity, cost, time duration, and scheduled start and finish dates.

6.       Task breakout by department.

For capacity planning purposes, make sure your software can forecast project requirements (what, when, and how much) to align staff and make other resources available.

7.       Capacity s.

This characteristic is quite important, especially if you plan to use software for future projects. Make sure your software accommodates multiple projects, stores an extensive number of tasks per activity or deliverable, and performs automatic replanning.

8.       Initial project schedule development.

Determine if your software has the capability to produce several different versions of your schedule (Gantt chart, Activity-on-Node, Activity-on-Arrow).

9.       Different calendar and time frame options.

Determine if your project management software is able to express your schedule in years, months, weeks, days, hours, or even minutes. Also, verify that it is able to utilize and convert different time scales.

10.   Critical path identification.

This functionality is not up for negotiation. Make sure your project management software defines and redefines (based on changes) the critical path.

11.   Project schedule updating.

A requirement to update your project schedule occurs over and over again. In addition to setting an original project schedule baseline, you will want to set additional baselines. Review the software’s capability to delete, resequence, or transfer information to another part of the project.

12.   Track actual progress versus plan.

This functionality is another critical aspect of project management software. Your software should be able to indicate percentage complete (task and project) and perform various earned value calculations.

13.   Ability to reflect different dependencies.

Determine if your project management software identifies and manages key task dependencies, including finish to start and start to start.

14.   Reporting.

Inquiring minds need to know. Make sure your software creates basic reports (for instance, money spent and resources available). Explore your software’s ability to report estimation to finish and estimate at completion status and supports ad hoc queries and report writer functionality.

15.   Integration with other systems.

The requirement for software to talk with each other has increased significantly since the 1990s. Investigate if your software imports and exports data files, minimizes manual data entry, and cuts and pastes from one application to another.

16.   Charting capabilities.

I remember an old saying that indicates that management wants to see everything on one piece of paper. Project management’s software power to produce graphs (or export data to other software for that purpose) is important. Review this carefully.

17.   Toggle between views.

Determine if your software switches back and forth between applications (for instance, a Gantt chart and an Activity-on-Node schedule).

18.   Data management

Make sure your project management software handles large quantities of data for reporting, creating charts, and tracking progress to plan.

19.   Ease of use.

Look carefully at the degree that the software is intuitive. Ideally, you should be able to use the software in the same way your project manager and your project team perform actual work.

Now that you know what to examine when you evaluate project management software, what should you expect from suppliers?

Explore these major areas (in this order):

1.       Study the history and demographics of the company.

Get a feel for the length of time the company has been in business. Consider the markets served. If you work in the construction business, determine if the software is prevalently used in that industry. Also, identify the size of the company and their level of profitability.

Make sure the company is stable so that you receive the desired level of support.

2.       Get references.

After you perform initial screening regarding history and demographics of the company, ask the company for references and visit sites that use the project management software you are interested in. Ask questions such as: “What were your objectives and has the software met them?” “Does the software crash?” “What are the system requirements for optimal use?”

Before you make a site visit, prepare and review your list of questions with project team members and with your information technology support personnel. If all of your questions are answered satisfactorily, remember that what works at one company may not work at yours.

3.       Obtain demonstration software.

If you are interested in low cost project management software, request a demonstration disk or ask the supplier if their Web site includes a demonstration version. Keep in mind that demonstration software may not be reflective of software you purchase.

4.       Check the documentation and user support capabillities.

Inadequate documentation is one of my major sore points. Make sure that documentation is well written, accurate, and complete. Additionally, determine if the company has a tutorial, online help, assistance from their company Web page and a toll-free help desk.

5.       Obtain training.

Training is an area that is often overlooked. Secure training directly from the project management software supplier or from a third party. This helps generate a good start and also helps you extract the largest benefit from the software.

6.       Join a user group.

Many large companies maintain user groups. Join one of these groups to leverage the software functionality. User groups are helpful but not essential.

7.       Investigate future plans.

Determine what is coming around the bend for future releases.

In the final analysis, to effectively select, implement, and use project management software, follow these three recommendations:

1.       Perform a needs assessment.

Make sure you base your decision on the needs of all users, but most certainly on the needs of core project team members, your project manager, and management.

2.       Evaluate available project management software.

Make a list and objectively review each item.

3.       Select software and implement it.

Purchase and implement software that meets your selection criteria and accomplishes your overall purpose.

Lesson 09

Chapter 1

Introduction

Welcome to Lesson 9. I am excited to share some important concepts with you today.

Many project managers and team members struggle to improve their projects’ output. Despite their best efforts to improve customer satisfaction, project personnel are often unable to make much progress.

When you use statistics to characterize and improve your projects, you cannot go wrong.

Today I will discuss the measures of location (median, mode, and mean), the normal curve and measures of dispersion (range, mean absolute deviation, variance, and standard deviation). I will discuss the Taguchi loss function as an alternative to traditional go/no-go inspection. I will also discuss how to measure variation and how to use prevention and statistical process control (SPC) to help you produce predictable and acceptable results.

Chapter 2

Measures of Location

It is very difficult to comprehend much when you examine unordered or unclassified data. For example, if I have 500 students in my class and I arrange test scores according to student identification numbers, it is difficult for me to determine how this class compares with similar classes.

In an earlier lesson, you learned that when you use a histogram to organize data into a frequency distribution, it increases your understanding. When you use statistics, you improve upon a histogram because you can better organize your data. Statistics describe physical conditions and situations by using two indicators: measures of location and measures of dispersion.

Many populations are too large to list all elements. For example, assume you are interested in the weights of all Siberian huskies in Alaska. How can you characterize these dogs so you can discuss them as a group?

Measures of location, also known as measures of central tendency provide the answer to this question.

The measures of location are the three M’s: median, mode, and mean. Let’s review each of the three M’s. This information may be review for many of you, but it is important that I discuss the three M’s before I move on to more sophisticated statistics.

Median

The median is represented by values positioned in the middle of a data group.

Real estate sales are often stated in terms of the median. Let’s review sales of homes yesterday in Springfield and Pittsville, two neighboring cities:

Springfield: $175,000, $225,000, $275,000

Pittsville: $100,000, $215,000, $235,000, $800,000

When you have an odd number of data points, find the median value at the middle position. For home sales in Springfield, the median is $225,000. For an even number of data points, find the median value by adding the two data points in the middle positions and dividing by two. For home sales in Pittsville, the median value is also $225,000.

Becky, a potential homeowner, is interested in purchasing a home in the Springfield/Pittsville area. When Becky reviews the median price of $225,000, she believes housing prices in both cities are equivalent and she can buy an average home for $225,000. However, upon closer scrutiny, Becky sees that Pittsville has a greater range of prices than Springfield. She is not sure what she can buy. Medians are therefore limited in what they convey.

Note: I realize that a prudent potential homeowner would look at home sale prices for more than just one day.

Mode

The mode is defined as observations that occur most frequently. Some populations do not have modes as there is no value that occurs more than once. A multimodal population exists when there are two values that occur equivalently.

If there are 100 homes sold in Fountain Gardens during a month and the most common sales price is $200,000 (for five homes), $200,000 is the mode.

Mean

Many people refer to means as averages, however, in statistics, the word average is not recognized. In my earlier example, the mean for housing prices for one day in Springfield is $225,000 and in Pittsville is $337,500. The average price in the Springfield/Pittsville area is certainly not $225,000.

In statistics, the mean is represented by the symbol xBar. When you understand the concept of the mean, it helps you understand the normal curve.

A few hundred years ago, scientists discovered that many measurements (temperature or weights, for example) had data that was distributed with the same shape. This data distribution became known as a normal distribution, the normal curve, or the bell-shaped curve. In our class, I will call this distribution the normal curve.

Although the shape of the normal curve resembles a bell, it can be a tall, thin bell or a short, broad bell. Also, the bell can move around because of the location of the mean.

Many phenomena in our world are described by normal distributions—for example, people’s IQs, heights, and ages. The normal curve also has an ability to predict.

The normal curve has most of the values clustered near a central point with progressively fewer values positioned away from the center. It is symmetrical around the central point because it spreads out evenly on both sides.

Use the terms shape, center, and spread to describe the normal curve. Calculate its measure of dispersion to provide additional statistical insights.

Review the following example of the normal curve:

Fig. 9.1. A normal curve

In this figure, you see 1SD, 2SD, 3SD, and 34.13%, 13.6%, and 2.1%. I will review these concepts in a short while when I discuss standard deviation.

Chapter 3

Measures of Dispersion

Measures of dispersion, also known as measures of variation, provide an indication of the variability within a population.

Suppose that I collect the following student test scores for three of my classes:

Class 1: 66, 66, 66, 67,67, 67, 68, 69; xBar = 67

Class 2: 52, 53, 61, 67, 71, 72, 78, 82; xBar = 67

Class 3: 43, 44, 50, 54, 67, 90, 91, 97; xBar = 67

You see that all three classes have the same mean. If I only relied on the mean, I would believe that test scores from the three courses are equivalent.

However, dispersion (spread) of the test scores differs greatly. Class 3 varies widely and Class 1 varies slightly. It is clear that the mean provides limited benefits. I need more meaningful indicators to help me understand dispersion of the test scores.

Fortunately, statistics provides these indicators.

Range

The range is the simplest measure of dispersion. To find the range, sequence data in ascending order and subtract the smallest value from the largest.

The ranges for the test scores in Classes 1, 2 and 3 are 3, 30 and 54, respectively.

Using just the range is limited because it does not take into account all members in a data population, just the end points.

Consider these test scores for five students in Class A and for five students in Class B.

Class A: 43, 68, 69, 80, 97

Class B: 43, 44, 83, 90, 97

The mean and range for Class A are 71.4 and 54. The mean and range are the same for Class B. But are these populations equivalent? If not, how can you describe the differences? I need another statistical concept.

Mean Absolute Deviation (MAD)

Let’s break down this statistical concept. The phrase mean absolute deviation is a mouthful. It is not that bad if you look at each word, one at a time.

I hope you are clear regarding the definition of the mean.

Absolute refers to something that you may remember from a math class, absolute value. The absolute value of 5 is 5 and of -5 is 5. In absolute value notation, |-5| = 5. Absolute value helps describe distance for each value in a positive way. Negative numbers are not used because they do not exist in the physical world and cannot be used to calculate distance.

Deviation is a fancy word that describes the difference of each value in our population from the mean.

Let’s use the test scores from Classes 2 and 3 to illustrate mean absolute deviation (MAD).

Fig. 9.2. Mean absolute deviation

Follow these steps:

1.       List test the scores in column one and label them Xi (called X sub i). Xi is a counter for each test score (x1 is for test score one, x2 is for test score two and so on).

2.       Calculate and list Xbar (the mean) in column two.

3.       Subtract the mean from each test score (Xi − Xbar) and list it in column three.

4.       Calculate the absolute value for each value in column three and list it in column four.

5.       Add all values in column four.

6.       Divide numbers totaled in step 5 by the total test scores in each class. The MAD for Class 2 is 8.75 and for Class 3 is 19.25.

Intuitively, you probably knew that Class 3 had a large MAD because of its low and high test scores. However, now that we have a precise number, we can quantify the difference and discuss it.

Variance

The good news is that when you learn about variance, you almost learn about standard deviation. Standard deviation requires just one additional step. Variance is an improvement over MAD because you do not work with negative numbers or absolute value. Variance uses the sum of squares.

Examine the following chart. It should look familiar to you.

Fig. 9.3. Variance

The chart for variance looks very similar to the one for MAD. The only difference is that instead of using absolute values of the differences between individual test scores and the mean, you square the differences.

While simple to calculate, variance is of limited value because numbers become large very quickly. For only eight test scores, each that are less than 100, we already have a variance of 509.7 for Class 3.

Standard deviation helps make variance results manageable.

Standard Deviation (SD)

How do you calculate standard deviation? It is straightforward. It is the square root of variance.

Let’s take a peak:

Fig. 9.4. Standard deviation

When you take the square root of the variance for Class 2 and Class 3, you have a SD of 10.98 for Class 2 and 22.58 for Class 3.

What does this mean?

Please review the next few paragraphs very carefully. It is my experience that many people, even those in technical positions, do not understand the significance of standard deviation. I want to make sure that you clearly understand it.

Let’s return to the normal curve and make some inferences.

According to Figure 9.1, 34.13% of a normal population occurs within +1 SD and another 34.13% occurs within -1 SD. This means that 68.26% (34.13% + 34.13%) of test scores lie within +/- 1 SD on the normal curve.

Let’s look at Class 2.

The mean for Class 2 is 67. The mean represents the center line for the normal curve. Our standard deviation (SD) calculation for Class 2 is 10.98. For simplicity, let’s round off this SD to 11. This means that one standard deviation is equal to 11.

One positive standard deviation (+1SD) is 11 and one negative standard deviation (-1SD) is -11. This means that +1SD moves 11 to the right of the mean and -1SD moves 11 to the left of the mean.

When you move +1SD, you are at 78 (67 + 11). When you move -1SD, you are at 56 (67 – 11). This means that 68.26% of test scores for Class 2 are between 56 and 78.

What should you expect at +/- 2SD? 2SD is equal to 13.6%. If you move another SD to the left (11), our test score is 45. If you move another SD to the right, our test score is 89. Since you add 13.6% twice to 68.26, you have now explained 95.46% of test scores. 95.46% of all test scores are between 45 and 89 because they equal +/- 2 SD. This makes perfect sense because the eight test scores are between 52 and 82.

When you add another SD (to reach +/- 3D), you add another 4.2% to arrive at 99.66%. 99.66% of all test scores are between 34 and 100.

I hope that you found this introduction to statistics helpful. Regarding standard deviation, remember that it is used to describe distance from the mean. The greater the SD is, the greater the spread. The smaller the SD, the less variation exists in a process.

Chapter 4

Variation and Process Improvement

No two human beings have the same fingerprints. No two grains of sand in the Sahara Desert are the same. This may be hard to accept, but if you measure fingerprints or grains of sand with the most precise, sensitive instruments, you see subtle differences.

If you have ever assembled a complicated product, you can appreciate this concept. I remember a swing set that my wife and I assembled one Christmas Eve. One of the reasons we selected this particular swing set was because of the wording on the box: Easy assembly! All tools included!

Little did we know that the assembly process was anything but easy. Many of the seemingly interchangeable parts (brackets, bolts, screws, and nuts) were not interchangeable. With great difficulty, we finished assembling the swing set two hours before sunrise. To succeed, we needed a specific combination of brackets, screws, bolts, and nuts. Despite a standardized appearance, the hardware varied to such a sufficient level to make our job anything but fun.

Throughout history, no matter how great the effort, manufacturers have not been able to produce truly interchangeable parts.

Manufacturers and customers learned to accept variation. “It’s close enough” or “that’s good enough” became operative phrases. Items were made acceptable by adding other things to the process (hold it together with tape or fill in those gaps with more glue) or by modifying the part with the variation (make it smaller by sanding the edges).

Many of my former companies viewed quality as an either-or proposition. A product either worked or it did not. Material either passed inspection or it did not. We used the goal post method to determine acceptable quality.

When you play soccer, you score a goal whenever the ball crosses the line between the two goal posts. It does not matter if you use your foot, leg, or head to power the ball in the center, lower-left, or upper-right of the net. A ball that hits the goal post and bounces to the side does not score a goal.

Let’s apply soccer logic to inspecting purchased materials. Please review the following figure that presents the goal post method and sets the stage for my questions about purchased materials for your project:

Fig. 9.5. Goal post method

Assume that you purchase materials for your project whose specifications are between 2.9″ and 3.1″ in length. Consider these specifications as soccer goal posts. If you receive materials that are 2.88″ or 3.12″ long, you reject them. Think about these three questions:

• Does a 2.92″ part work better than one 3.09″?
• Why are 2.88″ long and 3.12″ long parts rejected but 2.92″ long and 3.09″ long parts accepted? How do these parts truly differ?
• What action do you take if supplier output is between 2.8″ and 2.85″ in length and this is the best your one and only supplier can do?

Do you face these types of difficult questions?

Think of quality in terms of degree instead of as an either-or proposition. The Taguchi loss function presents a viable alternative to the soccer goal post method of measuring quality.

Please review the following:

Fig. 9.6. Taguchi loss function

Since I spend a great deal of time in a classroom, let’s use the Taguchi loss function to illustrate quality, learning, and temperature in my classroom.

At a target temperature (70 degrees), the vast majority of my students are comfortable and ready to learn. As I increase or decrease the classroom temperature, an increasing number of students become uncomfortable and are not ready to learn. As the curved line moves to the right (upper control target, UCT), temperature rises and costs (the cost of not learning) increase. As the curved line moves to the left (lower control target, LCT), temperature drops and costs also increase.

The best way to guarantee quality is to hit the target. This is difficult. To hit the target, measure and reduce variation.

A technical description of variation is dispersion of data. Dispersion of data measures distance of events or conditions (temperatures or dimensions of parts) from an ideal spot (a target). Since no two things are alike, all objects and processes contain a certain degree of variation.

Use standard deviation to manage and reduce variation. While variation can never be eliminated, reduce it so that you satisfy customers and decrease internal costs.

Moving from the detection of problems to the prevention of problems is very difficult for most organizations. To prevent problems, you need a deep understanding of how things currently occur. Use prevention as a way to avoid losses and also eliminate the need to perform appraisal (inspection). Design and manage processes with care to prevent defects.

Use the Taguchi loss function to identify opportunities for improvement and statistical process control to reduce variation and boost quality output.

Statistical Process Control (SPC)

Many people freeze when they hear the phrase statistical process control. They often think “Oh. I’ll never be able to learn about that. It sounds too difficult” or “Statistical process control sounds too scientific and boring.”

Well, statistical process control (SPC) may certainly be considered scientific, but I do not think it is difficult to learn and use. I also do not believe it is boring.

Let’s break down statistical process control:

·         Statistical: Use numbers and measures.

·         Process: The work you do.

·         Control: Helps produce desirable and predictable results.

Rearranged, SPC means use numbers and measures to help you produce desirable and predictable results.

I hope this rearranged definition clarifies SPC for you.

Let’s look at a typical process.

Fig. 9.7. Typical process

Prevention requires profound knowledge of processes. To manage a process, you need to identify and understand process inputs (people, machines, materials, methods, instructions, and environment), their relationship to one another, and also how outputs relate to stakeholder requirements.

Use SPC to accomplish these three objectives:

·         Develop innovative products and services to enable users to have higher satisfaction and your company to have lower costs.

·         Develop innovative processes to reduce costs.

·         Improve existing products and services by using process improvement tools.

Follow these requirements to effectively use SPC:

1.       Be data driven.

Satisfy stakeholder requirements (both external and internal) by using rational methods. Do not make emotional decisions. At my former company, we wore buttons that stated, “Show me your data!” and “Without data, you’re just another person with an opinion.”

2.       Be systematic.

Follow organized, well-defined and well-documented processes and procedures. Perform work in a logical, orderly, and standardized way.

3.       Measure results regularly.

Compare data to targets and take corrective action at the right time.

4.       Make it a company-wide program.

Ensure that SPC is supported by top management and pushed down through your entire organization.

5.       Make prevention your goal.

Replace detection/appraisal/inspection with prevention.

To get started with process improvement, ask these key questions and reflect on the responses:

1.       What do I want to achieve?

Answer this question by reflecting on your project goals (deliverables).

2.       Who are my stakeholders and what are they interested in?

This question focuses your attention on external and internal customers.

3.       What is my current process and what does it yield?

This question helps you assess current practices and levels of satisfaction.

4.       Where are my opportunities for improvement?

This question helps you determine gaps between desired and actual results.

5.       What are the barriers for improvement?

This question identifies obstacles.

6.       How can I improve?

Make changes on a small-scale basis using a pilot.

Lesson 10 (printer-friendly version)

Chapter 1

Introduction

Today, I will discuss dimensions of the project team. For your project to succeed, you need a skilled project manager and committed capable project team members.

In Lesson 10, I will identify essential competencies of an effective project manager. I will discuss how to establish a winning project team. I will lead you through the stages of recruiting, evaluating and selecting project team members. I will also discuss core teams, extended teams, and overly important project teams.

Chapter 2

The Project Manager as Team Member

It has been a while since I asked you to look at the Project Management Institute’s A Guide to the Project Management Body of Knowledge. Refer to Figures 9-1, 9-2 and 9-3 and the material in Chapter 9. You will find see some very good information on team dimensions.

Figure 9-1 is particularly good because it summarizes essential elements of organizational planning, staff acquisition and team development. Section 9.2 is also excellent because it discusses how to acquire staff for your project once you define what you need.

Now that you know what A Guide to the PMBOK has to offer about establishing your project team, let’s continue.

The secret for success to obtain an effective project team is to plan for it.

Let’s start with the project manager.

I consider a project manager to be part of a project team. In fact, a project manager is team member number one! During the early planning stages of a project, identify a project manager as the first person to work on your project.

Many organizations plan a project and appoint a project manager after the project begins and the project team is in place. Make it a priority to select and secure a project manager before you progress too far.

Levels of skill and distinctive competencies set outstanding project managers apart from the rest of the crowd. Project managers have inherent, universal competencies; traits that increase their ability to manage projects. Competencies are also related to specific projects. For example, a manager who has successfully managed corporate office landscaping projects may not be capable to manage a project to introduce a sophisticated piece of medical equipment.

In the past, many organizational decision-makers believed that the most qualified person to manage a project was a person with technical knowledge about a project’s product, service, or technology. While it may true that technical experts (engineer, scientist, information technologist) lacked management or interpersonal skills, projects were considered proving grounds to learn the finer points of leadership and teamwork. This no longer is a viable approach given the demands on organizations for high performance.

Anecdotal experience and research indicate that a technical person is often not the best person to manage a product. In fact, they may be the worst person to oversee and direct a project.

I remember attending a project review meeting, which was led by project managers from technical disciplines. Leadership and vision were cited as the two most important characteristics of an effective project manager. The two most prevalent failure modes cited for projects were a lack of understanding of project management processes and a lack of understanding of their project management role as a leader. While these project managers had technical competency, they lacked competency in the top two categories.

This may be hard for you to accept (especially if you are a project manager from a technical discipline).

Here is what often happens: A technical person has a tendency to gravitate to technical aspects of a project (design work and system functionality, for example) and micro-manage these tasks. This is pursued at the expense of the rest of the project.

I personally witnessed a project manager from a technical discipline focus on just a few technical details and completely ignore the rest of the project.

One of my former employers supplied plastic syringes as part of a heart catheter kit. Physicians used our syringes to inflate a small latex balloon at the end of the heart catheter (once placed within the heart chamber) and to inject water into a patient’s heart (to initiate a temperature change).

Our syringe supplier informed us on June 1 that effective November 1, they would no longer supply syringes. Our vice president of procurement initiated a project to locate a new syringe supplier and appointed Jim, a manufacturing engineer, as project manager.

Jim convened a meeting and created a project plan. An important task for this plan was extensive material qualification to assure compatibility of plastic used to mold syringes with plastic used in our catheters. The time duration for this qualification was estimated at three months. The scheduled completion date was October 1. This scheduled completion date supported the one month lead time for the new supplier to mold syringes and ship them by November 1.

Jim spent a great deal of time defining and reviewing physical properties of various potential replacement syringes. He also extensively assessed the compatibility of the different syringes with our five packaging trays.

Unfortunately, Jim did not organize any project team meetings and did not follow up on the material qualification activity. The team member responsible for performing the qualification became ill and did not delegate his task.

At a September 15 management review meeting of critical projects, the problem with the material qualification became apparent. Only two weeks remained to perform testing that required three months.

This case study does have a happy ending. We received syringes from a new supplier on November 1. However, we paid an external laboratory a $25,000 premium to perform the qualification. Management was not pleased with Jim’s performance on this project.

I realize that this case study is a generalization. In many cases, individuals from technical disciplines are effective project managers. However, they must be willing to assimilate many new skills, specifically in planning, control, and leadership. This is a challenge for project manages with technical backgrounds because they must subordinate their technical mind-set to a considerable degree.

Project Manager Competencies

I hope you realize by now that an effective project manager must be a formidable and capable individual. High-performing project managers have significant competencies in the following areas:

1.       Leadership competencies.

Project managers often have ill-defined organizational authority. It is common to appoint a project manager without clearly establishing authority boundaries. Because of limited position authority, project managers compensate for this lack of clarity through outstanding communication, excellent decision making, and timely direction of the project team.

2.       Team management competencies.

Project managers must show project team members the benefits of working together for a common purpose. Successful project managers guide team members through team development phases consisting of origination (coming together), opposition (conflict resolution), inclusion (acceptance of roles), and high performance (achieving project objectives). All teams go through team development phases.

3.       Stress management competencies.

A project is often under the gun. Project managers must be able to cope with pressure and provide project team members with stress relief techniques.

4.       Interpersonal skill competencies.

Project team members produce the majority of output for any project. Project managers must appreciate the differences in people, be a good listener, and mediate conflict to obtain maximum performance.

5.       Administrative competencies.

Administrative competencies refer to project managers’ abilities to stay on top of the paperwork hill. Successful project managers understand and execute reporting requirements and also keep project schedules up-to-date.

6.       Business competencies.

Good business sense and an ability to recognize and comprehend an organizational climate are important skills. Project managers must understand the basics of company policy and strategy and also be able to think outside of the box to develop creative solutions to problems.

Project Manager Selection

Now that you have a good grasp of the competencies of an effective project manager, where do you find such a talented individual?

Just about anywhere!

Two recent projects that I was close to concerned a new product introduction for a diagnostic control and a component changeover for bottle closures (a plastic screw top cap replaced rubber push stoppers). The project manager for the new product project came from the regulatory affairs department and the project manager for the component changeover project worked in purchasing.

Both individuals were well trained in project management principles and practices and also were pursuing graduate business degrees. They clearly understood their role regarding their project.

While top-notch project managers are essential, they cannot accomplish project objectives without exceptional team members.

Let’s review how a project team comes together.

Chapter 3

Establishing Your Project Team

Selecting project team members is a critical activity. If you select the wrong people for your project team, you will encounter big problems. When you attempt to modify team members’ behavior or reassign personnel who are a bad fit, it disrupts the cohesiveness of your team.

Ideally, you should use a formal process and a rational approach to recruit team members. Unfortunately, it does not always work out that way.

Marginal employees are much too often offered as perfect team members. If you have a choice, do not compromise your preferences for project team members. Defend against individuals who are “volunteered” by their functional managers or. Frequently, volunteered team members do not want to participate on your project and, consequently, do not add value.

When employees are assigned to a project, they may become resentful. The sources of this resentment are many. These sources include:

·         A lack of confidence.

·         Unfamiliarity with working in a team setting.

·         Inability to fulfill duties of the position because of low skill levels.

·         Personality conflict.

·         Unwillingness to be pulled away from current job duties.

·         See project as a probable failure.

As a project manager, if you have a green light to create your own project team, how do you proceed?

Start with a extended project. Borrowed from the pages of classic human resources management, a job analysis is a good starting point to assemble your team. It is a summarized procedure that yields two documents that you may be familiar with:

·         Job description: A written definition of a job and types of work performed.

·         Job specification: Identification of qualifications needed to effectively perform work identified in a job description.

In a project management context, a job description could state that a team member is needed to create training materials and deliver training to end users for a new release of software. A job specification for this position indicates that this team member must possess working knowledge of the software, be familiar with current training methodologies, and be able to present ideas clearly and concisely.

A job analysis creates criteria used to evaluate potential candidates. It is common situation for you, a project manager, to have a preliminary idea of your human resources needs. For the new software release project, you identify the need for a training specialist, a programmer and an integrator (to act as a bridge between providers and users).

Draft a project team member worksheet to brainstorm potential team member job duties with your project team before finalizing a job specification.

After you know what you need for your project, recruit and evaluate candidates.

Project team members participate on either a full-time or part-time basis. If your project is of a severe nature (such as repairing a structure damaged by a natural disaster), team members may participate on a full-time basis plus overtime until your project is complete.

After you determine requirements for project personnel, generate positive exposure and assemble your team.

Many problems surface and are resolved during team member recruitment. When potential project team members hear about an opportunity to be a part of your team, take time to communicate the nature of your project. Help them understand your expectations and also share how participation in your project will be a rewarding experience. When you promote your project properly, the likelihood of having a pool of excellent volunteers is high.

If your team is ultimately composed of individuals who want to be there, you avoid many problems.

Follow these guidelines to create a project team from a pool of volunteers:

1.       Publicize the need for project personnel through various organizational communication mediums. For internal recruitment: company newsletter, e-mail, company intranet, bulletin board postings, memoranda, word-of-mouth. For external recruitment: newspapers, the Internet, professional associations, colleges, universities, external networks.

2.       Define the purpose, objectives, expected time duration, and deliverables.

3.       Identify duties of each project team member. Use a job description to define responsibilities for each project team member.

4.       Identify how each project team member will be enriched because of the experience. Communicate benefits for potential team members by using the acronym WIIFM (What’s in it for me?).

5.       Be honest with each team member in terms of potential risks and conflict.

Earlier I identified pitfalls of team members that are volunteered (against their wishes) by their functional manager. Project managers prefer legitimate volunteers. But let’s be honest. Not all projects are a magnet for team members. For example, what should you do if no one volunteers to participate on your project to clean up a polluted lake?

For unattractive projects, management often performs a selling job on potential team members. They emphasize the positives and downplay the negatives. This type of communication creates resentment. It is worse when negative aspects of a project are not identified.

In many circumstances, however, a selling job is not performed for unpleasant projects. An employee may receive an e-mail from his boss that states, “Congratulations. You have been selected for the lake clean-up project. Please contact Tony Swaim for instructions and for information about the first team meeting.”

In many instances, employees view such an “invitation” similar to a summons to appear in traffic court.

Hopefully, however, you will find that an outstanding group of volunteers come forward and want to participate on your project. What is the next step?

Reach for the job specification section of your job analysis and follow these steps:

1.       Review an applicant’s resume or application.

Follow all applicable discrimination laws.

2.       Conduct interviews.

Conduct one-on-one interviews (between you and the applicant) and use a team that includes human resources and other project team members. For example, ask one team member to assess an applicant’s technical skills and another team member to evaluate interpersonal skills. Select team members who truly want to be part of your project. Avoid individuals who are just looking for a job.

3.       Perform reference checks.

This step may be of limited value, especially if you use a reference that an applicant provides. Many applicants provide biased references.

Ask an applicant if you may talk to previous team members. This may provide insights regarding an applicant’s ability to work well in a team environment.

After you complete these three steps, compile and compare an inventory of an applicant’s skills and competencies.

If and when you find a perfect project team member applicant, what characteristics would this individual have? Please review this list:

·         Possesses the desired life experience.

·         Reflect a desire to learn.

·         Demonstrates initiative, creativity, and flexibility.

·         Have a good grasp of project management and process improvement tools.

·         Possesses excellent communication skills.

·         Understands the value of teamwork.

·         Can work in a disruptive, chaotic environment.

·         Can work independently and demonstrates follow-through to completion.

·         Possesses a good business sense and an understanding of the big picture.

·         Has high standards for work.

·         Maintains a high energy level.

After you review this list, you may think, “These are great characteristics, but how do I know if an applicant possesses them?”

A vice president that I once worked for told me that if I maintained an applicant hiring success rate of 50 percent, I should consider myself fortunate. I do not know if percentages are that low, but there is no doubt that if do your homework, you should be able to recruit and select project team members to give you better success than 50 percent.

Chapter 4

Project Team Versions

At many organizations, a high-performing, self-directed project team is an odd entity. Instead of a stable, traditional hierarchical company organization structure, there are now people who work together in a unique way.

I worked on a project that was exactly like that. Departments were relocated to make room for the new project team. Team members trickled in from various parts of the company, the country, and the world. Before I knew it, there were about 40 people on the project team.

I heard questions such as, “Who are those people?” and, “What are they working on?” in the parking lot, hallways, and in the cafeteria.

When you hold your first meeting with your project team, most team members are on their best behavior or have a wait-and-see attitude. Eventually, your team has to get to work, with each other and with individuals inside and outside your organization.

It is possible that your project membership includes a core team and a temporary team. A core team is comprised of individuals who are either completely or to a very high extent dedicated to your project.

The extended project team is usually only required for a short period of time. These team members are only needed at the very beginning, in the middle, near the end, or at different intervals of your project.

Additionally, a temporary team may be needed on an ongoing basis, but only for support. A functional department manager serves this purpose. This manager, realizing the importance of a project, could facilitate availability of two of the most capable employees from an information technology department.

Identify everyone who needs to perform a project task at one time or another. External contractors fall into the extended team category.

Gaining support from the extended team may be challenging. Members of the extended team typically do not have the same interest or commitment level as the core team. As a result, extended team members may not be ready when called upon (they may even have forgotten about your project). Also, since they were not involved with your project as it has evolved, the extended team members may not understand your expectations.

Extended team members may have limited availability due to other commitments. Given the strong probability that your project schedule may change, revised dates for performance may not be acceptable to extended team members.

The Overly Important Project Team

While it may be difficult to mold personnel into a high-performing project team, just the opposite may be true. In addition to cohesiveness of your team, there may be too much togetherness.

A project team becomes overly important when they closely identify with one another so much that they forget they are part of a bigger picture: the organization they work for.

I have seen this a few times. For example, it is a common occurrence in the military. Members of a particular company or troop sometimes act inconsistently regarding higher-level military orders. It is also evident when self-directed work teams emerge within a company. Their charter is not well defined so they believe that they have a wide-open agenda.

In project management, this type of situation is not that prevalent because of the structure and organization that (hopefully) exists.

Nevertheless, it is important that you recognize that this type of situation takes place. Look for these behaviors to determine if an overly important project team exists at your organization:

1.       Violating company policy and procedure.

Sometimes the project team becomes so immersed in project tasks that they forget things like attending mandatory training sessions or a favorite activity at my prior company, Annual Company Documentation Clean-Up Day. (Yes, there actually was one.)

2.       Competing with other teams.

I have seen this happen too often. A member of project team exclaims, “Oh. You only have two process improvement projects that you’ve completed. We have 10.”

3.       Dragging out a project so that the team can still exist.

Of course, no team ever admits to this, but it does happen.

To effectively manage an overly important project team, keep them well informed of activities that take place in your organization.

Lesson 11

Chapter 1

Introduction

I believe a potent combination of a high-functioning project team and a capable project manager is essential for your success in project management. Effective project teams do not just happen. They come together through careful planning and action. When you blend team member personalities, interests and capabilities in the right way, you develop a project team that enjoys working together and more important, accomplishes project objectives.

Today, in Lesson 11, I will discuss work group theory, contrast formal and informal work groups and identify informal work group characteristics. I will discuss the stages of team development and review each stage. I will discuss why change is so important for your project, review why people are reluctant to change and provide strategies to help you overcome resistance to change. I will also discuss empowerment and explain how you can empower your project team.

Chapter 2

Work Group Theory

Work group theory helps you understand how team members relate to each other in a project team setting and, hopefully, over time increase commitment levels.

Being part of a group is a natural activity for human beings, inside and outside of work. Pressure from groups—overt, subtle, or imagined—affects individual behavior.

Work groups occur in a complex environment. Characteristics of a work group environment include the following:

·         Formal organizational relationships between bosses, subordinates, and peers.

·         Temporary appointed positions (such as project manager).

·         Communication networks.

·         Status of office size and location.

·         Years of experience on the job.

·         An individual’s position in an organization.

For high-performing work groups, you need a logical structure, a favorable image, and a positive work environment for team members.

Types of Work Groups

Within any organization, there are usually two types of work groups. A formal work group is the most visible as it is established and sanctioned by top management. All company operating units (divisions and departments, for example) are formal work groups. The authority for this type of work group is typically managed by a company official.

The other type of work group is an informal work group. Informal work groups are groups that share common interests and are not found on a company’s organization chart. Informal work group sometimes grow more powerful and accomplish more things than formal work group.

Informal work groups may actually be more numerous than formal work groups. While not officially recognized by your organization, practically everyone belongs to at least one or more informal work groups.

As employees enter your company, they interact with each other as they perform job duties. Areas of common interests begin to emerge from interpersonal contact. A strong sense of security and membership takes place as well as loyalty to the informal work group. Informal work groups sustain and satisfy an individual’s needs.

Consider the following project:

A college district receives a grant for 150 acres of land and 55 buildings because of a recent closing of a military base. My friend Paul is appointed to plan and implement a project involving reuse of the land and buildings. The total acreage of the land is greater than the two existing colleges in the district. It is a significant project.

After completing the first draft of a project plan, Paul assembles his project team and selects 75 team members from academia and the private sector.

The initial team meeting goes well. Paul establishes ground rules and determines roles and responsibilities. All areas appear to be well covered and Paul arranges for a team outing and dinner as team building activities.

Paul’s project team is defined by a project charter and project organization chart.

Let’s move the calendar forward a few months.

Paul’s project team members have many diverse responsibilities. Team members operate in a decentralized manner. Sharing of information is done on a need to know basis.

As Paul is very busy with pressing matters at hand, he decides to rely on the trust method to direct and coordinate his project team. Paul reasons that since he selected good people for his project, he can safely use an informal approach and trust project team members to provide timely input.

To a casual observer, it appears that Paul’s team meetings function as planned. Paul addresses each responsibility area and determines things are going smoothly. However, beneath this calm surface, a large number of informal work groups have emerged. Many of them are counterproductive to the goals of Paul’s project. In addition to the formal leadership vested in Paul as project manager, members of an informal work group are exercising unauthorized leadership. A case in point pertains to the reuse of the Officer’s Club.

The official project plan indicates that this facility will become a conference center for local industry. Unbeknownst to the rest of the team, a team member is working behind the scenes with venture capitalists and a few disgruntled city administrators (not working on the project) regarding an alternate plan for the Officer’s Club.

It seems that this alternate plan involves the creation of a robotics and office automation demonstration facility. The informal work group decides that the funds for this facility will be by city, county, and state officials, thereby undermining Paul’s official project plan.

What does Paul need to do? Is his project plan doomed?

All is not lost.

Paul needs to take a crash course in the inner workings of informal work groups. Once he reaches an understanding of the finer points of informal work groups, Paul can identify their existence and minimize their impact.

Paul learns that he identifies informal work groups by their behaviors.

Let’s learn about these behaviors.

A more familiar term for informal work groups is cliques. Some cliques are harmless; others are destructive. Informal work groups do not form overnight. They follow an evolutionary process.

Once cliques form, they take on a life of their own. Here are their characteristics:

1.       Establishment of norms.

A norm is an understanding or a pattern of behavior among group members concerning things to be done. Norms are standards of conduct. For example, a group of disgruntled employees may establish a norm that indicates informal work groups should never participate at team meetings.

Informal work groups use norms to influence members in a group. If you have children between the age of eight and 18, you may be familiar with this concept.

Pressure, evaluation, and enforcement (sanctions) by informal work groups help reinforce the existence of norms.

2.       Group cohesiveness.

This characteristic refers to degrees of solidarity of a group. Many informal work groups maintain a you-are-either-with-us-or-against-us posture.

Group cohesiveness is influenced by: physical proximity (location of members), group size, perceived status of the group, stability of members, strength of leadership and the ability to provide rewards to members.

Once you identify an informal work group, you must determine what effect the group has on your project. If an informal work group serves a useful purpose that does not detract from your project, there is no reason why it should not continue. On the other hand, if it is detrimental, take measures to reduce its influence or eliminate it.

An ideal situation is to have formal and informal work groups work together in harmony to support your project’s success.

Chapter 3

Team Dynamics

It is clear that just about everyone wants to be associated with a successful enterprise. You may observe this by watching children at a little league field as they exclaim, “I want to be on Johnny’s team.”

The same principle applies to project management. There are projects and also specific project managers that everyone would love to be part of and work with. Conversely, there are other projects and project managers that no one wants any part of.

The largest percentage of projects lies in the middle area, where no one really knows how a project will turn out. Since a project is a unique, one-time event, it is difficult to predict its outcome.

Some teams are together for just a short while, (for instance, a few weeks), while other teams stay together for a few years. Regardless on the length of a project, all teams go through a set of common experiences. These experiences are known as stages of team development.

The stages of team development begin with origination (when a team is announced, recruited, or assembled) and end with high performance (when team members complete project objectives).

Let’s look at a day in the life of project team members as they move through the project life cycle and commitment develops.

Stages of Team Development

There are a number of models that describe the stages of team development. You may have been exposed to other models. However, the model that I want you to remember has four stages. The differences between the basic models are not that significant. Please focus on basic concepts of my model and not the labels I use.

1.       Origination.

When team members are first assembled, they experience many different feelings. Many individuals are enthusiastic and optimistic, while others may be more cautious and adopt a wait-and-see attitude. During this stage, team members rarely display outright anger or resentment. Top management is often present during these early meetings, so team members are on their best behavior.

During this early stage, despite the desire on the part of a project manager and some team members, discussions usually focus on issues of lesser importance such as where team members sit or lunch break times.

Team members may question the validity of the project, but they are careful. The level of trust and commitment is typically low. In general, team members are uncomfortable during the origination stage.

2.       Opposition.

All project teams go through the opposition stage to a certain degree.

After the initial warm-up period is over and team members begin to know each other better, team members begin to feel more comfortable, open up and speak their minds. They challenge just about everything under the sun, including the way the project manager runs meetings and the amount of money available in the project budget.

Many team members form alliances during the opposition stage. Informal work groups begin to appear. This is not necessarily bad, however.

Many team members begin to internalize the project goal. Also, communication becomes clearer and certainly more direct. Additionally, various team members begin to demonstrate leadership.

An unfortunate aspect of the opposition stage is that due to a high degree of discomfort and conflict, many teams stall out and never move forward. For those that persevere, brighter days lie ahead.

3.       Inclusion.

During the inclusion stage, team members finally overcome their difficulties with each other, start to accept each other and accept their roles on the project team.

Unhealthy competition transitions to cooperation. Sharing of information and ideas is common. Team members become committed to achieving the project goals and trust increases. The influence of informal work groups is less prominent.

The project team is finally on the road to high performance.

4.       High performance.

This stage is the ultimate for the project team. Members form a cohesive unit and strengths are used to maximum advantage. It is a natural state that all team members enjoy.

Only a few teams ever reach this level of performance. The existence of empowerment is very noticeable. Teams achieve much with little direction because they become a well-oiled piece of machinery.

A Word of Caution

In regards to the stages of team development, look out for the following situation:

It is possible for teams to revert back to different stages. For example, if a new member joins your team or a different project manager is appointed, your team may move from the inclusion stage back to the opposition stage because of new team dynamics. Also, even with the same team members, your team can revert because of changing circumstances in your project.

Chapter 4

Change Management and Empowerment

There are two types of people in this world: those that like change, welcome it, and thrive on it and those that are secure with the status quo and hope things remain the same.

The ability to thrive on change is an inherent quality for many people. These people love stimulation and excitement of new things. They maintain a “been there, done that” mind-set and always look for the next challenge.

However, a larger group of individuals may encounter new experiences before they are ready for them. These groups prefer change later (if at all), not sooner.

In a project management context, change has two basic dimensions:

·         Change that each project team member must individually address.

·         Change that all team members must make to support your project.

When change impacts you or your team members, you must understand its nature to use change to your advantage.

The level of predictability for most projects is low. Consequently, it is necessary for each team member to become very comfortable with change.

Reasons for Resistance to Change

Why are so many people afraid to change? Let’s review the major reasons.

1.       They possess an “If it isn’t broken, it doesn’t need fixing” attitude.

A corollary to this statement is, “I’ve always done it this way. Why should I change?” For whatever reason, team members may not see the need for change because they believe current results are acceptable.

2.       They fear the unknown.

A team member may desire change, but a fundamental fear of what could happen (it could be worse) may reduce his openness to change.

3.       They fear failure.

Deep down, a team member may want change, but is afraid to fail. This belief may come from previous unsuccessful attempts at trying something new or because she has a poor self-image.

4.       They fear obsolescence.

This is a genuine fear that occurs in today’s technology-driven world. If you ask a team member to adapt a manual process (a project schedule written on chart paper) to a computer-based process, he may resist change because he fears job obsolescence.

5.       They resent forced change.

Most project team members want to be part of a project’s planning and decision process. I once worked for a highly autocratic boss who telephoned from a distant location to tell me he had reorganized my department. I was not involved in this decision. Some of my direct reports were moved to a new department and I received new responsibilities.

Do you think I resisted this change? No, but I did resent it.

6.       They have a personality conflict.

A team member may not be reluctant to a proposed change, but may hold a grudge against a team member who suggested the change. For example, Sandra may comment, “Since Mary thought of the change, there’s no way I’m going to go along with it.”

7.       The timing is bad.

There may not be a problem with an area or activity planned for change; however, the timing may not be right. A proposed change may be resisted if team members are not in a receptive mood.

8.       They believe that the change is a bad idea.

Project team members may completely understand a proposed change and are quite comfortable with the concept of change, however, they do not cooperate because they truly believe the proposed change is a bad idea.

When team members have this belief, hear them out so you understand their position. They may be right.

9.       They fear a loss of power and prestige.

During a project, it may be necessary for a big boss to sacrifice his huge office so that four project team members have someplace to sit. The big boss does not want to lose his big office because of a perceived loss of prestige.

Now that you know about the reluctance to change, how do you overcome this resistance?

Overcoming Resistance to Change

Follow my recommendations to overcome resistance to change:

1.       Involve those affected by a change in planning and implementing the change.

Team members support change that they help create. Advise team members that while their input may not be incorporated into a planned change, you value their contribution and will consider it.

If a proposed change is confidential, you may not be able to divulge information and include team member in planning changes. Also, when you ask team members to help plan and implement change, they may be willing to participate.

2.       Thoroughly explain the need for the change.

When you explain a proposed change to a team member, you may discover that a change is not needed.

3.       Involve a person with power or authority (usually a company executive) to help plan and implement the change.

While similar to the first recommendation above, this recommendation is different in a significant way.

There are some people that will not support a change unless they think of it. If you approach these types of people with a fantastic idea, they reject it because you proposed the idea (not them). To successfully implement a change in this type of situation, create your proposed change with them. These types of individuals often support changes that they help develop.

Plan your steps very carefully to influence someone with power or authority.

4.       Allow for a learning curve to occur for the change.

Do not expect team members to be comfortable and proficient with a new process the moment they begin to use it.

5.       Implement change in phases.

Remember, Rome was not built in a day. Build on your successes. Use the learn-by-doing approach.

6.       Be supportive.

At times, kind words are all you need to bring about a desired change.

Empowerment

One of my former bosses once commented that empowerment was nothing more than a modern day word for delegation. In this instance, I respectfully disagreed with my boss.

It is true that in order to use empowerment, an entire concept (the concept of empowerment) must be delegated. While delegation narrowly grants authority to perform specific of a small group of tasks and requires employees to accept accountability for their actions, empowerment is broader in scope.

Empowerment gives employees a considerable amount of authority to make decisions and to act in a number of different capacities. Empower your project team during the origination stage.

This is a two-way street. Empowerment is one way; the other way is accountability. As team members obtain more autonomy, they must accept an increased level of accountability.

Empowerment is successful when it is based on team member capabilities. Knowledgeable and skillful team members who possess a high degree of confidence and commitment are ready for high levels of empowerment. These individuals do not need much direction.

Conversely, new team members are not yet ready for empowerment because they lack capability. You need to provide a large amount of coaching and leading.

In project management, the best policy is the following:

As project team members’ abilities increase, increase the amount of empowerment.

This increases autonomy and efficiency and also heightens satisfaction levels of team members. It also frees up your time because less supervision is required.

Lesson 12

Introduction

Welcome to your last lesson. It seems like the course just began yesterday. You know what they say about how time flies when you are having fun.

When I look back on all the areas that we covered, I am absolutely amazed. When I created this course, I wondered how all of these subjects would come together. Overall, I believe it went well.

I really enjoyed helping you learn all about project management applications. I learned a lot when I put the course together. I hope that you also learned a lot. Thank you for taking my course and for the valuable input that you provided at the class discussion areas.

In Lesson 12, I will discuss fundamental organizational concepts. I will review the purpose of an organization chart and discuss the matrix organization as a common project management organizational structure. I will discuss coordinating principles including authority, responsibility, accountability and power. I will provide an overview of organizational culture and discuss key terms such as values, beliefs, and assumptions. I will also discuss the elements of successful delegation and present various theories of motivation and leadership.

Chapter 2

Organizational Structure

Think of an organization chart as a road map. It is a static abstraction of a dynamic condition (people that work together). An organization chart is limited because it does not identify intangibles such as personality, attitudes and experience.

Organization charts define company relationships. They help answer the following questions:

·         Who am I? (What is my position in the organization?)

·         What do I do? (What is my title and job description?)

·         To whom am I accountable? (What box am I connected to?)

·         Who is accountable to me? (What boxes are connected to my box?)

·         Who are other people of interest in the organization? (Who has boxes above, below, and to the side of my box?)

·         What do these people do? (What are their titles and job descriptions?)

·         What are the reporting relationships for these people? (What boxes are above and below their box?)

If you do not address these questions, you will not understand important organizational relationships. If you act without organizational knowledge, you violate company protocol and may unintentionally upset employees.

If you work on projects, it is likely that you use a matrix organization.

A matrix organization generates a great deal of conflict because it begs the question, “Who is my boss?” This question arises because of a dual authority system.

In a dual authority system, your project organization borrows an employee from another department. When you use a matrix organization, you create a team of specialists to accomplish your project goals.

Matrix structures are typically used for very important activities with a time-sensitive schedule. The essence of this type of structure is that it combines functional and product (project) orientation.

The advantage of a matrix organization is that it is very effective if buy-in occurs and a project manager has proper power and authority. The disadvantage of a matrix organization is the presence of interpersonal conflict.

Review this example of a matrix organization:

Fig. 12.1. Matrix organization

Please review Section 2.3.3 of A Guide to the PMBOK to read about project organizational structures.

Review these four concepts that relate to ability and right to act. Use these principles to help project team members contribute to your projects and to make the right types of decisions.

1.       Authority.

Authority relates to the vertical hierarchy of positions in organizations. It is defined as the right to act. Authority consists of making decisions within a designated scope, assigning tasks, and expecting satisfactory performance of tasks. Examples are directing others and authorizing the spending of funds.

You must delegate authority to enable others to act.

2.       Responsibility.

Responsibility is defined as an obligation to act. Unlike authority, responsibility (once accepted) cannot be delegated. Responsibility typically begins when an individual accepts a position at an organization.

3.       Accountability.

Accountability uses elements of authority and responsibility. It is defined as being liable for actions. Once you accept a delegated assignment, you have accountability to act and to answer for results. Your boss still bears ultimate organizational responsibility. Your boss cannot escape responsibility through delegation.

4.       Power.

Power is often confused with authority. Power is defined as ability to act without necessarily having a right to act. Power is measured by ability to give or promise rewards, and also to punish or threaten punishment.

Use of power is influenced by ethical and moral factors. Even though individuals may have authority, they may not have power. You may know an individual at your organization that fits this description.

An ideal situation is an equal blend of power and authority.

Two key problems that exist at most organizations regarding coordinating principles are the following:

·         Individuals want to maximize authority and power, but want to minimize responsibility and accountability.

·         Management asks employees to be responsible and accountable for an assignment, but does not provide sufficient authority.

Additional coordinating principles include the following:

1.       Line and staff.

The line and staff principle causes a great deal of conflict. Line employees have direct responsibility and authority to accomplish enterprise objectives. Staff employees support line employees.

Here’s an example:

Donna, a project manager, reports to Manuel, the director of project management. Donna is responsible for cost, performance, and schedule objectives for her project to implement new software. Rusty, an information specialist, reports to Carol, the director of information technology. Rusty advises Donna on technical matters.

In this example, Donna is a line employee and Rusty is a staff employee.

2.       Centralization and decentralization.

Centralization and decentralization refers to degree of delegation of duties and authority granted to lower levels of an organization.

Here’s an example:

Michael is the vice president of purchasing at a corporate office. Ten purchasing managers at different global manufacturing sites report to Michael. If Michael authorizes purchase orders, develops procedures and systems for all purchasing managers, and oversees day-to-day purchasing operations, he creates a centralized organization.

Alternatively, if Michael plays an advisory role and each purchasing manager has free will to act independently, the purchasing organization is decentralized.

The determinant of a centralized or decentralized organization is the degree of control, not the physical location of personnel.

3.       Span of control.

Span of control refers to the number of people or activities that can be effectively managed. When you direct just a few employees, you use a narrow span of control. When you direct many employees, you use a wide span of control.

Despite the efforts by personnel departments, there are no clear-cut criteria regarding the number of employees an individual can effectively manage. Span of control depends on task complexity, experience and capabilities of personnel, physical location of team members, and the amount of time a manager spends on discretionary tasks.

Be very careful to establish your span of control properly. For large projects, consider appointing assistant project managers to keep your span of control manageable.

4.       The Parity Principle.

The parity principle states that authority and responsibility go hand in hand to effectively perform a task.

The parity principle is frequently violated in project management. Quite often, authority for a project manager is ill defined (if defined at all). For example, Paul, manager for the military base reuse project, had responsibility for project results but little authority.

Chapter 3

Organizational Culture

A question that I like to ask when I visit a company is, “How would you describe your organizational culture?” Many times, I receive a funny look, but other times, I am told that the culture is adversarial, team-oriented, paternalistic, cold, or family-oriented.

Organizational culture is made up of many things besides human beings, computers, buildings, and office supplies. It includes shared values, beliefs, assumptions, perceptions, norms, and behaviors. Company culture is similar to personality. It is hidden some of the time, but is revealed in a variety of ways depending on a situation.

Since I mentioned some terms, I will define them and relate them to organizational culture.

1.       Values.

Values are important because they determine your view of the world. Once values become part of your makeup, they guide your actions. Likes, dislikes, viewpoints, and judgments make up values. Values are developed throughout your life and are shaped by many things, including family influences, peer pressure at work and school, and mass communications.

When you make a decision, your preferences are shaped by your values.

Values help form beliefs. If values do not fit with your job, there is a high probability that you will end up in an undesirable career position.

You use values to make decisions when you lack objective information. When your organization develops a vision statement, your chief executive officer’s (and any other contributing employees) values are reflected.

You establish shared values when you work in groups and when you internalize group decisions.

2.       Beliefs.

You develop beliefs through a combination of opinions, perceptions, and experiences. While a thought or idea may not be factual, if you believe strongly enough and act as if it is true, it might as well be true.

Beliefs are evoked when rumors circulate regarding reorganization, layoffs, facility relocations, and plant closures. Make it your policy to provide timely and clear communication to avoid creating false beliefs.

3.       Assumptions.

Related to beliefs, you develop assumptions based on internal concepts. Assumptions are not based on objective data, but if left unchecked, over time assumptions become accepted as fact.

4.       Perceptions.

When you perceive and assemble stimuli from your environment, you form a paradigm. A paradigm is an internal mental structure that shapes your discernment, interpretation, and understanding of messages, images, and other inputs. Paradigms create reality because you act based on your perceptions.

5.       Norms.

Norms are agreed-upon standards (although not always overtly) of individual and group behavior. Norms develop gradually over time. Norms are an important element of work groups.

6.       Behaviors.

Behavior is visible conduct. Behaviors become distorted when companies display “do as I say, not as I do” positions. This presents a credibility problem.

In addition to these variables that are largely founded in psychology and sociology, other factors that contribute to organizational culture are ceremonies, stories, routines, customs, and symbols.

The importance of organizational culture to project management is high. It is essential that you recognize a prevailing organizational culture before you initiate a project.

Your project need not necessarily comply with your organizational culture. Your project may be a vehicle to bring about a change in your organizational culture. For example, I know a project manager who deliberately acts in a contrary manner to instigate organizational cultural change.

When organizations are first formed, power and authority is concentrated at the top. Delegation is needed because without it, no one but a chief executive officer or president can officially act. It is a critical organizational principle that unfortunately, is not done well at enough organizations. It is also a behavioral topic because it involves both leadership and motivation.

You practice effective leadership when you delegate properly. Regrettably, what often passes for delegation is really a dump. When a manager dumps, he or she gives a task to a subordinate (sends an e-mail message, leaves a voice mail, or sends a request through interoffice mail) without discussing the task and securing employee buy-in.

Motivation has an importance relationship to delegation because without it, delegated task are not performed.

To delegate effectively to project team members, follow these steps (in this order):

1.       Determine desired results.

Make sure to develop a plan and create objectives. Many managers determine desired results, but do not communicate them clearly.

2.       Assign and discuss tasks.

Assignment usually takes place but not discussion. Provide team members with an opportunity to ask questions and clarify instructions. This is the most important ingredient for successful delegation.

3.       Delegate authority.

Make sure your team members and the rest of your organization know what tasks are delegated. There can be no confusion if authority to act exists and knowledge of which tasks have been delegated has been imparted.

4.       Communicate expectations.

This step is not done very well. “Just do it” or “just handle it” are all-too-common requests from project managers. Make sure that your expectations support your project’s desired results. Discuss the methods used, the processes for reviewing results, and the due dates for completion.

5.       Perform follow-up.

This is another step that is not done well. Some project managers follow up too much, others not enough.

In addition to completing these steps, follow these additional requirements to successfully delegate:

·         Listen to team members input regarding objectives and methods.

·         Be willing to let go.

·         Be willing to let others make mistakes.

·         Be willing to trust others.

Chapter 4

Motivation

Motivation assures or enhances a strong commitment to achieve your project objectives.

Successful project management requires an establishment of an environment in which team members work together toward a common objective. For you to achieve this, you must know what motivates your team.

Sometimes in a discussion about motivation, a few individuals want to substitute another M-word: manipulation. Manipulation is used to influence project team members to take action they do not want to take. When team members are motivated, they willingly perform tasks for your projects.

Motivation is an energizing force that directs people towards a goal. This goal may be unknown to others and may be irrational. Nevertheless, all behaviors are ultimately directed towards achieving a goal.

Underlying these energizing forces of motivation are drives, desires, and needs. These elements occur in a series and are influenced by environment factors.

Let’s review an example:

Assume that I am returning from a training assignment on an airplane. Because of my busy schedule, I missed dinner and instead, ate nine bags of those wonderful peanuts. About halfway through the flight, I become aware that I need a drink of water. Since I have a window seat, I do not want to inconvenience my two neighbors by crawling over their laps.

At this stage, I merely desire some water.

I hear the drink cart. My desire turns into a need. I need some water.

Ten minutes pass and finally, my drive for water compels me to leap over my two neighbors and exclaim to the flight attendant, “Please give me some water!”

I should have stopped at three bags of peanuts . . .

I need to clarify a misconception: A human being cannot motivate another human being. The best you can do is to understand what motivates someone and provide leadership. Ultimately, motivation is based on individual choice.

Let’s review a few theories of motivation. These theories are legitimate models that have been successfully applied in organizations for many years.

Reward and Punishment: The Carrot and the Stick

Many individuals are motivated because of a perceived reward (carrot) or punishment (stick). Money, a promotion, job satisfaction and recognition are types of rewards. Fear of losing your job, demotion, and public humiliation are types of punishment.

Rewards lose their effectiveness as motivators over time. If an individual is motivated by a reward and other people (thought to be less-deserving) receive similar rewards, the reward is viewed as an entitlement.

There is no doubt that fear of punishment is used to increase performance in the short run. In the long run, fear is a losing proposition because you suffer unnecessary stress and ultimately strive to escape fear and stress.

Maslow’s Hierarchy of Needs

In Maslow’s theory, five types of needs form a hierarchy. Please review this overview of Maslow’s model:

Fig. 12.2. Maslow’s hierarchy of needs

Once basic needs of survival and security are met, individuals attempt (by moving up the pyramid) to generate satisfaction and self-actualization.

Herzberg’s Motivation-Hygiene Theory

The motivation-hygiene theory consists of dissatisfiers and satisifiers. Dissatisfiers occur when hygiene factors are absent. Hygiene factors maintain an individual. For example, air conditioning is a hygiene factor in a hot, stuffy office. Its presence does not generate motivation, but its absence is a dissatisfier.

Use the motivation-hygiene theory to identify all essential hygiene factors at your organization. Examine job-content factors such as opportunities for promotion, recognition, and interesting work. These factors are satisfiers and true motivators.

Let’s look at the complimentary component of motivation: leadership.

A need for leadership exists because of a need to follow. Team members will follow you if they believe you can help satisfy their goals.

Leadership is an important competency for a project manager. The goal of a project manager is to instill a spirit of performance in a project team.

The ability to lead is rare. Many project managers take charge and ramrod their project implementation. It is much less common to influence team members so they willingly accomplish project tasks with eagerness and enthusiasm.

You do not need a magnetic personality or charisma to be an effective leader. To succeed in leadership, emphasize employee strengths and neutralize weaknesses.

There are basically three types of leaders:

1.       Autocratic leaders.

An autocratic leader uses authority and discipline without hesitancy. Known as a Theory X manager, this individual believes that project team members consider work distasteful and must be managed very closely.

2.       Participative leaders.

Known as a Theory Y manager, a participative leader believes that work is a natural, fundamental human activity. This individual involves project team members to reach success.

3.       Situational leaders.

This leader uses a situational approach (directing, coaching, delegating, and empowering) to great effectiveness.

What determines the type of leadership you use? Answer this question by reviewing these points:

·         Formal organizational relationships between bosses, subordinates, and peers.

·         Temporary appointed positions (such as project manager).

·         Communication networks.

·         Status of office size and location.

·         Years of experience on the job.

·         An individual’s position in an organization.