Reward Management on Projects: Shouldn’t Critical Path Workers Be Better Compensated?

Sorry for the silence the past several weeks – first ,family visitors for a month. Then selling our house and moving back into the city, into a rental apartment. A big project and lots of hard work: getting the house ready for “showing”, then moving. Still lots of boxes to unpack, but at leastthe furniture is in, if not all in the right spot. The P&S agreement on the sale should be signed today.

So I should be back on a regular basis hereafter.

***

There is a sense that, in addition to basic productivity, every worker’s compensation should be based on three primary factors:

  1. How rare, expensive and/or irreplaceable are the skills of the worker?
  2. What value do they add to the endeavor/organization?
  3. How hard/conscientiously did they work to provide that value?

A is the factor that is largely determined outside the organization that provides the employment. It depends on things like economic conditions, lagging response of labor markets in the form of educational trends and programs, and migratory flexibility. It is also the factor that is most easily understood by the corporate HR Departments that set compensation levels.

I well remember how in Boston from about 1997 to 2000, at any given moment there could be 10,000 jobs unfilled for computer programmers. Growing Internet usage, the dot-com bubble and the Y2K problem all combined to allow anyone who could qualify as a programmer to command a far greater salary than expert programmers could have done just a couple of years earlier, or would be able to do just a couple of years later. Companies and project teams were pleading with HR to boost salary offers to prospective new hires, and to give “stay” bonuses to programmers as incentives to not look elsewhere until their project was complete.

HR departments were often quite resistant to offering what they felt were exorbitant incentives. They knew what salary levels for programmers had been shortly before (and although they couldn’t know it, soon would be again!) and did not want to blow the whole organization’s wage structure out of the water.

But this reluctance (part of the phenomenon in economics that is known as wage-price stickiness) was hugely frustrating for project managers who needed new programmers to meet deadlines. They dreaded losing halfway through the project the specific programmer who had written the initial 50% of the code for a module. Yet Factor B above, the value the programmer was adding (or that would walk out the door with them if they left) was something that the folks in HR were not fully trained to comprehend. This is particularly the case regarding the disastrous consequences of delaying the critical path, especially in the charged atmosphere of product delivery in the high tech boom years!

This all brings us back to the crucial item that is explained in depth in my book Managing Projects as Investments and is discussed in many of these blog articles (you can find them by searching under the tags “value/cost of time” and “delay cost”): the fact that on the vast majority of projects, the value/cost of time is being left as an unquantified externality. It is not enough to quantify time simply in units of days or weeks. Nor is it sufficient to say: “Time is very important,” or “We can’t be late!” A project team has to know what the impact of duration, shorter or longer, is on the expected value of the project investment. That way, decisions that maximize ROI can be analyzed and made across the Golden Triangle of scope, cost and schedule.

The fact that must be recognized is that the refusal by HR to increase the offer to a new systems engineer by $20,000, or to provide a stay bonus of $15,000 to our current programmer, will result in an elongation of our critical path. At a drag cost due to reduced expected project value of, say, $100,000 per week!

Those who frequently work on the critical path of projects or programs usually have a lot of pressure on them. And they should – their work carries great value to the organization and significant drag cost for the time they take. But failure of an organization to recognize the value of such resources and to provide adequate remuneration to keep the project skipping on down the critical path often results in a lose-lose for all concerned.