PPM 301 - Project Management

Section 3. Alternative Project Applications


This lesson discusses various uses of projects and project teams. Objectives important to this lesson:

  1. Alternative project teams
  2. Reengineering through project teams
  3. Management of small projects
  4. Self-managed production teams
  5. Benchmarking teams
  6. Managing change by project management

The chapter 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?

Traditional Teams

  • 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

Non-traditional Teams

  • 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.

Reengineering Teams

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 like these.

Small Projects

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.

On 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 phase.
  • 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.

Benchmarking Teams

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
  • generic 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.

Managing Change

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 management.

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:

  1. Identify the problem
  2. State the need for change
  3. State the goals of making the change
  4. Describe what the new organization will look like
  5. Establish a schedule for the change
  6. Identify the participants who will accomplish the change
  7. Determine milestones for the project
  8. 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.