MANAGING REWARD SYSTEMS FOR THE PROJECT PDF

Title MANAGING REWARD SYSTEMS FOR THE PROJECT
Author Jeremy Elliott
Course  Project Management
Institution Central Washington University
Pages 7
File Size 73.6 KB
File Type PDF
Total Downloads 52
Total Views 144

Summary

Creation of a shared vision, management of reward systems for the project, orchestration of the decision-making process, facilitation of group decision-making, management of conflict within the project....


Description

MANAGING REWARD SYSTEMS FOR THE PROJECT

Project managers are responsible for managing the reward system that encourages team performance and additional effort. One advantage of this is that the work of the project is often inherently satisfactory, whether it manifests the way in an inspiring vision or a simple sense of achievement. Projects give participants a change of scenery and the opportunity to learn new skills and get out of their departmental cocoon. Another inherent reward is what is mentioned in The Soul of the New Machine as "pinball": the success of the project usually gives team members an option to undertake another exciting game. Either way, many projects are underestimated, bored, interfere with other more significant priorities, and are considered an additional burden. In some cases, the biggest reward is to finish the project so that team members can return to what they really enjoy doing and what will yield higher personal performance. Unfortunately, when this attitude is the main incentive, the quality of the project could suffer. In these circumstances, external rewards play a greater role in motivating team performance. Most of the project managers we talk to advocate for the use of group rewards. As the most productive project work is a collaborative effort, it only makes sense that the reward system encourages joint work. Recognizing members individually regardless of their achievements can distract team unity. The work of the project is too interdependent, so it can become problematic to distinguish who really deserves additional credit. Cash bonds and incentives need to be linked to project priorities. There is no point in rewarding a team for finishing their work early, if the priority is to control costs. One of the restrictions on cash bonuses is that they are too often spent within the household budget to pay the dentist or mechanic. To be more valued, rewards must have lasting meaning. Many companies convert cash into holiday rewards, sometimes with the corresponding rest time. For example, there is a company that rewarded the project team for doing the work early on an all-paid four-day trip to Walt Disney World for the full families of the members. This holiday will not only be remembered for years, but also reward spouses and children, who in a sense also contributed to the success of the project. Similarly, other companies are known to give members home computers and entertainment centers. Smart project managers negotiate a discretionary budget so they can reward teams who overcome major events with gift certificates for popular restaurants or tickets to sporting matches. Parties with pizzas and makeshift barbecues are also used to celebrate key achievements. Sometimes project managers should use negative reinforcement to motivate project performance. For example, Ritti tells the story of a project manager who was in charge of building a new manufacturing plant with the latest developments. His project team worked with several hiring companies. The project began to be

delayed, mainly because of a lack of cooperation between the parties. The project manager had no direct authority over many key people, especially the contractors of the other companies. However, he was free to convene meetings at his convenience. So the project manager instituted daily "coordination meetings" that required the main participants to be present at 6:30 a.m. Meetings continued for nearly two weeks until the project returned to its course. At that time, the project manager announced that the next meeting was canceled and no more sessions were scheduled at dawn. Although project managers tend to focus on group rewards, there are times when they need to reward individual performance. This is done not only to compensate for extraordinary effort, but also to show others what exemplary behavior is. More specifically, the rewards they use to motivate and recognize individual contributions include: Letters of recommendation. Even if project managers don't have responsibility for their team members' performance assessments, they can make letters of recommendation about their project performance. These letters can be sent to workers' supervisors for placing in their personal files. Public recognition for outstanding work. Brilliant workers should be publicly recognized for their efforts. Some project managers begin each statute review meeting with a brief mention of project workers who have exceeded the goals. Work assignments. Good project managers recognize that while they can't have much budget authority, they do have substantial control over who does what with whom, when, and where. Good work should be rewarded with desirable work assignments. Administrators should be aware of members' preferences and, where appropriate, meet them. Flexibility. Being willing to make exceptions to the rules, if done judicially, can be a powerful reward. Allowing members to work at home when a child is sick or apologising for a minor issue can lead to long-term loyalty. We reiterate that individual rewards should be used judicially and the main emphasis should be on group incentives. Nothing can undermine a team's cohesion more than when members start to feel that others are treated specially or that they are treated unfairly. Camaraderie and collaboration can fade quickly only to be replaced by quarrels and obsessive concern for the group's politics. These distractions can absorb a tremendous amount of energy that would otherwise be aimed at completing the project. Individual rewards should be used only when the entire team recognizes that a member deserves special recognition. Creating a shared vision Unlike project scope statements, including a specific cost, compliance dates, and performance requirements, one view encompasses less tangible aspects of project

