<<

. 3
( 6)



>>

smoothing it out is called level loading. Of course, a histogram is rarely flat.

4. Adjust the Schedule or Pursue Alternatives
Perry can level his histogram in several ways. He can change the logic of the schedule so that the number of
concurrent activities someone is as. signed is less. He can change the relationship between two activities (e.g.,
change a start-to-start relationship to a finish-to-start one) or add lag between the two activities to reduce
concurrency. He can also reduce the float of noncritical activities by lengthening their duration without
changing the total hours of effort. Finally, he can reduce the output from certain tasks, thereby leveling the
work.
When it becomes impossible to alter the schedule, then Perry can rearrange assignments to lower the working
hours per day or employ an alternative person, such as a consultant or contract employee (see “Consultants
and Outsources,” below).
Exhibit 9-2. Leveled histogram.
Overtime and Burnout
On many projects, especially ones where meeting the completion date is critical, overtime is the norm rather
than the rule. Periodic overtime is fine, but if taken to the extreme, it can have long-term effects on team
members and influence overall performance on the project.
From a behavioral perspective, extensive overtime can result in burnout, which is a common condition in
the information systems world. Burnout can lead to omissions, rework, and scrapped work, all contributing
to lower productivity. From a schedule, cost, and quality perspective, excessive overtime has an effect, too.
People™s performance becomes impaired.
Too much overtime is symptomatic of major project management problems. There may be an unrealistic
schedule, a management-by-crisis situation, poorly trained people, inadequate equipment or facilities, low
morale, or lack of teamwork. If excessive overtime becomes the norm, serious replanning is required.
To avoid overtime problems, level the major peaks in the histogram.

Exhibit 9-3. Work assignments.

Task No. Description Duration (Days) Assigned to Hours/Day

6.1.1.1 Identify limousine service to church 3 Ewing 8

6.1.1.2 Coordinate limousine service to church 1 Ewing 8

6.1.1.3 Identify limousine service to reception 3 Ewing 8

6.1.1.4 Coordinate limousine service to reception 1 Eisenberg 8

6.1.2.1 Determine transportation requirements to 3 Ewing 8
church

6.1.2.2 Coordinate transportation to church 1 Eisenburg 8

6.1.2.3 Determine transportation requirements to 2 Ewing 8
and from reception

6.1.2.4 Coordinate transportation to and from 1 Eisenberg 8
reception

6.1.2.5 Arrange for valet service for church 1 Smith 8

6.1.2.6 Arrange for valet service for reception 1 Smith 8



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



How Perry Levels the Load
Title

Perry develops a histogram for tasks related to transportation (6.0 in the work breakdown structure). He
notices that the histogram for Ewing has high peaks in the beginning and a sharp drop several days later.
Exhibit 9-3 shows the assignments of everyone to this task, Exhibit 9-4 shows the original histogram for
----------- Ewing, and Exhibit 9-5 shows that portion of the network diagram related to transportation.
Perry figures he has several options:
1. Switch the start-to-start relationship to finish-to-start for tasks 6.1.1.3 or 6.1.2.3, or both with
6.1.1.1.
2. Double the duration but not the work effort (hours) for 6.1.1.2, which is a noncritical-path task.
3. Replace Ewing on certain concurrent tasks (e.g., 6.1.1.1, 6.1.1.3, or 6.1.2.3, or both) with additional
help (e.g., consultant, contractor, or outsource). This will reduce the peak for Ewing.
4. Change the precedence relationships between tasks.
After making the changes to the assignments and changing the precedence relationships (see Exhibit 9-6), he
generates a leveled histogram for Ewing (see Exhibit 9-7).

Consultants and Outsources

Consultants
From time to time, project managers will not have sufficient labor resources to complete their projects. A
solution is to hire consultants.
But hiring consultants should not be done lightly, since their services can prove expensive and the quality of
their output is often debatable.
Take the following steps when hiring consultants.
1. Know exactly what you expect from the consultant. Is it a deliverable product? Is it a document or
just “advice” in oral form?
2. Look at several consultants rather than one as a sole source. Reliance on one consultant increases
dependency.
Exhibit 9-4. Unleveled histogram for Ewing.




Exhibit 9-5. Network diagram (portion for transportation).
3. Conduct a background investigation. Who is on their client list? How satisfied are the clients with
their work? What is their reputability in performing that type of work?
4. Monitor the performance. Expect periodic reviews to preclude the unexpected lack of delivery. Have
those reviews documented to prevent legal problems regarding the quality of output.
5. Include the tasks of consultants in the work breakdown structure and on the schedule. If
nonperformance occurs, it is easier to show the impact on the overall progress of the project, at least
from a schedule and cost perspective.
6. Ensure that the terms and conditions of an agreement exactly describe the deliverable. Don™t rely on
general statements, which can eventually lead to disagreements that can only be resolved in the courts.




Exhibit 9-6. Network diagram with logic change.

Outsourcing Services
An alternative to using consultants is outsourcing, by which an independent vendor provides a service and
assumes responsibility for the results. For example, a project manager might outsource the development and
delivery of a deliverable or component of the product being built.
Outsourcing has its advantages. It can help shift the development of difficult, complex deliverables to
expertise that does not exist on the team. It can shift nonessential deliverables to outside vendors so that the
team can focus on critical matters. Finally, it can allow for flexibility in responding to a fast-paced
environment, since less is invested in a project infrastructure and the outsourcing can be canceled without
investing too much.
Outsourcing has its disadvantages, too. The potential for losing control may be high. The work can cost more
initially. And it takes time to find a reliable outsourcing vendor.
To ensure that you make a good outsourcing decision:
1. Do an analysis to determine if outsourcing is a better option than having the team do the work.
2. Select from several outsourcing vendors. Compare each one, not just on a cost basis but also on
reputability of work and service.
3. Identify what is too critical to outsource. A bad outsourcing decision can have disastrous results on
the entire project.
4. Identify what you can outsource. Often, these are services or deliverables not essential to the
outcome of the project.
5. If outsourcing something critical, then ensure that reviews and audits are stipulated in the contract.
Actually, the rights for reviews and audits should be incorporated in the contract as a general rule, but
especially for critical services or deliverables.
Exhibit 9-7. Leveled histogram for Ewing.
Accelerated Projects
It™s called fast-tracking. It is building a product or delivering a service in a very short period of time, usually
undertaken for a time-to-market circumstance in an emergency. Information system projects that must
deliver an application under market pressure quite commonly fit this category.
People on accelerated projects work at a feverish pace for a short time. There are usually several concurrent
activities.
Fast-tracking works best when the project has a previous history, the team members are highly skilled and
have previous experience, and the opportunity for reuse exists. The emphasis is on getting results quickly
and correctly. Little time is available for experimentation, even creativity.
The downside to fast-tracking is burnout. While the focus on results does provide opportunities for effective
teaming, failures can be magnified and lead to finger pointing. Fast-tracking also requires constant training
and retraining so people can perform quickly.
Fast-tracking accelerates the life of a project. In exchange for speedy delivery, however, it can have
long-term negative consequences.

Summing Up Resource Allocation

The principles of resource allocation apply to inanimate objects such as desks and supplies no less than to
people. In either case allocating resources requires identifying the tasks, making assignments, building
profiles, and making adjustments to satisfy requirements. There is, however, one major difference. When
doing people allocation, Perry must be sensitive to their psychological needs (e.g., feelings, values), which, of
course, is not necessary for inanimate objects. This psychological factor becomes especially important not
only when Perry assigns tasks but also when he starts to organize his team to efficiently and effectively
achieve the goals of the project.

Questions for Getting Started
1. Did you identify the tasks to allocate your resources?
2. Do you know all the different types of resources you will need?
3. Is there a resource pool where you can get all the resources you need? If not, will you need
consultants? Will you need to out-source?
4. Did you assign people to all the tasks?
5. Did you run a resource histogram for each person?
6. Did you need to or attempt to level each of the histograms?
7. When you assign people to tasks, do you consider behavioral as well as technical factors?
8. If you use consultants or outsourcing, did you perform a background analysis first?
9. If overtime appears in the histograms, is it constant or sporadic? If the former, what steps are you
willing to take to deal with the effects of burnout?


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 10
Team Organization
Over the years, Perry has seen the symptoms of poor team organization. Some projects have too many leaders,
-----------
leaving only a few people to do the work and making coordination difficult. Other projects have too many
layers of management, impeding effective communication; team members become frustrated, waiting for all
the leaders to reach agreement or gain approvals. To augment frustration levels, tasks frequently are unclear,
lacking definitions of roles and responsibilities.
Good organization makes sense; yet project managers often give too little attention to organizing their group.
Frequently, teams are an assembly of people and nothing more. Some project managers fear alienating people
by setting up a project organization. Others lack an appreciation for its contribution to project success. Still
others have a preference for an unofficial organizational structure.
Through the function of organization, Perry can realize many advantages. His team can operate more
efficiently, since responsibilities and reporting relationships will be clearly defined. It can operate more
effectively, because each person will know what is expected of him or her. The team has higher morale,
because roles and reporting relationships will be clear ” which in turn reduces the opportunities for conflict.

Ten Prerequisites for Effective Organization
Perry must satisfy some preliminary requirements to build a formal organization, especially one that handles
medium to large projects like his:
1. He must know the project goals. This knowledge will help to determine how to best arrange his
resources.
2. He must know all the players. This knowledge will help him to determine who will support him
directly and who will provide ad hoc support.
3. He must understand the political climate. Although the team may be temporary, the project may be
around for a long time.
4. He must receive preliminary concurrence on the project organization from all the major players
(e.g., senior management, customers).
5. He must determine the appropriate span of control. This means determining how many people he
can effectively manage before establishing an additional layer of management (e.g., appointing team
leaders).
6. He must publish the organization chart as early as possible. This action will clarify roles early and
reduce the opportunity for conflict. It will also make assigning responsibilities easier.
7. He must consider how much autonomy to grant people on the project. This will depend on how
much control he wants to maintain. If he wants tight control, he will limit the autonomy he grants to
project participants.
8. He must consider issues of authority, responsibility, and accountability. How much authority will he
have and how much can he grant? How much responsibility can he relinquish and still be accountable
for the results?
9. He must consider how to group the functions of the project team. Should he mix them or segregate
them? If the latter, how will he encourage information sharing, communication, and teaming?
10. He must identify the line and staff functions. The goal of the project will help determine the
positions. Line functions contribute directly to the results; these are typically people on the core team.
Staff functions do not contribute directly to the results and ordinarily they are not part of the core team.

Types of Organizational Structure
There are two basic types of organizational structures for a project: task force and matrix. The task force
structure is shown in Exhibit 10-1.
The task force is a group of people assembled to complete a specific goal. The team is completely focused on
that goal and, consequently, devotes its entire energies to its accomplishment. By its very nature, task forces
are temporary; the team is disassembled once the goal is accomplished. It also usually operates autonomously,
with its own budget and authority.
The task force has the advantage of giving visibility to a project. It isolates team members from organizational
myopia and frees them from daily administrivia. It enables creativity and experimentation within the confines
of the goal and scope of the project.
Despite these advantages, Perry does not like the task force structure, at least for the Smythe Project. Since a
task force would last for only a fixed duration, there™s a danger that few people would have loyalty to the
project and stay the course. As the project experiences difficulties, some people might depart early, leaving it
vulnerable to schedule slippages and lapses in quality.




Exhibit 10-1. Task force structure.
As the project grows, too, it can become too independent, “stealing” people from other projects. Other
organizations and projects are robbed of badly needed expertise. As a project ends, the task force may
experience severe morale problems, as people scramble for new jobs before completing their responsibilities.
It is not uncommon for a project to experience lapses in quality as a result.
Keeping these shortcomings in mind, Perry agrees with his boss that a matrix structure is best for the Smythe
Project. A matrix structure obtains resources from functional organizations and also shares those people with
other projects. For command and control purposes, people report to their functional managers but support one
or more project managers. A generic matrix structure is shown in Exhibit 10-2 and the one for the Smythe
wedding is shown in Exhibit 10-3.
The matrix structure offers several advantages. It allows for sharing people with heavy expertise among
several projects. People don™t need to look for a new job as the project concludes. The project manager can
acquire people with the right skills at the right time, thereby reducing the need to keep people on when they
are not needed; this helps keep the cost lower. The matrix structure also gives senior management flexibility
in changing the scope or stopping the project owing to different market conditions.
Perry realizes, though, that a matrix structure presents challenges. It makes planning difficult, especially if
projects are sharing resources. Often, he must negotiate with functional and other managers to obtain people™s
help.
Exhibit 10-2. Matrix structure.

A matrix structure can wreak havoc on morale, too. Team members on multiple projects may be forced to
determine which project to give attention to. Sometimes the competition is so keen that individuals become
pawns in a power struggle among functional and project managers. That struggle can last a long time, adding
to team angst. Finally, the matrix structure often violates the unity-of-command principle (a single superior to
whom subordinates report).
To tackle these challenges, Perry recognizes the stress a matrix structure places on team members. He will
coordinate closely with functional and other project managers to facilitate availability and try to integrate his
project with other projects. He will encourage greater communication, information sharing, and bonding.
Finally, he will stress flexibility; change is a way of life in the matrix environment, since priorities and
resource availabilities constantly change.


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



Virtual Teams
Title

Recent advances in information systems have brought unparalleled changes to business, not just technically
but also in managing projects. These changes include e-mail, the Internet, groupware, and client-server
technology. Technologies such as these have enabled team members to work autonomously at remote
-----------
locations during all time periods (e.g., mornings, evenings). But a project team may never meet face-to-face
with some people and will only interact electronically. That is the nature of virtual teams.
There are many advantages to a virtual team. It reduces the need for expensive facilities. Team members feel
greater freedom, working with less supervision. A side benefit is a flatter organization chart, too.



