Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Conversion factor -Engineering and labour manhours

5 replies [Last post]
Kumar I
User offline. Last seen 13 years 39 weeks ago. Offline
Joined: 15 Jul 2003
Posts: 52
Groups: None
What is the conversion factor to be applied to the engineering manhours to convert to labour manhours ,if we want to load all the schedule activities with labour manhours,for earned value measurement

Replies

Andrew Dick
User offline. Last seen 8 years 10 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
No doubt there is more than one way to skin a cat.

I’m currently on a project that has not had official contract award at this time. We have a letter of intent (LOI) as of last week. The original project start date (When tendered) was very early May, so here we sit in early July with an LOI.

Now if you were all gambling men/women out there you wouldn’t even waste your money on betting what the current planned end date for the project is, even after a 2 month plus delay to engineering.

That’s right the same as it was 2 months ago. So what does that mean to my productivity factor. (OK stop laughing)

I couldn’t agree more with your method Steve of planning the schedule with fully dedicated resources. It really drives home the issue of shared resource pools when those results come out.
I guess I will continue to develop my schedule based on the deliverables list & budget, set the activity durations so that we meet the delivery time for all IFC drawings. Then I suppose I’ll be accused of not knowing one end of the schedule from the next when my resource profiles indicate that I now need another 18+ FTE’s to deliver the engineering by the planned date.

Lets not forget, that these blokes suggested that we could get 75000hrs of engineering done in 12 months with a team of 30. Now unless my calculator is broken I can only burn about 62500 hrs with 30 engineers over 12 months being 100% productive for 40 hours per week. Now that my schedule is only 9 months long I can only hope to burn around 46800 hrs. Oh dear, what will we do?????

I guess I will have to get my crayons out and start drawing some pretty pictures again.

It keeps me off the streets anyway. :-)

Andy
Stephen Devaux
User offline. Last seen 14 weeks 2 days ago. Offline
Joined: 23 Mar 2005
Posts: 667
Andrew wrote: "These two things are generally hard to link; particularly in an engineering firm where some staff are required on multiple projects and are not fully dedicated to one project."

Hi, Andrew. That point about multitasking is SO huge! Everyone knows about it and has a sense of how it diminishes productivity -- yet everyone gaily pretends it doesn’t exist so that they can understaff and then underestimate duration and cost!

One of the guidelines I teach is to always make initial estimates for the CPM schedule based on dedicated resources, even if we know there’s no way in hell we’ll get them. Then, when we load resources and go to the resource-constrained schedule, the project duration suddenly increases by 40% due to multitasking and part-time resources on the CP.

What is the cost of that 40% increase in time? That is the only way to begin justifying dedicated resources, by starting to compute the resource unavailability (and multitasking) costs.

Carmen wrote: "BUT there are no mysteries. Good Engineering Companies know the portion in the productivity factor that needs to be allocated to cover the unknowns.

Tracking the real productivity vs. a planned productivity is a healthy practice in order to ensure that the unknowns are more or less under control."

True, Carmen. But in my experience, "Good Engineering Companies", in terms of how they do project management, are only slightly less r5are than hens’ teeth. If aviation engineering companies did aviation engineering the way they do project management, three or four planes would fall from the sky every day.

Of course, if aviation engineering companies did aviation engineering the way that, for example, information systems does project management, no plane would ever fall from the sky, as no plane would ever get off the ground!

Fraternally in project management,

Steve the Bajan
Carmen Arape
User offline. Last seen 6 years 32 weeks ago. Offline
Joined: 26 Jun 2004
Posts: 292
Dear Andy,

Your post is so interesting that I could not miss the opportunity for joining the discussion.

First al all: a quick and easy explanation about the term:
“Labor productivity” is typically measured as a ratio of output per labor hour.

Based on the supposition that the conversion factor (mentioned by Kamir) would be the productivity (mentioned by you ), I would like to add the following:

Fully agree with regarding the 88% figure based on the knowns mentioned by you (including time for smoking -smoke area that might be on the street while his/her office is the fifth floor- , going to the toilet and chatting around the coffee machine.

SECOND and most important: the unknowns impacting the completeness of the deliverables (output) and demanding a lot of hours (input). These unknowns must be in the productivity factor.

The unknowns are the reason why the productivity remains a mysterious number (as you say.

BUT there are no mysteries. Good Engineering Companies know the portion in the productivity factor that needs to be allocated to cover the unknowns.

Tracking the real productivity vs. a planned productivity is a healthy practice in order to ensure that the unknowns are more or less under control.

Carmen
Andrew Dick
User offline. Last seen 8 years 10 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
Kumar,
If I understand your question, what you are after is some way of determining what sort of productivity you will get from your engineering team for direct engineering compared to how many man days they will be required to be owned (or how much time they will book) by the project?

These two things are generally hard to link; particularly in an engineering firm where some staff are required on multiple projects and are not fully dedicated to one project.

You firstly need to look at how you determine what constitutes ‘Direct Engineering’ hours. Does this effort pertain only to the effort required to produce a deliverable (Say a detail drawing)??
Then what is the split between the types of resource required, Engineer, Drafter, Reviewer??
How much time has been estimated in the production of that deliverable associated with “Churn” (The ‘Do it again’ factor).

There is much more to consider when determining what may have gone into the thinking of the person who generated the man-hours estimate on any single engineering deliverable (I’ve found that everyone does it differently)

As long as you can get agreement on what the budget comprises for each deliverable you’ve made a start.

Then you need to consider the available work-hours that you may get from any individual employee. This will go some way to determining what your possible productivity will be associated with the production of that engineering work.
This will not tell you ultimately how much it will cost, but moreover how long it will take.

Let’s take an example of the initial available productivity for Australia;

Figures are indicative only.

Days per year;
365
Actual available work days per year
104 (Weekends),
10 (Public Holidays)

Therefore;
365 – (104+10) = 251
251 * 8 (Hrs per day) = 2008 available productive hours per year

Then consider the amount of time an employee will actually work per year
Days per year;
365
Non work days per year;
104 (Weekends),
10 (Public Holidays)
10 (Sick leave)
20 (Annual Leave)

Therefore;
365 - (104+10+10+20) = 221
221 * 8 (Hrs per day) = 1768 available productive hours per year

What does this mean??
Productivity calc.
1768/2008 = ~.88

So each resource on your project (Over a year) would only be 88% productive based on daily work availability. This is of course if on the days they attend work they actually get a full 8 hours of work done, don’t go to the toilet (Except at lunch), don’t go for a smoke, coffee, or talk about the weekend, answer no phone calls etc etc etc..

HOWEVER they will still book the full 8 hours perday to the project so you would assume that each resource is capable of booking 1768 hours (Minimum) to you project each year.

In summing up (Hope I didn’t loose you) it would seem that at minimum the following would apply;

Over a 251 day work year you could only plan for 88% productivity out of any resource.
That resource will book a minimum of 1768 hours to your project over that year
The actual productivity of that resource will also be affected by time spent doing all the things we do at work (talk, eat, smoke, etc)

It still remains that the productivity is a mysterious number that will only be really known after the fact, that said when trying to explain this to any engineering team you must first understand what they have budgeted for in the budget for the deliverables. Then you need to help them understand what their actual available productivity is likely to be. Then discuss ways of mitigating actual PF against planned PF. Lets not forget that if you don’t have fully dedicated resources your actual PF is likely going to decrease as those resources swap from job to job as there are always inefficiencies when moving from one task to the next.

I hope this makes a start for you in answering these questions. It’s not the be all and end all, but just some basic figures that we all know go straight out the door as soon as the project starts.

Andy
Shah. HB
User offline. Last seen 15 weeks 1 day ago. Offline
Joined: 25 Nov 2008
Posts: 773
Hi Kumar

I guess you need to check per day the effort of Engineering and Labor, form that you can find the factor to be multiplied to get desired result