performance. It refers to an image that a project team has in common about what the project will look like when it is completed, how they will work together, and how customers will accept the project. At its simplest level, a shared vision is the answer to the question "what do we want to create?" Not everyone will have the same vision, but the images should be similar. Visions come in a variety of shapes and figures; can be captured in a slogan or symbol and can be written as a formal statement of vision. What is a vision is not as important as what it does. A vision inspires members to do their best. In addition, a shared vision unies professionals with different backgrounds and agendas for a common aspiration. Members are motivated by subordinating their individual agendas and doing what is best for the project. According to psychologist Robert Fritz, "in the presence of greatness, small things disappear." Visions also provide focus and help communicate less tangible priorities, making it easier for members to make appropriate judgments. Finally, the shared vision of a project fosters long-term commitment and discourages appropriate responses that collectively dilute project quality. Visions can be surprisingly simple. For example, the vision of a new car can be expressed as a "pocket rocket". Compare this vision with the more traditional description of the "intermediate price sports car" product. The "pocket rocket" vision gives a much clearer picture of what the final product should be. Design engineers should soon understand that the car will be small and fast, immediately starting, agile on laps and very fast on the straights. It is clear that many details would have to be worked on, but the vision would help to establish a common framework for decision-making. There seem to be four essential qualities of an effective vision: first, its essential qualities must have the ability to be communicated. A vision is useless if it only resides in someone's head. Second, visions must be challenging, but also realistic. For example, for the workforce overseeing the curriculum at a state university's business school, it would be strange for the rector to announce that his vision is to compete with Harvard Business School. On the contrary, developing the best business diploma program in the state could be a realistic vision. Third, the project administrator must believe in the vision. Passion for vision is an essential element for it to be effective. Finally, it should be a source of inspiration for others. Once a project manager accepts the importance of building a shared vision, the next question is how to achieve a vision for a particular project. First, project managers don't get the views. They act as catalysts and intermediaries for the formation of a shared vision of a project team. In many cases, visions are inherent in the scope and objectives of the project. Of course, people get excited when they're the first to bring technology to market or solve a problem that threatens their organization. Even with worldly projects, there are often ample opportunities to establish an attractive vision. One way is to talk to the different participants and find out from the beginning what excites them about the project. For some,

overcome the work of the most recent project or see satisfaction in the eyes of customers when the project is finished. Many visions evolve reactively in response to competition. For example, Kodak's team responsible for developing the FunSaver disposable camera was boosted by the vision of gaining the market arrival of a similar Fuji item. Some experts advocate participation in formal vision-building meetings. Typically, these boards include several steps, starting to identify with members the different aspects of the project, and generating ideal scenarios for each aspect. For example, in a construction project, scenarios may include "no accidents," "no demand," "winning a prize," or "how we're going to use our bonus for finishing the project early." The group reviews and chooses the scenarios that are most attractive and converts them into vision statements for the project. The next step is to identify strategies for achieving vision statements. For example, if one of these statements is that there will be no lawsuits, members will identify how they will have to work with the owner and subcontractors to avoid litigation. Members are then offered as volunteers to keep each statement up to date. The vision, strategies and name of the responsible team item are published and distributed to project stakeholders. In most cases, shared visions emerge informally. Project administrators collect information about what excites project participants. They test parts of their work vision during conversations with team members to assess the degree of emotion that early ideas cause in others. To some extent, they participate in basic market research. They take the opportunities to propel the team, such as an executive's derogatory comment that the project will never be done on time or the threat of a competing company launching a similar project. At first, consensus is not essential. The noun is a central group of at least one-third of the project team that is genuinely committed to vision. They will provide the critical mass that will rise to others on board. Once the language has been developed to communicate the vision, the statement has to be a basic part of all work agendas and the project manager should be prepared to give a campaign speech almost without prior notice. When problems or disagreements arise, all responses must be consistent with vision. Much has been written about visions and leadership. Critics claim that vision is a glorified substitute for shared goals. Others claim it's one of the things that separates leaders from administrators. The keys are to discover what excites people in a project, to be able to articulate this source of emotion in an attractive way and, finally, to protect and nurture this source of emotion through the duration of the project. Orchestration of the decision-making process Most decisions in a project do not require a formal meeting to discuss alternatives and determine solutions. Instead, solutions are made in real time as part of