Exhibit 10-3. Organization chart reflecting matrix structure of Smythe Project.
While sounding like a dream come true, reality may provide a different picture. Virtual teams can pose tough
challenges. The first is how to provide support for these virtual team members. There are issues concerning
hardware and software, plus administrative matters such as accessibility to the project library and ways of
collecting information nonelectronically.
Second is how to overcome the purported loneliness that affects some virtual team members. Many work
alone, in remote geographical locations. Their opportunities for social interaction and camaraderie are limited.
Third is the challenge of coordinating the activities of team members. With members geographically
dispersed and in different time zones, coordination can be a nightmare. Since oversight is difficult, project
managers cannot closely monitor work. Similarly, communication usually involves more than e-mail. There
must be a way to discuss major project activities.
Some ways to handle these challenges include:
• Conducting frequent face-to-face meetings and holding social gatherings
• Developing objective ways to measure performance and completion criteria
• Empowering people to assume responsibility and accountability for results
• Establishing time commitments for team members to respond to each other
• Providing a standard suite of hardware and software tools

SWAT Teams
Special Weapons and Tactics (SWAT) teams are a growing presence in project management. These are small
groups of individuals who are experts not just in project management but also in other subjects. In the sense
that their objective is to move quickly to complete their mission and pull out, these groups are like the police
SWAT teams from which they get their name. Specifically, a project SWAT team must quickly set up the
appropriate project management and technical disciplines at the beginning of a project. Once the disciplines
have been established, the team relinquishes control to a project manager and his group, who are responsible
for completing the project.
SWAT team work is intense. By the time its work is completed, it will have developed and implemented a
complete project plan, from estimates to schedules.
Although hard skills (e.g., expertise with software and hardware) are important, soft skills are important, too.
For example, SWAT team members must solicit buy-in for their work. Active listening, facilitation,
communication, and teaming skills are extremely important. Also important is the ability to keep calm under
pressure and a willingness to share equipment, expertise, or information.
To use SWAT teams effectively:
1. Obtain support for the work of a SWAT team by follow-on teleconferencing sessions; otherwise, the
team™s effort will be wasted.
2. Be aware that working on a SWAT team can cause burnout. Morale and energy levels can plummet.
3. Provide constant training for SWAT team members. They must keep abreast of technologies in
order to provide state-of-the-art expertise. Cross-training can help, but only so far.
4. Select people for the SWAT team who can handle ambiguity. Members must be willing to tackle
projects when goals and deliverables are ill defined.

Self-Directed Work Teams
In recent years, a different approach to building teams has emerged, called a Self-Directed Work Team
(SDWT).
SDWTs are teams that have considerable autonomy while building a product or delivering a service. It is a
group of professionals sharing responsibility for results.
These teams are cross-functional, meaning that people with different disciplines and backgrounds work
together to achieve a common goal. The team decides everything, from setting priorities to allocating
resources. Other actions include selecting people, evaluating performance, and improving processes. The key
characteristic is the autonomy to make decisions without supervisory approval.
Several trends are pushing toward the SDWT concept because these teams:
• Create flatter organizations
• Empower employees
• Encourage greater teaming
• Encourage people to have a more general background
• Enlarge spans of control
SDWTs are excellent candidates for applying project management ideas. Since the entire team is responsible
for the results, all members must help lead, define, plan, organize, control, and close the project. The tools and
techniques of project management enable teams to do that.
Questions for Getting Started
1. Did you determine whether your project organization has or should have a task force or matrix
structure?
2. Regardless of the type, did you consider the following when organizing the team:
• Accountability issues?
• Authority issues?
• Basis for grouping functions?
• Concurrence from the right people?
• Level of autonomy for team members?
• Players?
• Political climate?
• Project goals?
• Responsibility issues?
• Span of control?
• When to publish the organization chart?
• Which are the line and which are the staff functions?
3. If a task force structure, what can you do to deal with its shortcomings (e.g., decline in loyalty)?
4. If a matrix structure, what can you do to deal with its shortcomings (e.g., competition among
projects for key people)?
5. If you have a virtual team, even partially, how will you deal with the challenges (e.g., ongoing
technical support) often associated with such teams?
6. If you have a SWAT team, how will you overcome the challenges (e.g., burnout) often associated
with such teams?


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 11
Budget Development and Cost Calculation
Nothing gets done without money. Projects are no exception, and Perry is the first to realize this.
-----------

There are many reasons for calculating costs before they are incurred. To begin, they give an idea of how
much the goals will cost to achieve. Cost calculations later become a tool for measuring the efficiency of a
project team. They also help determine priorities as the project progresses. Finally, they contribute to the
overall profitability of a company.
As project manager, Perry has several responsibilities for budgeting. He must develop budgets on a
task-by-task basis and for the entire project. He must ensure that expenditures stay within the budget allocated
for each task and the project as a whole. He seeks additional funding, if necessary. Finally, he tracks and
monitors expenditures, identifying and reporting deviations to upper management.
When estimating his costs, Perry establishes a management reserve, usually 3 to 5 percent of the total
estimate for the project, to address unexpected costs. This reserve increases the overall cost estimate for the
project.
Later, while controlling his project, Perry uses the cost estimates to compare to actual expenditures. Of
particular importance are estimates versus actual costs up to a given point. If the actual costs exceed the
estimated costs up to a specific point, an overrun exists. If the actual costs are less than the estimated costs up
to a specific point, an underrun exists. Perry looks for overruns and underruns on a task-by-task global basis.
If the feedback has an overrun, for example, Perry takes corrective action.

Different Kinds of Costs
Perry knows that many items in a project cost money. The typical ones are:
• Equipment (purchase, lease, rental, and usage)
• Facilities (office space, warehouses)
• Labor (employee, contract)
• Supplies (paper, pencils, toner, sundries)
• Training (seminars, conferences, symposiums)
• Transportation (land, sea, air)
The standard formulas for calculating these costs are:
Equipment = purchase price
or
lease price — time period
or
rental price — time period
Facilities = lease price — time period
or
rental price — time period
Labor costs = (regular hours — hourly rate) + (overtime hours — time and a half rate) + (overtime hours —
double time rate)
Supplies = quantity — unit price
Training costs = (tuition cost — number of attendees) + (the sum of the labor costs for attendees)
Transportation costs = (daily, weekly, monthly, or hourly rate) — (period of usage)
There are also different ways to classify costs.

Direct vs. Indirect Costs

Direct costs directly relate to the building of a product ” for example, materials and specialized labor.
Indirect costs are other than direct costs and not necessarily related to the building of a product ” for
example, rent and taxes.

Recurring vs. Nonrecurring Costs

Recurring costs appear regularly ” for example, long-term payments for facilities. Nonrecurring costs appear
only once ” for example, the purchase of equipment.

Fixed vs. Variable Costs

Fixed costs are not alterable owing to changes in work volume ” for example, cost of facilities usage.
Variable costs vary depending upon consumption and workload ” for example, cost of materials.
Activity-Based Costing (ABC)
Activity-based costing (ABC) is a process approach to accounting, giving a realistic portrait of the total
costs for a project. With traditional accounting methods, labor is seen as the primary contributor to costs,
while with ABC, overhead and materials have significant impact. Traditional accounting emphasizes
"hacking away many heads," not reducing material and overhead costs. ABC instead focuses on processes
and their improvement, not just reducing head count. It also focuses on customers, since the true cost of the
final product is passed on to the customers.
Project managers can play a major role in furthering the use of ABC. ABC also requires good definitions of
what the customer wants (statement of work), a list of the activities for meeting those wants (work
breakdown structure), and fixed monies (cost estimates) to produce the product or deliver the service.
Project managers can realistically determine direct and indirect costs and also determine what processes to
improve or remove in order to increase customer satisfaction and reduce costs.

