<< . .

. 2
( : 16)



. . >>


Advanced Search


Previous Table of Contents Next



Scenario 3: Nobody Wants to Be the Project Client
Title

In this scenario, when the question, “Will the real project client please stand up?” is asked, no one stands up.
Everyone looks at each other, waiting for someone else to accept accountability for the project. Perhaps the
project is not worth doing at all. Maybe the support is not there to justify proceeding with the idea. However,
----------- if the project is required, then some of the powers that be within the organization must designate an individual
or a small group to be the project client. Unless this role is clearly defined, the project client may be reluctant
to allow his or her name to be put on the project paperwork or may have no intention of putting any time into
the project. In order to begin to set expectations in this situation, develop a job description that goes along
with this assignment. This description should clearly define the degree of involvement and the specific role
that this person will play in the project from initiation to completion. Once again, our recommendation is to
have one person or a small group led by one person be the project client, accountable for the project.
Where should this one person or small group come from? There are several answers (or a combination of
answers) to this question, such as:
Sources for Project Clients
• The person representing the area that has the greatest vested interest in the outcome of the project
• The person from whose budget the project is being funded
• The person who has a success record of on-time, on-budget project completions
• The person who has the political pull to get all the areas in the company to work together on the
project
• The highest-level decision maker who has the clout to make things happen
• The person who wants it bad enough to put the energy into the project and make it successful
• All of the above

Keep in mind these two rules of thumb when selecting a project client or having one selected for you: (1) have
one person or a small group led by one person be the project client and be accountable for the project, and (2)
have that person be strong enough and dedicated enough to invest the time and energy to fulfill the role
successfully.
What Are Your Overall Objectives?
The client, once determined, must work with the project manager to establish the objectives for the project.
Project objectives are variously, and loosely, defined as the scope, technical objectives, statement of work,
and/or specifications. This set of terms is often misunderstood and in need of explication and clarification.
Consensus on the meaning of these terms will probably never be achieved. However, some framework for
their use is helpful.

Project Objectives
Project objectives is the broadest and most inclusive of the terms; all project targets are part of the project
objectives. Thus, the objectives are the characteristics of the deliverable(s), the target costs at completion, the
target completion date, and the target resource and asset utilization at completion. Without the first three
characteristics, the project objectives are incomplete; the last two are optional. The target cost at completion
and the target completion date can be negotiated after preparation of the plan, or they can be provided to the
project manager as constraints to the planning process.

Technical Objectives
Technical objectives refers to the subset of the project objectives that addresses the characteristics of the
deliverable(s). Many people use the term scope to refer to the technical objectives. The technical objectives
contain two parts: specifications, which describe the characteristics of the product or service that is being
developed in the project, and standards, which enumerate the governmental, institutional, and organizational
norms that the project or service is expected to meet. We might also include the assumptions made to cover
gaps in available information during planning as part of the technical objectives. These assumptions must be
considered part of the project objectives and may be considered part of the technical objectives.

Statement of Work
A statement of work is usually synonymous with the technical objectives of a project, but the term is applied
differently by different organizations. Regardless of the terminology utilized, if the work effort is to be
considered a project, the following three parameters must be met:
Parameters of a Project
1. A statement describing the end-of-work item to be produced as a result of completing the project
2. A stated period of performance
3. A budget

Let™s discuss the first parameter, which describes the end-of-work item to be produced.

Defining Project Requirements
Defining requirements forces the project manager to define clearly and concisely the scope of the work and
place parameters, or a fence, around the project before the plans are developed. When the subject of technical
objectives is raised, references to the requirements of the end product or to the deliverable are often made.
The requirements are the components of the specifications of a deliverable defined by the project manager and
the project client. The definition of the requirements occurs after the goal of the project has been given to the
project manager but before the detailed plan for the project is created. The requirements describe the desired
features or performance characteristics of the product in quantifiable terms, necessary so that the results can
be measured. One of the problems with requirements is that they tend to overlap, and there is always some
question as to where one begins and another leaves off. Nevertheless, overlapping should not be regarded as a
disadvantage, because it tends to ensure comprehensive coverage of the desired attributes of the end product.
There are a number of possible requirements for describing and measuring a deliverable:
Requirements for Describing and Measuring a Deliverable
• Quality, performance, and quantity
• Reliability and maintainability
• Capability to survive
• Operability
• Manufacturability
• Flexibility
• Regulatory compliance
• Materials use
• Community relations and corporate image



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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Quality, Performance, and Quantity
Title

