<<

. 5
( 6)



>>

problem; failure to recognize that fact can cloud your objectivity in developing a meaningful solution.
5. Develop a plan. Devise a miniature project plan, if you will, to implement a solution.
6. Seek feedback. You may have addressed the cause but perhaps not in a way that completely fixes
the problem. Feedback will help you to refine your plan and achieve your solution.

Perry, for instance, decides to change the logic of the network diagram because the Smythe family wants to
have the bridal shower two weeks earlier. The Smythe family also wants to increase the number of attendees
by 20 percent and add more events. All this affects the schedule, of course, but also the scope of the project.
The changes also have positive and negative impacts. A positive impact is satisfying the customer; a negative
impact is temporarily slowing the momentum of the project, which in turn reduces productivity.

Contingency Planning
Ideally, risk assessment (see Chapter 12) provides the basis for good contingency planning. Contingency
planning involves developing responses to situations that have a good probability of occurrence and could
impact project performance.




Exhibit 17-2 Contingency plan form.
For the Smythe Project, Perry develops a contingency form, shown in Exhibit 17-2. He records the description
of the event; its probability of occurrence; its impact on cost, schedule, and quality; and the appropriate
response.
Reliable contingency plans don™t just happen, as Perry well knows. They require having information about
possible events, including their potential impact; time preparation; and feedback indicating when the events
do occur.

Summing Up Change Management
The project environment is not static. No matter what plans or baseline he establishes, Perry knows that he
will have to evaluate and implement changes. He also knows that change affects costs, schedule, quality, or a
combination of them. He is determined to manage change; otherwise, change will manage him and he can
quickly lose control.
Questions for Getting Started
1. If you decided to take corrective action, did you:
• Determine exactly what caused the need for corrective action?
• Determine the most appropriate corrective action and implement it?
• Receive input from the people affected by the corrective action?
• Set a “blockpoint” date for the corrective action to be implemented?
• Communicate the corrective action in advance?
• Seek feedback after the corrective action was implemented?
2. If replanning, did you:
• Determine what is the cause for replanning?
• Determine what areas (e.g., cost, schedule, quality) of the project are affected by the
replanning? The negative and positive impacts?
• Determine resource requirements and their availability for resource planning?
• Determine the data and information requirements for replanning?
• Obtain input from all of the people affected by the replanning?
• Obtain feedback from all the affected people once the new plans went into effect?
3. If doing contingency planning, did you:
• Determine and document the possible events using the risk assessment?
• For each event, determine and document the probability of occurrence, the projected impact,
and the appropriate response?
• Make sure the plans are readily available?
• Assign someone responsible for upkeeping and executing the contingency plan?
• Receive input from the people affected by the contingency plan?
• Obtain and assess relevant feedback from the individuals affected by the contingency plan after
it has been implemented?
4. Did you establish a change management infrastructure that includes a means for:
• Classifying changes?
• Prioritizing changes?
• Evaluating changes (e.g., change board)?
• Documenting changes?
• Tracking, monitoring, and addressing changes?
• Communicating changes?
• Following up on changes?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 18
Project Closure
All projects eventually end. Some end successfully, others end in disasters. Some common reasons why
-----------
projects end poorly are changing market conditions, lack of cooperation from clients, lack of management
support, lack of resources, politics, technical problems, and poor management. Exhibit 18-1 sums up the
management reasons for failure, while Exhibit 18-2 lists reasons for success.
Fortunately for Perry, the Smythe Project ended successfully: the wedding proceeded as planned, meeting all
milestone dates on time, consuming all monies within the budgeted amount, and giving the Smythe family
exactly what they wanted. Unlike other weddings, the team™s morale was extremely high up to the very end.
Despite overwhelming success, not everything worked perfectly. Some communications, coordination, and
implementation problems arose, and projects Perry handles in the future will benefit from what he learned.
Exhibit 18-1. Common reasons for project failure.
Leading Organizing
• Avoiding conflict • Lacking resources
• Burning out of team members • Lacking accurate knowledge and expertise
• Delaying decision making • Having unclear authorities and responsibilities
• Lacking cooperation
• Lacking customer involvement Controlling
• Lacking senior management support • Failing to deal with a changing environment
• Communicating poorly • Failing to manage change
• Setting unrealistic expectations • Overemphasizing on technology issues at expense of
business issues
Defining • Competing too much for resources
• Having ill-defined, too large, too small a scope
• Having incomplete or unclear requirements Closure
• Finding errors too late
Planning • Failing to learn from past problems
• No planning
• Poorly formulating plans
• Having unclear, unrealistic plans

Exhibit 18-2. Common reasons for project success.
Leading Organizing
• Having the support of senior management • Assigning responsibility for well-defined deliverables
• Obtaining customer involvement
• Maintaining realistic expectations • Having a good communication infrastructure in place
• Encouraging and sustaining a sense of owner
ship by all participants
• Having clear lines of authorities and responsibilities
• Having commitment and cooperation of all
participants
• Having a team with requisite knowledge and expertise
• Promoting integrity
Defining Controlling
• Chunking the project into manageable pieces • Having a documented change management in place
• Keep the scope well-defined
• Clear definition of requirements • Holding regular and frequent meetings
• Focus on customer • Avoiding scope “creep”
• Clear mission and objectives • Taking regular measurements of performance
Planning Closure
• Focusing evenly on technical and business • Releasing people correctly to minimize impacton morale
issues and performance
• Developing meaningful plans
• Having more frequent project milestones
• Having shorter flow time
• Simplifying



Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Learning From Past Experience
Title