Burdened vs. Nonburdened Labor Rates

Burdened labor rates include the cost of fringe benefits ” for example, insurance and floor space and
nonlabor overhead. Nonburdened rates are labor rates minus the cost of fringe benefits and overhead.

Regular vs. Overtime Labor Rates

Regular labor rates are less than or equal to 40 hours per week. Overtime labor rates are more than 40 hours
per week, including time and a half and overtime.

How to Calculate Costs
Making a reliable cost estimate depends on the amount of information available for estimating. Having more
information means you have greater ability to discern the elements that constitute an estimate. Making a
reliable cost estimate also depends on a good work breakdown structure (WBS); see Chapter 6. And, of
course, to produce a reliable cost estimate requires a good project definition; the better the definition, the
more reliable the estimate because the parameters of the final product or service have been established; see
Chapter 5.
Obtaining a reliable cost estimate depends on good time estimates, too. Most cost estimates rely on a count of
labor hours to complete work. If the work estimate is reliable, then the costs should have an equivalent
reliability, since they represent hourly rate times total hours; see Chapter 7. Finally, estimates often are based
on assumptions. Unless identified, these assumptions can lead to misunderstandings and ultimately to
inaccurate calculations. The assumptions are spelled out in the statement of work; see Chapter 5.


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



What follows is an example of how Perry estimates the costs for each task in the WBS. He uses a worksheet
Title
format (Exhibit 11-1) to calculate the figures. The summary of his calculations is the total cost for the project,
excluding the management reserve.
Perry tracks the estimate-at-completion for each task and the management-estimate-at-completion (MEAC).
The estimate-at-completion is a combination of actual expenditures to date up to a specific point plus the
-----------
remaining estimate to complete the project. The MEAC is the actual expenditures to date plus the remaining
estimate to complete the entire project. Both the estimate-at-completion and the actual expenditures to date
give




Exhibit 11-1 Worksheet for estimating costs.
Costs
($)
Labor 560.00
Telephone 12.00
Transportation 20.00
Training 0.00
Equipment 0.00
Supplies 0.00
Total Estimate 592.00
round to
600.00

Perry a good idea of how well expenditures have gone and will go if the current levels of performance
continue.

What Happens If Cost Estimates Are Too High?
Frequently, project managers are asked to reduce their estimates. Top management often feels that a project
can be completed with less money. It may even declare a 10 percent across-the-board reduction for all
projects. Dealing with such commands is one of the hardest challenges facing project managers. Fortunately,
they have several options.
The project manager can communicate her reasons for the cost estimates. She can explain, for example, the
rationale behind the time estimates and the accompanying calculations. Presenting the reasons and
assumptions especially gives a persuasive argument for retaining the cost estimates.
The project manager can also develop revised cost estimates. Based on feedback from senior management,
she can select the best revised estimate.
Finally, the project manager can negotiate with the customer to reduce or revise the scope of the project,
reduce the work requirements as described in the work breakdown structure, reduce the time estimates, and
modify the assignments. Ultimately, revisions to the scope will then be reflected in the estimated costs.

The key: Identifying and Managing Costs

Money is the oil that gets projects moving and keeps them running. The Smythe Project is no exception. Perry
appreciates the importance of identifying and managing costs throughout the life of the project. He knows that
how he categorizes costs is not as important as ensuring that the project completes within budget.
Perry knows, too, that costs, along with schedules, are susceptible to positive and negative changes that may
increase or decrease the reliability of his estimates. To a large extent, this reliability will be affected by the
degree of risk associated with his schedule and cost estimates.

Questions for Getting Started

1. Did you identify all the types of costs for your project?
2. Did you identify the rates for usage and quantity that you plan to consume?
3. Did you calculate the total costs by summing the totals for each task?
4. If you elect to have a management reserve, did you determine the appropriate percent to be
multiplied against the total costs of the tasks?
5. If you received pressure from your management or the customer for having too high an estimate, did
you develop alternative ways to deal with their resistance?


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 12
Risk Management
Projects can fail for a number of reasons and the risks are always high. While a project manager cannot
-----------
eliminate risk, she can prevent or mitigate its impacts by using risk management.

Managing Risk: A Four-Step Process
Risk management is the process of identifying, analyzing, controlling, and reporting risk. Risk identification
is the identification of major elements of a project and their associated risks. To do this, Perry will rely on his
and others™ knowledge and expertise. He will meet with core team members, the customer, and senior
management to solicit input. He will review documentation, including the statement of work, work
breakdown structure, and requirements documents. This information prepares him for the next step. Risk
analysis is the classification of those elements to different levels of risk. Perry will compare the “should be”
controls with the ones that do exist and will identify any discrepancies. He will also determine the probability
or likelihood each risk will materialize and whether a control is necessary. Risk control is the determination
of controls that can mitigate the risks. It involves deciding under what circumstances to take action to prevent
or mitigate the impact of a risk. Perry essentially will do contingency planning, which involves anticipating
responses to negative circumstances. Risk reporting is the act of informing team members and senior
management of those risks.
Perry knows that by managing risk, he can identify priorities, thereby focusing his energies and resources as
well as developing a meaningful project plan. The analysis of risk indicates the strengths and the weaknesses
of the project, so that he can maximize his assets and minimize his losses. It helps him to identify and put into
place the most important controls, rather try to control everything.
To perform risk management, Perry needs information, time, expertise, and perspective. The information is
necessary to understand the major processes and components, the accompanying threats, and the controls that
should be in place. It will take time to collect the information and assemble it in some meaningful form. He
will use his expertise in project management to apply risk management while maintaining a broad perspective
to avoid focusing on just one area (e.g., technical issues at the expense of business ones).
Exposure
Several factors can expose projects to higher than normal risk.
• Team size. The larger the team, the higher the probability of a problem arising. For example,
communications can be more difficult as the number of participants increases. The number of
interactions among people increases and thus they require greater coordination.
• History. Newer projects are riskier because the processes have not been refined. The more times a
project of a similar nature has been done, the greater the likelihood of success.
• Staff expertise and experience. If the staff lacks direct experience and knowledge of the subject,
people will struggle to learn as they go along, robbing the project of time and possibly introducing
errors.
• Complexity. The more sophisticated a project, the greater the opportunity of a mistake or slipup.
Untested technologies, such as ones dealing with information systems or biotechnologies, are risk
laden.
• Management stability. The more senior management plays “musical chairs,” the greater the risks of
a problem arising. With every new management comes the possibility of changed priorities and
directions. Management stability implies unity of direction, which in turn means reaching goals.
Management irritability can lead to unrealistic scheduling and inefficient use of resources.
• Time compression. If a schedule is highly compressed, then the risks are magnified. Having more
time means greater flexibility and the opportunity to prevent or mitigate the impact of errors.
• Resource availability. The more resources that are available, the greater the ability to respond to
problems as they arise. For example, more money brings greater ability to secure equipment or people
when needed. Plentiful resources, of course, do not guarantee protection from risk; however they do
provide the means to respond to it.