Quality is a broad and complex requirement. It can be described as excellence, robustness, or a level of
perfection in the product. Performance is usually more specific and may also be composed of additional
considerations. Performance may be measurable in terms of miles per hour or tensile strength, for example, or
----------- it can be discussed in nonmeasurable terms, such as the end users™ level of satisfaction with the way a product
functions. The requirement of quantity raises the question, When does the project end? Clearly if the objective
of the project is to produce seven identical items, project management may be utilized to manage the entire
effort until the seventh item has been delivered. But what if the quantity is 25,000 items to be produced over a
period of several years? Should project management be used to control the production effort? Probably not.
Nevertheless, a definition of completion of the project is required in order to plan for the transition from
project management to production management. This definition might be the completion of a pilot
manufacturing run or the point at which the bill of materials for the product is initiated in the computer. The
point is to have a tangible definition.

Reliability and Maintainability
Reliability is defined as mean time between failures or mean time to replacement of a component, part,
subsystem, or system. It can also refer to the useful life of the product. In both cases, the desired level of
reliability should be part of the definition of the objectives of the project. Maintainability is the mean time to
repair or replace a component, part, subsystem, or system. The end product must be designed to support the
level of maintainability that the end user desires. There is often an interplay between reliability and
maintainability; one drives the other. Many companies trade on the reliability or maintainability of their
products (e.g., the loneliness of the Maytag repairman).

Capability to Survive
This function relates to the capability of the end-of-work product to endure in its environment. Issues like the
range of temperatures and relative humidity in which the product can operate are considered to be part of
survivability. In addition, the ability to transport a computer, handle it roughly, and have it operate well can
be a survivability criterion.

Operability
Is the user able to operate the product? The size of the work crew required to operate the product is part of this
issue, as is the amount of training required for its successful operation. Operability refers to many of the
issues of system or product design that are commonly known as human engineering issues. Operability is one
of the areas of the project technical objectives that tend to be overlooked and can have serious implications
once the product has been delivered to the end user or client.

Manufacturability
Can the project team or the recipient of the design manufacture the product? Manufacturability has an image
of smokestack industries and the fabrication of complex industrial equipment, but it is an issue in other
industries as well. For example, in the area of software development, programmers need to be able to create
the necessary code from the product design. In the construction industry, manufacturability is replaced by
structurability. Regardless of industry type, manufacturability can and should be defined and specified.

Flexibility
Flexibility generally refers to an attempt to produce an end-of-work item that has multiple applications or can
be put to use in a number of areas. Modularity is related to flexibility. Building the end-of-work item from
standard modules or designing it as a complex of standard modules can enable the modules to be used for
other applications in the future, thereby increasing the return on investment for the project.

Regulatory Compliance
Regulatory compliance refers to the international, national, state, and local or municipal regulations with
which the project may have to comply. In addition, project standards may be determined by private
organizations such as Underwriters Laboratories, Inc., and/or the organization performing the project. Even
within an organization, corporate, divisional, and/or departmental standards may exist. All of these sources
comprise the body of regulations with which the project may have to comply.

Materials Use
A project team can often find itself constrained by the organization™s preference for certain types of material.
The Brick and Masonry Institute, for instance, probably would not favor a headquarters facility constructed
with aluminum siding. Related requirements are packaging and product appearance.

Community Relations and Corporate Image
Community relations is particularly important in construction project management, where concern with
disruptions in the neighborhood of the construction is part of the project team™s mandate. Community
relations often becomes an issue in other types of projects as well, such as the installation of communications
equipment that might interfere with television reception or the installation of high-voltage power lines that
could cause environmental damage. Corporate image, a more global concern, can affect the packaging of
products, serve as the basis for the approval or killing of certain projects, or affect materials use.
Project requirements serve as the basis upon which the plan is built. Part of the challenge to project teams is to
make sure that all of the requirements have been identified prior to submitting a project plan. The result will
be a better plan, with fewer errors of omission during the course of the project. The requirements should be
quantified in order to measure the project team™s performance. Let™s take a look at two examples and decide
what is wrong with the way the project requirement is stated:
1. “The new system must be better than anything we have used in the past.” What does better mean?
What is the standard-of-performance criterion that will equate itself to “better” after the project is
complete? Do we have a standard-of-performance criterion for current productivity against which we
can compare future productivity after the system is installed?
2. “You have to understand that this will be the greatest thing since sliced white bread, and our
company cannot survive without it.” This explains the why, not the what. Although it is essential that
the project client and manager understand the why, the what must be defined.
Documenting the answers to these questions in the form of a proposal or business case sets the stage for the
remainder of the project. It requires a concentrated, sustained effort. However, the return on investment for
the time and effort spent will be significant.
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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Conducting Focused Interviews With the Project Client
Title

