The Human Side of Project Management

Information Technology Project Management. Providing Measurable Organizational Value, Third Edition
Chapter 4: The Human Side of Project Management

ISBN: 9780470371930 Author: Jack T. Marchewka
copyright © 2009 John Wiley & Sons Inc.
The Human Side of Project Management

Chapter Overview

Chapter 4 focuses on the human side of project management. After studying this chapter, you should understand and be able to:

* Describe the three major types of formal organizational structures: functional, pure project, and matrix.
* Discuss the advantages and disadvantages of the functional, pure project, and matrix organizational structures.
* Describe the informal organization.
* Develop a stakeholder analysis.
* Describe the difference between a work group and a team.
* Describe and apply the concept of learning cycles and lessons learned as a basis for knowledge management.

Introduction

The key ingredients to IT project management are people, processes, and technology. Technology is a tool, while processes provide a structure and path for managing and carrying out the project. The success of a project, however, is often determined by the various project stakeholders, as well as who is (or who is not) on the project team.

In this chapter, we will discuss the human side of project management. According to the PMBOK Guide®, the processes under the knowledge area of project human resources management entail:

* Human resource planning—The creation of a staffing management plan. Includes identifying and documenting the various project roles, responsibilities, and reporting relationships.
* Acquiring the project team—Members of the project team with required skills and experience need to be recruited, hired, or acquired from within or outside the organization. The objective for every project manager is to staff a project with the best available people. Effective staffing involves having policies, procedures, and practices to guide the recruitment of appropriately skilled and experienced staff. This may include negotiating for people from other functional areas within the organization.
* Developing the project team—Often the technical, organizational, or interpersonal skills of the project team members may have to be augmented through training and so forth in order to improve their competencies and interactions as a team. Team development also involves creating an environment to develop and support the individual team members and the team itself.
* Managing the project team—Today, this can become a real challenge, as project teams may be spread across geographic locations, time zones, and even organizations when components of the project work are subcontracted or outsourced to subteams. Regardless, each team member’s performance must be tracked so that issues can be resolved quickly and changes to the project work can be coordinated. Each person’s quality of work and contribution to the project should be documented so that feedback in the form of performance reviews can help each member of the project team grow both professionally and personally.

This chapter will expand upon three PMBOK® concepts and integrate several relatively recent concepts for understanding the human side of IT project management. In the next section, we will focus on project and organizational planning. Three primary organizational structures—the functional, project, and matrix—will be described. In addition, the various opportunities and challenges for projects conducted under each structure will be discussed. As a project manager or project team member, it is important to understand an organization’s structure since this will determine authorities, roles, responsibilities, communication channels, and availability of resources.

While the formal organizational structure defines official roles, responsibilities, and reporting relationships, informal relationships will exist as well. It is important to understand why these informal structures and relationships exist and how they can influence the relationships among the different project stakeholders. In addition, understanding both the formal and informal organizations will help you to understand not only who makes certain decisions, but also why certain decisions are made.

We will also focus on the various roles of the project manager. In general, one of the greatest responsibilities of the project manager is the selection and recruitment of the project team. Once the project team is in place, the project manager must also ensure that the project team members work together to achieve the project’s MOV. Therefore, the language and discipline of real teams versus work groups will be introduced. These concepts will provide the basis for understanding the dynamics of the project team.

Once the project team is in place, it is important that the project team members learn from each other and from past project experiences. Thus, the idea of learning cycles will be introduced as a tool for team learning and for capturing lessons learned that can be documented, stored, and retrieved using a knowledge management system.

In the last section of this chapter, we will focus on the project environment. In addition to staffing the project, the project manager must create an environment to support the project team. If necessary, this includes appropriating a suitable place for the team to work and ensuring that the team has the proper tools and supplies needed to accomplish their work.
Organization and Project Planning

The performance of an organization or a project is influenced largely by how well its resources are organized. In general, structures are created within an organization to manage the input, processing, and output of resources. For example, departments or areas based on the specialized skills needed to manage a particular resource are created—that is, accounting and finance manages the money resources, personnel manages the human resources, and information systems manages the information resource. As a result, many organizations adopt a structure based upon function. Other organizations may adopt a structure based on the products it sells or its customers. These structures may use brand management or geographical divisions.

However, the structure of an organization must fit its strategy, and since organizations may follow different strategies, it makes sense that no single structure can work well for every organization. Therefore, there are different organizational structures and ways to efficiently and effectively manage not only the organizational resources but the work and processes involved. As long as the firm performs well, a particular structure and strategy will exist. On the other hand, when a firm performs poorly, a change in structure and/or strategy may be required.

Projects are part of an organization and can be thought of as micro organizations that require resources, processes, and structure. Moreover, these resources, processes, and structures are determined largely by the organizational structure of the supporting or parent organization, which may determine or influence the availability of resources, reporting relationships, and project roles and responsibilities. Therefore, it is important to understand how the project interfaces with the host or parent organization and how the project itself will be organized. In this section, we will focus on three formal structures that tie projects explicitly to the organization. Each structure provides distinct opportunities and challenges, and choosing and implementing the correct structure can have a major impact on both the project and the organization.
The Formal Organization

An organization’s structure reveals the formal groupings and specializations of activities. Generally, these groupings and activities are documented in an organizational chart to clarify and portray the lines of authority, communication, reporting relationships, and responsibilities of individuals and groups within the organization. Although an organization’s formal structure does not tell us anything about the informal lines of communication among its subunits, it does provide us with an indication of how a project will interface with the parent or supporting organization. In other words, the formal organizational structure will determine how resources are allocated, who has authority over those resources, and who is really in charge of the project.

Figure 4.1 illustrates the three most common structures—the functional, matrix, and project-based organization. Keep in mind that these organizations are not exhaustive—they represent a continuum of approaches that may evolve over time or as the result of a unique situation. An organization may choose to combine these forms any number of ways to create a hybrid organization such as a functional matrix or project matrix.

Figure 4.1 Organizational Structures

[Click to enlarge]
The Functional Organization

The functional organizational structure may be thought of as the more traditional organizational form. This particular structure is based upon organizing resources to perform specialized tasks or activities in order to attain the goals of the organization. As Figure 4.2 illustrates, individuals and subunits (i.e., groups of individuals) perform similar functions and have similar areas of expertise. Subsequently, projects are managed within the existing functional hierarchy.

Figure 4.2 Functional Organizational Structure

[Click to enlarge]

Projects in a functional organization are typically coordinated through customary channels and housed within a particular function. For example, a project to install a new machine would be a self-contained project within the manufacturing function because the expertise required for the project would reside within the manufacturing subunit. The project manager would most likely be a senior manufacturing manager, and the project team would be made up of individuals from the engineering and production areas. As a result, the manufacturing subunit would be responsible for managing the project and for supplying and coordinating all of the resources dedicated to the project.

However, a project may cross functional boundaries. In the case of an information technology project, the knowledge and expertise to design and develop an application may reside in the information systems subunit, while the domain or functional knowledge resides in one of the functional subunits. As a result, the project team may consist of individuals from two or more functional areas. There are two main issues that must be resolved at the outset of a project: Who will be responsible for the project? What resources will each subunit provide?

There are a number of advantages for projects sponsored by organizations with functional structures. These include:

* Increased flexibility—Subject matter experts and other resources can be assigned to the project as needed. In addition, an individual can be part of the project team on a full-time or part-time basis. Once the project is completed, the project team members can return to their respective functional units.
* Breadth and depth of knowledge and experience—Individuals from a particular subunit can bring a wealth of knowledge, expertise, and experience to the project. This knowledge can be expanded even further as a result of their experiences with the project. As a result, the project experience may lead to greater opportunities for career advancement within the subunit. If the project crosses functional areas, an opportunity exists for these individuals to learn from each so that a less parochial solution can be developed.
* Less duplication—Coordination of resources and activities can lead to less duplication of resources across projects since specialization of skills and resources are housed within a functional area. The project also tends to be more focused because a primary functional area is responsible for and ultimately takes ownership of the project.

There are, however, several disadvantages associated with projects sponsored by organizations with functional structures. These include:

* Determining authority and responsibility—As was mentioned previously, determining who has authority and responsibility for a project must be resolved at the outset, especially when the project involves more than one functional area. For example, in an IT project, will the project manager be from the IS department or from the functional area? A project manager from the IS area may have knowledge and expertise with respect to the technology, but lack critical knowledge about the business. On the other hand, a project manager from the functional area may understand the business, but lack an understanding of the technology. Furthermore, there is a chance that the project manager will have an insular view of the project—that is, the project manager’s allegiance and loyalty to a particular functional area may lead her or him to focus primarily on the interests of that area. The likelihood of this happening increases when the project expands across several functional boundaries. Other functional areas may begin to ask if there is anything in it for them and withhold resources unless their needs and expectations are met. The project manager may not have the authority for acquiring and providing the resources, but will certainly be accountable for the failure of the project.
* Poor response time—The normal lines of authority and communication delineated by the functional structure determine who makes specific decisions. Projects may take longer if important decisions have to pass through several layers of management and across several functional areas. Unfortunately, what’s important to you may not be important to me if a particular functional unit has a dominant role or interest in a project. Due to the potential for parochial interests, problem resolution may break down because of finger pointing or trying to place blame for the problem rather than focusing on problem resolution.
* Poor integration—The culture of the organization may encourage functional areas to insulate themselves from the rest of the organization as a way to avoid many of these parochial issues. However, this can result in two problems. First, the individuals in a functional area may act in their own best interests instead of taking a holistic or organizational view of the project. Second, the functional area may attempt to become self-sufficient by acquiring knowledge, expertise, and technology outside of its normal area of specialization. While specialization of skills and resources can reduce duplication of activities and resources, the functional structure can also increase this duplication. It may lead to an organization of warring tribes as functional areas compete for resources and blur lines of responsibility.