Categories of risk
Risks can be viewed as business, technical, or operational. An example of a business risk is misuse of project
funds. A technical risk is the inability to build the product that will satisfy requirements. An operational risk is
the inability of the customer to work with core team members.
Risks are either acceptable or unacceptable. An acceptable risk is one that negatively affects a task on the
noncritical path. An unacceptable risk is one that negatively affects the critical path.
Risks are either short or long term. A short-term risk has an immediate impact, such as changing the
requirements for a deliverable. A long-term risk has an impact sometime in the distant future, such as
releasing a product without adequate testing.
Risks are viewed as either manageable or unmanageable. A manageable risk is one you can live with, such as
a minor requirement change. An unmanageable risk is impossible to accommodate, such as a huge turnover of
core team members.
Finally, risks are either internal or external. An internal risk is peculiar to a project, such as the inability to get
the parts of a product to work. An external risk originates from outside the scope of the project, such as when
senior management arbitrarily cuts funding by 20 percent.
Categorizing risks is, of course, mainly an academic exercise. These classifications can help you determine
the source, relative importance, and impact to the project.

Key Concepts in Risk Management
When performing risk management, Perry remembers the following concepts.
• A component is a basic element of an overall system. A project is a system consisting of components
that, in turn, can consist of subcomponents. Components can be processes, deliverables, or both.
Examples of a component are a process like “determining requirements” or a deliverable like a
“requirements document.”
• A threat is the occurrence of an event that negatively affects a project in some manner. A threat
exploits a vulnerability, or exposure. An example of a threat is when there is no customer buy-in of a
schedule or requirement. A vulnerability is the inherent degree of weakness of a component, such as a
schedule having no acceptance by the customer.
• Probability is the odds that something, like a threat, will occur any-where from 0 to 100 percent.
Probability determines the extent to which a risk will occur and the level of vulnerability.
• Control is a measure in place to mitigate, prevent, or correct the impact of a threat. A control can be
physical, such as a required signature, or logical, such as a peer review.
Keeping the above concepts in mind, Perry can perform risk management using two approaches: quantitative
or qualitative.


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



The quantitative approach relies on statistical calculation to determine risk, its probability of occurrence, and
Title
its impact on a project. A common example of the quantitative approach is decision tree analysis, applying
probabilities to two or more outcomes. Another example is the three-point estimating technique described in
Chapter 7. Still another approach is the Monte Carlo simulation, which generates a value from a probability
distribution and other factors.
-----------
The qualitative approach relies on judgments, using criteria to determine outcomes. A common qualitative
approach is a precedence diagramming method, which uses ordinal numbers to determine priorities and
outcomes. Another approach is heuristics, or rules of thumb, to determine outcomes.
An example of a qualitative approach is to list in descending order specific processes of a project, the risk or
risks associated with each process, and the control or controls that may or should exist for each risk. See
Exhibit 12-1.

Ways to Handle Risk
There are four basic ways to deal with risk.
1. Accept the risk, known as risk acceptance. Perry can do nothing to prevent or mitigate the impact of
a risk. For example, he continues to
Exhibit 12-1. Example of a qualitative approach.
Process Risk Control
1. Obtain involvement of Inability to make regular Mail or e-mail duplicate
client. contact. copies of project management
documentation to the client.
2. Determine requirements. Unclear requirements. Conduct periodic reviews.
Unavailable requirements. Draft requirements and review
them with client.
address the same requirements despite management having reduced the budget.
2. Adapt to the risk, known as risk adaptation. Perry can take measures that will mitigate the impact of
a risk. For example, he reduces requirements to reflect the corresponding cutback in funding.
3. Avoid the risk, known as risk avoidance. Perry takes action that will keep a risk from seriously
impacting his project. For example, he decides to narrow the scope of the project to avoid certain high
risks.
4. Transfer the risk, known as risk transfer. Perry lets someone else assume the risk. For example, he
contracts out or outsources certain high-risk tasks rather than let the core team handle them.
When performing the contingency planning, Perry will identify the expected event or threat, its probability of
occurrence, and its impacts (e.g., economic, technical, operational), and then devise an appropriate response.
He uses a simple form to capture this information, as shown in Exhibit 12-2.
Perry also reviews the schedule to identify possible risks. He considers options like changing the
dependencies, durations, requirements, resource assignments, or time estimates.

Risk Reporting
Risk reporting occurs after risk identification, analysis, and control are complete. Perry has the option to
develop either a written or an oral report. In either case, however, the content of the report will be basically
the same.
A risk report should be clear, concise, and self-explanatory. It should contain categories of risks (e.g.,
business and technical); components; risks for each component, to include probability of occurrence and
impact; background and scope of project; and recommendations or actions to strengthen controls or respond
to risks when they become actual problems (e.g., contingency plans).
Exhibit 12-2. Risk response form.
Probability of
Description Occurrence Impacts Response
Cancellation of air Low • Less attendance at Set up charter flight
transportation reception or wedding
• Delays in arrivals

The Key: Risk Management, Not Elimination
In a dynamic environment, a project will always face risks. The key is not to try to eliminate risks but to
manage them. Perry identifies and analyzes risks. He then implements controls to mitigate or eliminate their
potential impact. However, he also communicates the list of risks and their accompanying controls to all
people who have a need to know. By developing and distributing documentation on risks and their controls,
Perry can either prevent related problems or minimize their effects when they occur.

Questions for Getting Started
1. Did you identify the major components and processes for your project?
2. Did you identify the major threats to your project? Did you identify their probability of occurrence?
3. Did you identify the controls that should exist for preventing or mitigating risks to each component
or process?
4. Did you conduct research to determine what controls actually exist?
5. For all control weaknesses, did you determine whether contingency plans should be in place? If so,
did you prepare the appropriate response?


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 13
Project Documentation: Procedures, Forms, Memos,
and Such
-----------

Perry recognizes that documentation is essential for leading, defining, planning, organizing, controlling, and
closing a project. He also realizes that too much documentation is as much a problem as too little. A balance
must exist, depending largely on the size and importance of the project.
Good documentation serves as an excellent communication tool. It provides an audit trail for analysis and
project reviews. It lends order and structure to the project by giving direction and setting parameters. It
increases efficiency and effectiveness because everyone follows the “same sheet of music.” And it gives team
members confidence, especially when things appear chaotic or there are too many unknowns.
Project documentation consists of the following items:
• Procedures
• Flowcharts
• Forms
• Reports
• Memos
• Project manual
• Project library
• Newsletters
• History files