Perry collects and compiles statistics from the project by using the project data repository. Mainly the
measurements used during the project, these data help Perry ascertain what did and did not go well. He plans
to include the information in a special document.
-----------
The lessons-learned document captures the successes, challenges, and other information of a project.
Managers of similar projects in the future can refer to what is in the document and, consequently, operate
more efficiently and effectively. The lessons-learned document not only communicates useful information to
future project managers, but also helps to identify their own strengths and weaknesses. But these advantages
can be realized only if the document is well prepared. The outline for a lessons-learned document is shown in
Exhibit 18-3. Many times, the document is poorly written, contains unsubstantiated claims and personal
grandstanding, and is filed in an inaccessible place. To ensure that these shortcomings do not appear, Perry
takes the following actions.
Exhibit 18-3. Outline for a lessons-learned document.
Lessons-Learned Document
I. Present title page, which includes:
A. Document title
B. Document number
C. Original release date
D. Appropriate signatures and date
II. Present table of contents, which includes:
A. Section headings
B. Relevant page numbers
III. Present introduction, which includes:
A. Goals
B. Scope
C. Objectives, like
• Technical
• Business
D. History/background information
IV. Present events, and what went right; what went wrong, and what was done; and what might have
been done otherwise, which include:
A. Activities
B. Critical items
C. Major milestone deliverables
D. Political actions
E. Roadblocks
V. Present summary, which includes a wrap-up of the project
1. He ensures that the data are useful. This task is easy since he has collected reliable, valid measures
throughout the project.
2. He identifies other sources of information. Since he collected and organized data throughout the
project, this action is easy. He especially uses the information in the project history files.
3. He assigns someone on the noncritical path to do the preliminary work for preparing the document.
This includes collecting documents and data, as well as preparing the draft. This approach allows Perry
to handle concurrent activities during project closure.
Information Systems Projects: A Lesson for Everyone
Although project failure appears in all industries, information systems (IS) projects seem to get special
attention. Their record of successes and failures has been referred to by some as a crapshoot.
It™s no surprise. The news is replete with examples of IS projects having disastrous results. The state of
Washington stopped developing a system that would process driver™s licenses and vehicle registration; the
project was several years behind schedule and millions of dollars over budget. California had even more
disastrous results while developing a large PC-based network”the project was millions of dollars over
budget and lasted over twelve years. And as with Washington, California had a Department of Motor
Vehicles project that blew its schedule and exceeded its budget. Then there is the Oregon Driver and Motor
Vehicle Services project, which has exceeded twice its original cost estimate.
Do not blame the public sector, however. The private sector has had its share of failures. The Xerox IS
project, called the Market to Collection Project, passed its scheduled completion date by two years and
exceeded its budget.
These examples may be more common than first realized. In the late 1980s, Capers Jones, president of
Software Productivity Research, revealed some sobering statistics about projects with more than 64,000
lines of code. He noted that less than 1 percent finished on time, within budget, and met all user
requirements. The “average” project was more than a year late and the cost was double the estimate.1
Almost seven years later, the Standish Group announced that IS development projects succeed only slightly
more than 1 percent”that is, finishing on time and within budget. If an organization is large, the success
rate drops.2
1“Software Productivity and Quality,” System Development, April 1987, pp. 1-6.
2“Few IS Projects Come in On Time, On Budget,” Computerworld, December 12, 1994.

What are the major contributors to such dismal results? According to the Center for Project management, 73
percent of the companies it surveyed had inadequately defined project plans. Less than 25 percent had
well-defined and practical project management processes.3
3“Pesky Projects,” Computerworld, April 11, 1994, p. 118.

4. He solicits input from project participants for ideas and information to include in the document. This
ensures a more objective and complete document. He has team members review the draft to preclude
any biased content.
5. He submits the document to senior management, whose responsibility is to ensure that it is not
forgotten and apply its contents to similar projects in the future.
Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Releasing People and Equipment
Title

At closure, Perry must release the people who have worked on the project. Releasing people is not simple. If
released inefficiently and ineffectively, morale problems can occur. If there™s a feeling of pending disaster,
people may depart prematurely and leave tasks unfinished.
-----------
Since it is a matrix environment, Perry knows that prematurely releasing people may mean losing them
permanently. So he reviews the responsibility matrices and schedule to determine the remaining work. He
then releases only those without work, since people sitting idle will in time interfere with the others™
productivity, spread rumors, or add unnecessary labor costs. Perry also ceases use of any unnecessary
equipment or facilities.

Recognizing and Rewarding People
No project is complete without recognition for outstanding performance. While conceptually simple, Perry
knows in reality its implementation is difficult. He must decide whether to reward individuals or the team or
both, what the most meaningful recognitions would be, and what rewards are within his power. These are
difficult to determine; still Perry follows some basic principles when giving recognition and rewards.
1. He strives for objectivity. He uses objective criteria for measuring results. It is hard to forget the past
or divorce yourself from the personalities of the individuals. The only way to avoid those circumstances
is to be as objective as possible.
2. He determines the values and behaviors he wants to reward. He rewards these values and behaviors
that best satisfy those of the company.
3. He remembers the expectancy theory. Expectancy theory states that successful performance depends
on people™s expectations of rewards, whether extrinsic or intrinsic. In other words, a person™s
expenditure of effort depends on his or her expectations of reward. If a person expects a financial
reward and receives a nonfinancial one, morale might fall and productivity decline.
4. He appears fair and consistent. If several people gave outstanding performances, he gives them
equal recognition and rewards. Even the appearance of being unfair or inconsistent can cheapen a
recognition or reward.
5. He is timely. He presents the recognitions and rewards within a reasonable time to gain maximum
motivational value. If he gives recognitions or rewards long after completing a milestone, for example,
they lose their meaning and impact.
6. He does not rely on monetary rewards. In fact, he avoids them. Money provides only short-term
satisfaction and can prove divisive, especially if a person feels shortchanged. He uses a variety of
nonfinancial rewards, from plaques to dinners to trips. For many project managers in a matrix
environment, such rewards may be all they are entitled to dispense.

Some Guidelines for Future Projects
Throughout the project, Perry kept a balance between the classical and the behavioral aspects of the project.
He knew that a detailed work structure or formal change control procedures are simply tools for completing
his project. In other words, they are the means to an end, not the end themselves. Using these tools requires
good judgment; therefore he was continually asking himself. Did the statement of work give a real portrayal
of what had to be done? Was the planning sufficient and could I have anticipated problems better? What
procedural changes would I make next time?
These are tough questions and often there are no definitive answers. Project managers must use their
judgment, which is based on their knowledge, experience, and expertise. Nevertheless, there are some general
guidelines that are useful for making good judgments.
1. The costlier the project, the more important it is that project management disciplines be in place. A
large monetary investment indicates a project™s level of importance”for example, a $1 million project
is more important than a $10,000 one. It makes sense, therefore, that the monies for the larger project
are all accounted for and justifiable. Project management disciplines help ensure that inefficiencies do
not occur.
2. The larger the project team, the more important it is that project management be used. Larger project
teams present greater challenges for coordination and communication. For example, a fifty-person
project is more difficult to coordinate than a five-person one.
3. The greater the complexity of the final product, the more important it is that management disciplines
are in place. For example, building a state-of-the-art information system is more complex than building
an outdoor shed. The former requires greater coordination of personnel and resources.
4. The longer the project, the more important it is that all procedures and schedules be in place. Along
with more time to complete a project is the tendency to overlook the need for good project
management. The “we™ll do it later” syndrome takes over and often results in key elements never being
implemented or implemented in a mad rush at the last minute. The project managers should identify
and implement as many elements as early as possible, before the project gains too much momentum.
5. The more ambiguity there is about a project™s scope, the more discipline needs to be imposed on the
project. The project manager must define the goal of the project and develop a path for achieving it. If
the project lacks clarity of purpose, then coordination, communication, and other key activities become
difficult, even impossible.
6. A lack of precedence requires that more discipline be in place. If a project of a similar nature has
never been done, then there™s a greater likelihood that management may be stymied. For example,
previous experience leads the way to greater efficiency and effectiveness.
7. The more dynamic the project environment, the more procedures and schedules should be in place.
If the environment is constantly in flux, then the project must be adaptable to change yet retain the
focus on the goal. Project management tools help achieve focus and adaptability by evaluating the
impact of changes as they appear.
The six functions of project management are critical to success; however the degree of application remains a
matter of judgment. These guidelines can help the project manager decide what tools and techniques should
be applied and to what degree. In the end, however, the project manager makes the decisions regarding
management of his or her project.