The Project Organization

At the other end of the spectrum from the functional organization is the project organization (see Figure 4.3). Sometimes referred to as the pure project organization, this organizational structure supports projects as the dominant form of business. Typically, a project organization will support multiple projects at one time and integrate project management tools and techniques throughout the organization. Each project is treated as a separate and relatively independent unit within the organization. The project manager has sole authority over and responsibility for the project and its resources, while the parent or supporting organization provides financial and administrative controls. Both the project manager and the project team are typically assigned to a particular project on a full-time basis.

Figure 4.3 The Project Organization

[Click to enlarge]

There are advantages and disadvantages associated with projects supported by the project organization. Advantages include:

* Clear authority and responsibility—Unlike the projects in a functional organization, the project manager here is fully in charge. Although he or she must provide progress reports and is ultimately responsible to someone who has authority over all the projects (e.g., a program manager), the project manager has full authority over and responsibility for the assigned project. Moreover, the project team reports directly to the project manager, thus providing clear unity of command. This structure may allow the project team to better concentrate on the project.
* Improved communication—A clear line of authority results in more effective and efficient communication. In addition, lines of communication are shortened because the project manager is able to bypass the normal channels of distribution associated with the functional organizational structure. This structure thus results in more efficient communication and fewer communication problems.
* High level of integration—Since communication across the organization is increased, the potential for a higher level of cross integration across the organization exists. For example, the project team may include experts with technical skills or knowledge of the business. Fewer conflicts over resources arise since each project has resources dedicated solely to it.

Projects supported by project organization structures face several disadvantages. These disadvantages include:

* Project isolation—Since each project may be thought of as a self-contained unit, there is the potential for each project to become isolated from other projects in the organization. Unless a project management office or program manager oversees each project, inconsistencies in policies and project management approaches may occur across projects. In addition, project managers and project teams may have little opportunity to share ideas and experiences with other project managers and project teams, thus hindering learning throughout the organization.
* Duplication of effort—While the potential for conflicts over resources is reduced, various projects may require resources that are duplicated on other projects. Project managers may try to stockpile the best people and other resources that could be shared with other projects. Each project must then support the salaries of people who are part of the dedicated project team but whose services are not needed at all times. There is then the problem of what to do with these people when the project is completed and they have not been assigned to another project. Many consulting firms, for example, refer to people who are between projects as being on the beach or on the bench. While awaiting the next assignment, consultants are often sent to training in order to make the most of their idle time.
* Projectitis—Projectitis sometimes occurs when the project manager and project team develop a strong attachment to the project and to each other. As a result, these individuals may have a difficult time letting go, and the project begins to take on a life of its own with no real end in sight (Meredith and Mantel 2000). The program manager or project office must ensure that proper controls are in place to reduce the likelihood of this happening.

The Matrix Organization

The third type of organizational form is the matrix structure. The matrix organization is a combination of the vertical functional structure and the horizontal project structure (see Figure 4.4). As a result, the matrix organization provides many of the opportunities and challenges associated with the functional and project organizations.

Figure 4.4 Matrix Organization

[Click to enlarge]

The main feature of the matrix organization is the ability to integrate areas and resources throughout an organization. Moreover, people with specialized skills can be assigned to the project either on a part-time or on a more permanent basis. Unfortunately, unity of command is violated since each project team member will have more than one boss, leading to the possibility of confusion, frustration, conflict, and mixed loyalties. The functional manager will be responsible for providing many of the people and other resources to the project, while the project manager is responsible for coordinating these resources. In short, the project manager coordinates all the project activities for the functional areas, while the functional areas provide the wherewithal to carry out those activities.

The matrix organization can take on various forms that can create hybrid organizations. The most common forms include:

* Balanced matrix—In the balanced matrix form, the project manager focuses on defining all of the activities of the project, while the functional managers determine how those activities will be carried out.
* Functional matrix—The functional matrix organization tends to take on more of the qualities of a functional organization. Here the project manager focuses on coordinating the project activities, while the functional managers are responsible for completing those activities that are related to their particular area.
* Project matrix—It follows, then, that a project matrix structure would take on more of the qualities of a project organization. In this case, the project manager has most of the authority and responsibility for defining and completing the project activities, while the functional managers provide guidance and resources, as needed.

There are several advantages and disadvantages for projects supported by a matrix organization. The advantages include:

* High level of integration—The cross-functional nature of the matrix structure allows for the access and sharing of skilled people and resources from across the organization, and people within the organization can be assigned to more than one project. This ability to share can result in less duplication of resources and activities.
* Improved communication—Due to the high level of integration, communication channels are more efficient and effective. As a result, problems and issues can be addressed by the project manager and functional managers, and decisions can be made more quickly than in a functional organization.
* Increased project focus—Because a project under the matrix organization has improved communication channels and access to a repository of resources and skilled expertise, the project team can focus on the activities of the project. This ability to focus should increase the likelihood of projects being completed on time and meeting the needs of the organization better.

On the other hand, there are several disadvantages for projects supported by the matrix organization. These include:

* Higher potential for conflict—Since power is distributed, project team members may wonder who really is their boss. They may receive conflicting orders, especially if the project and functional area managers have different goals or are fighting over scarce resources. In general, power may depend on which manager has the fewest direct reports to the chief executive office. The project manager may be required to be a skillful mediator and negotiator in order to keep the project on track.
* Poorer response time—Because the concept of unity of command is violated in a matrix structure, there can be confusion, mixed loyalties, and various distributions of power. Communication can become bogged down, and decisions may require agreement from individuals who are in conflict with each other. As a result, the project may stall and the project team may begin to experience low morale, little motivation, and the pressure to pick sides.

Which Organizational Structure Is Best?

Unfortunately, there are no simple answers. It really depends on factors such as the nature of the organization’s products and services it provides, the business environment, and its culture—that is, the personality of the organization. Projects supported under a functional organizational structure may work best when the organization focuses on a few internal projects. On the other hand, a project organizational structure may work better if an organization takes on a large number of external projects. Subsequently, most consulting firms follow the project organization structure. On the other hand, the matrix organizational structure may work best when an organization takes on projects that require a cross-functional approach.

There has been some research in this area. For example, Larson and Gobeli (1988) surveyed more than 1,600 project management professionals. The results of their study suggest that both project and functional managers have a strong preference for the project or project matrix organization. The functional and functional matrix organizational structures were viewed as the least effective, and the balanced matrix structure was seen as only marginally effective. Larson and Gobeli suggest that the success of a project is linked directly to the project manager’s degree of autonomy and authority.

The success of large, complex projects may require a concentrated project focus that can be best supported by the project or project-matrix organization. On the other hand, the matrix organizational structure may work well when an organization cannot dedicate scarce staff and resources to a project or when a cross-functional focus is needed. If a project is undertaken within one specific area of the organization, then a functional-matrix structure would be effective. Although there is little evidence to support the effectiveness of projects supported under a functional organization, it would make sense that the best organizational structure would balance the needs of the project with those of the organization (Gray and Larson 2000).
The Informal Organization

The formal organization is the published structure that defines the official lines of authority, responsibilities, and reporting relationships. While the formal structure tells us how individuals or groups within an organization should relate to one another, it does not tell us how they actually relate (Nicholas 1990). In many cases the informal organization bypasses the formal lines of communication and authority because of the inevitable positive and negative relationships that occur over time in any organization. While communication in the formal organization is supposed to flow through published channels, it can flow in any direction and at a much faster pace through the network of informal relationships—the famous grapevine. Power in an organization, therefore, is not only determined by one’s place in the hierarchy, but also how well one is connected in the informal network. A person’s degree of connectedness in the informal organization largely determines what information is received or not received.
Stakeholders

Stakeholders are individuals, groups, or even organizations that have a stake, or claim, in the project’s outcome. Often we think of stakeholders as only those individuals or groups having an interest in the successful outcome of a project, but the sad truth is that there are many who can gain from a project’s failure. While the formal organization tells us a little about the stakeholders and what their interests may be, the informal organization paints a much more interesting picture.
Stakeholder Analysis

A published organizational chart is usually fairly easy to acquire or create. The informal organization may be more difficult to understand or explain, even for those well connected individuals. To help the project manager and project team understand the informal organization better, one can develop a stakeholder analysis as a means of determining who should be involved with the project and understanding the role that they must play. To develop a stakeholder analysis, one may start with the published organizational chart and then add to it as the complexities of the informal organization become known. Since the purpose of the stakeholder analysis is to understand the informal organization, it may be best to view this as an exercise rather than a formal document to be made public. The following steps provide a process for developing a stakeholder analysis:

1. Develop a list of stakeholders. Include individuals, groups, and organizations that must provide resources to the project or who have an interest in the successful or unsuccessful outcome of the project.
2. Next to each stakeholder, identify the stakeholder’s interest in the project by giving the stakeholder a “+1” if they have an positive interest in the project’s outcome or a “–1” if they have a negative interest. Neutral individuals or groups can be given a “0.” If you are not sure, then give a stakeholder a “?”.
3. Next, it may be useful to gauge the amount of influence each stakeholder has over the project. One can use a scale from 0 to 5, with 0 meaning no influence and 5 meaning extremely high influence—that is, this person or group could terminate the project.
4. After determining each stakeholder’s degree of influence, the next step involves assessing whether potential conflict among the different stakeholders exists. An IT project is planned organizational change, and some stakeholders may act in their own self-interest. This self-interest can often be in conflict with the self-interest of other stakeholders. For example, an individual or group may want to increase the functionality of the system. This increase in functionality will require more time and resources that may be in conflict with another individual or group that wants to limit the project’s budget or shorten the project’s schedule.
5. This step involves defining a role for each of the stakeholders. For example, every project should have a champion or someone prominent within the organization who will be a public supporter of the project. In addition, it is important to identify the owner of the project. This list may include an individual, group, or organization that will accept the transfer of the project’s product. Other roles may include consultant, decision maker, advocate, ally, rival, foe, and so forth. Use adjectives or metaphors that provide a clear meaning and picture of the stakeholder.
6. Once you determine who has an interest in the project, what that interest is, and what influence they may have, it may be useful to identify an objective for each stakeholder. This may include such things as providing specific resources, expertise, or guidance navigating through the political waters of the organization. In the case of potential adversarial stakeholders, this may require getting their acceptance or approval concerning certain aspects of the project.
7. Lastly, it is important to identify various strategies for each stakeholder. These strategies may require building, maintaining, improving, or reestablishing relationships. This list should include a short description of how the objective could be attained.

The exercise for developing a stakeholder analysis can be conducted and summarized in a table as illustrated in Figure 4.5.

Figure 4.5 Example Stakeholder Analysis Chart
Stakeholder Interest Influence Potential Conflicts Role Objective Strategy
Hirem N. Firem
(+1)
5
Competition for resources with other functional managers
Project sponsor and champion
Provide resources, approvals, and public support for the project
To maintain open communication so that political landmines can be avolded
Dee Manitger
+1
3
Resources not made available as promised by functional managers
Project Manager
Lead and manage the project so that it achieves its MOV
Work closely with project stakeholders and project team
Project Team
+1
2
This project will change a number of business processes. Affected users may resist change by withholding information
Steve Turner- Network Administrator Shedelle Bivits- Systems Analyst Corean Jenkins- Programmer/DBA Myra Dickens- Inventory Analyst
Provide expertise to complete the project work
Support project team with adequate resources while minimizing distractions
Will Sellit
–1
4
As the marketing manager, Sellit is not pleased that this project was chosen over his proposed project. May withhold promised resources.
Foe
Build and maintain best possible relationship to minimize attempts to divert resources
Maintain open communication, use project sponsor’s influence as necessary
The Project Team

The word team has different meanings for each of us. As a result of past experiences with teams, those meanings probably have both positive and negative connotations. Information technology projects require various resources; but people are the most valuable resource and have the greatest influence on the project’s outcome. Indeed, the human resource of a systems development project will consume up to 80 percent of its budget (McLeod and Smith 1996). It is important, then, that the project manager and project team members be chosen wisely. In addition, people must be sure to support the project team so that project success is not a random event.
The Roles of the Project Manager

One of the most critical decisions in project management is selecting a project manager or team leader. The project manager is usually assigned to the project at the earliest stages of the project life cycle, but a new one may be brought in as replacement in the later stages of a project.

The project manager must play many roles. First, the project manager must play a managerial role that focuses on planning, organizing, and controlling. The project manager, for example, is responsible for developing the project plan, organizing the project resources, and then overseeing execution of the plan. The project manager must also perform many administrative functions, including performance reviews, project tracking and reporting, and other general day-to-day responsibilities.

Although this work sounds fairly simple and straightforward, even the best thought out plans do not always go the way we expect. Thus, the project manager must know when to stay the course and when to adapt or change the project plan by expediting certain activities or acting as a problem solver.

The success of the project, of course, depends not only on the project team, but also on the contributions and support of all project stakeholders as well. Therefore, the project manager must build and nurture the relationships among the various stakeholders. To do this effectively, the project manager must play a strong leadership role. While the managerial role focuses on planning, organizing, and controlling, leadership centers on getting people motivated and then headed down the right path toward a common goal.

Choosing a project manager for a project is analogous to hiring an employee. It is important to look at his or her background, knowledge, skill sets, and overall strengths and weaknesses. Some attributes of a successful project manager include:

* The ability to communicate with people—A project manager must have strong communication skills. A project manager need not to be a great motivational speaker, but should have the ability to connect with people, share a common vision, and get everyone to respond or head in the right direction.
* The ability to deal with people—Aside from being a good communicator, a project manager must have the soft skills for dealing with people, their egos, and their agendas. The project manager must be a good listener, hearing what people say and understanding what they mean. This skill allows the project manager to get below the surface of issues when people are not being completely honest or open without being annoying or alienating them. A project manager must also have a sense of humor. Often, project managers and project teams are expected to perform during stressful situations, and a sense of humor can make these situations more manageable. Although a project manager does not have to be everyone’s best friend, people should feel that they are at least approachable and should be comfortable talking with him or her. In addition, the project manager must also be willing to share knowledge and skills with others and be willing to help each individual develop to her or his fullest potential.
* The ability to create and sustain relationships—A good project manager must be able to build bridges instead of walls. Acting as a peacemaker or negotiator among the project client or sponsor, top management, the project team, customers, suppliers, vendors, subcontractors, and so forth may be necessary. In addition, the project manager should be a good salesperson. An effective project manager must continually sell the value of the project to all of the stakeholders and influence others over whom he or she has no direct authority.
* The ability to organize—A project manager must be good at organizing—developing the project plan, acquiring resources, and creating an effective project environment. The project manager must also know and understand both the details and the big picture, which requires a familiarity with the details of the project plan and also an understanding of how contingencies may impact the plan.

Team Selection and Acquisition

Another critical task of a project manager is selecting and staffing the project. Staffing involves recruiting and assigning people to the project team. Selecting the right mix of people, with both technical and nontechnical skills, is a decision that can influence the outcome of the project. Although a project manager should strive to acquire the brightest and the best, project team members should be chosen based on the following skills:

* Technology skills—Depending upon the nature of the project, members with specific technology skill sets—programmers, systems analysts, network specialists, and so forth—will be required.
* Business/organization skills—Although technology skills are important in IT projects, it is also important to have people or access to people with domain knowledge. These skills include knowledge or expertise within a specific domain (e.g., compensation planning) as well as knowledge of a particular organization or industry (e.g., healthcare) to augment the technical skill requirements.
* Interpersonal skills—The ability to communicate with other team members and other stakeholders is an important skill for team members. It is important not only for the team members to understand one another, but for the project team to understand the project sponsor’s needs. Due to the nature of many projects, other desirable characteristics should include creativity, a tolerance for ambiguity, acceptance of diversity, flexibility in adapting to different roles, and the capacity to take calculated risks.

The size or scope of the project will determine the size of the project team. Although smaller teams have the potential to work faster and develop a product in a shorter time, larger teams can provide a larger knowledge base and different perspectives. Unfortunately, there is also a tendency for larger teams to function more slowly. One solution to this latter problem may be creating subgroups to make the project more manageable and to facilitate communication and action.

The project manager may recruit project team members internally or externally. For example, in the functional or matrix organization, people may be acquired from the functional areas. In a project organization, a project manager may recruit people who are currently in between projects or who will be soon rolling off an existing project. The project manager may have to negotiate with other managers for specific individuals with specific skills or areas of expertise. On the other hand, a project manager may have to hire individuals from outside the organization. In either case, for a particular project, training may be required. Therefore, the timing of when a particular individual can begin work on the project is a significant factor that can impact the project’s schedule.
Team Performance

The project team has a direct influence on the outcome of the project. Therefore, it is important that the team’s performance be of the utmost concern to the project manager. In The Wisdom of Teams, Jon R. Katzenbach and Douglas K. Smith (1999) provide an insightful and highly usable approach for understanding the language and discipline of teams. In refining the language of teams, they provide a distinction between work groups and several types of teams.
Work Groups

The work group is based on the traditional approach where a single leader is in control, makes most of the decisions, delegates to subordinates, and monitors the progress of the assigned tasks. Therefore, the performance of a work group depends greatly on the leader.