Procedures
For many projects, particularly large ones, procedures facilitate management. They help achieve efficiency by
ensuring consistency of action. They improve effectiveness by ensuring that people achieve project goals.
They reduce the learning curve by providing guidance on the “way things are done.” Finally, they improve
productivity because people with questions can refer to the documentation rather than interrupt other people.
Key Insights for Preparing Procedures
Developing procedures is more than just writing words on paper. Regardless of your writing ability,
consider the following when developing procedures.
1. Define acronyms the first time they appear and spell out abbreviations at first use. The reader may
not know what you mean.
2. Define special terms. The reader needs to understand what you are saying.
3. Avoid clich©s. They are a tired way of expressing what you mean. Be original -- but always clear
in your meaning.
4. Check for typographical and spelling errors. They distract from the message and show sloppiness.
5. Use positive expressions. Avoid “do not” or “cannot” because such phrases create a mental block
in the reader™s mind. Be positive.
6. Use the active rather than the passive voice. The active voice is strong language; the passive voice
is weak and reveals a tentative writer.
7. Watch your organization. Ideas should flow logically, such as from the general to the specific, or
vice versa. Chronological order is also good.
8. Avoid wordiness. Keep sentences short (less than 15 words) and paragraphs brief (usually less
than 5 sentences). Ideas are easier to grasp this way.
9. Integrate text and graphics. If using both, ensure that the text references the graphics and that the
two match information.
10. Track your revisions. Assign a version number to each and note the date, so everyone uses the
most recent version.

To develop a good set of procedures, you need the following:
• Information to write about the topic
• Time to prepare, review, and publish the documents
• People with good research, writing, and editing skills
• Management and user buy-in to ensure people follow the procedures
• Feedback loop to ensure completeness, currency, and usability
Procedures are often less than adequate on projects, for several reasons. For one, the project manager may
view writing procedures as something that must be done only to “satisfy requirements.” The results are poorly
written and incomplete procedures. Or the project manager may assign the task to someone who knows little
about the project or whose role is minimal. Sometimes the project manager prepares the procedures late in the
project, mainly to satisfy reviewers and auditors. Finally, the procedures are prepared and then set on a shelf,
never to be used by anyone.
Perry, of course, ensures good procedures by following four simple steps.
1. Identify the topics. Perry can either develop a set of topics on his own or solicit help from the team.
He chooses the latter, as well as conducts research on previous projects to find similar procedures.
Some specific topics include:
• Change control
• Forms
• Meetings
• Organizational structure
• Purchases
• Reports
• Resource usage
• Responsibilities
• Schedules
• Statusing
2. Determine the format for the procedures. There are four possible procedure formats: narrative
(Exhibit 13-1), sequential (Exhibit 13-2), playscript (Exhibit 13-3), and item-by-item (Exhibit 13-4). As
Exhibit 13-1 demonstrates, the narrative format has an essaylike appearance. Although a narrative
presentation is easy to read, information within it is often hard to find quickly. Also, it causes eyestrain,
since the blocks of text minimize white space. And it is difficult to update or revise because it lacks
modularity.
The sequential format, as shown in Exhibit 13-2, has a step-by-step appearance. Each sentence is a generally
brief command. Its brevity, abundant white space, and simplicity make it easy to follow and find information.
It is best used for procedures involving one person.
Exhibit 13-1. Narrative format.
Completing and Submitting the Monthly Status Report Form
Project:

Date:

Start (baseline):

Finish (baseline):

Management estimate at
completion (MEAC) date:

Variance:

Original total cost estimate:

Estimated cost to date:

Actual cost to date:

Management estimate at
completion (MEAC) cost:

Variance:

Overall performance evaluation:

This procedure describes how to complete and submit the Monthly Status Report (MSR) form, which is
shown above.
The MSR must be completed to track and monitor the performance of your project. It is therefore important
to complete all fields and submit the form on time.
In the project field, write the name of the project. Be sure to add the project number if one has been
assigned. In the date field, write the date you are completing the form, using the month/day/year format
(e.g., 11/26/00). In the start (baseline) field, write the original start date using the same format as the one for
the date field. Do the same for the finish (baseline) field. In the management estimate at completion
(MEAC) date field, record the actual progress to date plus the remaining estimate of the work to be
completed. In the variance field, write the difference in days between the MEAC and the original finish
date. In the total cost estimate field, write the original estimated cost for the project. . . .1
After completing the MSR, make three copies. Keep one copy for your records. Submit one copy to your
next higher level of management or to the chairman of your steering committee, if applicable. Then attach
the remaining copy to the original and submit both to the Project Review Office (PRO) at mail stop 78H1.
One final note. The PRO must have possession of the MSR no later than the final working day of a month.
1. Authors™ note: This example of the narrative format would actually have been one paragraph
longer; however, we deleted the instructions for the last five fields to spare our readers.



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



Exhibit 13-2. Sequential format.
Title
Monthly Status Report Form
Instructions: Complete each field according to the procedure Completing the Monthly Status Report Form,
below. Make a copy for your records and forward the original to the Program Office, mailstop 3X-41.
-----------
Project: A Date: B

Schedule:
Start Baseline: C
Finish Baseline: D
Management Estimate at Completion Date: E
Variance: F
Budget:
Original Total Cost Estimate: G
Estimated Cost to Date: H
Actual Cost to Date: I
Management Estimate at Completion: J
Variance: K
Overall Performance Evaluation: L
Completing the Monthly Status Report Form
This procedure describes how to complete the Monthly Status Report form.
1. Obtain a copy of the form from the project office.
2. Answer each field on the form by matching the applicable letter below with the corresponding one
shown in the figure on the next page.
A. Name of the project
B. Date you completed the form
C. The original start date in month/day/year format
D. The original finish date in month/day/year format
E. The date reflecting actual progress-to-date plus the remaining estimate of the work to be
completed in month/day/year format
F. The difference in days between the management estimate at completion and the original
finish date
G. The original estimated cost for the project
H. The original estimated cost up to a specific date
I. The costs accrued up to a specific date
J. The actual costs accrued up to a specific date plus the remaining estimated costs to complete
the project
K. The original total estimated cost minus management at completion cost
L. Your opinion about the overall progress of the project as well as a description of the major
cost, budget, requirements, and technical issues impacting the project

Exhibit 13-3. Playscript format.
Processing the Monthly Status Report Form
The procedure describes how to process the Monthly Status Report Form. It does not explain how to
complete it. For that, refer to the procedure Completing the Monthly Status Report Form.
PROJECT MANAGER
1. Obtain a copy of the Monthly Status Report Form.
2. Complete the Monthly Status Report Form.
3. Date and sign the form.
4. Make two (2) photocopies.
a. Retain one copy for the project history file.
b. Attach the other copy to the master document.
PROGRAM OFFICE
1. Review the Monthly Status Report Form for completeness.
2. If incomplete:
a. Prepare a memo noting the shortcomings.
b. Attach a copy of the memo to the master document.
c. File the copy.
d. Return the memo and master copy to the project manager.
3. If complete:
a. Date-stamp the master document and photocopy.
b. File the master copy.
c. Return the copy to the project manager.

