<< . .

. 16
( : 22)



. . >>




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

<< . .

. 16
( : 22)



. . >>