Questions for Getting Started

1. If collecting and compiling statistics, did you:
• Determine all the sources of information?
• Decide whether the data are reliable and valid?
• Determine what is required to make the data meaningful (if it is not)?
2. If preparing a lessons learned document, did you:
• Determine all the sources of information?
• Prepare an outline?
• Take steps to ensure its objectivity?
• Submit it to senior management or other people who might use the information in the future?
3. When releasing people, did you determine the criteria to identify who should remain and who should
be redeployed?
4. When releasing equipment, facilities, etc., did you determine the criteria to identify what should
remain and what should be redeployed?
5. When recognizing and rewarding people, did you:
• Determine whether to reward the entire team or select individuals or both?
• Seek to be objective?
• Appear fair and consistent?
• Determine what recognition and rewards approaches are available to you?
• Match the expectancy of recognition and reward with the type sought by the team or
individuals?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Part III
Project Management Enhancement
Chapter 19
-----------

Automated Project Management
Project management software can help you generate a project plan quickly, produce reports rapidly and
consistently, perform “what if” scenarios, identify inconsistencies with data, and reuse data from similar
projects. In short, today™s software can go quite far in helping project managers be more effective in their job.
Using project management software, despite its obvious benefits, presents some challenges, too. Some of
these challenges include getting people to understand the purpose of the programs; reducing the learning
curve; increasing people™s receptivity to the output; producing reliable information rather than garbage in,
garbage out; and ensuring that the software program supports the project and not that the project supports the
software. Of course, you must also have the right hardware, operating software, and utilities on hand; the
software must be available at a reasonable price; and the licensing agreements must be fair.
You can use project management software to calculate early and late dates for each task and to determine the
critical path. You also can use software to allocate resources and calculate costs. In addition, you can use
word processing software to draft the statement of work and a spreadsheet program to estimate the hours
needed to complete the project.
Today, automated project management is going through immense changes. In the past, the scope was fairly
narrow; software was used to build schedules and calculate costs. But the advent of local area networks, Web
technologies, and mobile computing have expanded the scope of automated project management dramatically.
Current”and future”applications will drastically change the way projects are completed and help ensure
their completion on time and within budget.
The discussion in this chapter visualizes the structure of present-day automated project management in the
form of a three-level pyramid, as shown in Exhibit 19-1.
Exhibit 19-1 Automated project management structure.

Personal Computing Systems
Building a program plan and doing risk assessment requires an automated project management package,
easiest on a personal computer. There are software packages at the minicomputer or mainframe level, but their
purchase or lease costs often are too high, the number of records insufficient, and the learning curve too long
for most limited-term projects. PC packages have the capabilities of larger systems but can be used at PC
level.
To choose a software package, consider your needs. A project manager might likely have the following
requirements:
Typical Software Needs and Wants
• Cover a large number of tasks.
• Assign multiple resources to a task and generate resource histograms for each resource and composite
ones.
• Build a project repository.
• Choose different types of network diagrams that provide multiple displays of information.
• Create bar charts for multiple levels of the work breakdown structure and have the ability to tailor
and custom-build.
What the Software Won™t Do
Many project managers, especially inexperienced ones, believe that the software makes or breaks a project.
Unfortunately, this belief is as unrealistic as the idea that a paintbrush makes a good painter or a pencil
makes a good writer.
Software is simply a tool to help you manage a project. It is an aid, an enabler”if you use it correctly. It
will help you make decisions. It will help you communicate with people. It will help you track performance
and take corrective action, if necessary.
The software, however, will not do these things for you. You must make the decisions. You must
communicate. You must take action to get back on track. In other words, you must provide the leadership to
bring a project in on time and within budget. It happens because of you, not because of the software.
Many project managers have a tendency to blame the tool when things go awry. That serves only as an
excuse for poor project management. After all, as an old saying goes, good carpenters never blame their
tools.
If this sounds like preaching, it is, and heed the warning. Many a project has failed despite the availability
and use of the best project management software tools.
• Define and change the logic relationships between tasks as well as the lag value for all network
diagrams.
• Detect logic errors in network diagrams and identify the problem.
• Establish a baseline, or target, schedule to measure against.
• Generate graphics (e.g., pie charts and Pareto diagrams) using data from the repository.
• Offer a common user interface that enables using other application packages easily.
• Perform “automatic” resource leveling.
• Perform “what if” scenarios to determine the impact of the cost and schedule milestones.
• Provide calendaring capabilities that can be modified to suit specific circumstances.
• Provide standardized reports and have ability to tailor and custom-build.
• Use with other well-known word processing, database, and spreadsheet programs.
Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Assign a value to each software need to reflect its relative priority, as shown in Exhibit 19-2. Then collect
Title
literature (e.g., sales brochures and magazine reviews), experiment with demos to see how well they satisfy
your needs, and interview subject matter experts. Finally, tally the results of your investigation and select the
best package based on the total score.
Exhibit 19-2. Sample software evaluation.
-----------

Package A Package B Package C
Calculated Calculated Calculated
(Weight — (Weight — (Weight —
Requirements Weight Value Value) Value Value) Value Value)
Build a project
repository 3 2 6 (3 — 2) 3 9(3 — 3) 1 3 (3 — 1)
Add level number of
tasks 2 3 6 3 6 2 4
Select different types
of network diagrams 1 2 2 2 2 1 1
Provide standardized
re-ports and ability to
modify each one 3 1 3 1 3 3 9
Establish baseline
schedule 3 2 6 1 3 3 9
Create and tailor bar
charts 1 1 1 2 2 3 3
Define and change
logic relationships 2 1 2 3 6 2 4
Assign multiple
resources to tasks 3 1 3 2 6 1 3
Perform automatic
re-source leveling 3 1 3 3 9 3 9
Grand Total 32 46 45

Remember that selecting the right package involves more than performing mechanical steps.
1. The agreement. Should you buy individual packages or multiple packages? If the latter, will you
receive a discount?
2. How easy is it to learn the package? Will the vendor provide basic training?
3. What type of support services are there? Is there a support line? Is there a charge for consultation? Is
it available 7 by 24, meaning seven days a week, twenty-four hours a day?
4. How long has the vendor been in business? If not long, what happens if it goes out of business after
you have invested in its product?
5. How well can the package be integrated with other popular applications and other projects (e.g.,
spreadsheets)? Will it require complex programming to share data?
6. How long is the learning curve? Will it help the team focus on the work rather than on satisfying the
needs of the software? In other words, is the software an enabler?
Once the package is selected and delivered, ensure that team members understand how to use the software and
provide the output. The need and level of understanding depends on the audience, of course. People working
directly on the project team (e.g., core team members) need a more detailed understanding of the capabilities
and outputs than senior management and the customer. Hence, tailor your presentation to reflect these
different needs.
Follow the same process when selecting risk management software. Identify the needs and wants in the
software package, find several popular packages, apply an objective approach to select the right software, and
ensure that people using the software are trained sufficiently. Some leading project management and risk
management software packages are shown in Exhibits 19-3 and 19-4.

Distributed Integrated System
Although there are excellent packages for project management, more often than not the computing
environment is distributed, whereby processing power is split among different levels in a systems
architecture. A distributed computing architecture is client/server. That is, some or all the application
processing may reside at the client, or PC, level, or be shared with a server, or be at a mini- or mainframe
computer level.
A typical scenario is for the project application software to reside on the client; the major processing and data
occur on the server. This architecture offers several advantages. First, users have a user-friendly interface
while simultaneously having access to considerably more power and data than on a PC. Second, hardware and
software cost less since the preliminary work is done at the client level. And third, data can be shared among
multiple users as well as provide uniform data management.
The client/server environment has substantially affected project management as a complementary or
supplementary tool for new technologies such as telecommuting, mobile computing, and groupware.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Telecommuting
Title

Increasingly, people work on projects via personal computers in their homes. They provide their services and
expertise electronically. Telecommuting reduces the need for office space, plus saves time and commuting
dollars for the individual. It allows people to accomplish more in less time, thanks to fewer interruptions and a
----------- flexible work schedule.
Project Management Methodologies
In some situations, projects can make use of a project management methodology, or PMM. Sometimes the
methodology is developed in-house; other times it is purchased from an outside firm. Whatever its origins, a
PMM offers several advantages. It provides a consistent, standardized approach for managing projects. It
sets the groundwork for compiling data. And it improves communications.
The PMM must be flexible in its application. It must also be documented and accessible, and it should be
supported via training and vendor assistance. Finally, it should present information clearly and concisely.
A PMM does not guarantee success; it takes leadership to get people to use the PMM. And this leadership
should come not from just the project manager but also from senior management. Commitment comes just
as much from the top as it does from the rank and file.
Some PMMs are stand-alone, meaning they™re not part of a much bigger methodology”for example, the
Practical Project Management Methodology (P2M2) by Practical Creative Solutions and KLR Consulting.
Other PMMs are part of a much bigger methodology, such as Productivity Plus (P+) by DMR, which is
oriented toward software development.

There are challenges to telecommuting, and many of them are financial. Telecommuters must have
technological tools, including a personal computer (e.g., laptop or workstation), software (e.g., terminal
emulation), modem, printer, pager, and cellular phone. They also need training and perhaps technical support
to resolve connections problems and answer advanced application quieries. Project managers must ensure that
telecommuters have the current software, from project management to word processing.
There are also potential performance problems. There is corruption and other degradations of data associated
with transferring data across telephone lines. Slow transmission speed can increase costs, requiring
installation of high bandwidth lines.
Exhibit 19-3. Leading project management software packages.

Package Description Contact
Primavera Project Planner A comprehensive planning and control Primavera Systems, Inc.
(copyright) package. It also provides e-mail and Web Two Bala Plaza
publishing functionality. Considered Bala Cynwyd, PA 19004-1586
useful for medium to large projects. (610) 667-8600
www.primavera.com
Results Management A suite of project management products, ABT Corporation
of which Project Workbench plays a key 361 Broadway
role. Project Workbench provides an New York, NY 10013-3998
extensive project planning and control (212) 219-8945
system. Considered useful for medium to www.abtcorp.com
large projects.
Microsoft Project for Windows A planning and controlling package that Microsoft Corporation
generates standard and tailorable charts One Microsoft Way
and reports. Microsoft Project for Redmond, WA 98052-6399
Windows works well with other Microsoft (425) 635-7155
products. Considered useful for small to www.msn.com
medium projects.
CA-Superproject A project management package that is Computer Associates
very resource driven and provides International, Inc.
extensive graphics and reporting One Computer Associates Plaza
capabilities. Considered useful for small to Islandia, NY 11788-7000
large projects. (800) 225-5224
www.cai.com
Project Scheduler 7 for A project management package noted for Scitor Corporation
Windows ease of use, resource handling capabilities, 333 Middlefield Road
and managing multiple projects. 2nd floor
Considered useful for small to large Menlo Park, CA 94025
projects. (800) 533-9876
www.scitor.com

Mobile Computing

Like telecommuting, mobile computing is a result of advances in client/ server technology. Project team
members can be on the road and still contribute to deliverables. It gives team members the flexibility to work
at different locations, and enables them to work at a remote location and still provide timely results.
Exhibit 19-4. Leading risk management software packages.

Package Description Contact
Monte Carlo for Primavera Risk analysis software that is used with Primavera Systems, Inc.
Primavera Project Planner. It enables Two Bala Plaza
determining the probabilities for Bala Cynwyd, PA 19004-1586
completing a project on schedule and (610) 667-8600
within budget. www.primavera.com
Rank-It Risk assessment software that enables Jerry Fitzgerald and Associates
applying precedence diagramming (not to 506 Barkentine Lane
be confused with precedence network Redwood City, CA 94065-1128
diagramming for schedules) for (415) 591-5676
identifying and ranking threats and //ourworld.compuserve.com/
processes and associated controls. homepages/jerardra
Risk + Risk analysis software to use with Program Management
Microsoft Project for Windows. It enables Solutions, Inc.
applying Monte Carlo simulation to 553 N. Pacific Coast Highway
determine the probability to complete Suite B-177
tasks. Redondo Beach, CA 90278
(805) 898-9571
www.prog-mgmt.com
Total Risk An integrated risk management package Redpoint Software, Inc.
for monitoring and controlling risk by One Cabot Road
creating a “virtual data warehouse.” Suite 190
Hudson, MA 01749
(508) 870-0070
www.rpsi.com



Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Of course, there are challenges to mobile computing. The costs can be high. A mobile computing workforce
Title
requires laptops, batteries, printers, software (e.g., applications, communications), CD-ROM attachments,
modems, adapters, docking stations, PCMCIA cards, and drivers.
There are other factors, too: skyrocketing communications costs, additional servers to handle demand,
training, and support to resolve technical problems. And there is the time and money to ensure the data
-----------
security and restrictive access to corporate networks.