A work group can also include members who interact to share information, best practices, or ideas. Although the members may be interested in each other’s success, work groups do not necessarily share the same performance goals, do not necessarily provide joint work-products, and are not necessarily held mutually accountable. A study group is an example of a work group. You and several members of a class may find it mutually beneficial to study together for an exam, but each of you (hopefully!) will work on the exam individually. The grade you receive on the exam is not a direct result of the work produced by the study group, but rather of your individual performance on the exam. In an organizational context, managers may form work groups to share information and help decide direction or policy, but performance will ultimately be a reflection of each manager and not the group. Work groups or single leader groups are viable and useful in many situations.
Quick Thinking—Projects as Social Networks

Simply storing and disseminating information will not encourage individuals assigned to a project to share ideas or become involved as a team. A project social network is an influential mapping of people and ideas.

Managing a project is more than just a set of project plans, tools, and assignment to activities. It’s also about people. An effective project manager understands that people assigned to a project enter with a set of self-interests and expectations so it’s important to know what makes them tick. For example, a newbie might try to over-achieve and impress, while a more seasoned veteran may believe that he or she has seen it all, and a negative neutron may find all kinds of reasons why nothing will work. As a result, a social network is created as each person shows and communicates a strong set of self-interests that, in turn, inform and influence the people they work with. Command-and-control techniques or a one-size-fits-all approach will not get people to work together. The project manager must understand the signals each person is sending out and how interests and events can be aligned to create a basis for a successful project.

The available resource pool is an important input for acquiring a project team. Unfortunately, many project managers don’t consider fully a person’s previous experience, interests, and characteristics when negotiating for or assigning people to a project team. Project managers should not just staff a project, but staff the social network in their favor.

In addition to getting the right people, the project manager adds to the social network by creating a sense of belonging that goes beyond a celebratory project kick-off. This may include thanking people for being part of the project or by bringing them into the loop by asking them what they think about the project charter, scope, or plan. The project manager can create an environment where people want to belong to the project. By meeting with each person individually, the project manager can get a realistic sense of each person’s involvement and commitment.

The project manager should craft a shared vision that is a collection of the expectations and interests of each of the team members. A constancy of purpose should tie everyone together and make everyone feel as though they’ve been heard. However, one of the most important criteria for creating a social network is a candid, approachable, and likeable project manager.

1. Why are project social networks important?
2. What other aspects should a project manager consider when developing a social network for the project?
3. Why is it important that a project team believe that the project manager is managing a project and not their work?

SOURCE: Adapted from Sainath Nagarajan, The Project Social Network, Project@Works, November 29, 2007.
Real Teams

In cases where several individuals must produce a joint work product, teams are a better idea. More specifically, Katzenbach and Smith (1999) define a team as:

a small number of people with complimentary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable. (45)

Moreover, calling a group of people a team does not make it one nor does working together make a group a team. Teamwork focuses on performance, not on becoming a team. Subsequently, there are several team basics that define a real team:

* A small number of people—Ideally, a project team must be between two and twelve people. Although a large number of people can become a team, a large team can become a problem in terms of logistics and communication. As a result, a large team should break into subteams rather than try to function as one large unit.
* Complementary skills—For achieving the team’s goal, a team must have or develop the right mix of skills that are complementary. These skills include:
o Technical or functional expertise
o Problem-solving or decision-making skills
o Interpersonal skills—that is, people skills
* Commitment to a common purpose and performance goals—Katzenbach and Smith distinguish between activity goals (e.g., install a local area network) and performance goals (e.g., ship all orders within 24 hours of when they are received). The concept of a performance goal is similar to the concept of the MOV and sets the tone and aspirations of the team while providing a foundation for creating a common team purpose. As a result, the team develops direction, momentum, and commitment to its work. Moreover, a common performance goal and purpose inspires pride because people understand how their joint work product will impact the organization. A common goal also gives the team an identity that goes beyond the individuals involved.
* Commitment to a common approach—Although teams must have a common purpose and goal, they must also develop a common approach to how they will work together. Teams should spend as much time developing their approach as they do defining their goal and purpose. A common work approach should focus not only on economic and administrative issues and challenges, but also on the social issues and challenges that will shape how the team works together.
* Mutual accountability—A group can never become a team unless members hold themselves mutually accountable. The notion that “we hold ourselves accountable” is much more powerful than “the boss holds me accountable.” Subsequently, no team can exist if everyone focuses on his or her individual accountability. Mutual accountability requires a sincere promise that each team member makes to herself or himself and to the other members of the team. This accountability requires both commitment and trust because it counters many cultures’ emphasis on individualism. In short, it can be difficult for many people to put their careers and reputations in the hands of others. Unless a common approach and purpose has been forged as a team, individuals may have a difficult time holding themselves accountable as a team.

Based on their in-depth study of several teams, Katzenbach and Smith provide several commonsense findings:

* Teams tend to flourish on a demanding performance challenge.A clear performance goal is more important to team success than team-building exercises, special initiatives, or seeking team members with ideal profiles.
* The team basics are often overlooked.The weakest of all groups is the pseudo team, which is not focused on a common performance goal. If a team cannot shape a common purpose, it is doomed to achieving mediocre results. We cannot just tell a group of individuals to be a team.
* Most organizations prefer individual accountability to team accountability.Most job descriptions, compensation plans, and career paths emphasize individual accomplishments and, therefore, tend to make people uncomfortable trusting their careers to outcomes dependent on the performance of others.

Katzenbach and Smith provide some uncommonsense findings as well:

* Strong performance goals tend to spawn more real teams.A project team cannot become a real team just because we call them a team or require them to participate in team-building activities or exercises. However, their findings suggest that real teams tend to thrive as a result of clearly defined performance-based goals.
* High performance teams are rare.In their study of teams, Katzenbach and Smith identified high performance teams. These are real teams that outperform all other teams and even the expectations given. This special type of team requires an extremely high level of commitment to other team members and cannot be managed.
* Real teams provide the basis of performance.Real teams combine the skills, experiences, and judgments of the team members to create a synergy that cannot be achieved through the summation of individual performance. Teams are also the best way to create a shared vision and sense of direction throughout the organization.
* Teams naturally integrate performance and learning.Performance goals and common purposes translate into team members developing the skills needed to achieve those goals. As a result of open communication and trust, the members of a team are more apt to share their ideas and skills so that they may learn from one another. Moreover, successful teams have more fun, and their experiences are more memorable for both what the team accomplished and in terms of what each member learned as a result of the team process.

Project Teams and Knowledge Management

The primary challenge of real teams is to develop shared performance goals and a common purpose. For project teams following the IT project methodology, this challenge requires defining and getting agreement on the project’s MOV. It also requires that the team members learn from each other and from other project teams’ experiences.

In The Radical Team Handbook, John Redding (2000) describes a fundamentally new and different form of teamwork based on learning. Based on a study of 20 teams, Redding suggests that traditional teams tend to:

* Accept background information at face value.In short, most teams accept the project challenge as it is first defined and do not challenge preconceived notions about the problem or opportunity and what they must do.
* Approach projects in a linear fashion.Projects have a beginning and end, and the project plan outlines all of the steps needed to complete the project on time and within budget. Traditional teams tend to focus on the project’s schedule and, therefore, base project success on completing the project on time and within budget.
* Provide run-of-the-mill solutions.Since the team focuses on the challenge as it was handed to them (i.e., the way the challenge was originally framed), they never really understand the challenge and subsequently provide a solution that has minimal impact on the organization. In other words, the team may focus on a symptom and, therefore, never focus on the real problem or opportunity since the solutions remain within the original frame or how the challenge was originally presented to them.

In contrast, Redding describes a radical team as a team that is able to get to the root or fundamental issue or challenge. In general, radical teams do not accept the original performance challenge at its face value. The core objective of a radical team is to question and challenge the original framing of the problem or challenge at hand.

The way the problem or challenge is defined may very well be the problem. Too often a team is handed a performance challenge that is framed by a senior manager. For example, the team may be told by a senior manager that the company is losing money and, therefore, the team should focus on cutting costs. If the team accepts this framing of the challenge, they will develop a solution aimed at saving money. If, however, a team challenges this original frame, they may find out that the real reason why the organization is losing money is because customers are leaving due to poor service. Unless the project team understands the real problem in this case, its solution to cut costs will have little impact on the organization and the organization will continue to lose money.
Learning Cycles and Lessons Learned

Learning cycle theory was originally proposed by John Dewey in 1938 and used to describe how people learn (Kolb 1984). More recently, the concept of learning cycles has been applied to project teams and knowledge management. More specifically, learning cycles provide a way to resolve ambiguous situations through the repeated pattern of thinking through a problem (Dewey 1938). Figure 4.6 illustrates a team learning cycle.

Figure 4.6 A Learning Cycle

[Click to enlarge]

SOURCE: The Radical Team Handbook, John Redding, Jossey-Bass 2000. Reprinted by permission of John Wiley & Sons, Inc.

Redding (2000) suggests that a team learning cycle has four phases:

1.

Understand and frame the problem.It is important that a project team not accept the issues and challenges presented to them at face value. Assumptions must be surfaced and tested because the problem or issue as it is originally framed may not be the real problem after all. Thus, the project team must get to the root of the problem. At the beginning of a project, the team members’ understanding may be quite general, or they may feel that they really do not understand the challenge assigned to them. Unfortunately, few people are willing to admit that they do not have all the answers or that their understanding of the team’s challenge is limited. On the other hand, other members of the team may approach the project with a high degree of certainty—that is, they may act as though they know what the solution is and, therefore, the team just needs to work out the details of how to go about implementing the solution. Opinions are often accepted without question and can result in erroneous assumptions that lead the project team in the wrong direction or keep the team from getting at the real problem. Moreover, there is often pressure for the team to take immediate action so that the project can be completed on time and within budget. In either case, the team runs the risk of not getting to the root of the problem and may propose solutions that have minimal impact on the organization.

For example, a project team may meet with a project sponsor who tells them that the company has an inventory problem. More specifically, the company has too much inventory on hand, and the cost to warehouse this inventory is becoming too costly. After touring the warehouse, the project team can see for themselves that the company’s product takes up just about all the available floor space and is stacked to the ceiling. The project sponsor tells them that an information system would increase efficiency and therefore provide a solution for reducing inventory. Without questioning the problem (and solution) as it was handed to them, they may focus on solving the project just as it was handed to them.

Therefore, the project team must come to understand two things: Preconceived solutions are likely to produce run-of-the-mill results, and teams should encourage open humility. In other words, it is all right for team members to recognize and admit that they do not have all the answers, especially at the beginning of a project. As a result, team members may feel more comfortable admitting they have more questions than answers and the potential for preconceived ideas leading to mediocre solutions is reduced.
2.

Plan.To help teams understand and reframe the problem, teams should create a shared understanding of the problem or opportunity. This understanding includes defining what the team is trying to accomplish and how they are going to go about it.

The team can brainstorm what they know (the facts), what they think they know (assumptions), and what they don’t know (questions to be answered). Early in the project, a team may have more questions and assumptions than facts. That is to be expected because the team may not really understand the problem or challenge fully. Assumptions are ideas, issues, or concepts that must be tested (e.g., “The users will never agree to this,” or “Senior management will never spend the money”). Often, a person can make an assumption sound like a fact, especially if she or he says it with enough conviction or authority. Therefore, it is every team member’s responsibility to separate the facts (proof, evidence, or reality) from assumptions (theories, opinions, or guesses). On the other hand, if the team identifies (or admits) things it does not know, these can be classified as questions to be answered.

Figure 4.7 shows an example of a team learning record. After meeting with the sponsor and touring the warehouse, the team may list the facts, assumptions, and questions to be answered. The first column lists all the facts or evidence from their tour of the warehouse. The second column attempts to separate the sponsor’s opinion from fact so the team does not fall into the trap of solving the wrong problem or just a symptom of the problem. The third column provides an opportunity to admit that no one has all the answers at this time, but answers can be found.

Figure 4.7 An Example of a Team Learning Record
What we know (Facts) What we think we know (Assumptions) What we don’t know (Questions to be Answered)
Company has too much inventory on hand
It may be an efficiency problem
Why are inventory levels so high?
Cost of maintaining current inventory is becoming prohibitive
Management believes a new information system will improve efficiency and therefore lower inventory levels
What are the current levels of inventory?
Inventory turnover needs to be increased
 What is the desired level of inventory?

SOURCE: Adapted from, The Radical Team Handbook, John Redding, Jossey-Bass 2000. Reprinted by permission of John Wiley & Sons, Inc.

Once the project team identifies what it knows, what it thinks it knows, and what it needs to find out, it can create a plan of action. Team members can volunteer or be assigned to specific tasks that require testing assumptions or learning answers to questions. Documenting who does what by when also provides a tool for accountability. An example of a plan of action is illustrated in Figure 4.8.

Figure 4.8 An Example of an Action Plan for Team Learning
Who? Does What? By When?
Shedelle and Steve
Interview sales team to understand past, current, and future trends for the company’s product
Tuesday
Myra
Provide a detailed count of the current physical inventory on hand
Thursday
Corean
Research potential inventory management system commercial packages
Thursday
Steve
Research average inventory levels for the industry
Wednesday

SOURCE: Adapted from, The Radical Team Handbook, John Redding, Jossey-Bass 2000. Reprinted by permission of John Wiley & Sons, Inc.
3.

Act.The key to team learning is carrying out the actions defined in the team’s action plan. Team members can work on their own or together to test out assumptions, try out hunches, experiment, or gather and analyze data. The purpose of these actions should be to generate knowledge and test assumptions, not to complete a series of tasks like a to-do list. Thus, the purpose of these actions is to confirm or disconfirm assumptions and learn answers to questions the team does not know. Redding suggests that what teams do outside of meetings is just as important as the meeting itself because only by acting do teams have the opportunity to learn.
4.

Reflect and learn.After the team has had a chance to carry out the action items in the action-learning plan, the team should meet to share its findings and reflect upon what everyone has learned. To be effective, this reflection must take place in an environment of openness, honesty, and trust. Once the team has a chance to meet and reflect on the information it has acquired, the team can document what it has learned. One format Redding suggests is for the team to answer the following questions:
* What do we know now that we didn’t know before?
* Have we encountered any surprises? Have we gained any new insights? If so, what were they?
* What previous assumptions have been supported or refuted by what we have learned so far?
* How does the team feel the project is progressing at this point?
* How effective has the team been so far?

Following our example, the team may find out that the real reason why inventory levels are so high is because the company’s product is obsolete or no longer in style. If the team had followed blindly the sponsor’s recommendation that an information system would reduce inventory levels through efficiency, only modest improvements would have resulted. Remember: Many times the problem may be the way the problem is handed to you.

Another approach for documenting lessons learned is the United States Army’s After Action Review (AAR). The format for an AAR is:

* What was the intent?Begin by going back and defining the original purpose and goal of the action.
* What happened?Describe as specifically and objectively as possible what actually occurred.
* What have we learned?Identify key information, knowledge, and insights that were gained as a result.
* What do we do now?Determine what will be done as a result of what has been learned, dividing actions into three categories: short-term, mid-term, and long-term.
* Take action.
* Tell someone else.Share what has been learned with anyone in the organization who might benefit.

The team learning cycles and lessons learned can be documented and shared with other project teams. However, the completion of a team’s lessons learned marks the ending of one learning cycle and the beginning of another. Based on the learning that has transpired, the team can focus once again on understanding and reframing the problem and then repeat the plan, act, reflect and learn phases again. Figure 4.9 illustrates this concept.

Figure 4.9 Team Learning Cycles over the Project Life Cycle

[Click to enlarge]

SOURCE: The Radical Team Handbook, John Redding, Jossey-Bass 2000. Reprinted by permission of John Wiley & Sons, Inc.

As shown in Figure 4.9, an entire project can be viewed as a series of learning cycles. An initial team meeting can examine the original problem or challenge assigned to the team. During that meeting, the team can develop an initial action plan. Between meetings, the members of the team can then carry out their assigned tasks for testing assumptions or gathering information. At the next meeting, the team can reflect on what it has learned, document the lessons learned, and then start the beginning of a new cycle. Each cycle should be used to challenge the framing of the problem and create new opportunities for learning.

Teams do not always begin and end learning cycles at each meeting. Some learning cycles may take longer, and some can be accomplished in a shorter time if face-to-face meetings are not needed. Redding suggests, however, that three dimensions can be used to assess team learning: speed, depth, and breadth.

* Speed—First, a team should follow a learning cycle approach rather than a traditional, linear approach. Second, speed refers to the number of learning cycles completed. Therefore, the opportunity to learn can be increased if a team can complete more cycles in a given amount of time.
* Depth—Just increasing the number of learning cycles does not guarantee that teams will increase their learning. Subsequently, depth of learning refers to the degree to which a team can deepen its understanding of the project from cycle to cycle. This learning includes challenging the framing of the problem and various assumptions. In short, depth focuses on how well the team is able to dig below the surface in order to get to the root of the problem. Redding suggests that a team can measure depth by asking the question: Was the team’s conception of the project at the end any different from what it was in the beginning? (47)
* Breadth—The breadth of learning refers to the impact the project has on the organization. It also focuses on whether the learning that has taken place within the team stays within the team or is shared and used throughout the organization. If a team can uncover complex relationships, it can develop a solution that impacts the whole organization. For example, what originally was thought to be a marketing problem could very well cross several functional or departmental boundaries.

The Project Environment

The project manager is responsible for many things. In addition to acquiring human resources, the project manager must also focus on the project environment. The project environment includes not only the physical space where the team will work, but the project culture. More specifically, the project environment includes:

* A place to call home—It may seem obvious, but a project team must have adequate space to work and meet. If the project team is internal to the organization, a work area may already be available. However, consultants often are found camped out in a conference room or even the organization’s cafeteria because no other space is available. Therefore, the project manager should make sure that the team has a place to call home and a place to meet as a team for the duration of the project.
* Technology—In addition to having an adequate work area, the team will also need adequate technology support. Support may include a personal computer and appropriate software, Internet access, electronic mail, and a telephone. In addition, many teams today are geographically dispersed. Technology provides a means for teams to collaborate when they cannot meet at the same time in the same place. Collaboration tools not only can improve communication, but can increase the speed of the team’s learning cycles by allowing the team to store and share minutes of team meetings, action plans, and lessons learned.
* Office supplies—Aside from technology resources, the team will need various office supplies, such as paper, pens, pencils, staplers, and so forth.
* Culture—Each organization has its own culture, but a project team should have its own culture as well. Culture reflects the values and norms of the team. One way of establishing a culture for the project team is to have the project team develop a team charter early on in the project. The team charter allows the team to agree on a set of values and expectations that will help define the project team culture. This charter includes:
o What is expected from each member?
o What role will each team member play?
o How will conflicts be resolved?

