|
Contents
Home Page
Book List
Seminars
and Workshops
Resources
and Links
To Order
To Contact
Us
|
 Chapter
Exerpts from
Applying Project Management in the
Workplace
The following are exerpts from each of the chapters
of Applying Project Management in the Workplace.
You may scroll through the page or click one of the links below to move
directly to a particular chapter.
Back to Book List
Chapter 1: Introduction
Chapter 2: Project Pre-Work
Chapter 3: People Skills for Project Leaders
Chapter 4: Project Planning
Chapter 5: Project Implementation
Chapter 6: Project Closure
Chapter 7: Checklists and Forms
Appendix A: A Problem-Solving Process
Appendix B: Problem-Solving Tools
Chapter 1: Introduction
"This text presents an approach to project management
that is somewhat different from those commonly used. The difference centers
around a basic assumption about how projects are handled by employees within
existing organizations:
The project manager within an organization is rarely
a manager in the traditional sense.
Frequently, individuals are given responsibility for a
project based on their expertise in the area that the project impacts.
For example, a technically-oriented individual may be given responsibility
for a development project based solely on his or her perceived expertise
in that technology — not on their management ability, position in the organization,
or experience. Project managers in organizations are almost always expected
to be active participants in the work of their projects — they are not
expected (or even allowed) to be "managers" in the traditional
sense. A more appropriate title would be "project leader."
This unique characteristic of projects undertaken within
organizations creates some problems with the generally accepted approaches
to project management. Since project leaders within organizations are frequently
not in management positions, they do not have the traditional hierarchy
behind them. They do not have common managerial responsibilities or authority
such as "hire and fire" authority; responsibility for employee
performance reviews; the power to grant raises or promotions; disciplinary
authority; etc. Even those who are managers frequently must work their
projects with personnel who do not report to them. The problems this situation
can create are not usually addressed by project management methodologies
which assume true managerial authority and responsibility as a prerequisite
for undertaking a project.
This text addresses the lack of managerial authority in
several ways:
There is an emphasis on negotiation. This is a skill which
will allow a project leader to develop a team and the technical support
assistance necessary to successfully complete a project without relying
on nonexistent authority.
There is a section dealing specifically with leadership
with an emphasis on leading project teams. There is also a section on the
origins and use of power and authority within organizations that provides
insights into how truly effective project leaders achieve goals and gather
support without relying on "position power" (power granted by
one's position within the hierarchy of the organization).
There is extensive material on developing and working
with teams made up of individuals who are not dedicated to the project
on a full-time basis.
Most of the tools, techniques and forms described in this
text are designed for non-managers."
Next Chapter
Contents
Chapter 2: Project
Pre-Work
From "Determining Needs and Wants"
"When talking with the project's customer and sponsor
about the history and background of the problem to be addressed, you can
also explore their ideas about what you should do to solve it.
There is a major caution that goes along with this:
Customers can frequently tell you what they want but they
may not be able to tell you what they need. Your job is to find out what
they need.
As a starting point, you should ask most of the following
questions:
- How do you see the problem? What are your ideas about
possible solutions that would fix it?
- Why do you think that would fix it?
- Can you see other alternatives that might also fix the
problem?
- How will you measure the success of the solution?
- What are the major requirements for a successful solution?
Armed with this basic information, you can begin to develop
a list of Needs and Wants. There is a distinct difference between a "Need"
and a "Want." For our purposes here, the following definitions
will be used:
- Need – a requirement that must be met by any solution
implemented in order for the solution to be viewed as minimally successful.
- Want – a desired outcome of the solution that, while
it may be important, is not critical to success.
Using these definitions, it should be clear that Needs
are very black and white; they are mandatory for success. If these results
are not achieved, if these resources are exceeded, if these policies are
violated, etc., the solution is a failure. Needs are either addressed by
the solution, in which case the solution meets the minimum requirements
for success or, they are not and therefore the solution fails to meet the
minimum standards of success."
Next Chapter
Contents
Previous Chapter
Chapter 3: People Skills
for Project Leaders
From the "Introduction"
"Of all the subjects in this book, this one has no
one place where it fits neatly in the flow of a normal project. The skills
discussed in this chapter are necessary throughout the life of a project.
People are the key ingredient in any project. People will
make the plans, perform the work, solve the problems, track the progress,
deliver the output. People skills are critical for any successful project
leader.
Before getting into project planning and implementation
processes, a discussion of working with people on the project team and
others within the organization is appropriate.
Project leaders in most organizations are working with
borrowed resources — people who are already scheduled by their managers
to do work unrelated to the project. Commonly, the people on your project
team do not report to you. You don't manage them. You don't write their
performance reviews. You can't grant them raises, bonuses or promotions.
They work for someone else. You only have them on loan.
In situations like this, you can't manage people in the
traditional sense of telling them what to do and expecting that they will
do it. You need to manage through influence rather than authority.
The following material covers a wide range of "people"
topics. Not all of them will apply to every situation but, the chances
are quite good that all of them will apply at one time or another during
your career as a project leader.
In this section, we will look at several aspects of working
with people, individually and on project teams. There are six subjects
which will be discussed:
- The development and use of power and authority.
- Motivation.
- Leadership.
- How teams grow and change over time.
- Negotiation.
- Communication."
Next Chapter
Contents
Previous Chapter
Chapter 4: Project Planning
From the "Introduction"
"Project planning is the most critical single activity
on any project. Without a well-thought-out plan, your project is in trouble
before you ever start to work on it.
Several points need to be made at the outset:
- Project planning, at least at the beginning, is a sloppy,
chaotic, confusing process.
- Project planning is best done by at least some members
of the project team as a group activity. It can be done by a single person,
but the process presented here is intended for, and results in a better
end product when done by, a group.
- Project planning is a repetitive process — it is done
in "layers" and the "layers" are created in successive
passes through the plan. In the first several passes, flexibility is the
key to success. If you try to finalize your plan from the beginning, you'll
find that you have forgotten pieces; others are out of their correct order;
details are missing; etc.
- Project management software is just that — project MANAGEMENT
software. It is not designed as project planning software and is not, in
most cases, appropriate (or even usable) for the planning activity.
- Project plans are almost never "set in stone."
At best, they're set in semi-firm Jell-O®. The chances that some part
of the plan will need to be changed as the project progresses are almost
100%.
- The finished project plan is the source of all the management
tools necessary to track and control the project."
Next Chapter
Contents
Previous Chapter
Chapter 5: Project Implementation
From "Set the Ground Rules"
"In reviewing the "ground rules" you should
make your expectations clear. People will generally do what you want them
to if they know what it is. Some of the issues you should consider including
in this part of the meeting are:
- The need for constant, clear, honest communication about
project activity.
- Your expectations about participation in the work of
the project as well as in project meetings and reviews.
- How conflicts will be resolved and how problems will
be solved.
- How you will keep the team updated on progress and issues
of project-wide concern.
- What you expect from team members in the way of status
reports, when you expect them and what you will do with the information.
Laying out these expectations up front, and getting agreement
about them, will save massive headaches later in the project.
There is another element that can, and usually should,
be included in the kickoff: Cheerleading. A little "motivational"
talk about the importance of the project to the organization (or some part
of it), and a reminder of the importance of success to each team member
is always in order. Don't try to turn a simple project into the moon landing
project but try to find encouraging and "inspirational" words
for whatever projects you work on."
Next Chapter
Contents
Previous Chapter
Chapter 6: Project Closure
From "Timing of the Transfer and Implementation Process"
"Particularly on internal process and software projects,
this is the big one during this stage. Exactly when and how are you and
the project team going to implement the project output in the customer's
environment? What involvement will customer personnel have in the implementation?
What support will be needed from other groups? How long will the implementation
take?
The majority of this negotiation will be between the project
leader (and possibly core-team or other project-team members) and the customer.
Virtually every project, regardless of the type, requires a close working
relationship between the project team and an internal customer. Some of
the elements of this issue are:
- When should transfer start?
- When should transfer be completed?
- Who will perform which tasks?
- What are the disruptions that are likely to occur in
the customer's work patterns during transfer?
- How will the disruptions be managed?
- What are the contingency plans needed to cover possible
problems?
- How should the training and implementation be coordinated?
- How will final adjustments be performed and by whom?
- What "fall-back" options exist if the implementation
must be aborted?
- What are the indicators that the transfer is complete?
Answering these questions before the actual transfer begins
generally results in a smoother process and the least disruption to the
customer's work patterns."
Next Chapter
Contents
Previous Chapter
Chapter 7: Checklists
and Forms
NextChapter
Contents
Previous Chapter
Appendices
Appendix A: A Problem-Solving Process
From "'As Is' and 'To Be'"
"At the foundation of any problem-solving process
is the problem statement and some idea of what a desirable solution would
look like. According to this process, a good problem statement contains
two specific parts:
The "As Is" portion of the statement contains
a description of the situation exactly as it is — with no implication of
why it is the way it is and with no indication of what should be done about
it. This portion of the statement should be based on facts as much as possible.
For example:
- Employees rate the food selection, quality and service
in the company cafeteria at 2.3 on a scale of 1 to 5 (with 1 being lowest
and 5 being highest) according to a survey conducted on March 1st of this
year.
This statement simply states the facts according to the
survey. There is no indication of why the employees don't think much of
their cafeteria. There is no indication that, for instance, hiring more
servers or offering a wider variety of food would solve the problem. In
fact, from this statement, the solution (or solutions) are not at all clear.
The "To Be" portion of a good problem statement
contains the desired outcome of solving the problem. It does not contain
any indication of how the problem will be solved — only how we will know
that it has been solved. For example:
- Employees will rate the overall food selection, quality
and service in the company cafeteria at 4 or above when the March 1st survey
is re-administered in July of this year.
There is no indication of how this improvement will be
accomplished. This statement simply provides a statement of how to determine
whether the problem was solved.
Working on a problem stated in this manner requires that
the problem be analyzed to determine exactly why the "as is"
situation exists and how the "To Be" condition can be achieved.
Defining problems using this method will go a long way
toward preventing jumping into solutions without really looking at the
problem."
Next Chapter
Contents
Previous Chapter
Appendix B: Problem-Solving
Tools
Solution Selection Worksheet
Contents
Previous Appendix
|
Just
Released:
