Estimating effort hours...

[quizzical1]

Hi All,

We’ve been tasked with estimating the effort hours required to complete a task, test and project to help rate the effectiveness of the engineering team. Does anyone have any experience in this?
It seems hard to do accurately other than an initial SWAG since almost every activity we get is always different.

I remember auto mechanics had a book on how long it took to repair everything on the car to help estimate flat rate pay scale, is there anything like this for mechanical engineering?

Thanks in advance,

Q~

 

[D Scullion]

Is the sole purpose of this activity to rate the effectiveness of the engineering team? Or will these estimates be used for costing or quoting purposes?
If it is just to rate effectiveness then why use time as the metric? . . .bear with me, metrics to measure engineering performance are a minefield and one I have spent a fair bit of time trying to navigate. .

A company measures its success by how much money they make and there are three financial metrics that determine this: Profit; is that profit an adequate Return on Investment; and is money coming in as and when it's needed i.e. Cash Flow.
The effectiveness of an engineering team (or any team in the company for that matter) should therefore relate to their impact on those three metrics.

Profit relates to how much business you get and how much your customer values your product/service over and above your cost to deliver it. In terms of a metric for engineering, one could be how well is your engineering team meeting your customers demand. Do you work with a product design specification or project spec? - Does your engineering team deliver everything on those specs? can that be quantified or measured by something like an FMEA?

Return on investment - Clearer in a company that designs products that it then goes on to sell (rather than a contracted project business model) Part of the company's investment is in the engineers time to develop the product. As part of their market research, the company should have a reasonable estimate of their predicted annual sales volume and a idea of the period of time over which they want to recoup that investment. The cost of the engineering teams time (total project cost) relates to a percentage of the cost of every unit they expect to sell. That percentage is a measure of the engineers impact on return on investment.

Cash flow is fairly straight forward, is there a budget tied to deadlines and is the engineering team meeting those deadlines & therefore cost milestones?

I know that is probably not the answer you were looking for but perhaps there is something relevant there for you

Declan Scullion CEng

http://www.leandfm.com

 

[KoachCSR]

quizzical1,

I believe D Scullion has certainly provided some excellent information for you.

To directly answer your question based on my experience - there is no standard reference for engineering manhour estimates (as you state, each task or project will have its own nuances).

In order to estimate engineering effort, you must first start with the scope of the task. Once you have a firm and well defined scope, you can begin walking through the steps of the design process and gauging how much involvement from whom you'll need at each step. I caution that an attempt to generalize engineering tasks can be very misleading - for example, a pipe stress analysis may take 40 hours for one particular line given it's routing, while another pipe stress analysis for a line of similar size and length may take 80 or 100 hours due to some additional restrictions placed on it (such as nozzle loads allowables at a critical piece of equipment, or spacial constraints on the routing itself).

 

[GeoEnvGuy]

There are four ways to estimate effort.

Bottom up - identify all the tasks and estimate the hours for each task then sum the total
Top down - estimate the total fees and estimate the hours for each task to match the total
Lump sum - Routine assignments based on past performance, larger projects get inflated to capture risk costs
staff level estimating - larger projects determine the amount of staff required to complete the job on full time or half week effort

Reality in consulting is bottom up, then top down, then bottom up and top down until your happy with the proposal price.

Finally I get to reference that PM training I had to take to check a box.

 

[truckandbus]

this sometimes becomes a debate between how many hours will it take to do the work versus when will the work be done (costing versus scheduling).

An 8 hour task could be completed in a single day or it could be completed in 8 weeks if you can only work on it 1 hour a week.

When you do use estimates for scheduling purposes you then need to decide if you want to factor in downtime in the estimate itself or account for that downtime in the hours the engineer has available (i.e. a 30 hour task can be estimated at 40 hours because traditionally you know the engineer has 10 hours of coffee breaks, IT issues, interruptions from other engineers, etc. -or- you can say the engineer only has 30 hours available each week for project work since the other 10 hours is coffee breaks, IT issues...)

 

[quizzical1]

Excellent replies!!

The short answer is the owner is an “efficiency expert accountant” and is trying to rate the effectiveness of each member of the team and thinks assigning man hours to each task is the answer. That way the employee can be rated by their performance at review time (I.e. give raise, stay same or terminate).

Stage-gate project tracking was mentioned. Could this help?

 

[IRstuff]

Who gets to scope the hours; the person doing the work, or someone else? One path is liable to degenerate into padding, the other into mutual assured destruction, or padding, if everyone does the wink-wink.

You could look at historical data and determine scaling factors on scope, i.e., this task looked like that task, except that the complexity is 125%, etc.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[quizzical1]

LOL IR,

We just discussed that exact thing yesterday (padding) and all started laughing!

I like the historical data idea though and think that’s gonna be as good as it gets.

 

[D Scullion]

I have never seen estimating hours work out, either because of padding as mentioned or because the engineer becomes annoyed at the person doing the estimating's lack of understanding or lack of appreciation of the value of what they do. Imagine being given a dart, then being blindfolded, pointed in the general direction of the dart board and told that the reported success or failure of a team of workers rest on your ability to hit the bull's eye. Unless you can estimate very very accurately then it is just not fair on the team.

Also you mentioned the owner wants to rate the effectiveness of each member, not the team as a whole. That means any estimating needs to be so much more accurate. It also sounds like serious micro-management which is a whole other issue.

I'm not sure what the dynamic is between you and the owner but I would really be pushing back on a request like this. (maybe show them this thread!)