As with the sequential format, the playscript format (Exhibit 13-3) has a step-by-step appearance and
possesses the same structure. Similarly, its brief style, abundant white space, and simplicity make it easy to
follow and to find information. It is best used for procedures involving two or more people.
The item-by-item format, shown in Exhibit 13-4, has all the characteristics and advantages of the sequential
and playscript formats. It works best, however, when a procedure covers a mixture of topics.
3. Prepare, review, revise, and publish the procedure. This step should involve as much
participation as possible by members of the team, so as to seek buy-in from those who must follow the
procedures. Here is an outline of a typical procedure:
I. Purpose
II. Scope
III. Contents
IV. Approvals
V. Appendices
Exhibit 13-4. Item-by-item format.
Handling All Reports for Competitive-Sensitive Projects
This procedure describes how to handle reports generated for projects designated proprietary.
I. Cost Report
A. Review the report.
B. Store one copy of the report in a secure room, drawer, or safe.
C. Shred any additional copies.
II. Schedule Report
A. Review the report.
B. Store one copy of the report in a secure room, drawer, or safe.
C. Shred any additional copies.
III. Monthly Status Report
A. Complete the report.
B. Upon receiving the date-stamped copy from the program office, shred the original.
C. Store the retained copy in a secure room, drawer, or safe.
4. Follow the procedures. At first the comment might sound academic; however, many projects have
written procedures, let alone plans, that no one follows. In the end, the procedures serve no function
other than to occupy a bare spot on a shelf.

Flowcharts
Many times, pictures and diagrams are preferred over text or are treated as supplements to text. Flowcharts
indeed are worth a thousand words.
Flowcharts are easier to understand than written procedures and communicate more with less. However, even
using flowcharts requires effort. It takes time to prepare them. They must be updated to maintain relevancy.
And users and management must buy in to them if the project manager expects people to follow them.
When developing flowcharts, keep the following points in mind.
1. Use symbols consistently. Provide a key to the symbols.
2. Put the flowcharts under version control. Different versions can quickly be released, thereby
confusing people.
3. Use a software toot to generate the diagrams. Revisions will be easier and the charts clearer.
4. Keep it simple. Avoid putting too much on a page. A cluttered page can be as mentally taxing as
large blocks of small text on a page.
There are a number of flowcharting techniques. Some charts show the flow of control (e.g., do step 1, then
step 2, and, if positive, do step 3). Others show the flow of data (e.g., the use of early and late dates and
durations to calculate float). Exhibits 13-5 and 13-6 have flowcharts showing flow of control and data flow,
respectively.


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



When flowcharting, follow these four steps:
Title
1. Determine the topic, just as you would with written procedures.
2. Determine the type of diagram and whether it is a substitute or a complement to a procedure. Flow
of control is the most popular, followed by data flow diagrams.
3. Prepare, review, revise, and publish the flowchart. This step is the same for procedures.
-----------
4. Follow the flowchart. Like procedures, they can quickly end up covering a bare spot on a bookshelf.

Forms
Although many people dislike completing forms, Perry sees their value in managing his project. Forms
capture and communicate information. They also provide audit trails to help learn from past experience,
compile statistics, and conduct postimplementation reviews.
Unfortunately, many forms are not user-friendly. The instructions for completion and distribution are unclear.
The fields do not flow logically. They ask for way too much information. And there are usually too many
forms of too many varieties.
Ideally, forms should have these qualities:
• Be logically organized
• Be readily available
• Not exceed one page
• List a source and destination
• Have clear and concise instructions for completion and submission
• Have adequate space for filling in information
• Request only the necessary information
For use in project management, forms can capture information on such topics as activity descriptions, Activity
estimating, assignments, change management, estimated labor usage, labor and nonlabor costs, problem
identification and tracking, and status of activities.
Exhibit 13-5. Flow of control.




Exhibit 13-6. Data flow.
Here are some guidelines on how to prepare a usable form:
1. Determine its purpose (e.g., capturing schedule or cost data).
2. Determine who will complete the form and who will process it.
3. Identify the exact data to capture.
4. Determine its source and destination.
5. Prepare the instructions for its completion.
6. Prepare a draft of the form (e.g., using a graphics or spreadsheet program).
7. Circulate the form for evaluation (e.g., to people who can complete it and to others who will use
data that it captures).
8. Make revisions, if necessary.
9. Determine the number of copies and how the copies will be made.
10. Reproduce the form.
11. Distribute it either electronically or in hard copy.
Exhibit 13-7 is an example of a well-defined form.
Perry performs four steps to draw up forms for his project.
Distribution Methods
There are essentially two ways to present forms, reports, memos, and the like.
• Hard copy. Traditional papers, usually typed or printed. It has the advantage of being familiar; the
downside is that it can be costly to maintain, labor-intensive to revise, difficult to keep current, highly
prone to human error, and takes up file space.
• Electronic copy. On computer disk or tape. Electronic copies can reduce the need for storage
space, lower labor-intensive actions (e.g., revisions), and make updating easier. Unfortunately,
electronic copies still remain susceptible to human error, although less so with the recent advances in
electronic storage. Hard copy backups have been the norm, here.
Electronic storage has its challenges, too. It requires investing in and maintaining a technology
infrastructure (e.g., local area network or Web site), training people to use the technology, and dealing with
administrative issues such as disaster recovery and backup.
1. Determine the topics requiring forms. These are topics for which he will need information
throughout the project.
2. Design the forms. As with procedures and flowcharts, Perry will obtain input from the major
participants. This action increases people™s buy-in and their willingness to use the forms. When
designing the forms, he also chooses an open layout that is easy to use.
3. Distribute a first draft of the forms. Perry gives everyone involved a chance to revise the forms and
sharpen their design.
4. Perry prepares the forms in their final form, for either electronic use or as printed hard copies. Each
form includes instructions on submitting the completed form and also handling changes to the form at a
later date.

Reports
The right amount of feedback can make the difference between the success and failure of a project. Reports
are vehicles for giving reliable feedback.
Reports communicate information. They help project managers monitor and track individual and overall
performance, indicating when to take corrective action. And they give feedback to everyone involved about
their contributions to the project.
Exhibit 13-7. Overall performance evaluation.
Monthly Status Report Form
Instructions: Complete each field according to the procedure "Completing the Monthly Status Report
Form." Make one copy for your records and forward the original to the Program Office, Mailstop 3X-41.
Project Name: Date:
Schedule:

Start date (baseline):
Finish date (baseline):
Management Estimate at Completion Date:
Variance:
Budget:
Original Total Cost Estimate:
Estimated Cost to Date:
Actual Cost to Date:
Management Estimate at Completion Cost:
Variance:
Overall Performance Evaluation:

For reports to offer these advantages, however, they must have certain characteristics. They must:
• Be easily understood
• Be produced and available in a timely manner
• Have timely, meaningful information
• Not be too numerous
To use reports on his project, Perry performs the following seven steps:
1. He identifies the topics. Will he need reports on the schedule? Costs? Quality? Typical reports are
activity relationship reports, bar charts, cost reports, histograms, network diagrams, problem reports,
project status reports, and resource usage reports.
2. For each report, Perry determines information requirements and the means to collect it. He reviews
the statement of work for reporting requirements, determines the readership for each report, and
interviews recipients to determine their informational needs.
3. He lays out the report, keeping in mind clarity, logic, and relevancy. He remembers to keep the
report simple and focuses on obtaining the information that™s needed.
4. He determines the frequency of generation. Weekly? Biweekly? Monthly? Ad hoc?
5. He distributes the reports. Often, he will generate these reports via a software package on a personal
computer to give him the ability to experiment with communications modes.
6. He obtains feedback. Sometimes the reports will not contain enough information; other times, they
might have too much and be distracting. Because generating reports takes time and effort, he wants to
minimize frustration by keeping the reports helpful and concise.
7. He stores a copy of each report, in case he needs an audit trail or to develop lessons learned in the
project.