Groupware Computing

Thanks to client/server architecture and the movement toward flatter organizational structures, groupware
computing enables the sharing of applications and data. Groupware is often not enterprise-wide; it is used
within a smaller organization, such as a department, work unit, or project. Its software components fall into
one of these categories:
• Electronic mail and messaging over a network
• Information sharing (e.g., document management)
• Personal and group calendaring and scheduling
• Real-time conferencing (e.g., electronic meetings)
• Workflow (e.g., automation of common business functions)
To function in a groupware environment, team members need microcomputers or workstations, servers,
cabling, network devices, and software (which often includes two or more categories). It requires a
commonality of software and data.
Groupware improves the communciation and distribution of information. It capitalizes on trends toward
decentralization of computing, using mid-range and personal computer-based computing. But groupware also
presents its challenges. Like telecommuting and mobile computing, it requires support personnel to resolve
technical difficulties and answer inquiries. There must be a substantial initial investment in hardware and
software, as well as upgrade efforts and training. All this increases project costs and adds to flow time.
Web Technology
The Internet is revolutionary technology that ties organizations and projects together. Many companies apply
Web technology in the form of intranets. The broad, primary difference between the Internet and an intranet
is that the latter uses a firewall, or server, to regulate or screen communications”hence, Internet technology
is used on a smaller, restricted basis.
The technology for using the Internet or an intranet is varied, but they share common requirements:
• Workstation and browser for each user
• Database servers
• Expertise in SQL (structured query language), HTML (hypertext markup language), CGI (common
gateway interface), Java, and a database management system (e.g., relational)
• Operating system at the workstation
• Protocols (such as HTTP, TCP/IP) for communications
Web technology is truly an enabler of projects. It gives people access to information that was once difficult to
obtain. It has tools (browsers, HTML [hypertext markup language], etc.) that are relatively easy to use and
piggyback on an existing communications network and client/server infrastructures. Finally, it furthers
communication through e-mail or conferencing at relatively low cost.
Web Site Design
The enthusiasm for Web technology has hit just about every organization. Even medium-size projects are
building their own Web sites. Quite often, the Web pages of these sites appear cluttered, confusing, and
irrelevant.
To develop a Web page for your project, ensure that it is clear, concise, consistent, relevant, and simple.
Your Web pages should:
• Follow a logical structure rather than appear as a hodgepodge of unrelated data.
• Have text free of spelling and grammatical errors.
• Keep hypertext and navigational links to a minimum and current.
• Use color sparingly to emphasize main points and draw attention.
• Use graphics, audio, and video to support the main focus of the site, not distract.
• Use language that is familiar to everyone; define acronyms and jargon.
• Use plenty of white space to increase readability and minimize bandwidth use.

Many projects establish Web sites. A Web site is what people inside and outside of the project access to send
or obtain information.
A project typically has one Web site for people access, which provides hypertext links to contents throughout
the site and navigational links to other pertinent sites. The information likely to be on a Web site is:
• Cost and time estimates
• Forms
• Lessons learned from previous projects
• Meeting schedules
• Memorandums
• Phone and contact listings
• Procedures
• Reports
• Risk assessment
• Schedules (bar and network)
• Statement of work
• Work breakdown structure
Taming the E-Mail Beast
In the past, it was not uncommon for project managers to find a pile of memorandums on their desks. Unless
they were masters at time management or could read quickly, they found themselves overwhelmed.
Today, the same challenge exists, except the memorandums are in electronic form. With the ease of using
e-mail, in many respects, the volume of memorandums has become worse.
To lessen the e-mail volume, emphasize that team members use “e-mail etiquette,” meaning:
1. Consolidate your messages to the receiver.
2. Ensure that the contents of the message move from major to minor points.
3. Include your name and/or organization on the message.
4. Keep the message to minimum length.
5. Ensure the receiver can print an attached file, if necessary.
6. Use good spelling and grammar.
To reduce the volume of e-mail you receive, you can:
• Distribute a style guide on e-mail and guidelines for everyone on the project.
• Establish a scheme for determining which messages are more important than others (e.g., topic or
person).
• Set aside some time during the day to address messages.
• Store messages for later reference onto a hard drive or floppy disk.



Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



In addition, the Web site can be the place to broadcast messages, enable access to databases, and distribute
Title
updates to application software.
Despite the advantages of Web technology, it can add to the overall cost of a project. There are several issues
the project manager needs to address.
1. Content management. Setting up a Web site is one thing; keeping it current is another. There must
-----------
be someone on the team to refresh the site to ensure that its content and links stay meaningful.
2. Security. Especially for highly proprietary projects, project managers must restrict access and take
measures to prevent a virus from being downloaded. Firewalls, password protection, and encryption are
some ways, but they can be costly.
3. Support. Unless someone already has expertise in Web-related areas (e.g., HTML, Java), then the
project manager must train someone or hire the necessary support.
4. Infrastructure. The right technological infrastructure must be in place to use Web technology,
including ways to author and deploy documents for the site, hardware with sufficient capacity (e.g.,
sufficient RAM, processing speed), and software for assessing data created by legacy systems.
5. Productive use. With technological power at their fingertips, team members can be tempted to surf
the Internet, which can result in nonproductive time and effort as well as access to unrelated data and
software. Project managers must provide standards and guidelines for using this technology, especially
on highly visible, politically sensitive projects.
6. Sufficient bandwidth. Web technology goes beyond accessing and transferring text. It involves using
static images, audio, video, and data, all of which use bandwidth and challenge the overall capacity of
the supporting network infrastructure. Insufficient bandwidth can result in problems like long response
time at peak periods of usage.
7. Copyright laws. Placing documents on a Web site may be all right if generated internally, but if the
documents have been developed by another organization, issues of fair use and ownership arise.
8. User confidence. Although a key attraction of Web technology is its ease of use, many team
members find themselves gun-shy and may experience longer than usual learning curves. Training can
help resolve this issue.
The project manager needs to define his requirements upfront, look at the existing technological and
knowledge capabilities of his team members, and establish an infrastructure before deciding whether to take
advantage of Web technology.