In order to understand and to document the project requirements and objectives, you as project manager need
to interview the project client to determine what belongs within the scope of the project, what work needs to
be done, when the end product is needed, who needs to be involved, and any additional considerations. Here
-----------
are some questions to ask the project client:
Determining the Client™s Objectives
• What do you really want?
• Is there a specific time when you need it? What circumstances have mandated this time frame?
• What are the exclusions, if any (for example, the new product will not be sold outside the United
States)? What specifications do not have to be included in this project?
• By what standard will you measure the end product?
• How do you see the end product performing?
• What will be the use(s) for the end product?

Creating a Context for the Project
• Why do you want the project done?
• Why now?
• What have you tried before, and what were the results?
• What are the risks?
• What do you foresee as the impact that this product will have in your organization and in the
marketplace?
• Are there any future implications that should be considered in addition to the short-term benefits?
• What will it cost?
• What are the tangible and intangible benefits to be realized?
Preparing the Project Initiation Documentation
Among the topics that may be addressed in the documentation for initiating a project, some are mandatory,
and others are optional. Depending on the size of the project, its visibility, and the requirements of
management or the client, select the segments that provide the best return for the effort expended.
• Problem/opportunity statement (mandatory): What is the problem or opportunity that this project
addresses? This section should provide background on the factors that led to this project and, where
appropriate, some history of what has been attempted in the past.
• Scope definition (mandatory): What are the quantifiable characteristics or end results to be achieved?
The scope definition should respond to the problem or to the opportunity. The end product might be a
specified product, process, or service.
• Completion criteria (mandatory): What needs to be done? How will it be measured in the most
objective terms? How will we know when we™re finished? The completion criteria should indicate
whether it is the design, the prototype, or a complete working product, system, or process that is the
goal. Consequently, this completion criterion or standard of performance needs to be quantifiable. The
objective is to eliminate subjective analysis after the completion of the project.
• Assumptions (optional): What has been assumed? Is everyone aware of these assumptions?
Remember that what you, the project manager, assume will form the basis upon which to build the
project plans. If the other people on the team, particularly the client, have not made the same
assumptions, there will be a major variance in expectations.
• Impact statement and interfaces (optional): Upon whom or what will this project have an impact or
an interface? Most projects do not exist in a vacuum. The creation of their end products may have a
ripple effect within the organization, outside the organization, or both. These impacts may have either a
beneficial or detrimental effect, so they should be documented and evaluated.
• Risk (optional): What are the risks of doing or not doing this project? One variation of risk analysis
can be a detailed mathematical presentation with which to project the financial and other ramifications.
Another variation is to provide a business analysis of the major risks and rewards that provide the basis
for deciding whether it is prudent to proceed with the project.
• Resource requirements (optional): What resources will be required? This section should alert
particular areas of the organization that their staff members will be required to support this project. You
may also want to announce whether you will need any special or unusual resources for the project. Do
not make definitive specifications at this point since you do not have enough information to plan.
Rather, include a generic statement of skill mixes that will be eventually requested.
• Constraints (optional): Are there any special constraints imposed upon the project? These could be
environmental factors such as terrain, weather conditions, or Environmental Protection Agency
requirements. There may be constraints imposed by equipment, technology, or chronological
limitations to be considered. Get them out on the table at the beginning of the project so that you will
have the opportunity to reevaluate and pursue alternative solutions.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 3
Building the Project Team
Building the project team is your primary and most critical task. Your success is based on choosing the right
-----------
team members and obtaining their commitment to the project. In this chapter we describe the typical process
for assembling a project team, explore in detail the ways to build a strong and successful project team, and
discuss the factors that affect a team™s performance during the course of the project.