Memos
Many people hate to write memos. That™s unfortunate, because a well-written memo can have tremendous
impact on coworkers.
A memo provides a record of results. It encourages commitment to an idea or cause. It offers traceability. It
raises issues and helps resolve them. Above all, memos are excellent tools for communicating with other
people.


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



To fulfill these purposes, however, memos must be clear, concise, direct, legible, and organized. Exhibit 13-8
Title
is an example of a well-written memo.
Perry will always prepare a memo to clarify a policy or subject, document the results of a meeting, raise an
issue and get it resolved, record an accident, or schedule events. Thus, a memo should contain a date,
addressee, subject, message statement, giving the who, what, when, where, and why of a subject, information
-----------
on a response if desired, and signature. Memos can be prepared and sent electronically or via hard copy.

Newsletters
Not every project is big enough to warrant its own newsletter. For large projects, however, a newsletter can be
invaluable.
A newsletter can enhance communications, informing everyone of important happenings and giving new
information. It provides the project manager with the opportunity to “get the word out,” especially about
matters that directly affect project performance. It also serves as a record of significant activities and
accomplishments. Finally, it answers questions and dispels rumors before they arise.
Exhibit 13-8. Example of a well-written memo.
Date: February 28, 19XX
To: Gina Davies 713-1
Cynthia Fralusinski 714-2
Raymond Leazowitz 713-2
David Rockford 713-3
Vy Toon 714-3
Hank Wilson 715-1
Henry Winkless 716-8
cc: Eva Brewster 716-7
Larry Eisenberg 715-4

Subject: Planning Meeting for Bridal Shower
On March 10, we will hold a planning session for the Smythe bridal shower in the Rainbow Conference
Room on the second floor of the Corporate Headquarters Building.
Prior to the meeting, prepare and bring a list of action items to share with the group.
If you have any questions or comments, please feel free to contact me at extension 4127.
Perry
Project Manager, Smythe Wedding
Mailstop 713-4

There are, however, several issues related to publishing a newsletter. For example, the newsletter can become
a political rather than a communications tool, serving merely to pacify political sensitivities. It is
time-consuming and labor intensive to develop. Writing, proofreading, printing, and distributing a newsletter,
whether in hard copy or electronic form, is no easy task. It requires, too, people who can write and edit,
talents that are not too common apparently.
A newsletter can cover many topics, including team successes, challenges, biographies of participants, and
new techniques developed. The key to keeping a newsletter active is to encourage team members, and the
internal customer, to submit articles for the publication. That encourages people to read it and feel it is not a
propaganda rag.

History files
During the fog of managing a project, important documentation can be lost or misplaced. To ensure that does
not happen, Perry sets up project history files.
These files can be a drawer in a filing cabinet or a directory on a personal computer or file server. In any
form, they provide the ability to reconstruct situations for an audit trail, review problems, and satisfy audit
requirements. They help reduce the learning curve of new team members, as they review titles to become
familiar with critical issues and they provide background information for further work.
Project history files frequently contain: bar charts of schedules, drafts of documents, work estimates,
completed forms, memorandums, minutes of meetings, network diagrams, procedures, reports, responsibility
matrices, statements of work, and work breakdown structures.
Perry must keep the files up to date, from the start to the end of the project. That™s why he establishes them as
early as posible. He also establishes a procedure for removing and tracking files to avoid losing or misplacing
documentation. For example, he might provide a check-in/checkout sheet that people sign when removing and
returning a file. He designates an area where everyone can access the files. (Often, by accident, project
managers lock the files in their drawers or do not store them on the file server, thereby making accessibility
difficult.) Finally, he assigns someone to maintain the files.
Perry performs four basic steps to set up project history files:
1. He identifies their contents, e.g., as being only recent sets of schedules, or all previous versions.
2. He determines their organization, e.g., by topic or date.
3. He controls their removal, e.g., by means of a check-in/check-out sheet.
4. He makes their location obvious and provides the information needed to access them, e.g., by
writing an announcement and distributing it via newsletter or e-mail.

Project Manual
It is often handy to have certain information readily available, such as phone numbers and task listings. Perry
knows that a project manual can be that reference. It is an essential reference book for project management.
The project manual, however, does more than provide its readers with useful information. It is also a
communication tool, enabling people to interact efficiently and effectively.
Exhibit 13-9 is the table of contents for the Smythe Project manual. Of course, there is no restriction on
content other than being useful, relevant, and readable.
Ideally, the manual should be prepared early on and be maintained throughout the project cycle. Everyone
should have ready access to it, either in hard copy or electronic form.
To compile the project manual, Perry performs these six steps.
1. He determines the contents, e.g., by interviewing team members or reviewing the statement of work.
2. He organizes the contents, e.g., arranging them by topic or phase.
3. He determines the number of copies, e.g., by using the size of the team as the basis.
4. He assigns responsibility for maintaining the manual, e.g., to someone working on a noncritical task.
5. He publishes and distributes the manuals, e.g., electronically or as hard copy.
6. He seeks feedback from the users of the manual, e.g., by providing tear sheets on which they can
submit suggestions.


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



The Project Library
Title

The project library, like the history files, stores information. The major difference is that the library contains
more than project management information. The project library also stores company and project-specific
policies and procedures, history files, newsletters, journal publications, and related books, and technical
-----------
documentation.
As he did to set up the history files, Perry follows these steps to set up the library:
1. He identifies the contents, e.g., by interviewing team members for their suggestions.
2. He determines the organization, e.g., arranging documents by title, code, or author.
3. He controls the removal of documents, e.g., by providing a check-in/check-out sheet.
4. He determines the location of the library, e.g., providing a readily accessible site; he also determines
the procedures for accessing material.

Determining the Paper Trail™s Length
Too much or too little documentation can negatively affect a project. Perry recognizes that the key is to have
the right amount of documentation to satisfy the right needs. He knows that the content of documents should
be current, clear, concise, and organized to be useful to team members. He ensures, too, that the
documentation is accessible to everyone, such as through a project manual or library.
Exhibit 13-9. Table of contents for the Smythe Project manual.
Table of Contents
I. INTRODUCTORY SEGMENT
A. Purpose of the manual
B. How to use the manual
C. Who to contact for revisions
II. PROJECT BACKGROUND INFORMATION
A. Statement of work
B. Project declaration
III. RESPONSIBILITIES
A. Organization chart
B. Job descriptions and responsibilities
IV. POLICIES, PROCEDURES, AND WORKFLOWS
Copies relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
V. FORMS
Copies relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
VI. REPORTS
Samples relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
VII. REFERENCE LISTINGS
A. Phone listings
B. Functional priorities
C. Documentation matrix

<<

. 3
( 6)



>>