Videoconferencing
Videoconferencing once could occur only in a large facility equipped with a vast array of electronic gadgetry.
Today, with powerful personal computers and digital networking, videoconferencing takes place on a much
smaller scale. Many projects, especially ones with team members spread over a wide geographical area, are
increasingly using videoconferencing.
Videoconferencing offers many advantages. It encourages collaboration and communication, and encourages
real-time planning rather than relying on passive media like documentation and e-mail. Some major
capabilities of PC-based videoconferencing include:
• Multipoint conferencing and point-to-point conferencing
• Providing system diagnostics
• Setting up address books
• Sharing applications
• Transferring files
• Whiteboarding (e.g., electronic diagramming)
However, several challenges remain. The technology is immature, reflected in often blurry, ghostlike, and
jerky images. The sound often is not synchronized with the image. Other times, there are incompatibilities
between points owing to protocol differences. Sometimes, too, the transmission slows dramatically during
high usage periods, causing competition for bandwidth. Finally, preparing for videoconferencing can be
costly; the start-up costs alone can be up to three to four times the cost of a workstation.
To get started in videoconferencing, project managers should have a fully configured setup at a sending and
receiving site. The technology then includes:
• Additional microcomputers for multiple-site conferences to manage interaction
• Audio board supporting speaking and listening
• Cabling
• Digital camera
• Microcomputer, preferably a Pentium
• Microphone for group interaction; headset for individual interaction
• Modem for phone lines
• Software that provides control settings for audio and video quality; supports standard protocols (e.g.,
H.320 for ISDN [Integrated Services Digital Network] and H.324 for Plain Old Telephone Service
[POTS]); and, sharing applications, transferring data, and white-boarding
• Videoboard

Project Automation: Recognizing the Limitations
A technological tool like a software package can make managing a project easier and the manager more
efficient and effective. However, its use does not guarantee success. Numerous projects have failed although
armed with top-notch software. Perry recognizes that a tool does not lead; nor does it define, plan, organize,
control, or close a project. People like Perry, and not some silver bullet, do that. Perry realizes, however, that
using the right software or other tool”and using it right”helps clear the path to a successful project
outcome, and so he selects such tools carefully.

Questions for Getting Started

1. If looking for a project management software package, did you:
• Define your requirements?
• Determine how you will go about selecting the package?
• Consider value-added issues like vendor support? Training? Warranties?
2. If looking for a risk management software package, did you:
• Define your requirements?
• Determine how you will go about selecting the package?
• Determine the type of risk analysis and assessment approach to take?
• Consider value-added issues like vendor support? Training? Warranties?
3. If you are working in a client/server environment, did you:
• Determine the necessary hardware and software requirements?
• Determine the necessary level of technical support?
• Determine how to deal with issues related to hardware and software performance?
4. If team members are telecommuting, did you:
• Determine the necessary hardware and software requirements?
• Determine the necessary level of technical support?
• Determine how to deal with issues related to hardware and software performance?
5. If team members are using mobile computing, did you:
• Determine the necessary hardware and software requirements?
• Determine the necessary level of technical support?
• Determine how to deal with issues of data backup and recovery? Security? Compatibility of
hardware and software as well as distributing upgrades?
6. If team members are using groupware computing, did you:
• Determine the necessary hardware and software requirements?
• Determine the necessary level of technical support?
• Determine ways to overcome hardware and software compatibility and upgrade problems?
7. If team members are using Web technology, did you:
• Determine the necessary hardware and software requirements?
• Elect to set up a Web site and determine its layout and contents?
• Determine what ways to use Web technology (e.g., broadcast messages, access databases)?
• Determine the necessary level of technical support?
8. If team members are using PC-based videoconferencing, did you:
• Determine the necessary hardware and software requirements?
• Determine the necessary level of technical support?
• Determine the desired uses of the technology (e.g., sharing applications, whiteboarding)?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Appendix
Case Study Work Breakdown Structure
1.0 Parties
-----------
1.1 Bachelor Party
1.1.1 Location
1.1.1.1 Determine location
1.1.1.2 Arrange for facilities
1.1.2 Entertainment/Music
1.1.2.1 Determine type of entertainment/music
1.1.2.2 Arrange for entertainment/music
1.1.3 Food/Beverage
1.1.3.1 Determine type of food/beverage
1.1.3.2 Arrange for food/beverage
1.1.4 Party
1.1.4.1 Conduct bachelor party
1.2 Bridal Shower
1.2.1 Location
1.2.1.1 Determine location
1.2.1.2 Arrange for facilities
1.2.2 Entertainment/Music
1.2.2.1 Determine type of entertainment/music
1.2.2.2 Arrange for entertainment/music
1.2.3 Food/Beverage
1.2.3.1 Determine type of food/beverage
1.2.3.2 Arrange for food/beverage
1.2.4 Party
1.2.4.1 Conduct bridal party
1.3 Reception
1.3.1 Location
1.3.1.1 Determine location
1.3.1.2 Arrange for facilities
1.3.2 Entertainment/Music
1.3.2.1 Determine type of entertainment/music
1.3.2.2 Arrange for entertainment/music
1.3.3 Food/Beverage
1.3.3.1 Determine type of food/beverage
1.3.3.2 Arrange for food/beverage
1.3.4 Reception
1.3.4.1 Conduct reception

2.0 Stationery
2.1 Invitations
2.1.1 Bachelor party
2.1.1.1 Determine whom to invite
2.1.1.2 Select type of invitation
2.1.1.3 Mail invitations
2.1.2 Bridal shower
2.1.2.1 Determine whom to invite
2.1.2.2 Select type of invitation
2.1.2.3 Mail invitations
2.1.3 Reception
2.1.3.1 Determine whom to invite
2.1.3.2 Select type of invitation
2.1.3.3 Mail invitations
2.1.4 Wedding
2.1.4.1 Determine whom to invite
2.1.4.2 Select type of invitation
2.1.4.3 Mail invitations
2.2 Announcement of Engagement
2.2.1 Select whom to contact (e.g., newspaper)
2.2.2 Prepare announcement
2.2.3 Mail announcement to newspapers
2.3 Thank you cards
2.3.1 Mail thank you cards for bachelor party
2.3.2 Mail thank you cards for bridal shower
2.3.3 Mail thank you cards for reception
2.3.4 Mail thank you cards for wedding

3.0 Photography/Videography
3.1 Engagement participants
3.1.1 Determine portfolio
3.1.2 Arrange for photographer
3.1.3 Arrange for videographer
3.2 Wedding portraits
3.2.1 Determine portfolio
3.2.2 Arrange for photographer
3.2.3 Arrange for videographer
3.3 Bachelor party
3.3.1 Arrange for photographer
3.3.2 Arrange for videographer
3.4 Bridal shower
3.4.1 Arrange for photographer
3.4.2 Arrange for videographer

4.0 Gifts and Favors
4.1 Bachelor party
4.1.1 Collect gifts
4.1.2 Safeguard gifts
4.1.3 Determine favors
4.1.4 Distribute favors
4.2 Bridal shower
4.2.1 Collect gifts
4.2.2 Safeguard gifts
4.2.3 Determine favors
4.2.4 Distribute favors
4.3 Reception
4.3.1 Collect gifts
4.3.2 Safeguard gifts
4.3.3 Determine favors
4.3.4 Distribute favors