everyday interaction patterns between project managers, stakeholders, and team members. For example, as a result of the routine question "how's it going?", a project manager discovers that a mechanical engineer is trapped trying to meet the performance criteria for a prototype to build. The project manager and engineer go down the aisle to talk to the designers, explain the problem and ask what can be done, if anything. Designers distinguish which criteria are essential and which can be compromised. The project manager then checks with the marketing group to make sure the modifications are acceptable. They agree with all but two modifications. The project manager returns to the mechanical engineer and asks if the proposed changes would help solve the problem. The engineer agrees. Before authorizing the changes, he calls the project sponsor, reviews the events, and causes the sponsor to sign the changes. This is an example of how, by practicing WBWA (route management), administrators consult team members, request ideas, determine optimal solutions, and create a sense of engagement that creates trust and commitment to decisions. In any case, the projects find problems and decisions that require the collective wisdom of the team members, as well as the relevant stakeholders. Group decision-making should be used when the quality of important decisions is improved. This is often the case with complex problems that require the input of a variety of specialists. Group decision-making should also be used when a strong commitment to the decision is needed. Participation is used to reduce resilience and ensure support for the decision. Joint decision-making would be requested for controversial issues that have a significant effect on project activities or when confidence is low within the project team. Facilitation of group decision-making Project administrators play an essential role in guiding the group in decisionmaking. They should remember that their job is not to make a decision, but to facilitate discussion within the group so that consensus is reached on the best possible solution. Consensus within this context does not mean that everyone supports the decision at 100%, but that everyone agrees that it is the best solution in those circumstances. In essence, facilitating group decision-making includes four important steps. Identification of the problem. The project administrator needs to be careful not to assert the problem in terms of options (for example, should we do X or Y?). Instead, you should identify the underlying problem for which these alternatives, and perhaps others, are potential solutions. This allows group members to generate options, not just choose from them. A useful way to define problems is to consider the gap between where a project is (for example, the current state) and where it should be (desired state). For example, the project may have a four-day delay in the program or the prototype weighs two pounds longer than stipulated. Whether the gap is small or large, the goal is to eliminate it. The group must find

one or more action courses that will change the existing state to the desired state. If one detects a defensive posture during the scan to identify the problem, then it would be smart, if possible, to postpone troubleshooting. This allows emotions to come down and members to get a fresh perspective on related topics. Generation of alternatives. Once there is general agreement on the nature of the problem, the next step is to generate workarounds. If the problem requires creativity, a brainstorm is recommended. Here the team generates a list of possible solutions on a flipchart or blackboard. During this time the project manager establishes an extension to criticize the ideas under evaluation. Members are encouraged to take the ideas of others, extend them, or combine them to form a new idea. The goal is to create as many alternatives as possible, no matter how strange they may seem. Some project managers report that for real strong problems they have found it beneficial to conduct those sessions outside the normal work environment; changing scenery stimulates creativity. Get to a decision. The next step is to evaluate and consider the merits of alternate solutions. During this phase it is useful to have a set of criteria to evaluate the merits of the different solutions. In many cases, the project manager can take the priorities of the project and have the group evaluate each alternative in terms of its impact on cost, program and performance, as well as reducing the problem gap. For example, if time is crucial, then the solution that solves the problem as soon as possible would be chosen. In the course of the discussion, the project administrator tries to reach consensus among the group. And it can be a complicated process. Project managers need to provide periodic summaries to help the group keep track of their progress. They must protect the members who represent the minority's point of view and ensure that those views get fair attention. They need to ensure that everyone has the opportunity to share their opinions and that no individual or group dominates the conversation. It may be useful to bring a stopwatch to regulate the use of weather in the air. Project administrators need to participate in consensus tests that determine where the group agrees and what are still the sources of conflict. Be careful not to interpret silence as a covenant; confirm the agreement by means of questions. Finally, through careful interaction, the team arrives at a "mind meeting" as to which solution is best for the project. Tracking. Once the decision is made and carried out, it is important for the team to find the time to evaluate the effectiveness of the decision. If it does not provide the advance solution, then the reasons should be explored and lessons learned for the collective memory bank of the project team. Conflict management within the project

It is natural for disagreements and conflicts to arise within a team during the life of the project. Participants will disagree on priorities, resource allocation, the quality of specific work, solutions to discovered problems, and so on. Some conflicts support the group's goals and improve the performance of a project. For example, two members can engage in a discussion about a design grant decision that includes different characteristics of a product. Both argue that their preferred feature is what the primary customer actually wants. This disagreement can force them to talk or learn more about the customer, with the result that they realize that neither feature is highly valued and that instead the customer wants something else. On the other hand, conflicts can also hinder the group's performance. Initial disagreements can escalate into heated disputes and both sides abruptly leave the office and refuse to work together. Research by Thamhain and Wilemon revealed that sources of conflict change as projects progress throughout the project lifecycle. During the definition of the project, the most significant sources of conflict are priorities, administrative procedures, programmes and the workforce. Disputes occur because of the relative importance of the project compared to other activities, what administrative structure to use (especially how much control the project manager should have), the personnel to be allocated, and the project schedule in existing workloads. In the planning phase, the main source of conflict remains priorities, followed by programmes, procedures and technical requirements. Disputes arise when reviewing the importance of the project against other activities that project managers often use (especially how much control it should have), the personnel that will be assigned, and the project schedule in normal workloads. During the planning phase, conflicts for the boss remain priorities, followed by programming, procedures and technical requirements. This is the phase where the project moves from a general concept to a detailed set of plans. Disagreements often arise over a final program, resource availability, communication and decision-making procedures, and project technical requ...


Similar Free PDFs