PPM 301 - Project Management
Section 3. Alternative Project Applications
This lesson discusses various uses of projects and project
important to this lesson:
- Alternative project teams
- Reengineering through project teams
- Management of small projects
- Self-managed production teams
- Benchmarking teams
- Managing change by project management
begins with a discussion about traditional an non-traditional
project teams. The authors explain that most of this text is about work
that is done by traditional teams, but this chapter will discuss work
that is appropriate for non-traditional teams. First, what is the
difference between the two types?
- typically concerned with design, development, and construction of physical entities for an organization
- they follow a traditional life cycle
- they are used in projects that require substantial resources of various types
- this is the most common type of team, used throughout history
- usually created in support of an organizational process that already exists.
- often created to improve efficiency and effectiveness of the organization
- usually deal with identification and improved use of resources instead of new hardware
- can be used for several purposes (see below)
- may be used for strategic initiatives
- can be used to implement cultural change in the enterprise
On page 89, the
text discusses several special purposes that non-traditional teams have been used for. Some of them are:
- market assessment and research - determining changes in the market and possibilities for improvement or new products
- competitive assessment - assessing one's competition in order to make plans that provide for it
- organizational strengths and weaknesses - evaluating internal characteristics to find points to improve
- benchmarking - reviewing what industry leaders are doing, so we can follow suit or improve ourselves
- establishing performance standards - determining how well we are doing and where we could improve
- vision establishment - examining future trends to adjust our vision statement
- stakeholder evaluation - determining who our stakeholders are and what is important to them
- reengineering - determining whether we should continue as we are, or recreate the processes that we use
- crisis management - the purpose of such a team depends on the crisis it is meant to handle
- quality improvement - as several other bullet points mention, we can use this kind of team to determine what we can do better
The text continues with several detailed discussions about teams that are dedicated to specific purposes.
Teams that are tasked with reengineering are usually working on processes used by an organization. The text offers some key questions to ask about processes:
- What business are you in?
- What are the processes that we use? How do they work?
- Why are those processes used? Do they accomplish what we need from them?
- Why are our processes done the way we do them? Can they be improved?
The text points out that reengineering can lead to reorganization or elimination of jobs. The possibility of losing jobs generally causes fear, uncertainty, and doubt
(FUD) among the staff of the organization, which is counter productive
to the reengineering process. This is doubly so for the reengineering
team if its members are drawn from the organization itself, as the text
suggests on page 94. The text offers several suggestions for reducing the effects of these negative perceptions.
- Keep the staff updated about the purpose, the activities, and the outcomes of the reengineering team.
- Provide assistance to people who will be displaced
by the reengineering process. The text words this oddly. Jobs may be
eliminated. People are not eliminated, unless we are involved in
criminal activities. (You don't have to be told not to hurt people, do
you? Primum non nocere.)
- Determine what the staff are perceiving and feeling about the process. Deal with their problems, complaints, and attitudes truthfully and helpfully.
The text presents a list of messages of reengineering on page 93 which seem
to be full of self-importance and reliance on slogans. We will ignore
this section, because it is at odds with the slightly more humane
attitude of the previous section.
The text offers some suggestions about reengineering on page 94. They apply to other kinds of projects as well.
- Establish specific and measurable goals.
- Draw team members from the key functional areas involved in the reengineering process to serve as subject matter experts.
- Establish an understanding about how how people will
interact in the project, how decisions will be made, and what outcomes
will be produced.
- Establish authority and responsibility for the project.
On page 95, the text presents a long bulleted list of steps in the life cycle of a reengineering project. Many are the same steps you would find in a software development project. The main difference is conducting a study first to determine whether there are any areas in the organization that might benefit from reengineering, then selecting from among the candidate areas the actual targets for the project.
This section ends with a list of "trigger events" associated
with reengineering. These are goals that might be realized if a
reengineering project is successful, if these were the goals of the
project, and if the culture of the organization supports them. These
goals will not be realized if the organization does not seek changes
The text continues with a discussion of work done on small projects. It presents several definitions of what a small project is.
- PMBOK says a small project will run thirty days or less. The text says it may run up to three or four months.
- There may be one decision maker.
- Small projects may be measured by their budget. The text
suggests budgets between $5000 and $50,000 are small. Of course, this
will vary in the context of the budget of the organization.
- Small teams may determine small projects. The text suggests no more than five members on the project team.
- The text offers some examples of small projects. The common factor among them seems to be a small scope or purpose.
page 97, the text provides a list of six steps to use in managing a
small project. As above, they apply to larger projects as well.
- identify the need for the project, the desired outcome, the funding source, the customer's perception of the problem
- plan the project -
what are the goals? what are the work units? what is the schedule? how
will we evaluate the project? what are the deliverables?
- collect information: what do we do now? why? what do we want to do? use several techniques: interviews, observation, review of existing documents
- analyze data: what works? what does not work?
- develop and evaluate alternatives: brainstorm ideas, rate the ideas on their probable benefits, select a best choice with the customer
- present recommendations: report findings, conduct a lessons learned session with the staff
As you should note from the last step above, small projects
are often fact finding projects whose output is more likely to be a
recommendation than a change in the organization.
Self-Managed Production Teams (SMPT)
The text explains that this kind of team manages its own
processes and creates the goods and services that are its part of what
its organization does. This kind of team is more autonomous than
production teams in other environments.
The text offers us a short list of phases that may be used
when setting up teams of this sort. Each phase has several bullet
points, shown on pages 102 through 104.
- Conceptual phase -
Gather information on other organizations who have been successful with
SMPTs, design a training program, and develop a statement of the SMPT's
authority and responsibility.
- Education and training
phase - Train staff in all skills needed by the team, including
technical, social, team building, conflict resolution, management, and
overall fit in the organization.
- Gaining commitment
phase - Get commitment from the organization and the team members to
function according to the requirements developed in the conceptual
- Steady state operation phase - The SMPT concept becomes a standard part of the organization.
The text tells us that SMPTs move some duties from being the
responsibilities of a first level manager to being general
responsibilities of the whole team. Some of these responsibilities are quality control, safety, planning, hiring, and training.
Assignment 1: Form a
group. Consider the list of causes of failure for SMPTs that appears on
page 106. Pick three of the causes. Discuss the problems in your group,
and propose one or more methods of addressing each of your chosen
problem areas. Give examples of what you would have the team do that
would address the problems.
A benchmarking team may have one of three general purposes, listed on page 107:
- competitive benchmarking - determining how our organization measures up when compared to our competitors
- best-in-the-industry benchmarking - determining
how our organization measures up when compared to several organizations
that are recognized as the best in our industry
benchmarking - determining how our organization measures up when
compared to business practices that are recommended across industries
The text explains that any area of production or service might be something you can benchmark. Like other project teams, a benchmarking team should communicate with management and staff about its information gathering methods, the data gathered, its analysis of the data, and its recommendations.
As the text recommends about other project teams, this team will find
it difficult to do its job without the endorsement of all levels of
management. If the boss doesn't tell people that something is
important, they are unlikely to put an effort into helping it happen.
The last section in the chapter deals with change management,
which is a large topic. In a large organization, you are more likely to
see a project team created for this purpose than for any other purpose
in the chapter. The text warns us that change is often perceived as a threat, which causes staff to become enemies of change. A goal of change management is to overcome fear, uncertainty, and doubt, and to build trust among those the change will affect.
Note the two graphics on pages 110 and 111. They both make the point that we will fail in our project if we do not sell
our reasons for change to the relevant stakeholders. Yes, some
organizations are run by despots who can mandate any rule or change
they wish. Even in such environments, there will be some form of
resistance that we could do without by using appropriate change
Note the list of negative reactions to change that appears on
page 113. The text tells us that this is a sequence of attitudes and
events that typically occurs when change management is not used. It is
interesting to me that it has five stages, and is similar to the five stages of grief made famous by Elisabeth Kübler-Ross.
- disruption of work
- denial of change
- realization of change
- negotiating change
- acceptance of change
It is tempting to think that the last stage leads to a happy
outcome, but consider the text's description of it on page 113. We are
told that people are working in a productive manner, but we are also
told that they have feelings of helplessness and depression. This is
not a state of mind that leads to productivity.
Compare this unmanaged model with the list of steps in making a plan for a change management project at the top of page 112:
- Identify the problem
- State the need for change
- State the goals of making the change
- Describe what the new organization will look like
- Establish a schedule for the change
- Identify the participants who will accomplish the change
- Determine milestones for the project
- Plan a celebration for the end of the project
It should be clear to you at this point that you will need to communicate this plan to all stakeholders in such a way that they can discuss it, contribute to it, modify it, and finally accept it as a good plan.
The plan above is a better plan than the one on page 114. We should discuss why this is so, so that will become the second assignment for this section.