5.0 Attire
5.1 Bride
5.1.1 Gown
5.1.1.1 Select gown
5.1.1.2 Tailor gown
5.1.2 Headpiece
5.1.2.1 Select headpiece
5.1.2.2 Fit headpiece
5.1.3 Veil
5.1.3.1 Select veil
5.1.3.2 Fit veil
5.1.4 Hairstyle
5.1.4.1 Select hairstyle
5.1.4.2 Coordinate with hairstylist
5.1.5 Makeup
5.1.5.1 Determine cosmetic requirements
5.1.5.2 Coordinate with cosmetician
5.2 Groom
5.2.1 Tuxedo
5.2.1.1 Select tuxedo
5.2.1.2 Tailor tuxedo
6.0 Transportation
6.1 Wedding
6.1.1 Bride and groom
6.1.1.1 Identify limousine service to church
6.1.1.2 Coordinate limousine service to church
6.1.1.3 Identify limousine service to reception
6.1.1.4 Coordinate limousine service to reception
6.1.2 Guests
6.1.2.1 Determine transportation requirements to church
6.1.2.2 Coordinate transportation to church
6.1.2.3 Determine transportation requirements to and from reception
6.1.2.4 Coordinate transportation requirements to and from reception
6.1.2.5 Arrange for valet service for church
6.1.2.6 Arrange for valet service for reception

7.0 Fees
7.1 Church service
7.1.1 Pay for church service
7.2 Parking
7.2.1 Pay parking fees for wedding
7.2.2 Pay parking fees for reception

8.0 Flowers
8.1 Wedding
8.1.1 Determine floral requirements
8.1.2 Coordinate floral delivery
8.1.3 Pay florist
8.2 Reception
8.2.1 Determine floral requirements
8.2.2 Coordinate floral delivery
8.2.3 Pay florist

9.0 Honeymoon
9.1 Determine location for honeymoon
9.2 Arrange for transportation to honeymoon location
9.3 Arrange lodging for honeymooners
9.4 Develop itinerary for honeymooners
9.5 Depart for honeymoon

10.0 Guests
10.1 Develop guest list
10.2 Coordinate lodging
10.3 Coordinate transportation (ground and air)
10.4 Arrange for food and beverages
10.5 Send letter of contact regarding services

11.0 Flowers
11.1 License
11.1.1 Prepare wedding license
11.1.2 Coordinate with civil authorities
11.2 Registry
11.2.1 Set up registry at church

12.0 Rings
12.1 Engagement ring
12.1.1 Determine requirements from bride
12.1.2 Determine requirements from groom
12.1.3 Coordinate with jeweler
12.1.4 Deliver ring to bride
12.2 Wedding ring
12.2.1 Determine requirements from bride
12.2.2 Determine requirements from groom
12.2.3 Coordinate with jeweler
12.2.4 Deliver ring to bride
12.2.5 Deliver ring to groom

13.0 Lighting
13.1 Wedding
13.1.1 Determine lighting requirements at church
13.1.2 Coordinate lighting requirements at church
13.1.3 Install lighting at church
13.2 Reception
13.2.1 Determine lighting requirements
13.2.2 Coordinate lighting requirements
13.2.3 Install lighting

14.0 Rules
14.1 Wedding
14.1.1 Identify bridesmaids
14.1.2 Identify best man
14.1.3 Identify maid of honor
14.1.4 Identify flower girls
14.1.5 Identify ring bearers
14.1.6 Identify ushers
14.2 Reception
14.2.1 Identify who will be in receiving line
14.2.2 Identify who will toast the newlyweds

15.0 Decorations
15.1 Wedding
15.1.1 Determine decoration requirements for church
15.1.2 Coordinate set up of decorations at church
15.1.3 Set up decorations at church
15.2 Reception
15.2.1 Determine decoration requirements at reception area
15.2.2 Coordinate set up of decorations at reception area
15.2.3 Set up decorations at reception area

16.0 Food/Beverages
16.1 Reception
16.1.1 Determine food requirements
16.1.2 Coordinate food delivery
16.1.3 Coordinate serving of food
16.1.4 Determine alcoholic and nonalcoholic beverages
16.1.5 Coordinate beverage delivery
16.1.6 Coordinate serving of beverages

17.0 Church
17.1 Contact church of choice regarding date, time, and number of attendees
17.2 Coordinate with church specific requirements regarding service
17.3 Conduct wedding

18.0 Cake
18.1 Determine requirements for cake
18.2 Submit requirements to bakery
18.3 Arrange for delivery of cake to reception area
18.4 Coordinate serving of cake

