ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Project Rewards and Recognition – Fair or Adding Risks?
Saturday, 10 July 2010 05:00

Project Rewards and Recognition – Fair or Adding Risks?

Written by  Gary Hamilton, Gareth Byatt, and Jeff Hodgkinson
Rate this item
(0 votes)
RecognitionReward and recognition for project resources who deliver successful projects is generally accepted as good practice in the workplace (indeed, rewarding staff for successful performance against agreed criteria is commonplace in today’s organizations). Regardless of an organization’s general structure (be it projectized, functional, matrix-based etc), successful project completions are rightly celebrated. At project closing, the project team should take the opportunity to celebrate their accomplishments, with the project manager and/or upper level of stakeholders using this event as an opportunity to recognize particularly strong performances from individuals on the team. Celebrating project success, when it is merited, is a worthy process; however, the manner or magnitude in which you celebrate project success has the potential to cause problems elsewhere within your organization if it is not handled in a measured way. 

Let’s consider a couple of scenarios: the dynamics of the “functional organization”, and those of the “projectized organization”.

In a functional organization, when resources are assigned to a project team, the people made available for selection will depend on which qualified resources can be pulled away from their functional role for the prescribed time duration estimated for them to complete their part in the project. If the project is of a high priority, “A Performers” may be allocated from functional work (or perhaps other projects). Do these people get replaced in their functional role? If not, those who have to fill-in and undertake their functional tasks may cause discontent in the functional group, which may lower morale and cause performance issues. The potential for disquiet outside the project will be magnified if the project team celebrates their project on closing and no thanks were made about the coverage of the functional work others shouldered in their absence. You will suffer more of the same risks should the same small group of resources continually be selected for projects (akin to placing all your eggs in the one proverbial basket).  In the extreme, people who are not given opportunities may seek other internal or external opportunities, and your organization may fail to build a strong “bench” of resources who have the ability to work on a variety of projects (which leads to succession planning problems). Be sensitive to such risks through appropriate communications and an understanding of how the tasks of projects and ongoing functional teams are equally important in your organization.

Now let’s look at the “projectized organization”, where project work is the primary priority. Does such an organization consistently staff its high-profile projects with the same star performers or does it mix reward and opportunity appropriately? Do your high-profile projects consistently get far more recognition and larger rewards than so-called lesser priority projects? If the answer to this question is yes, then many of the risks discussed in the functional organization are present here also. People who are not given opportunities to work on your high-profile projects may feel “passed over”, and may begin to look for external opportunities. At the same time, maybe your star performers feel over-worked, stressed, and in need of recharging their batteries. In the projectized type of structure you need to be careful to provide the right opportunities to your teams; manage succession planning appropriately, giving opportunities to up-and-coming people and “stretch targets” for your team members all round.

 

So, how do you balance project reward and recognition on project completion regardless of the organization structure? Plain and simple, there is no standard method for reward and recognition that spans all projects in all organizations. The process you use for project resource selection will have a direct correlation on the perceived fairness of your project and the reward and recognition system used. There are a few actions you can take as a Project Manager (and with your senior management) to ensure a project reward and recognition system is just and appropriate.

A few pointers we suggest are as follows:

  1. Make sure the reward given for project staff is appropriate for the contribution made, and make sure reward measures are clearly laid out at the start of the project, and communicated to all involved.
  2. Ensure lesser experienced staff that needs coaching before they are fully productive are given appropriate opportunities to work on all projects (whilst not leaving them, or the organization, exposed). These resources can serve as “shadow” or back-up resources to those accountable for the project deliverables. The“shadow” resources will serve two purposes: 1) broaden your bench, allow some tasks to be delegated to the shadow 2) begin to make an equitable reward process. The shadow resources should be considered in the project’s reward and recognition structure based not only on their contributions, but also on their knowledge, growth and performance during the project.
  3. Ensure only desired behaviors are rewarded. Individuals that may get the assigned tasks completed, but do so through over-time, non-conforming manners or other behaviors not consistent with your organization should not receive individual recognition.
  4. Always ensure that any recognition is given in a timely manner and communicated properly to the appropriate management levels.
  5. Consider the project celebration in the context of the overall organization and the overall contribution of people who may not be directly on the project but indirectly have played their part.

