Decision-Making
6
The project manager is responsible for resource allocation and use, as well as cost and schedule tradeoffs and changes in terms of the project‧s scope, direction, or characteristics (Adams, Barndt, and Martin 1979). These responsibilities obviously require strong decision-making skills. Though decision-making is not the domain of the project manager alone, it is certainly an important role because each decision has consequences that affect the overall direction of the project. Project managers must work constantly to build consensus or confidence in decisions about critical aspects of the project (PMI 1987).
PMI (2008a) describes four common decision-making styles: command, consultation, consensus, and coin flip (random). Each style is appropriate in certain situations. According to PMI, decision by consensus is optimal; the effective project manager is one who can lead others through the decision- making process. The project manager should work to balance the triple constraints of the project and trust his or her team to ensure the quality of the project‧s deliverables in conjunction with the customer‧s acceptance criteria.
PMI suggests a decision-making model consisting of the following stages:
Problem definition. Make sure you understand the problem before making a decision.
Problem solution generation. Brainstorm various solutions.
Ideas to action. Determine criteria to use in making the decision, assess advantages and disadvantages of each possible solution, and then select the best solution and make the decision.
Solution action planning. Involve those who will be affected by the decision to gain their commitment and buy-in to it.
Solution evaluation. Analyze what happened after the decision was made. What lessons were learned? Was the decision appropriate?
Evaluation of the outcome and the process. Assess how well the problem was solved and how it affected the project‧s goals and objectives. Were the team‧s goals and objectives advanced by the decision?
The program manager has a broader focus: the program‧s objectives and the organization‧s culture and processes. He or she must make decisions about, and affecting, resource use across the program (PMI 2008c). The program manager has to take into account how decisions will affect other program components.
At the portfolio level, there are even more decisions to be made as the portfolio components are selected and prioritized (PMI 2008b). The portfolio manager, working with stakeholders, typically establishes the portfolio decision- making process and guides the selection, prioritization, and balancing process. He or she also supports senior-level decision-making and ensures timely and consistent communication on the progress of components in the portfolio, their progress, and any changes to them.
PMI (2006) describes two types of decisions. Decisions made in an emergency situation, when something must be done immediately—for example, in a fire—are naturalistic or qualitative. Decisions that are based on quantitative data—those that depend on information—are called rationalistic. PMI says that a blend of both types is ideal in the project environment.
Decisions are critical at each stage of the program and project life cycle and throughout the portfolio management process. This chapter examines the types of decisions program and project managers must make and approaches that will help them make ones that are effective and beneficial. It also describes the role of the portfolio manager in his or her work with senior executives in the decision-making process. It concludes with a decision-making checklist that the portfolio, program, or project manager can use.
The Importance of Team Cohesiveness in Decision-Making
It is wonderful to be on a team in which everyone enjoys working together and is pleased to begin each workday. One project manager was part of such a team early in his career and thought that this was the norm. (Unfortunately, this team was the only one he was on in which it was a pleasure to work.) Everyone on the team felt that working together was rewarding. Its projects required collaboration at various levels, and everyone performed their assigned roles and stepped in as required to help others with their tasks. To this day, almost 40 years later, members of that team have maintained their close camaraderie, respect for one another, and personal ties. The manager is still grateful for this experience.
However, few teams are like the one described above. Most lack sufficient time to develop close relationships and trust; bickering among team members, boredom, and a lack of commitment or pride are all too common. People often miss team meetings, or if they attend, they read and write emails during the meeting rather than focusing on the problem at hand. On virtual teams, they “participate” in conference calls by pressing the mute button and doing other things.
On these teams, the cohesiveness needed for effective decision-making and program and project accomplishment is lacking. Even if teams like these complete their deliverables on time, their members are pleased when the program or project is over and they can return to their functional team or start another program or project. They have no desire to work together again on another program or project.
Cohesiveness, as defined by Fisher (1974), is “the ability of group members to get along, the feeling of loyalty, pride, and commitment of members toward the group” (p. 31). He further notes that cohesiveness may be viewed as an output of the social dimension of a team or a group; it is therefore not so much a process but a state of being. While all teams have some degree of cohesiveness, it varies widely.
Fisher emphasizes the importance of tension in teams to help hold them together. The presence of tension implies that there is work to be done. Tension will vary over the life cycle of a program or project, but it is typically high when the program and project begins, starts to drop off once the program or project is underway, then rises as the program or project reaches the closing stage.
It is a difficult but important challenge for program and project managers to get their teams focused around cohesiveness and productivity and an even greater challenge when working in a virtual environment. This focus is especially essential when key decisions that affect the planned benefits and deliverables of the program or project must be made. More ideas can be generated by a team than by a single individual working alone, and the cohesive team can critically evaluate the ideas generated as the decision is made. It is also more likely to buy into the decision and wish to implement it.
The Decision-Making Process
Decision-making is more complex on larger programs or projects because more stakeholders, at a variety of levels, are involved. These stakeholders may be internal or external to the organization and may include the general public and the media. When many stakeholders are involved, the decision-making process tends to take longer. On virtual teams, cultural considerations may add another dimension to the decision-making process, and while diversity can help teams make better decisions, it also sometimes prolongs the process. Procrastination can slow down decision-making as well. Program and project managers often gravitate to solving routine problems rather than proactively tackling complex decisions.
Fisher (1970) describes four key phases in the process of team decision- making, here tailored slightly to the program and project management environment:
Orientation phase. In this phase, team members are beginning to understand the overall purpose of the program or project and why it is being done. They are getting acquainted and often express opinions tentatively. A solution may be obvious to a particular team member, but he or she may elect to remain silent for a while to see if others come to the same decision. Program and project managers must create an environment in which people feel free to openly communicate and make suggestions.
Team members are unsure about their position on the team and their key roles and responsibilities, and they tend to agree more often in this early stage. For example, if the client suggests a new requirement, even though it may affect the project‧s deliverables, team members are more likely to accept it and move on to actually completing the work, rather than analyzing it in detail and determining whether a change order is required.
Conflict phase. At this point, the team members are involved in the program or project and are familiar with one another‧s roles and responsibilities. A work breakdown structure (WBS) has been prepared; teams usually have a resource breakdown structure (RBS) and a resource assignment matrix (RAM) or responsible, accountable, consult, and inform (RACI) chart as well. If subject matter experts will be called upon during specific phases, people recognize why they will be required and are willing to accept them as temporary team members. When a decision must be made, people feel able to express their points of view, positive or negative, even if they conflict with others on the team. People back up their views with specific data to support them, and they do not express opinions in a tentative or ambiguous manner.
Emergence phase. During this phase, team members express fewer negative opinions. The program or project direction is better defined, and debates are less frequent; people understand the vision and mission of the program or project. People are more willing to confront and resolve problems when they occur, rather than waiting until later. They are familiar with their teammates’ points of view and know where they stand on key issues. Teams more easily reach compromises. If teams cannot reach agreement, they are likely to follow the procedures set forth in the team charter and escalate the decision to the program manager or project manager, or even higher, until a decision can be made. As Fisher writes (1974), in this phase “the eventual outcome of group interaction becomes increasingly more apparent” (p. 143).
Reinforcement phase. This final phase is the one in which the team achieves consensus. People continue to provide data to support their views on key issues. Team members make fewer arguments against the proposed decisions because there is greater unity within the team. Team members may re-propose suggestions that they withdrew earlier because the team is now ready to work toward consensus.
The Decision-Making Process on Virtual Teams
Is the decision-making process different on virtual teams? Hedlund, Ilgen, and Hollenbeck (1998) found that on virtual teams, members have varying levels of expertise, so the project manager must coordinate the team members’ suggested solutions into the final decision. Consensus may not even be desirable in the virtual team. These authors suggest that in the initial phases of the project, the project manager must initiate a flow of information that is helpful for individual decision-making, but when decisions depend on the contributions of other team members, social pressure to conform to team norms and to respect the expertise of other team members, especially in highly specialized projects, often prevents virtual teams from being efficient. These teams must rely on electronic communications rather than face-to-face interaction, often making the entire process more challenging. The program or project manager must pay more attention and be more involved if the decision-making process is to be effective.
Bourgault, Drouin, and Hamel (2008) studied the decision-making process within a virtual team, exploring the relationship between team autonomy and formalization of the process and the quality of the decisions and overall effectiveness of the team‧s work. Their work showed that it is essential for virtual teams to have a quality process to guide decision-making that helps avert or proactively address obstacles. They noted that while it is difficult to implement such a process, it is the project manager‧s responsibility to do so. Another important factor contributing to successful decision-making was an emphasis on team members’ autonomy and on building an empowered team that can make its own decisions and escalate them to the project manager when required.
Creating and Implementing a Decision-Making Process
Of course, a quality decision-making process can benefit a co-located team as well. How can program or project managers best put such a process in place? Here are some guidelines:
Review the types of decision-making processes other teams have used successfully in the organization, either through a knowledge management repository, if one exists, or through interviews with program and project managers whose work was considered successful.
Draft a decision-making process, then ask the team to comment on it before it is implemented to gain their buy-in and support for it. In a co-located or a virtual team, set up a way for people to comment anonymously, quickly, and easily.
Make sure people understand their specific roles and responsibilities and the degree of autonomy they have to make decisions on their own; describe the escalation process people should follow if a decision cannot be made without the involvement of others.
Depending on the length of the program or project, survey team members and other key stakeholders about the effectiveness of the decision-making process. Ask people for specific feedback, using open-ended questions as much as possible. Make clear that you are willing to change the process as necessary.
The Power Bases
When making decisions, sources of power are a key consideration. Etzioni (1961) was one of the first of many authors to discuss this dimension. He described the differences between position power and personal power and how each type of power influences decisions. In a program or project context, position power refers to a person‧s ability to influence another to do a certain work package or activity because of his or her position in the organization. For example, assume the sponsor of a project is the chief information officer (CIO) in the company. One project team member is reluctant to be on the team because she is close to making a breakthrough innovation in her functional department. She constantly complains to the project manager about her role on the team and asks to be reassigned back to her functional unit. The project manager knows he needs her expertise on a critical part of the project and also wants her to be involved in other areas of the project, so he asks the CIO to meet with her. She has never met the CIO before and is amazed that the CIO would spend valuable time with her. He acknowledges her work in her functional unit but asks her to put this work aside until the project is successfully completed because the project is so important to the company. The CIO‧s ability to influence this team member to be an enthusiastic and active contributor stems from his position in the organization.
By contrast, a person with personal power uses it to encourage others to support him or her on a program or project. Personal power typically is earned, and people who are noted for it are respected in the organization. For example, assume a project team member was working on testing software modules as they were completed. He believed his expertise would be better used in development than in testing, and he was new to work in the testing world. He asked the project manager if he could be reassigned to development. The project manager explained that he had sufficient resources in development and really wanted the team member to work in testing. Still, the team member was dissatisfied, and the project manager recognized that his poor morale might be affecting others working in testing. He asked the CIO to meet with this team member. Though the team member had never met the CIO before, he respected him because of his credentials and the various responsibilities he had in the company before becoming the CIO. He had read various articles the CIO had written for technical journals and believed the CIO understood not only the technical aspects of the work to be done but also the overall importance of the work to the organization.
When the team member met with the CIO, the CIO used personal power to gain this disgruntled team member‧s commitment to the project. The CIO told him that working in testing would enable him to broaden his skills, contributing to his own individual development and overall worth to the organization. The team member returned to the testing unit with some enthusiasm for the work to be done. He complained less and instead offered constructive criticism and feedback.
Etzioni‧s concepts of personal and positional power influenced French and Bell‧s concept of sources of power (1973). They describe five sources of power managers may claim: reward power, coercive power, legitimate power, referent power, and expert power.
Reward Power
A manager with reward power is able to give team members rewards, such as money, recognition within the organization, and security. It is usually easier for program managers to apply this type of power than it is for project managers because programs tend to last longer, and core team members may stay with the program for some time. Any projects operate in a weak matrix, not a strong matrix or projectized structure, and project managers are rarely even able to participate in team members’ performance reviews.
However, everyone appreciates recognition, especially if it is sincerely and appropriately given. PMI (2008a) asserts that a team-based reward and recognition system is appropriate. People are motivated if they feel the organization values their work; rewards can demonstrate that people are valued (p. 234). The program or project manager should do his or her best to find rewards that he or she can give for outstanding individual or team accomplishments. For example, the manager might place a notice in an organizational newsletter or post on a portal that a team member did exemplary work, offer an extra day off for a long weekend if team members worked overtime to complete a critical milestone, or allow a team member to attend a seminar for personal development.
Managers must realize that this source of power is to be respected; “only desirable behavior should be rewarded” (PMI 2008a). For maximum effectiveness, program and project managers should give rewards throughout the life cycle, rather than just at the end of the program or project. When other team members see that people are being rewarded for good work, they may contribute more than they otherwise would.
Coercive Power
A leader who wields this type of power makes clear that if team members do not comply with the organization‧s or its leaders’ mandates, there will be major negative repercussions. For example, one project manager who used coercive power mandated that everyone arrive at work no later than 7:45. If someone arrived late, this manager made the person take an hour of personal leave. Exceptions were not allowed even if there was bad weather. This manager abused coercive power, and it led to an atmosphere of fear that overshadowed the project. In an economic climate noted by downsizing, outsourcing, or offshoring, the power of such coercive tactics cannot be understated. People often accept assignments they do not really want so that they can keep their jobs. They also believe that they must follow the organization‧s program and project management procedures explicitly and should not make suggestions for improvement to avoid rocking the boat; they want to be considered “ideal” team members. This approach ensures compliance but stifles new ideas that actually could benefit not only the program or project but also the entire organization.
Legitimate Power
A leader who claims this type of power asserts that he or she has a legitimate right to influence others and expects everyone to follow his or her approach to the program or project. Team members may show respect for the leader, but teams led by a manager who emphasizes his or her legitimate power often fail to show continuous improvement and do not develop breakthrough approaches that could provide the organization, program, and projects with additional benefits. Under such circumstances, team members often believe that they cannot live up to their manager‧s standards and that they lack the needed skills and competencies to contribute.
The manager for a project to develop a plan for the transportation infrastructure of the nation for the next 20 years was new to the organization and was noted for her willingness to explore new ideas. The sponsor for this project was pleased by his stature in the organization and how quickly he had attained it, and he relied on his legitimate power. He believed new ideas were not appropriate and insisted that the organization‧s standard project management methodology be followed explicitly. The team members and project manager believed that the traditional methodology would be detrimental and limiting to the project if it were followed without tailoring because this project was different from the organization‧s typical types of projects. But the project sponsor discouraged any innovative approaches when they were presented to him. The project team‧s morale steadily decreased, and many members found other jobs; some even left the agency.
Referent Power
Referent power is based on people‧s identification with a leader and what the leader symbolizes. People admire the leader, value his or her charisma, want to follow him or her, and seek his or her approval and appreciation. The leader may not consciously promote this power.
Assume you have been assigned to work on a project. The project manager is a well-recognized thought leader in the field and speaks regularly at the local PMI chapter and occasionally at PMI congresses. She has PgMP (Program Management Professional) and PMP credentials, she holds a master‧s degree in project management, and she is now in a doctoral program. You feel honored to be on her team.
The project is a complex one involving the development of a new food additive. More than 150 people are working on the project; they are divided into core teams based on specific work packages. You wish you were a core team leader, and you think that you might be chosen if you grab the project manager‧s attention, but you rarely see her except in large group meetings.
When your core team leader says he believes an approach other than the one the project manager proposed will enable your sub-team to complete its work package more effectively and quickly, you are concerned because your sub-team is not following the project manager‧s original suggestions. You want the project manager to admire the work you are doing and worry this will be impossible to achieve if you do not do the work the way she suggested. You decide, then, to ask for an individual meeting with her. Of course, she contacts the core team leader before the meeting to find out why you wish to meet with her. When you meet with her, you learn that the core team leader has already briefed the project manager on the new approach. Your desire for the project manager‧s admiration has led you to go over the core team leader‧s head and assume she was not informed of the change in direction. Your core team leader then meets with you and indicates that you need to follow the chain of command in the future and first meet with him or at least ask him to accompany you to meetings with the project manager.
Expert Power
A leader with expert power uses his or her experience or knowledge to influence others. For example, assume you are on a team with the project manager described above, who is noted for her expertise in the field. Your teammates respect this project manager because they believe her leadership will guide them in their work. Her approach is more persuasive; she does not use the command and control approach used by leaders who favor coercive power. She requires status updates and meetings with team members in order to better influence the team and guide it toward success. This leader realizes she cannot stand totally on her credentials and must continually show she is focusing on her own continuous development in the project management field and expects team members to do the same.
Table 6-1 presents some approaches you might consider if you are a team member working for a program or project manager who has a dominant source of power.
While Table 6-1 focuses on ways a team member might best interact with a program or project manager who claims or is endowed by others with a certain source of power, Table 6-2 offers suggestions that you as a manager can use if you notice that you tend to exhibit a dominant source of power over others. The table explains how the manager can use each of the five sources of power to gain team members’ support and avoid making the team atmosphere one that is considered hostile or undesirable.
Table 6-1 Working with Managers Who Hold One of the Five Power Sources
| Source of Power | Suggestions for Effective Work with the Manager Who Holds This Power |
| Reward power | While the team charter is being developed, discuss the inclusion of a section on rewards and recognition and decide when individual, as opposed to team, rewards and recognition are appropriate. If you are evaluated by your functional manager but have been working for the program or project manager for the majority of the evaluation period, ask your functional manager if the program or project manager can participate in the performance evaluation. If you know you will be continuing with the program or project into the next evaluation period, include specific performance objectives in your performance plan relative to the program or project. Encourage the program or project manager to conduct team- based assessments on a periodic basis and to provide feedback on how the team can better perform for overall program or project success, which in turn could lead to greater rewards and recognition. |
| Coercive power | While job security is important, realize that at times, you may need to challenge the program or project manager and his or her approach. However, do so in a careful and respectful manner. Ask the program or project manager if it is a good time to talk to make sure you are not interrupting him or her at an inappropriate time or when he or she is under stress. When meeting with the program or project manager, present your ideas in a way that does not appear to be in complete opposition to the manager but instead complements the manager‧s approach. |
| Legitimate power | Recognize that the manager has worked diligently to attain his or her position in the organization, so treat him or her with respect. If you have a suggestion that you believe is beneficial, first share it with others on the team before approaching the manager directly. If others on the team believe your idea has merit, work with them to develop a way to present it to the manager. You should introduce the idea in a nonthreatening way, showing that it is not totally different from the manager‧s approach and is designed to enhance it, not replace it. Make sure that when you present the idea, the manager is not in the midst of a crisis and has the time to listen. Thank the manager for taking time to listen to your ideas. |
| Referent power | Show respect for this program or project manager‧s accomplishments, but do not constantly seek his or her attention. Ask the manager for advice, or ask him or her to suggest a mentor who can help you enhance your own knowledge, skills, and competencies. Seek out opportunities to show your own value to the organization and to the project management profession by writing articles on your own time and submitting them for publication by journals, volunteering at the local PMI chapter, or attending prerecorded webinars that do not take time away from the project but do help you develop as a project professional. Point out your accomplishments in a subtle way, especially when it is time for your own performance review. You should avoid seeming egotistical when you do so, but you do not want your work to go unnoticed. When you speak with the manager, convey in an understated way your desire to follow a similar career path. |
| Expert power | Recognize this person‧s accomplishments and demonstrate from the beginning that you are pleased to be a member of his or her team. Be willing to present your own ideas if you feel they can lead to a breakthrough. Approach the manager cautiously and confidently when he or she has time available. Without undermining the manager‧s expertise, show that your idea can benefit the program or project and the organization, and ask the manager to review it at his or her convenience. Later, meet with the leader again to obtain feedback. Do not take criticism personally; the criticism may help you enhance your suggestion and enable you present it again to the manager. |
Table 6-2: Effective Ways to Use the Five Sources of Power
Making a Decision
First, it is necessary to determine who is responsible for the decision. Is it one that:
A team member is empowered to make on his or her own without consulting the project manager or others on the team?
The team can make on its own without consulting the project manager?
The program project manager can make on his or her own?
Must be escalated to the sponsor, the governance board, a steering committee, or another group?
It may be helpful during the preparation of the change management plan to classify the types of changes that may occur and link them to the specific roles and responsibilities, perhaps using a RACI chart to show who is responsible for making decisions, who needs to be consulted, who needs to be informed, and who is accountable for its implementation.
Sometimes the decision-making process can be inclusive, while at other times, decisiveness is required. Wellman (2007) presents an analysis of a case study of an organization within a Fortune 100 company that has used matrix management since the 1950s. There were three key conditions in the organization that influenced decision-making: an open environment in which it was acceptable to disagree with senior executives; a need for program team members, program managers, and executives to make decisions quickly; and an emphasis on rational decision-making based on clear thinking, rather than an expectation of always getting good answers. One participant noted, “Even if the decision wasn‧t total agreement with my way of thinking, I had good rationale … it wasn‧t a matter about saving face and egos … it was about let‧s talk about it in the open, make a decision and make some consensus if at all possible” (p. 68).
In this organization, sometimes there was enough time to wait for additional information before making a decision, and delaying the decision was beneficial. Other times the decision had to be made immediately or with little time for additional interaction with others involved. Portfolio, program, and project managers must determine how much time is available and whether sufficient information must be gathered before a decision can be made.
Consider the following questions if you are working in an environment in which time is of the essence:
If I could ask the opinion of only one or two team members, who would I select, and are they available?
If I could obtain one other piece of information before making this decision, what would I want to see, and how long would it take to generate it?
If the organization has up-to-date information on the knowledge, skills, and competencies of its resources, can I easily and quickly locate someone with the expertise to assist me, even if he or she is not on my team?
Once I make the decision, if others feel I have made the wrong choice, is it possible later to reverse it or change it in any way? What will the ramifications be?
Escalating the Decision
Ideally, one should not make a decision unless he or she is completely confident that all the information needed to make the decision is available and that the decision will not affect other aspects of the program or project or other work underway in the organization. At times, however, all the necessary information may not be available and it may not be possible to get that information before a decision is required. If you have doubts about your authority to make the change, the best approach to follow is to escalate it. Escalation can help promote executives’ buy-in to the ultimate decision and may make it easier to implement. The escalation process can be described in the team‧s charter and in the charters for the program and project managers. However, if you believe you are empowered to make the decision, do so if you have the needed information and expertise, keeping in mind any time constraints.
Communicating and Documenting the Decision
Once the decision is made, follow the program or project‧s information distribution process to share it with stakeholders. PMI (2008b) suggests using a decision log (sometimes called a memorandum for record) to document decisions. Levin and Green‧s (2009) decision-log template offers one approach to describing the decision and relevant background information and noting the decisionmakers, the implementation date, the person responsible for implementation, and the actual implementation date. The template also links the decision to the program work breakdown structure. The decision log should be part of the program‧s knowledge repository system and placed on the portal or shared drive for reference during program work. It also can be used for future programs and projects as a source of lessons learned.
Making Decisions and Accepting Change
Once a decision is made, it will lead to a change in the portfolio, program, or project. At the portfolio level, for example, different business units or departments may propose activities to pursue that will advance the strategy, and resources may have to be allocated or reallocated accordingly. Ideally, the stakeholders will buy into the changes and accept them, but this is unusual. Even if certain stakeholders had active involvement in the decision-making process, they may still have to work to accept it. Lewin (1947) described a three-phase change acceptance process:
Unfreezing: In this phase, the goal is to prepare stakeholders for the change. The objective is for each person to see the need for the change, even if they do not support it.
Changing: During this phase, the stakeholder is motivated to change; identifies a way of changing; tries to make the change meaningful for the stakeholder; or internalizes the change into his or her approach to the work.
Refreezing: At this time, the change has been accepted, new ways of working are in place, and stakeholders are following them. The change is reinforced and ingrained.
Applying this approach to portfolio, program, and project management, PMI (2008a, 2008b, and 2008c), notes distinctions in how each type of manager approaches change. The project manager tries to keep changes to a minimum and to control and monitor them, while recognizing that change is inevitable (2008a). The program manager embraces change and expects it to occur both internally and externally to the program, so he or she must have skills in managing change across the program (PMI 2008c). And the portfolio manager monitors changes in the organization‧s environment that might affect the portfolio at a strategic level and shares these changes with members of the portfolio review board or a comparable group (PMI 2008b).
For example, assume you are managing a large program that is scheduled to last six years. There are nine different projects in the program management plan; three are already underway. It also has nonproject work. A large virtual team is working on this program; its members are located in various areas on three different continents. When changes occur and decisions are made, you want to be able to easily implement them without disruption to the team. Levin and Green (2009) suggest:
Preparing a change management plan early in the program, as part of the planning process, that describes the processes and procedures that the team will use to manage program changes
Recognizing that certain types of changes are mandatory, while others are optional but may benefit the program
Realizing that some changes are more risky
Describing the process to follow to submit a change request and listing the people who will need to sign off on it
Determining how the change is to be communicated and how its status is to be tracked.
Decision-Making Checklist
The following decision-making checklist is for use by portfolio, program, and project mangers.
Who makes the decision?
• Sponsor, portfolio manager, program manager, project manager, team member
What alternatives are considered before the decision is made?
• How is information obtained before making the decision?
• Who provides the information?
• Is the source considered credible, or are experts required to evaluate the information?
• Is the person with the greatest access to the information able to make the decision? This gives a sense of ownership to the decision.
• How are priorities determined?
• Are different categories of decisions made at different levels?
• When is escalation required?
• Is a team charter or program or project manager charter followed?
Have all available resources been considered and used?
• Were subject matter experts consulted, or does the program or project manager lack the time to consult others?
• Were the necessary internal and external stakeholders consulted?
Are any additional problem-solving skills needed before the decision is made?
• Should the decisionmaker use focus groups (to obtain information on attitudes), brainstorming (to obtain a variety of ideas in a random way), the Delphi technique (to obtain consensus using a facilitated approach anonymously), the nominal group technique (to obtain ideas by asking only one person at a time to share his or her ideas), or interviews?
• Should decision matrices and decision trees be used?
Are people satisfied with the process that is being followed?
• How often is the process evaluated?
• Does the team charter help the team determine if a decision requires escalation?
Is a log of all decisions made on the program or project maintained for future lessons learned and for the archives?
Are the decisions effective?
• What criteria are used to make the decision?
• Are prevailing organizational values or standard approaches to making decisions followed?
• Are people committed to implementing the decision?
Discussion Questions
Fisher (1974) lists a number of inaccurate myths about group decision-making:
Members of a group discussion do not focus on argumentative positions but maintain an open mind and a spirit of free inquiry.
If there is too much interpersonal criticism, communications break down.
Effective groups strive to achieve nearly equal participation among their members.
Each member must perform certain duties.
Making decisions is more important than getting along with one another.
A group must follow an orderly agenda that directs it to its goal for effective decision-making.
Some people are natural leaders.
The group members’ personalities exert the most significant influence on group decision-making.
In the long run, the group will achieve more effective results through using democratic processes than if it achieved results in other ways.
Almost any job can be done by a group rather than an individual.
Consider the above list. Are any of these myths true for your program or project? If so, how can you prevent their occurrence? For example, what would you do if your team felt everyone had to be involved in each of the work packages; if a team member believed he was such a natural leader he tried to usurp your authority; if your team consisted of all extraverts except for one introvert, and the introvert rarely contributed in team meetings?
If your team has not experienced any of the problems listed by Fisher, why do you think this is the case?