Figure 4.10 provides an example of an actual team charter. Because many organizations operate globally today, many projects teams are made up of people from different backgrounds and cultures. The project manager and the project team members must be sensitive to these cultural differences.

Figure 4.10 Project Team Charter
Expectations and Team Values

* Everybody’s ideas and opinions count
* Everyone must learn something new technically and with the business
* Work hard, but have fun
* Produce necessary, quality periodic deliverables throughout the course of the product
* Add values to clients’ organization
* Heavy team commitment
* Show up for team meetings
* Team coordination
* Accountability
* Assistance
* Communication with clients and team
* No such thing as a stupid question
* RESPECT for everyone
* Research: expanding knowledge base as well as comfort zone
* Extend ourselves (Leave our comfort zones)
* Punctuality and group attendance
* Equal contributions from members
* Be prepared for meetings: check e-mail and team web site before every meeting
* Trust one another

Grievance Resolution

* Try to resolve issue with each team member first

Quick Thinking—Learning from Failure

Michael Hugos says that he often learns more from failure than success. He concedes, “When I succeed, it just confirms what I already know—I’m a genius. When I fail, I have an opportunity to learn, if I can bring myself to take an objective look at what happened. This is hard, but then making the same mistakes over again is even harder. So failure can be a great opportunity to learn.”

Hugos also provides some lessons learned from what he calls “one of the greatest learning experiences in his career” when he was a development leader on a systems development project that turned into a multimillion-dollar disaster. Since then, he has delivered many new systems successfully, and much of that success is due to the lessons he learned from the failure of this project. The following is a summary of what happened and some of the lessons learned from his experiences on that project.

* Although the project started out with great fanfare and enthusiasm, there were no clearly defined goals or objectives. The basic idea behind the system was to empower the sales force to grow revenues by $1 billion. Lesson: Be wary when projects start out with wild enthusiasm and unclear goals. This can lead to the “bandwagon effect,” where intelligent people do dumb things.
* The first six months of the project was spent investigating technology and dreaming up ideas. The development team put together a slide show and a short demonstration of some of the technology. Senior management liked what it saw and approved major funding for the project. Lesson: Getting lots of ideas and money can commit a team to unrealistic expectations. A better approach may be to focus on only a few realistic ideas that cost less money.
* Four teams were working together on the project. One team was responsible for programming and hardware selection, while the other three worked on design specifications. Although all four teams were supposed to work together, the design teams began to duplicate each others’ work. No single person was in charge of the entire project. Team members became confused, tempers flared, and feelings were hurt. Lesson: Teams should have clear and nonover-lapping assignments, and a project leader should resolve disputes to keep the project on track.
* After six months and hundreds of pages of specifications the design was still incomplete, but pressure mounted to start programming. Regardless, the design was handed over to the programming team who were overwhelmed by the volume and complexity of the specifications. Lesson: Spending more time designing a system will result in greater complexity. It may be better to design and build smaller components of the system in short, iterative steps.
* To cope with the pressure, the programmers began to change the specifications and cut out features they didn’t understand. In addition, new hardware and software releases kept coming out, so the programmers rewrote many of the programs to take advantage of the new technology releases. It took about a year to program and reprogram the system. Lesson: System specifications must be clear and complete. Developers should stick to them and not redesign the system while building it. New features can be added in future releases.
* Beta testing resulted in a slow system that crashed often. Lesson: After almost two years and such high expectations, the performance of the tests seriously damaged the credibility of the project.
* Support for the system began to fade as the programmers scrambled to fix the bugs. Senior management began to question the constantly increasing budget and cancelled the project—writing off millions of dollars. Lesson: Dividing a large project into smaller subsystems or projects is better than trying to deliver one large system in a few years. Smaller systems are easier to debug and can show a return to the organization more quickly.

1. Should a project team wait until the end of a project to document its lessons learned?
2. How can lessons learned be documented and made available to other project teams?
3. What lessons have you learned from your experiences and applied them?

SOURCE: Adapted from Michael Hugos, Lessons Learned from a Major Project Failure, Computerworld. August 21, 2006.
Chapter Summary

Organizations create a specific structure to support a particular strategy. If the organization performs poorly, then the firm will often develop a new strategy and/or formal organizational structure. Three different formal organizational structures were discussed in this chapter: the functional organization, the project organization, and the matrix organization. These organizational structures represent a continuum of possible structures, and an organization can create structures that are between functional and matrix organizations or matrix and project organizations.

Each organizational structure presents opportunities and challenges for projects in terms of flexibility, knowledge and expertise available, and authority and responsibilities. While the formal organization, in terms of an organizational or hierarchical chart, defines the official line of authority and communication, the informal organization includes the informal relationships and internetworking of people within the organization that develops over time. Understanding the formal and informal sides of an organization is important because it will help the project manager and project team better understand the politics and culture of the organization and provide greater insight into the decision-making process.

The project manager is a key position that should be filled at the earliest stages of the project. The project manager plays many important roles that include not only the traditional roles of a manager, but roles specific to the nature of projects. Therefore, the project manager must be a skillful communicator, negotiator, organizer, and relationship builder. In addition, the project manager must perform several critical tasks, including selecting and acquiring members of the project team and creating the project environment.

Two relatively new approaches to managing project teams were introduced in this chapter. First, The Wisdom of Teams by Jon R. Katzenbach and Douglas K. Smith (1999) provides a new language and discipline for project teams. For example, a work group can follow a traditional approach where a single leader or boss is in control, makes most of the decisions, and delegates to subordinates who work independently from each other. Or a work group can include several individuals who come together to share information or set policy, but work independently from one another and do not necessarily share the same performance goals or work products. On the other hand, real teams are a special type of team, with a few individuals with complimentary skills who focus on a performance-based goal and share a common purpose and approach. Based on their study of teams, Katzenbach and Smith found that real teams consistently outperform work groups.

Project team members must learn from each other and from other project team experiences if they are to provide a solution that gets to the root of the problem and not just a symptom. Learning cycle theory has been around since 1938, but has recently been applied to team learning and knowledge management. In The Radical Team Handbook, John Redding (2000) provides an interesting approach for teams based on learning cycles. Here, it is important that a team not accept the problem or challenge as it is originally presented to them. Following a learning cycle, the team follows four phases: (1) understand and frame the problem, (2) plan, (3) act, and (4) reflect and learn. The conclusion of a learning cycle and the beginning of the next is marked by the documentation of lessons learned.

Instead of developing a solution prematurely, the project team is to encourage open humility by acknowledging that it does not have all the answers, especially at the beginning of a project. Therefore, the project team is encouraged to discuss and separate facts from assumptions or opinions. The team then creates an action plan to research questions and test assumptions. When the team meets, the members reflect on and learn from the information collected. Surprises, insights, and confirmed (or disconfirmed) assumptions are then documented as lessons learned. A team’s learning can be assessed using three dimensions: (1) speed or the number of learning cycles, (2) depth or the degree to which the team deepened its understanding of the project, and (3) breadth or the impact of the team’s proposed solution on the organization.

Although the project manager is responsible for overseeing many project activities, it is his or her responsibility to ensure that the project team has an adequate work environment. A suitable workspace and the technology to support the team are necessary. In addition, each project should define its own culture. It is helpful to have the team develop a team charter that outlines the roles, values, expectations, and methods for resolving conflict in order to set proper expectations.
Review Questions

1.

What is the relationship between an organization’s strategy and organizational structure?

2.

What is meant by the formal organization?

3.

Why is it important for a project manager to understand the formal organization?

4.

Describe the functional organizational structure.

5.

What are some challenges for IT projects under the functional organizational structure?

6.

What are some opportunities for IT projects under the functional organizational structure?

7.

Describe the project organizational structure.

8.

What are some challenges for IT projects under the project organizational structure?

9.

What are some opportunities for IT projects under the project organizational structure?

10.

Describe the matrix organizational structure.

11.

What are some challenges for IT projects under the matrix organizational structure?

12.

What are some opportunities for IT projects under the matrix organizational structure?

13.

What is projectitis? When might you expect to encounter projectititis? How could an organization minimize the likelihood of projectititis?

14.

Describe the balanced matrix, functional matrix, and project matrix organizational structures.

15.

Describe what is meant by the informal organization. Why should the project manager or project team be concerned with understanding the informal organization?

16.

What is a stakeholder?

17.

How does conducting a stakeholder analysis help the project manager and project team understand the informal organization?

18.

Why would the project manager and project team not want to make a stakeholder analysis public to the entire organization?

19.

In conducting a stakeholder analysis, why is it important not only to identify those who will gain from the project’s success, but also those who may gain from its failure?

20.