In conclusion, reward and recognition systems for projects are difficult to get right. First make the project selection equitable, consider the overall impact of people on the project and on its periphery, and ensure the reward and recognition process is set appropriately.

 


Bios:

Gareth Byatt, PMP is Head of the IT Global Program Management Office for Lend Lease Corporation. Gareth has worked in several countries, and is currently located in Sydney, Australia. Gareth has 14 years of project and program management experience in IT and construction. Gareth can be contacted through LinkedIn. Gareth holds numerous degrees, certifications and credentials in program and project management as follows: an MBA and first-class undergraduate management degree, PgMP®, and PRINCE2.


Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary has 14 years of project and program management experience in the IT, Finance and HR. He has won several internal awards for results achieved from projects and programs he managed. Gary can be contacted through LinkedIn.  Gary holds numerous degrees and certifications in IT, Management and project management which include: an advanced MBA degree in Finance, PgMP®, PMP®, PMI-RMP®, ITIL-F, and SSGB. Look for Gary at the PMI Global Congress 2010-North America.


Jeff Hodgkinson is the IT Cloud Program Manager for Intel Corporation. He is a 30-year veteran of Intel Corporation with a progressive career as a Program/Project Manager.  He is located in Chandler, Arizona and also volunteers in various support positions for the Phoenix PMI Chapter.  Jeff was also the 2nd place finalist for the 2009 Kerzner International Project Manager of the Year AwardTM.   Due to helping people achieve their goals, ‘Hodge’ as referred to by his many friends is one of the most well networked and recommended people on LinkedIn.  Jeff holds numerous certifications and credentials in program and project management as follows: CCS, CDT, CPC™, CIPM™, CPPM–L10, CDRP, CSQE, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMW, and SSGB. See Jeff at the PMI Global Congress 2010-North America as he will be co-presenting a paper on, "Value of the PgMP® Credential in the Working World".

 


STYLE-->

Attribute Level

CI (Customer Impact) Factor

TS (Technical Severity) Factor

 

1

7 =

Directly Affects Major Customer’s Business Objectives

Directly Affects Revenue

Required/Affects most/all of the company 

Negative Impact to your organization and/or business

No Solution and/or no progress and the is solution overdue

Group has high degree of influence / impact to effect change or solution

Great time investment

4 =                                                                                                               No known technical solution or owner at the company

 

2

5 =

Customer business impacted without requirement

Direct Impact to IT Organization and/or Business

Commitment made by org but not being implemented

Required/Affects multiple customers and sites

Solution in progress

Completion date unknown

Group has some degree of influence/impact to effect change or solution

Good time investment

3 =

Some technical investigation, theory, or direction as to fix.

 

Technical Solution Owner(s) identified 

 

3

3 =

Customer can work without this requirement /request

Solution in progress and completion is date known

Required by single customer or unique need (small scope)

Project Team being formed

No resource or funding

Group has little degree of influence/impact to effect  change or solution

Questionable time investment

2 =

Technical Solution currently being designed. 

 

Could be near Alpha quality

 

4

1 =

Solution done – in maintenance or monitoring mode

Project Team (resourced/funded) working on  implementation

Solution in place & monitoring progress w/ customer/supplier

Group has no degree of influence  or impact to effect change or solution

Poor time investment

1 =

Technical Solution currently being designed.

 

Could be near Beta quality.

 

Solution currently being tested or implemented. 

Technical Work-around exists / usable

Read 25757 times Last modified on Monday, 30 August 2010 13:55
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 364 guests and no members online

Got something to say?