Assembling the Project Team
Typically, you should begin assembling a project team while developing the work breakdown structure
(WBS) for the project because that is when the skills required to execute the project become apparent. Assess
the ability of your permanently assigned staff to fill the project requirements. If there are required skills that
they do not have, identify other sources of personnel possessing these skills.
Once you have identified these sources, begin your negotiations to assemble the project team. Approach each
supervisor of personnel with the required skills and explain the nature of the project and the assignment. If
you can™t obtain a commitment from the supervisor to support the project, investigate alternative sources or
raise the problem with senior management in order to get assistance in obtaining the required commitment.
Even after the individual in question has been assigned to your team, you may need to conduct subsequent
negotiations with the person™s supervisor. For example, the project might call for the participation of multiple
members of the skill group on the project, or it might require a long-term commitment of a key member of the
group.
The organization™s structure and distribution of authority will affect the nature of these negotiations. In some
cases, you may find it necessary to alter the project™s schedule and budget to accommodate the availability of
the staff you need. In other situations, the skill group manager may find it necessary to alter other priorities to
accommodate the demands of the project. In either case, after the negotiations are completed, the head of the
skill group will be asked to assign specific staff members to accommodate the project plan. Nevertheless, if
you are still unable to obtain specific assignments to the plan from the supervisor, you may have to investigate
alternative sources of the required skill or go to senior management for a decision on the relative priority of
the project versus other components of the skill group™s workload.
There are a variety of objective or technical criteria to use in choosing the team members: perceived technical
ability, estimating proficiency, project management skills, experience as a task leader on other projects, and
attitude toward this project and toward projects in general. Often it is the subjective or personal attributes that
are critical ” for example, prior experience with the subject matter, information from fellow project
managers, or an opinion based on casual contact with the individual offered as a team member. For these and
similar reasons, we suggest that you talk to potential team members before negotiating to have them join the
project. In order to determine the potential effectiveness of prospective team members, you need answers to
the following key questions:
What to Look for in Prospective Team Members
1. Would I want this individual working for me?
2. Would I want this individual as one of my peers?
3. Would I want to work for this individual?

Defining and Documenting Team Member Commitment
In order to obtain commitment from team members, it is important to define and document their contributions
to the team. Two tools can help you here: the skills inventory matrix and the responsibility matrix.

Skills Inventory Matrix
Every project requires a variety of skills that will need to be matched to the appropriate tasks. In the beginning
of the project, it is important that you appropriately match people, skills, and tasks. As the project progresses,
it may be necessary to split assignments, add staff to existing assignments, or trade assignments. In order to
have this flexibility, you need to know which people on the project team possess which skills. In many cases,
you will already have this information.
If you want to codify an inventory of the skills available from your project team, we suggest using or adapting
the skills inventory matrix shown in Figure 3-1. Set up a simple matrix form with the skills or areas of
expertise depicted along the x-axis and the resources (people) along the y-axis. Then place a checkmark in the
box indicating which skill(s) each team member possesses. In this way, you create a useful overview of team
members and skills from which to assign tasks.




Figure 3-1 Skills inventory matrix by area of expertise.

Responsibility Matrix
Now consider who on the project team is most qualified to perform each task. In order to do this, develop a
responsibility matrix (Figure 3-2). This matrix is the documentation of a performance contract among the
project manager, the project team members, and their supervisors. It is an important mechanism for obtaining
individual commitment, or buy-in, and for graphically depicting that responsibility.
To develop the matrix, list the tasks on the left axis and the names or job titles of the project team members
along the top. Then match the tasks to the members by indicating the person with prime responsibility (P) and
those having support responsibility (S). Each task requires one and only one prime; several supporting team
members may be assigned. The team member with prime responsibility is accountable for ensuring that the
task comes in on time, within budget, and at the expected level of quality. Those in a support capacity are
chosen because they have skills needed on that task. Follow these five rules of thumb when preparing a
responsibility matrix:
Preparing a Responsibility Matrix
1. Assign staff because they have the correct skills, not because they have time available.
2. Do not assign too many people to one task.
3. Obtain buy-in from team members: “ask,” don™t “tell.”
4. Consider who is good at what, who wants to do what, who can or cannot work together, and who
likes to create versus maintain.
5. From the perspective of the project, consider what skills are needed, what skills are available, and,
if someone left a task, whether his or her work could be redistributed.

Ideally, as the project manager, you have some exposure to these areas of responsibility. This background ”
coupled with intuition, a bit of psychology, and a bit of luck ” can make the task of assigning responsibility

<< . .

. 2
( : 16)



. . >>