What is the purpose of defining a role and objective for each stakeholder identified in the stakeholder analysis?

21.

Describe the roles of a project manager.

22.

What qualities are required for a good project manager? Can you come up with any on your own?

23.

What skills or qualities are important in selecting a project team?

24.

What is the difference between a work group and a real team?

25.

What is the difference between a performance-based goal and an activity-based goal? Give an example of each.

26.

Why is focusing on a performance-based goal, such as a project’s MOV, more important than having the team go through a series of team-building exercises?

27.

Why do you think many teams accept the project opportunity at face value and never question the way the project was originally framed?

28.

Describe the concept of a learning cycle.

29.

What purpose does creating a lesson learned at the end of a learning cycle provide?

30.

What advantage does a team have when it encourages open humility instead of trying to solve the problem or provide a solution as soon as possible?

31.

What is meant by the speed of learning cycles? How is speed associated with team learning?

32.

What is meant by depth of learning cycles? How is depth associated with team learning?

33.

What is meant by breadth of learning cycles? How is breadth associated with team learning?

34.

What is the project environment? Why must a project manager ensure that a proper project environment is in place?

Extend Your Knowledge

1. Develop and write a job description for hiring a project manager to manage an Enterprise Resource Planning (ERP) project. Once the job description is complete, describe how you might go about finding this person externally. What sources would you use?
2. If you are working on a semester assignment with other individuals in your class, complete a stakeholder analysis using the Stakeholder Analysis Chart in Figure 4.5.
3. If you are working with other students on a semester project assignment, do you consider yourselves more of a work group or a team? Why? How effectively has this worked for you? What would you like to change? What would you like to leave the same?
4. If you are working with a team on a class project, go through a learning cycle as a team.
* Write down the problem or challenge assigned to your team as you originally understood it. What is the MOV (i.e., performance-based goal) that your team is trying to achieve?
* Using the following table as a guide, write down what you know (facts), what you think you know (assumptions), and what you don’t know (questions to be answered). Be sure to challenge any opinions or assumptions before concluding they are facts.
What We Know (Facts) What We Think We Know (Assumptions) What We Don’t Know (Questions to be Answered)
  Â
  Â
  Â
* Once you and your team members finish brainstorming facts, assumptions, and questions, develop an action plan and assign responsibilities for each member of the team using the following table as a guide. Agree on a meeting day and time so that each member has a chance to complete his or her assignment and so that the team can meet to discuss these findings.
Who? Does What? By When?
  Â
  Â
  Â
* After everyone has had a chance to complete his or her action-learning assignments, the team should meet to share this information. Each member should take a turn presenting what he or she found. While a team member is presenting what they found, the other members must listen carefully and not challenge any of the information presented. Clarification questions are fine. After each member has had a chance to present her or his findings, the team should focus on the following questions:
1. Is there anything we know now that we didn’t know before?
2. Were there any surprises? Have we gained any new insights? If so, what are they?
3. What assumptions have been supported and not supported?
4. How well is the team progressing?
5. The answers to these questions should be documented. Once documented, the team has completed one full learning cycle. The next step is to start over and reframe the project challenge as you did in Part a.

Global Technology Solutions

Tim Williams thought he was going to be the first one to arrive at the office, but as he turned into the parking lot, he could see Kellie Matthews’ car in its usual spot. Tim parked his car next to Kellie’s and strode into the GTS office. This was going to be an exciting and busy day because several new employees were going to report for their first day of work at GTS. He wanted to get to the office early so he could greet them and prepare for their day of orientation.

As Tim walked through the office door, he made a beeline for the small kitchen area where a fresh pot of coffee was waiting. The smell brought a smile to his face as he poured the dark liquid into his favorite coffee mug. Tim turned around as Kellie entered the kitchen area. “Good morning!” Kellie exclaimed. Tim never had been a morning person, and he wondered to himself how anyone could be so cheerful this early. He tried to be as cheerful as possible given that he hadn’t had his first cup of coffee. “Good morning to you, too.” Tim could see that Kellie was at least one cup of coffee ahead of him, which gave him some consolation. “Care for another cup?” Tim asked as he offered to pour a cup for Kellie. “Sure, thanks,” said Kellie as she held the cup out.

As Tim poured the coffee for Kellie, she smiled and said, “After you left yesterday, I received a phone call from Sitaramin. He said that he would accept our offer and join us at GTS next week.” That news seemed to wake Tim up. “That’s great!” Tim exclaimed.

Both Tim and Kellie have been busy during the last two weeks interviewing and negotiating with a number of candidates to join GTS. With the addition of Sitaramin, the team for the Husky Air project would be complete.

Kellie sipped her coffee and said, “Well, our budget for salaries is going to be slightly higher than we had planned, but I guess that can be expected given the job market for information systems professionals and the fact that we had to pay a premium because we’re a start-up company. But if all goes well, I’m pretty sure that the Husky Air project will still be profitable for us. We can develop a detailed project plan and use the latest software metrics for planning the project schedule and budget, but the success of this project rests largely on how well this team performs.”

Tim agreed, looked at his watch and said, “We have about an hour before our new employees arrive. I suggest we go over the details of the day’s agenda one more time.” Tim refilled his coffee mug and Kellie’s before they made their way to the conference room where the orientation would be held. As they walked down the hall, Tim thought about what Kellie had said. He knew that it was going to be a challenge to form a cohesive and high-performance team from people who would meet for the first time in less than an hour.
Things to Think About

1. What feelings might a new employee have when starting a new job?
2. What could GTS do to help new employees transition successfully to their new jobs?
3. Why does the success of a project rest largely on the performance of the team?
4. How can a group of individuals become a cohesive and high-performing team?

Husky Air Assignment—Pilot Angels
Developing a Stakeholder Analysis

To become more familiar with the project environment, you will conduct a stakeholder analysis. Use the following grid and information about each stakeholder to complete your analysis.

1. Create a list of project stakeholders. The following will provide a basis for your analysis.
Stakeholder
Interest
Influence
Potential Conflicts
Role
Objective
Strategy
      Â
      Â
      Â
      Â
      Â
      Â
      Â
* L. T. Scully is the president and CEO of Husky Air. He hired Global Technology Services (GTS), the consulting firm, to work on the Pilot Angels project. He believes that this project will allow Husky Air to increase the number of charitable flights significantly but in a cost-effective manner. L. T. has the authority to authorize all payments for the project.
* Alma Coleman currently schedules and coordinates all Pilot Angel flights using a manual system. She has been with Husky Air from the beginning, but has worked for various organizations over the past 40 years. She has mentioned to various individuals that she is apprehensive about using a computer and will consider retiring if the new computer system is “just too hard to learn.” Alma just about knows all of the volunteer pilots and healthcare organization contacts on a first-name basis, and believes that an automated system will depersonalize these relationships. Although she maintains meticulous care of all the paper files and folders, she has been accommodating but not enthusiastic when she has had to interact with any of the GTS project team members.
* Tim Williams is the project manager and one of the co-owners of GTS. Aside from contributing to the bottom line of GTS, this project, if successful, can lead to additional projects with Husky Air.
* Sitaramin, Yan, and Pat are employed by GTS and members of the project team who will be involved in the design, development, and delivery of the new Pilot Angels system. Sitaramin and Yan are experienced and knowledgeable systems analysts who have the requisite database and programming skills. Pat is a network specialist with several technical certifications.
* Volunteer pilots provide the means for transporting patients, organs, or medical personnel. They donate their time and use of their aircraft.
* Passengers include patients, their family, care-givers, or other medical personnel.
* Review the case at the end of Chapter 1 to come up with any other stakeholder whom you think should be included.
2. Complete the analysis:
* Determine each stakeholder’s interest in the project. For example, you could represent a positive interest with (+1), a negative interest with (–1), or neutral interest with (0).
* Define each stakeholder’s degree of influence. Use a scale of 0 (no influence) to 5 (high influence).
* Describe any potential conflicts with other stakeholders.
* Develop a metaphor for each stakeholder to reflect his or her role in the project (e.g., project champion, leader, ally, etc.).
* Identify an objective for each stakeholder that will make the best use of the stakeholder if he or she has a positive interest in the project’s outcome, help to overcome any potential conflicts with other stakeholders, or gain the acceptance or approval of any stakeholders who may have a negative interest in the project’s success.
* Develop a strategy that outlines how each stakeholder may be involved in the project. This should focus on attaining the objective you set for each stakeholder.

Case Studies
Choosing the Right Team

Bill was a novice attending his first meeting with other project managers to pick people for their upcoming projects. He felt like the other project managers stepped all over him when he ended up with all the “leftovers.” He vowed that he would never let that happen again when his project didn’t go all that well.

The next time, Bill thought he was better prepared. Before the meeting, he approached the top-skilled people and sold them on the project so their managers agreed to let them work on Bill’s project. According to Bill, “I got all the people I wanted. And it turned out to be a terrible project.”

Bill picked his team for their technical skills and ended up with a team of prima donnas who couldn’t work together. Bill learned a few things over the years. First, a great project team requires more than just great technical skills. It takes the right mix of “soft” skills, personalities, and attitudes to make a team gel.

