(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.
Hi Guys,
I’m just posting to see if anyone can help with a query I have on productivity.
I work on an oil refinery for a large E&I contractor who hold the term contract here. Our duties are to perform all project works from installing new cables for substations to piping up new instruments. This means my programme is made up of hundreds of jobs that range from 6 hours up to 5000 hours.
A senior member of staff has asked me to take a look at recording productivity for each job. I am able to record burned hours through a clocking system and we record which job each guy on site has been working on daily. We can effectively whittle the overall burned hours down to each job number from this. We also receive an estimate of each job so I can populate the budgeted hours into the programme. So as the percentage rises within the programme (% is linked to hours earned), we would just use the equation:
Hours Earned (% of estimate complete) over Hours Burned (Collected from clocking system)
An example is:
Hours Earned = (50% of works complete on 1000 hour estimate) = 500 hours
Hours Burned = Straight from clocking system = 600
Productivity = 500 over 600 which would give me 0.833...
My problem lies when we get site instructions through. We don’t receive estimates for these so the labour units and durations are unknown. If I was to use the same example:
Hours Earned (50% of works complete on 1000 hour estimate) = 500 hours
Hours Burned = Straight from clocking system = 600
This would produce the same productivity as above - 0.833...
BUT if we had completed 50% of a 1000 hour SI linked to the same job it should be as follows:
Hours earned = 500 hours from estimate (50% of 1000 hours) + 500 hours from SI (also 50% of 1000 hours)
This would then be 1000 hours over 600 hours which would show our productivity to be 1.66...
The problem lies in not knowing any information about our SI’s.
Any guidance would be greatly appreciated!
Kind Regards,
David Craig
Printer-friendly version
Send to friend
There are many different approaches to productivity measurement and their calculation and interpretation requires careful consideration.
From http://en.wikipedia.org/wiki/Productivity
Productivity is a measure of the efficiency of production. Productivity is a ratio of production output to what is required to produce it (inputs). The measure of productivity is defined as a total output per one unit of a total input. These definitions are short but too general and insufficient to make the phenomenon productivity understandable.
From http://www.investopedia.com/terms/p/production-rate.asp#axzz2219wSFAo
Definition of 'Production Rate' In manufacturing, the number of goods that can be produced during a given period of time. Alternatively, the amount of time it takes to produce one unit of a good.
Productivity and Production Rate are not the same and very frequently interchanged. Given the above definitions I am aware that for Spider Project productivity means Production Rate, it is an issue of software syntax you got to be aware.
In any case the units for productivity and production rates shall never be plain hours, the insistence of using plain hours as the units of productivity by some software is what I never got. On the other hand I have no problem adapting with the other definitions based on some volume of work.
My view is the burned hours burned from the clocking system is not a representation of productivity, which is a measure of volume of work over a dimension of time.
To the other issue of separate SIs hours against base hours, without knowing any information about the SIs is not possible.
The scope of SI must be known to separate it from the base.
To me Productivity without relating it to Volume of Work means nothing. It is a tendency followed by poor software developers I cannot understand, as if hours alone means productivity.
What can hours alone tell you about productivity?
1000 hours productivity I do not understand.
0.50 man-hours/sf of elevated slab forms is a measure of productivity I can understand, a measure of productivity you can report on a meaningful way for weekly productivity as well as for to-date. We report unit job costing as well as volume of work and total cost (weekly and to-date) but unit productivity trends is our key index.
When we compare actual productivity to a reference productivity we call it efficiency but never productivity. We use efficiency ratios to adjust productivity to special conditions.
Best regards,
Rafael
I think its just re-measurable. So we do the job, complete any SI's associated with it, then charge the client for what we installed. The price is rarely agreed before works are carried out. We are using a SOR so all this is easily done once the job is completed. I think option C is probably best suited for this as the SI's are much smaller than the main job 99% of the time. Thanks for the advice Gary!
Kind Regards,
David Craig
If you're currently at Option B, how do you get paid for the SIs? If you don't produce a budget before the works, and aren't tracking actual costs seperately for the SI...?
Are you just doing total hours burned across both orignal and SI minus original budget hours equals cost of SI? Or is there a schedule of rates?
If you can get to Option C, then you can at least track productivty of the budgeted work.
Depending on the ratio of SI work to budgeted, and assuming the nature of the work is similar, it could be reasonable to assume productivity of SIs would be equivalent to that of budgeted work.
Hi Gary,
Sorry I have not made myself too clear. It was quite difficult to get my head around first thing on a morning!
My current situation is the option B. We have no estimates for SI's and we arent currently breaking down burned hours into original scope and SI's.
I believe at a push I could manage to produce option C if I get supervision to distinguish original scope from SI work.
My main issue is that we dont have an estimate for SI works. This is really throwing me!
Kind Regards,
David Craig
Hi Mike,
Thanks for taking the time to read the post. Im pretty sure this is a common problem within the construction industry, however im not sure how I can overcome the issue. Do you have any suggestions I could have a think about? Im really stumped on this one. As always your help is really appreciated!
Kind Regards,
David Craig
David,
I'm getting confused here -The example you give doesn't seem to match with the explanation of your problem.
Do you:
a) have an estimate from which you can calculate hours earned for SIs, but don't record any hours burned for SIs (as in your example calculation for 1.66 productivity)
b) have no estimate from which to calculate hours earned for SIs, and are unable to seperate hours burned on the SI vs hours burned on the original budgeted work
c) have no estimate from which to calculate hours earned for SIs, but can seperate out hours burned on the SI vs hours burned on the original budgeted work.
Hi David
You will only get the true result on productivity when the task is 100% complete.
Currently you are comparing burnt hours with estimated hours without any input of how much of the physical task is complete at the 50% time stage.
Best regards
Mike Testro
Email: PPadmin@planningplanet.com
Replies