19.0 Rehearsals
19.1 Wedding
19.1.1 Coordinate with church the date and time of rehearsals
19.1.2 Coordinate with wedding party the date and time of rehearsals
19.1.3 Conduct first wedding rehearsal
19.1.4 Conduct second wedding rehearsal
19.2 Reception
19.2.1 Coordinate with reception area owner the date and time of rehearsals
19.2.2 Coordinate with receiving line and toaster the date and time of rehearsals
19.2.3 Conduct first reception rehearsal
19.2.4 Conduct second reception rehearsal


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Glossary of Project Management Terms
active listening
Genuinely hearing what the speaker says.
-----------
actual cost of work performed (ACWP)
The actual costs accrued for one or more tasks up to a specific point in time.
arrow diagram
A charting approach that uses nodes to represent events and arrows to describe the task between the
nodes.
assessing status
Determining how well the project has and will achieve its goals and objectives.
backward pass
Using the durations and dependencies in a network diagram, and moving from right to left through a
network diagram, beginning with the very last task, to calculate the late start and finish dates.
bar or Gantt chart
A charting approach that displays a list of tasks and, for each one, an accompanying bar to reflect the
flow time or duration.
baseline
Agreed-upon points of reference. In a project environment, baselines are set for schedule, budget, and
quality.
body language
The physical movements that account for 70 to 90 percent of our conversation (e.g., facial expressions,
body movements, posture, and eye movements).
budgeted cost for work performed (BCWP)
The estimated value of the work completed up to a specific point in time.
budgeted cost for work scheduled (BCWS)
The estimated value of the work scheduled.
burdened labor rates
Rates that include the cost of fringe benefits (e.g., insurance, floor space, nonlabor overhead).
cause and effect diagram
A charting approach to identify the cause of a problem by identifying the interrelationships among the
four M™s: machines, manpower, materials, and methods.
change, corrective
Revisions that are nice to have but unnecessary.
change, high-priority
Revisions that demand immediate attention.
change, low-priority
Revisions that are addressed, if time permits.
change, major
Revisions that dramatically affect schedule, cost, or quality.
change, medium-priority
Revisions that do not require immediate attention.
change, minor
Revisions that do not fit in the major change category.
change board
The people responsible for classifying and prioritizing changes.
checkpoint review
A type of session held at specific times, usually after a red-letter date or significant event (e.g.,
completion of a major milestone).
checksheet
Document that records the frequency distribution of a number of incidents.
client/server environment
A computing architecture where some or all application processing may reside at the client (e.g.,
microcomputer level) or be shared with a server (e.g., mini- or mainframe computer level).
closing
A function of project management that involves compiling statistics, releasing people, and preparing
lessons learned. component A basic element of a system.
concept phase
The first phase of the project cycle. During this phase, the idea of a project arises and preliminary cost
and schedule estimates are developed at a high level to determine if the project is technically and
economically feasible.
constraint date
The time mandating that a task may have to begin or finish on or by a specific date.
contingency planning
Tentative responses to situations that have a good probability of occurrence and could impact project
performance.
control (n.)
A measure in place to mitigate, prevent, or correct the impact of a threat.
control chart
A diagram that identifies normal and anomalous situations ” specifically a variance from an average.
controlling
The function of project management that assesses how well a project meets its goals and objectives. It
involves collecting and assessing status, managing changes to baselines, and responding to
circumstances that can negatively impact project performance.
corrective action
Steps taken to get the project back on track.
cost variance
The difference between budgeted and actual costs.
critical path
One or more paths through the network diagram with tasks having zero float.
data flow
A diagramming technique showing the flow of data through a system.
defining
The function of project management that determines exactly the purpose and boundaries of a project. It
involves determining the overall vision, goals, objectives, scope, responsibilities, and deliverables of a
project.
delegating
Having a person act on behalf of another individual.
direct costs
Charges directly related to the building of a product (e.g., materials and specialized labor).
dissatisfier
Psychological desire that if not satisfied will negatively impact motivation.
distributed computing
A computing environment where processing power is split among different levels in systems
architecture.
diversity
A work environment tolerating a variety of backgrounds, including race, nationality, ethnicity, and
religion.
duration
The flow time of a task.
early finish date
The earliest time a task can be completed.
earned value
The integration of cost and schedule to determine the level of progress.
effectiveness
Whether a project is achieving its goals and objectives.
efficiency
Whether a project is consuming more or fewer resources than expected.
expectancy theory
Successful performance depends on the expectations of rewards, whether extrinsic or intrinsic, that a
person has.
expected time
Using the most likely, most optimistic, and most pessimistic variables to calculate the time anticipated
to complete a task.
feedback loop
The flow of information between the project manager, team members, the customer, and senior
management.
finish-to-finish dependency
The relationship between tasks whereby they must finish around the same time.
finish-to-start dependency
The relationship between tasks whereby an earlier activity, or predecessor, completes before the next
one, or successor, can begin.
fixed cost
Unalterable charge owing to changes in work volume (e.g., cost of facilities usage).
float, free
The time that an activity can slide without impacting the start date of its successor. Tasks with free float
appear on the noncritical path.
float, total
The time that an activity can slide without impacting the project completion date.
flowchart
Pictures and diagrams used for displaying processes and procedures.
form
Document that captures and communicates information; useful for providing audit trails.
formulation phase
A time in a project cycle when complete project plans are developed, which include a statement of
work, work breakdown structure, and schedule.
forward pass
Using durations and dependencies in a network diagram and moving from left to right through a
network diagram, beginning with the very first task to calculate the early start and finish dates.
Gantt chart
See bar chart.
global efficiency factor (GEF)
estimate A technique that incorporates nonproductive time into an estimate.
groupware computing
A computing environment allowing the sharing of applications and data.
hierarchy of needs
A psychological model of motivation developed by Abraham Maslow. It identifies people™s needs
according to this hierarchical order: physiological (food), safety (shelter), social (acceptance), esteem
(sense of importance), and self-actualization (becoming).
histogram
A graphical depiction of resources being or that have been utilized. The high points are called peaks
and low points are called valleys.
histogram, leveled
A histogram with the extreme peaks and valleys smoothed out.
histogram, unleveled
A histogram with an irregular shape, consisting of many peaks and valleys.
implementation phase
A time in a project cycle when the execution of the plan achieves the goals and objectives.
indirect cost
Charge not necessarily related to the building of a product (e.g., rent and taxes).
installation phase
A time in a project cycle when the final product is delivered to the customer.
Internet technology
Electronic technology that ties together communities throughout an organization.
intranet
Basically the same computing technology as that used to operate the Internet. The primary difference
between the two is that an intranet uses a firewall, or server, to regulate or screen communications.
item-by-item format procedure
Procedural documentation that contains a mixture of topics.
job enlargement
Increasing the number of tasks and responsibilities to perform on a job.
job enrichment
Structuring or assigning tasks and responsibilities to give a person the opportunity to actualize.
job rotation
Moving a person from one job to another to increase his overall awareness or exposure.
key project indicator (KPI)
Element of a project that contributes to its successful completion.
lag
The gap between the end of one task and the start of another.
late finish date
The latest time a task can be completed.
late start date
The latest time a task can begin.
leading
The only function of project management that simultaneously occurs when executing the other five
functions. It involves inspiring people to accomplish goals and objectives at a level that meets or
exceeds expectations.
lessons learned document
A medium for capturing the successes, challenges, and other information of a project.
maintenance factor
A dissatisfier, meaning that if not present to a sufficient degree, it will negatively impact motivation.
management estimate at completion (MEAC)
A combination of actual expenditures to date plus the remaining estimate to complete the project.
management reserve
A fund set aside to address unexpected costs, usually 3 to 5 percent of the total estimate for the project.
managerial level
The detail that is “rolled up” to higher levels for reporting purposes, usually the higher levels in the
work breakdown structure.
matrix structure
Resources from functional organizations that are shared with other projects.
mean
The average of the values for items in a group of data.
median
A position average at the midpoint for a frequency distribution.
meeting, ad hoc
A type of meeting that is held irregularly, often spontaneously, by team members.
meeting, staff
A type of session that is held regularly. All team members meet to receive information from the project
manager and to share additional data and insights.
memo
A brief document that should contain a date, subject title, addressee, signature block, purpose
statement; it should also answer the who, what, when, where, and why of a subject.
metrics
Tools and techniques to determine standards and track against them.
metrics, qualitative
Intangible, noncalibrated measures that are subjective.
metrics, quantitative
Tangible, calibrated measures that are objective.
Michigan studies
Management research that revealed two types of supervisory styles that can affect motivation:
production and employee centered.
milestone chart
The outlay on a Gantt chart that shows an icon or symbol for the occurrence of an event rather than a
bar for durations.
mobile computing
An information systems environment that enables team members to work at remote locations and
provide timely results.
mode
The value that appears most frequently in a series of numbers.
monitoring
Projecting into the future using past performance.
most likely estimate
The effort (usually in hours) to complete a task under normal or reasonable conditions.
most optimistic estimate
The effort to complete a task under the best or ideal circumstances.

<<

. 5
( 6)



>>