Unfortunately, many project managers fall back on some of the most common questions used in interviews to help select people for their projects. Some of them can be downright dumb. Examples include:

* “Where do you see yourself in five years?”Few organizations can guarantee you a job for five years so a career path is even more difficult to predict. You can always answer that you hope to be “happy and productive working in a job you love for a company that values your talents.”
* “What would you do if I gave you an elephant(or insert here: some other ridiculous object)?” Sometimes interviewers ask this ridiculous question to new graduates because they think it’s cute and because it’s supposed to test how they think.
* “What are your weaknesses?”The stock answer to this question is “I’m a perfectionist” even though you’re really thinking that it’s putting up with people who ask dumb questions.

This is just an example of some of the questions people ask. The objective of an interview is not to make the candidate squirm, or to be a psychology exam. Some interview questions can be illegal if they deal with age, family responsibilities, and lifestyle. Some examples include:

* Can you work overtime, evenings, and weekends?
* What child care arrangements have you made?
* How old are you?
* Where were you born?
* What is your marital status?
* Are you living with anyone?
* Do you plan on having more children?
* What are your religious beliefs?
* Have you ever filed a lawsuit against an employer?

So what questions should you ask to help you make the right decision? Questions should help make the right decision and give some insight as to how well someone will perform on the project. This requires being specific, since a decision to hire or bring someone on the project team can be very difficult to undo.

* Ask for real examples of what the person has accomplished.A resume will tell you something about a person, but you really need to find out what they can do. Looking at someone’s work is a good method for understanding a person’s capabilities. Ask them to provide you with a sample of their work.
* Use the review of their work as a guide to prepare specific questions.In a follow-up interview, you can ask the candidate to take you through how they developed the sample of the work they left with you. You can ask them to critique it first by asking them what they liked and then didn’t like about it. Ask them how they made certain choices and then ask your prepared questions concerning what else you’d like to know about their work.
* Give them a deliverable like a program, database design, or project plan to critique.A few days before, forward a good, but not great, deliverable, to the candidate. This could be something that has some things that could be improved. Ask questions regarding what works or doesn’t work. What could be improved? Or what would they have done differently?
* Scenarios and case studies can be used as an interview exercise.Real and project situations that someone could reasonably expect to encounter can be a useful interview too. Examples could include handling a change request, or a risk that needs to be addressed, or dealing with conflicts. It is important to give the candidate enough time to think about a response and have a specific response in mind.
* Have the candidate meet with the team members he or she will work with.This can provide an invaluable sense of how the candidate might interact with the project team. The team members should have some specific questions in mind when talking with the candidate, and you should have questions in mind when talking with the team afterwards. The focus should be on how the candidate and team interact—not on the skills.

These suggestions will not guarantee that you always will pick the perfect team; however, they may help get a better sense of who you will be dealing with and how they may react in certain situations. As Mark Mullaly points out, “Sure, you can just ask someone what their strengths and weaknesses are. For my money, though, it’s far more valuable to get them to show you.”

1. Suppose you are the project manager for a small project that will be based in Chicago. At this point, you have four other project team members on board. All you need to do is hire a C++ programmer. Later today you will be interviewing Mary, who recently graduated from a large university nearby. Develop a interview plan that includes an itinerary and set of interview questions. Mary is schedule to arrive at 10 AM and will be available until 4 PM.

SOURCE: Adapted from:

Kathleen Melymuka, How to Pick a Project Team, Computerworld, April 12, 2004.

Mark Mullaly, Deadly Questions for the Killer Candidate, Gnatthead.com, August 11, 2005.

Liz Ryan, Stupid Interview Questions, Business Week, September 21, 2005.

Ronald L. Krannich, 38 Illegal, Sensitive, and Stupid Interview Questions … and How to Respond, Washingtonpost.com, April 11, 2003.
The Project Manager Career Path

There are basically three career paths for project managers: corporate project managers, consultant project managers, and the independent project manager. Each type of project manager works in a distinct environment with its own unique advantages, disadvantages, opportunities, and challenges.

The corporate project manager is an employee of an organization assigned either to manage an internal project or oversee the installation of the company’s product or service for a client or customer.
Advantages

* The organization may have a project management office (PMO) that has a standardized project methodology in place.
* An enterprise-level software system is often available to help manage projects and project resource availabilities and skill sets.
* The project manager usually has a high level of authority because of a strong link between project team members’ performance and compensation and/or career progression.
* The corporate project manager generally has input in choosing his or her project team.
* Project procurement, financial, and other major project functions are managed by a central organizational function like the accounting department.
* Key project team members on an internal project would be from the same organization as the project manager so everyone would share similar knowledge of the organization and industry, as well as organizational culture.

Disadvantages

* The corporate project manager may have to deal with more organizational politics, controls, or bureaucracy.
* Senior management’s priorities may change, resulting in weak sponsorship and resources diverted to other projects.
* Project managers may become protective of their resources and thereby limit the exchange of resources among other projects.
* A project manager can become typecast or so focused in a particular industry or product line that moving to another project environment may be difficult. Often the project manager is too busy to be released for training.
* Often the most talented project managers are called in to take over a failing project even when a successful recovery is improbable.

The consultant project manager manages a project as part of a contractual engagement for a client. In many cases, the consultant project manager begins the project after the requirements and objectives are locked down in a signed contract. Although one could make the case that all project managers are essentially consultants, the consultant project manager is transplanted to a new project environment rather than the project coming into the project manager’s environment.
Advantages

* The consulting organization may have its own proven project methodology or solution to support the consulting team.
* A consulting firm may have many successful and experienced project managers with diverse skills and experiences to assist other project managers with peer advice, mentoring, or coaching.
* Often a client will call upon a consultant when they need experienced or expert help. Depending on the consulting organization’s reputation, the consultant’s advice can carry a great deal of credibility initially. Subsequently, the consultant project manager usually has the freedom to use new ideas, technologies, or methods when creative solutions are needed.

Disadvantages

* Typically, the client sponsor reserves and defines project management authority before the outside consultant is selected, so the consultant project manager may have little or no input to select team members from the client side.
* The consultant project manager may work with a project team made up of consultants from the same firm, the client organization, and even consultants from competitor organizations.
* Scope, schedule, and time estimates may be unrealistic if the project manager was not involved with the original project planning. Subsequently, the project manager and team may be locked into a project doomed from the beginning.
* Some clients may have the “Not invented here” or “You’re not experienced enough” attitude or perception that can be difficult to overcome.
* It is not uncommon for employment to be discontinued at the close of the project.

The independent project manager works as an independent contractor or practitioner. He or she is a company of one.
Advantages

* As a self-employed project management consultant, the independent project manager has the freedom to refuse undesirable projects.
* Work and life outside of work may be planned with more balance and control.
* Often the independent contractor has built a reputation for service or expertise in a very specific area. Clients may therefore perceive this person as someone who is more cost effective than hiring someone with similar skills and experience, or hiring a consulting firm.
* This project environment can provide a direct relationship between the independent contractor and the client.
* Delivering a specialized, high-quality product or service can be extremely rewarding.

Disadvantages

* Developing the business (e.g., developing marketing materials, maintaining a Web site, writing proposals, billing and collecting for services) can be time consuming and requires additional skills and resources.
* The independent contractor must be aware of tax status and financial reporting requirements.
* Clients can come up with surprises that must be dealt with in an efficient and professional manner.
* Changes in the marketplace can have an immediate and detrimental impact if the majority of a contractor’s client base is in one area.
* Clients may expect more travel and tighter deadlines. Or if the contractor only has one client, the client may feel solely leased to the project.
1. Which project manager model appeals most to you? Why?
2. Why is it important that you manage your own career while your knowledge and experience as a project manager grows?
3. What does a person need to consider if he or she was a corporate or consultant project manager and desires to become an independent project manager/contractor? What skills would be transferable? What skills would have to be acquired?

SOURCE: Adapted from Ann Sachs, Whose Grass is Greener?, Projects@Work, January 31, 2008.
Bibliography

Dewey, J. 1938. Logic: The Theory of Inquiry. New York: Holt, Rinehart, and Winston.

Gray, C. F. and E. W. Larson 2000. Project Management: The Managerial Process. Boston: Irwin McGraw-Hill.

Katzenbach, J. R. and D. K. Smith 1999. The Wisdom of Teams. New York: HarperCollins Publishers.

Kolb, D. 1984. Experiential Learning. Upper Saddle River, N.J.: Prentice Hall.

Larson, E. W. and D. H. Gobeli 1988. Organizing for Product Development Projects. Journal of Product Innovation Management 5: 180–190.

McLeod, G. and D. Smith 1996. Managing Information Technology Projects. Danvers, Mass: Boyd & Fraser Publishing Company.

Meredith, J. R. and S. J. Mantel, Jr. 2000. Project Management: A Managerial Approach. New York: John Wiley.

Nicholas, J. M. 1990. Managing Business and Engineering Projects: Concepts and Implementation. Upper Saddle River, N.J.: Prentice Hall.

Project Management Institute (PMI) 2004. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: PMI Publishing.

Redding, J. C. 2000. The Radical Team Handbook. San Francisco: Jossey-Bass.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License