In my experience, the most successful engineering teams were given budgets and deadlines for projects, often very tight deadlines, and made to deliver on them. A project plan was reviewed with them on a regular basis and a team leader or manager worked with them and was able to report back who was carrying the projects and who was drift wood. The norm among engineers is to work hard and do a good job, respect that and keep things simple, drifters can't hide for long.

Declan Scullion CEng

http://www.leandfm.com

 

[KoachCSR]

I recall an interesting paper I stumbled upon several years ago which proposed a methodology for estimating engineering effort based on material quantities and labor hours for a project - likely more suited for an EPC type of project, but I believe it fits the discussion here.

Here is a Link to it. I have not tried this methodology yet for estimating purposes.

 

[quizzical1]

Thanks D and Koach,

I’ll check out the link much appreciate the help.
Micro-management is totally his thing. I believe he’s trying to find where the engineering team is “leaking oil” and weed out the “slackers”.

We’re getting a new Director of Engineering in a few weeks who’s big on stage-gate project management. Any chance that will help?

Q~

 

[GeoEnvGuy]

Stage gate pm systems are just a way to organize staff levels on multiple projects at varying levels or stages of development. It also allows for evaluating team member skills at particular tasks and stages. Assuming the team is made of licensed engineers or EIT's the team has smart people on it and the management focus should be on interpersonal skills and motivation.

An engineering department is leaking oil when you have engineers not provided a vision of the end goal (that always changes) or they lack senior guidance on technical requirements (because the team never did the task before). The slackers are the engineers that have trouble seeing the changing vision and spend a lot of time exploring the wrong paths. Other common issues for engineers is communicating with peers or supervisors to get guidance on how to do the job, common issues are pride,intimidated, or competition between staff.

 

[D Scullion]

Very good point GeoEnvGuy about providing a vision and senior guidance. Not to sound like a millennial hugger but professionals need more than 9 to 5 and a pay cheque, they need to see the bigger picture, believe they are really contributing to something and feel supported.

I'd say a new Engineering Director will be a big help regardless of their project management sway. They will become the middle man between the owner and the team and hopefully deflect a lot of micro-management. Also if they have got to Engineering Director level and have a preferred project management approach, then you can be fairly sure they know how to make that approach work.

Declan Scullion CEng

http://www.leandfm.com

 

[truckandbus]

my past companies have had more success in putting time estimates on to overall projects versus individual tasks. My current company does have an estimator though, based on historical data, for taking the number of new parts you think you will be designing and based on the type of part (bracket, harness, casting) will generate an time to design number

 

[quizzical1]

Thanks for all your input guys I really appreciate it!

Q~

 

[IRstuff]

A couple comments on granularity of estimates
> the finer the granularity, the harder it is to cut hours at the bottom-up process -- the idea is the while it's easy to imagine cutting 10% from a 40-hr task, it's much harder to cut 10% from 30 1-hr-ish odd chunks at add up to 40 hrs. This is great in cost-plus contract negotiations if you are the sub.
> all that is irrelevant when the boss says, "this is a must-win, so we need to cut 10% across the board." Naturally, over time, we learn to pad by 10%.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[CWB1]

Given the repetitive nature of ethical engineering, a decently experienced engineering manager should be able to SWAG an overall project timeline and cost accurately within ~10%, usually enough for initial customer contact and quoting purposes. To refine that further you need to have a project plan established by the working team and historical data for projects with similar tasks. If you've got those two datasets then the boss should easily be able to evaluate individual team members and hold their feet to the fire. The trick is having the systems and project management team working behind the scenes to mine the data. I've had employers with excellent and terrible project management depts. The former could very accurately, very efficiently plan 90% of a large project and keep engineers working at max efficiency without being stressed and working overtime. Consequently projects were usually on-time, on-budget, or very nearly so without having to pad the plan and budget, work anybody to death, or have a crap culture. The later would be challenged to report current status without talking to a dozen engineers first, projects were regularly late and/or overbudget despite generous padding, and the culture sucked.

 

[eshibi]

The usual way we do it is to derive an accurate list of engineering deliverable ( stress reports,P&IDs, data sheets, study reports...). This is fully correlated with the project scope ( no of equipment, plot size, area of building, etc) and can be quite accurate. Then, use man-hours per type of deliverable which are based on previous historical data. This way, the estimated man-hours can always be reviewed at each stage of the project and can adjusted as scope changes as well as used to monitor performance. Factors to account for level difficulty, or familiarity can be applied to further adjust each deliverable man-hours. Poor estimates can be traced to either the quantity of deliverables not being correct or the manhours per deliverable not being correct, which can be used as a feedback for future project estimates.

 

[maxhairloss]

In the business that I work in, this results in what is called a Basis of Estimate or BOE for short. When bidding on a government contract, the proposed vendor has to be able to show how they arrived at the cost figure that they'e proposed. I've done these in private industry and evaluated them in government as a Program Manager. And yes, it's laughable when associated with government work since they never seem to come in on budget...

What I would recommend is to assemble a team of people who are experienced in the particular fields that you want to estimate. Work with them to define the tasks to sufficient detail to get the job done, and then ask how many man-hours it takes to do the work and at what level of expertise. The level of expertise drives the labor rate. For long-term efforts, the risk of loss of key personnel needs to be factored in to the estimate for the project, not only in terms of cost to find someone else, but the time it's going to take to get them in the door and up to speed on the job. Add any other plant and equipment costs required.

As a suggestion, I would look at what's called "Earned Value Management System" (EVMS) to give you some ideas on how to go about framing the work, costing the effort and managing to project. It's not 100% applicable, but as a general model it's pretty good.