×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Best Practices for Technical Work Assignments
2

Best Practices for Technical Work Assignments

Best Practices for Technical Work Assignments

(OP)
Hello All:

If you had to make a quick list of best practices for managing Technical Work Assignments, what would be included on such a list?

By technical work assignments, I am referring to the process by which a technical manager scopes out an assignment, delivers it to staff and then reviews and accepts it.

Thanks in advance for your time and thoughts.

RE: Best Practices for Technical Work Assignments

2
One would think that "best" practice would involve a "bottom-up" scope and estimate, before, the work is assigned.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
Thanks IRstuff:

Good point.  Could you give a little more detail on "bottom-up"?

What about the mechanics of assigning technical work?  Could you list some best practices here?

Thanks in advance,

OREx

RE: Best Practices for Technical Work Assignments

Unfortunately, most (possibly all) of us are sinners in that regard, we know what is the "correct" way to do things, but don't do it that way.

In the ideal world, when you are given an assignment, you should have complete "buy-in" on the schedule and scope, i.e., you agree that statement of work is consistent with the assigned job and that it will require the hours given.  And while some managers could ostensibly proxy for the assignees, i.e., they do the scoping and simply hand out the work packages, not all managers are equally good at that, nor are the employees, necessarily.  Additionally, having only one manager do the scoping leads to potential "I forgots" that could seriously affect the adequacy of the hours, so additional eyes on the problem is generally a good idea.

As a side note, in the ideal organization, there should be a database of previously executed jobs, and the hours they took, and the problems they encountered.  An ideal organization would then only be interested in the accuracy of scaling the scope of the new tasks relative to a previous task, and glean all the lessons learned from the previous effort.

The work should be partitioned into quantifiable, and small, packages, that can be monitored for progress, and that can be assessed with short latencies to identify potential problem areas.  You do not want to assign someone a 6 month task with no interim milestones and be surprised at month 5, day 15 that he's 4 months behind schedule and overrun 150% of the budget.  The general rule is that 2-week chunks of scope should be doled out and monitored, and would allow you to know with 1 week if you are behind or in trouble.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
Hi KENAT:

Good point.  Could you elaborate a little on how you would go about scoping?  I would like to try to put together a document is built from this thread if we can flesh out enough detail.

Perhaps we could start a GoogleDoc that would reflect the Best Practices.  Thoughts??

I have not been able to find an elaborated list with details in the literature.

RE: Best Practices for Technical Work Assignments

While there is the occasional exception (for blue skies type stuff), generally knowing what you want/need to achieve (and when) is essential.

This is not just the technical performance requirements but also what steps need to be taken along the way.

This is where the Statement of Work (SOW) that IRstuff mentions comes in.  (Called different things different places)

It's a document that states the work that needs to be done and lists the deliverables and usually some kind of time line.

Sometimes the person asking for the work gives you the SOW, sometimes you have to generate it.

It doesn't always need to be a big 100+ page document - for simple tasks it might just be an email.

It is not a detailed project plan.

So to generate a SOW you might start with the technical requirements, you then make a list of what steps need to be taken to get an end product that meets them (conceptual design, detail design, analysis, testing...) & what deliverables (such as drawing packs, technical reports, proof of concept/prototypes...) are required.

How much of this relates directly to your field I'm not sure but the principles should be pretty sound.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

At a previous employer we generally prepared timings based on the 'slowest worker' for any specific task.  If this started to make the number of hours, & hence cost, get too high we'd look at putting other faster staff on it or similar.  This was manageable for a small company like us.

However, for a large company this probably wouldn't work.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

A good example of an ideal scenario would be the Dodge Book for construction cost estimation.  Any possible job related to constructing a building in the book, with hours and materials, with variations for high-end and low-end design and materials.  From there, you can scale your effort accordingly, i.e., if you build a shower stall that's 1.6 times the typical, you can scale the effort for the new job.  So if you know that a defined DSP-based circuit board cost 600 hours to design and lay out, a board with 50% more complexity will cost correspondingly more.  One beauty of this is that the customer cannot attack your cost basis, they can only downscope.  Sadly, my previous company seemed to be institutionally incapable of estimating that way, and the customer's buyers would attack our cost estimates and we'd wind up knuckling under.

Somewhere else, there was mention of lump work packages.  That's OK, but bear in mind that costs change, sometimes abruptly, so even though the package is disassociated from the hours, ultimately, you're still accountable for lump_sum/hourly_cost.  We've often been caught flatfooted when "someone" determines that the wrap rate is 20% higher, so you suddenly lose 20% of your budgeted hours, or dollars, machts nichts.  It's particularly bad if it's retroactive and you've already spent a big chunk of your budget and carefully managed the cost to the original estimates.  Suddenly, you've gotten 20% taken off the top, but it's more like 40% cut of your remaining budget, since you've already spent 50%.

Obviously, the ideal approach is to have a management reserve, but in a tall contract structure, i.e., one where Boeing subs to Raytheon who subs to someone else, everyone along the chain is holding a reserve, except the guy on the bottom, who started out slim, and is working to an even slimmer budget, because everyone above him has taken a reserve cut.

Even so, given a lump amount, you still want to be managing and statusing to smaller work packages and assignments, to ensure that ME Joe didn't wind up frittering away 500 hours on an FEA that wasn't even that critical, and should have only spent 80 hrs.

The biggest impediment to best practice is simply the common practice of underbidding.  What I've observed, over the years, is that the initial bottoms-up bid, fromt the actual executors of the work is often correct from the get-go, and the management "challenges" and "trims" simply put you deeper in the hole each time they thumb the cost volume and decide it's still not a winning price.

Unfortunately, it's so institutionalized that most experienced customers build the underbidding into their own cost estimates; only inexperienced customers who buy into our rosy predictions of cost get screwed, and fired off their own programs when we overrun.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments


>>is that the initial bottoms-up bid, from the actual executors of the work is often correct from the get-go, and the management "challenges" and "trims" <<

Ha!  IRstuff has been around the block a few times smile   

RE: Best Practices for Technical Work Assignments

(OP)
Great Points!!

Perhaps we can talk a little more about the "lump sum" issue for managing tasks.  In going through the literature on project management, all approaches boil down to managing hours.  As Kenat points out, the definition of an hour is ambiguous.  It can vary between individuals, groups, companies and it can also vary for a given individual if he/she is being managed according to a target utilization rate.  Some weeks they may have an overabundance of work and be very efficient.  Other weeks they may not have enough work and still need to meet a utilization goal so the hours become less productive, i.e., the amount of time necessary to complete a task grows to the size of the hours allocated.

When we manage personnel by hours, we accept more responsibility for their performance and they accept less.  Managers have to deal with issues such as efficiency, motivation, productivity, etc. and have to implement expensive training and motivational programs to improve profitability.

Why not manage by task?  We can set a base salarly level for staff that would be guaranteed, but we can make the work assignments lump sum and tell the staff that they will be paid above their base salary level dollar for dollar as they complete tasks correctly.  The key here is to accept the work when it is done correctly.  The focus of management then becomes one of technical management and not personnel management.

Over the last several years I have been using a tasks-based management approach in my own business and have spent all of my management efforts on two areas: 1) technical training; and 2) making sure that the technical side of projects is performed correctly.

Managing by task would permit the simplification of performance reviews by looking at the base salary levels compared to number of tasks completed correctly.  If compensation is tied to tasks completed, staff would essentially be able to determine their own salary.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

I'm not sure I agree with that, given that your dollar loading for any given contract is based on the initial basis of estimate for the proposal, which assumed a certain skill mix and a certain hourly rate for the effort.  If this was not done, then you have serious problem, anyway.  

One tactic often used is precisely to bid as if all the work is to be done by junior engineers, but when work commences, you wind up needing senior engineers to do the work.  And while you might be tracked in hours in one forum, the cost accounting is always done in dollars, since that's what's ultimately billable.

As a manager, you have to manage both, as you are often graded on both hours expended as well as the budget consumed.  

I'm unclear how the "task-based" effort is accomplished in a general scenario, since most companies hire engineers at a set salary, so task completion under cost usually reaps few benefits to the workers.  Only in a profit-sharing scenario would that make sense, and only if the contract is fixed-price.  Many aerospace contracts are cost plus, and there is no advantage, other than being a good trooper, to come in under budget, since that just leaves money on the table.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
IRstuff:

Agreed.  The point that I am trying to make is that when we guarantee a base salary level, tie task production to dollars worked against the base salary and pay dollar for dollar above the base, an immediate bonus comes with each paycheck where the staff has exceeded the target.

I am also suggesting that we sell tasks and not hours to the client.  We would provide a clearly defined set of tasks for lump sum amounts (much like a menu).  The only question the client has to answer is how many of these do you want us to accomplish.

Using "squishy" hours as a basis for cost estimating causes bad management decisions.  One error that I have seen repeated over and over is that "We were generous on the number of hours in the estimate so we have some leeway to handle changes in scope or inefficiencies in staff performance".  This approach leads to loss of control on budget and hence profit.

I am suggesting that we make cost estimating more reliable by tying down some of our variable costs (such as labor).  If we don't have labor as a variable, we can price more confidently.

If we are selling tasks, then the client will know what it will cost for a change (adding more tasks).  As I mentioned earlier, it would be like handing the client a menu and asking them to select what they want to eat.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

I know for sure that proposal wouldn't fly in the aerospace/defense industries.  Our bidding often requires basis of estimates down to level 3 or 4 on a WBS.  From a customer perspective, that's the only way to determine what each bidder is offering.  If you got bids from two contractors for Task A that differed by 50%, how would you determine why there is a variance without getting insight into the bid details?  The only way you could, would be if the hours for subtasks are known, and you can see whether contractor1 simply forgot to include critical tasks, or whether contractor2 simply skinnied their bid.

The US military, on really big programs, does its own cost reality, and will often "adjust" the "true" cost of a bidder's proposal up or down to level the WBS structure and effort.

Also, from a custormer's perspective, I'd be wary of big "lumps" in the bid, since I would have no insight into any future cost deltas, i.e., if TaskA is modified, and the contractor comes back with a delta bid that's 95% of the original TaskA, is that a reasonable bid or not?  If, on the other hand, I had the details on the subtasks of TaskA, and the delta bid came in with the same level of detail, I could assess whether the cost is reasonable, based on the descriptions in the basis of estimate, and I could do a better job of managing the contractor.

Now, perhaps your contractual relationships are not that adversarial, but I doubt that a customer will be willing to sign off on task-oriented bids without any insight into the effort proposed, i.e., am I getting a good deal, or am I getting taken to the cleaners.

In general, A&D bid hours are never "squishy," they are almost always less than what's actually and normally required.  Any changes are often relegated to a "time&materials" bid, so as to not affect the bottom lime bid.  It's then up to the customer to have the experience to know that he needs to have a 50% reserve above the contracted price to cover the cost overruns that are almost inevitable.

But, I would not disagree with the notion that A&D contracting is seriously disfunctional in that regard.  It's a form of liar's poker, for the most part.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
I am going through this thread now to try and start summarizing and I need to ask:

What is a wrap rate?

Also, I used the term "Squishy" to describe that an engineering hour is generally not a fixed amount.  There are efficiency, method of measuring, method of reporting, and perhaps other issues that that make the definition nonprecise and nonstandarized (at least in my discipline).

In proposing to manage tasks by lump sum, perhaps I should provide a little more detail.  I would propose to use a Work Breakdown Structure (WBS) that goes all the way down to the individual technical work assignments (TWA's) and to build the lump sum cost estimate from the individual lump sums of the TWA's.  In geotechnical engineering, for the types of projects that I have been dealing with, my TWA's generally occur on levels 5 - 7 depending upon complexity.

Perhaps here we struggling a little with semantics because of being in various technical disciplines.  By technical work assignment, I am referring to a small, quantifiable, work package of short duration that is performed by one person.  IRstuff refers to these as 2 week efforts, I have found that 1 to 3 days is a good duration for the work I have been managing.

Nevertheless, if budget reporting is down to the lowest level on a WBS, I would think that it would be easy for a client to see enough detail to tell if something had been missed.  If the individual tasks are broken down in this manner and pricing is associated with it, then clients who need to trim prices would have to look at the individual TWA's and decide what is not necessary from the definition and/or decrease the number of TWA's.

In my experience, if the TWA's are well-scoped and the pricing is rational, the bidder is in a much stronger position during negotiation.

Also, if the TWA's are developed at the most fundamental level of a project, then modifications would be in terms of the number of TWA's of a particular type.  At that point, everyone knows the pricing, the bidders costs have been fixed (if labor can be fixed as previously suggested) and decreasing the number of TWA's will not have any effect on profit margins (ideally).

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

(OP)
Hello All:

I have started a Google Doc that I am using to summarize this thread.  I will add to it as more people bring ideas and there appears to be a consensus building.  There are three sections: 1) those best practices about which there appears to be consensus; 2) those best practices that are suggested but for which there is not consensus; and 3) a copy of the thread for reference.

The link is:

http://docs.google.com/Doc?docid=0AT6GaEkkR9PUZGRwNHRrN2RfMGc2enRmOGhy&hl=en

I would invite all who are interested to review and modify the document.  In the end, we will post this in eng-tips.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

The wrap rate is the multiplier against your basic hourly rate that accounts for G&A, overhead, etc.  At previous companies, the wrap rate was about 3, and so someone making $60/hr would be charged against a contract at 3*$60 = $180/hr.

I don't have any issue with your TWAs and durations, now that you've explained them more.  The durations have to be tailored to the total duration of the project.  The last project I worked on, it was about 2.5 yrs to the Critical Design Review, so smaller work packages would have been too unwieldy, whereas in a project that might be completed in a few months, just about every day would be a critical chunk of time.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

gandersen - to go back a couple of posts.  You're proposing to pay employees some kind of basic lets call it 'minimum wage' and then get paid per task on top of that based on task definition rather than time to complete it?

Kind of a variation of job & finish?  Except rather than leaving early once done, you get paid more for 'doing more'.

It has attractions but as IRstuff points it, it has its downfalls too.

At the last place I worked on many jobs the customer did buy 'tasks' but was usually given a summary of the hours required to do them.  

This meant we essentially bid 'moderately high' to make sure we were covered if a task took slightly longer than anticipated.  If it was a non competitive bid the customer usually had already approved our hourly rate and so was given a fairly detailed breakdown of hours per task to justify the total cost.  If we managed to complete the task in less hours good for us, if it took more then generally tough luck, we had to eat it.

On more competitive bids where there were other bidders we'd bid tighter, but be stricter on defining tasks, listing exclusions etc.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

(OP)
Hi Kenat:

No, I am not proposing a minimum wage.  I am suggesting that for the management of technical work assignments, another best practice could be to change the motivation of staff away from hours and utilization targets to tasks completed correctly.  In other words, I am suggesting that we focus on the task and define achievement as completing it correctly.

Also, I am suggesting that the guaranteed salary be the present salary and that we build an equation between technical work assignments and salary so that each person knows what each assignment is worth and how many they have to do in order to "justify" their salary.  We would determine value based on estimated hours worked by an average employee and then let each individual loose to perform as many technical work assignments correctly as they possibly can.

Those who work well and are motivated, would earn above their present salary.  Those who are not motivated or not efficient will not cover their present salary (even though they would be paid because it represents a base), will know that they cannot continue to underperform.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

Why can't they continue to under perform?  Even without this kind of structure it's often possible to know who isn't pulling their weight, and in many cases one suspects they have some realization of this, doesn't stop them though.

Plus what about the occasional 'dog' task that everything goes wrong on no matter what you do?   

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

(OP)
Interesting perspective!!  I would assume that with the economics pointing south (i.e., the person is not carrying their own weight and not justifying their own salary), there would be a business decision to cut them loose at some point.

The advantage of managing by task is that the result of underperformance is obvious and impersonal, especially if there are others around that are taking on similar tasks and excelling.  Hence, the decision of letting someone go is directly related to economics.  In my opinion, this is the best position for management to be in.

With respect to "dog" tasks, could you be more specific?  I think that if the technical work assignments are subdivided and given out only when all of the necessary input is available, then the performance of the task is entirely under the control of the staff.  If, on the other hand, a task is given where there is the need to wait for the input of others, then a "dog" could develop.

If it is necessary to work ahead on something and make assumptions that will later be verified by others, then perhaps the best approach is to treat the "Work Ahead with Assumptions" as a separate task from the "Verify Once All Input Data Has Been Delivered".

Could you provide a little more detail on "dog" tasks from your perspective?

Thanks.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

I think that this approach cannot be adequately institutionalized:

>  It's naive to think that underperforming players automatically get booted.  Underperformance does not always imply stupidity or incompetence; it could also be smart&lazy.  Some women are very adept at playing the discrimination card.

>  There are those that are happy with the norm and see no need to excel, as that usually forces the baseline up, so why guarantee a higher work load in the future for no added benefit?

>  Such a system is relatively easy to game, particularly in a development environment; you simply estimate a higher hour load to ensure that you come in under budget.

>  Companies go out of their way to hide salaries and to minimize overt competition in the workplace.  Such as system would make it obvious who the higher paid employees are.  

>  Most people do not want to be operating to a quota system, and this is a form of a quota system.  

>  Not everything is about money, so just because you can get more money, doesn't mean that you would.  Why break your back for a small increment on your salary while everyone else is taking easy by comparison?

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
I think that these are very good points and that they should be discussed in more detail as they are very real barriers to profitability in technology-based companies.  Sorry for the length here.  If necessary, we can split this into smaller pieces in the future.

1) (IRstuff) It's naive to think that underperforming players automatically get booted.  Underperformance does not always imply stupidity or incompetence; it could also be smart&lazy.  Some women are very adept at playing the discrimination card.

If the Technical Work Assignments (TWA's) are performance-based, the only measures that matter are:
a) whether or not they are done correctly; and
b) whether or not they are completed on time.

If staff are measured against productivity on TWA's, and I am the manager, it doesn't matter to me how "lazy" or "smart" they are, only whether or not the TWA was done correctly and within the allocated time.  A staff can try to game the system, but in the end it boils down to correctness and timeliness and there is no substitute for either.

Layoffs depend on a lot of factors.  The underperformers don't always get the pink slip, but the if the company is managed by TWA's on lump sums counted against salary, the cost of keeping an individual will be clear and the management can make a more informed decision.

2) (IRstuff) There are those that are happy with the norm and see no need to excel, as that usually forces the baseline up, so why guarantee a higher work load in the future for no added benefit?

I am not sure how the proposed approach would guarantee a higher work load with no added benefit.  The benefit would be a direct increase (dollar for dollar) on compensation in each paycheck.  As the capacity of an individual increases in performing the same tasks, they will be able to do more and receive higher compensation.

In any organization there will be all sorts of personalities.  There will also be those who would be happy at a particular level of compensation.  It would be the role of the management to set levels of compensation related to technical work assignments so that such individuals could work at their particular level and on average meet their required level of productivity.

If someone works hard and significantly increases their compensation (base salary plus bonus in each paycheck) then they would be in line for an increased base salary and for taking on more difficult TWA's that would have higher lump sums.  These would again incentivize them to work harder.  I am not sure that I see this as a limitation to the proposed best practice.


3) (IRstuff) Such a system is relatively easy to game, particularly in a development environment; you simply estimate a higher hour load to ensure that you come in under budget.

Estimates of level of effort would need to be developed and/or approved by the technical manager with buy-in from the staff.  I agree with the comment in regards to a "Development" environment.  Kenat's point about a "dog" work assignment is very relevant here.  Perhaps we need to qualify the list of best practices for "application" environments where the tools and techniques are well established.

In a "Development" environment where the scope is open-ended, we will probably need to be more explicit about the technical approach that will be taken and amount of effort on each of the steps and we will need to define achievement accordingly.

4) (IRstuff) Companies go out of their way to hide salaries and to minimize overt competition in the workplace.  Such as system would make it obvious who the higher paid employees are.

I am not sure how the suggested best practice would reveal the salaries or make higher paid employees more visible, except to the technical manager who can see who is taking on the most assignments.  The salary equation is for the staff member and management alone.  No one else knows.

Outside of the company, the only thing visible would be the lump sum cost for a particular TWA.

5) (IRstuff) Most people do not want to be operating to a quota system, and this is a form of a quota system.

This is a good point.  I am not sure that there is an answer to this.  Could you give more detail about what you mean by quotas?  Every staff has performance targets.  In most businesses, one of these is related to number of billable hours.  All the proposed best practice does is to change a utilization target into a work assignments completed target.

6) (IRstuff)  Not everything is about money, so just because you can get more money, doesn't mean that you would.  Why break your back for a small increment on your salary while everyone else is taking easy by comparison?

The point here is that the employee can make the decision about how much they want to earn.  This will vary between employees and can vary for a given employee depending upon changes in their personal circumstances.  The point here is that the employee has more direct control and can throttle up and down as necessary.

Also, the amount of increase in compensation is not a small increment.  If, average an employee decides to increase their productivity by 10% above average, they would increase their compensation by 10%.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

I'm not sure the idea could work with some employment laws in some places either.  Don't get me wrong, in principle I'm all for performance related pay, but I'm also for not being screwed by unscrupulous, or just plain incompetent, management.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

Many of my bullets are essentially variants of the same basic issue, which is that you're proposing a competitive situation to people who didn't sign up for a competition, and the rules of the competition must change over time to ensure profitability of the company.  To wit, if we decided today that 100 hrs is required to do Task A, and everyone beats the metric by 20 hrs, we're going to, in the long run, decrease the metric to maybe 85 hours, to minimize our profit sharing outlay and to ensure that the company gets something out of it as well, i.e., we have to pick a metric that forces certain people to fail to meet the metric.  

Only then could we even contemplate the notion that there are "deadwood" employees.  The employees are not stupid, so they will realize relatively quickly that beating the metric by a large margin serves them poorly financially in the long run.  Moreover, the 100 hrs is the quota, and they will see than excelling will simply mean that they have to do the same amount of work in fewer hours with no long-term reward.  In the end, only those that are truly suicidal would attempt to beat the metric by anything but a tiny margin.

And of course, this would never pay off in aerospace, since underbidding is almost de rigueur, and an aerospace company is not about to "blow" what little profit it might get, since that's essentially the only management reserve there is.

I can tell you that a manager at one of my previous companies attempted something similar, but in a more global sense.  He attempted to do a "rack&stack" for performance reviews, rewarding lower-paid employees proportionally more than higher-paid employees, on the basis that the higher pay was already rewarded for past performance, and so someone in that pay grade would have to do substantially more to get even a minor pay raise.  Suffice to say that productivity among the higher paid employees cliffed altogether.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
IRstuff:

The workplace is competitive.  People understand that they are being measured against others.  The proposed best practice (BP) merely places the competition on an even playing field with a focus on work product.

With respect to profitability of the company, if the labor costs are fixed for each TWA, the profits are also fixed (meaning that there is no uncertainty in how much they will be able to make).  By increasing productivity, the company gets more work done in less time (higher profits with fixed labor costs) and employees get more salary.  It is a win-win situation.

If the company were to then change the metric to attempt to get more production for even less labor cost, they would be cutting their own throats by deincentivizing the more productive employees as you point out.  This is the same thing that happens when governments increase taxes and deincentivize success.

It may be a hard sell initially in some quarters, but if enough companies do it, they will become more competitive than those that do not and the tide will eventually change.

It may seem a little counterintuitive that you have to give up something to get more, but increased productivity and fixed labor costs mean higher profits.  Giving more to more productive employees is rational.

Essentially, the idea is to make the employee more responsible for accomplishing the work and to take more of the management burden off of the managers.

Following this BP, managers could focus on more productive uses of their time such as performing more billable work, conducting technical training, and marketing for new projects (if appropriate); all of which would further increase profitability.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

"take more of the management burden off of the managers."

So presumably then the managers base salary would be cut accordingly.

Not much of an incentive then for the managers to do it.

With this concept you are essentially transferring a bunch of the 'risk' from the employer to the employee.  The same way as some larger companies now outsource much of their work to other companies.

Maybe it's different in your field but from my experience the 'Technical Work Assignments' are often not well enough understood/defined up front to allow this to work.  It might be OK in situations where the process is more 'cookie cutter' but where there is more significant invention/innovation/development and the associated risk, I'm not sure it's a realistic solution.  

Too much chance of folks being disadvantaged by getting 'dog' projects.  Any project that smells like a dog, or even has a moderately high level of risk will be avoided by those that can.  So you could end up that your most skilled workers actively avoid the difficult jobs.  You are disincentivising innovation/risk/stretching yourself etc.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

(OP)
KENAT:

Under this BP, the focus of the managers would be more on technical issues and less on personnel issues.  With senior people spending more time on the technical side of the business, there is less technical risk.  The result would be higher profits and happier customers.

When a technical manager is more billable, the profitability of the company increases.  I don't see why this would lead to lower salaries for managers.

With risk comes responsibility and rewards.  This BP is intended to help employees "own" their behavior and be rewarded accordingly.

This BP needs to be implemented with the other BP's that you and others have spoken about.  One of the most critical is definition of scope and buy-in from both the manager and employee.  Also, there needs to be a clear definition of acheivement (how success will be measured).  Also, there needs to be only one manager.  Others can provide input and define scope, but the scope needs to be finite and unchanging before the TWA starts.  If the scope changes during the execution, then the definition of achievement has to change along with cost and schedule.  All of this has to be documented so that there is no ambiguity.

Where innovation/invention/development are involved, the measure of success needs to be modified to define what someone will be attempting to do and not guarantee an outcome.  Again, proper scope and success definition are critical and if properly focused will not stifle innovation.

As far as difficult jobs, these should cost more for the client and should have more potential reward for the company and employee.

I am summarizing all of these points and will post a BP list shortly.

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

My point was that in most organizations managers get paid a premium for 'managing'.  If they are no longer managing but doing technical work then I'd assume the premium for 'management' would be reduced accordingly.

Posting guidelines FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm? (probably not aimed specifically at you)
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?

RE: Best Practices for Technical Work Assignments

This can only work when there is a well-defined and established benchmark to be measured against, i.e., a Dodge book for engineering.  That, as far as I know, does not exist.  Currently, estimation is still pretty much a crap shoot for any developmental work.  Most of our projects contain a large amount of "I forgots" and unk-unks, and the ability to accurately predict the number of hours required for a specific task is pretty low, and the estimate variability, particularly for short duration tasks might barely be 25%.  Even in the best conditions, we estimate and bin the people into "senior" and "junior" engineer classes, yet the variation between people is much larger than can be readily confined into two pay grades.

At the point, there is no way to prove that the system is fair, particularly since not everyone even has the exact same set of equipment and software, or manager requirements, etc.  Someone equipped with a nailgun can work at about triple the rate of a someone with a hammer.  That's a pretty massive data collection to undetake to try and find where the level playing field might be.

And how do you judge the capabilities of the individual worker?  Or do you?  Someone with 5 yrs of experience vs. 1 yr of experience?

At some level, any "pay for play" system will have the appearance of unfairness.  And those that are talented are going to be overly rewarded, while those that are less talented will become unmotivated over time.

In the end, when you try to slice and dice this way, you will wind up losing overall profitability, since you give money away to the high performers, but you still have to pay the lower performers.  Right now, the system basically averages out between the two classes, and you take profit off the top, but in the proposed way, if you still want the same profit, you have to bid a higher amount to over the performance bonuses.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Best Practices for Technical Work Assignments

(OP)
I have done my best to incorporate the above discussion into a list and have taken the liberty to add my own opinions about what would constitute best practices for Engineering Related Work Assignments.  I am placing it below and would appreciate any and all comments.

Best Practices for Engineering-Related Work Assignments

For the purposes of this discussion, an Engineering-Related Work Assignment (ERWA) is a work package delivered by a technical project manager to staff in an organization that performs engineering tasks.  ERWA's are at the heart of engineering projects and their success or failure has significant implications to the overall success of the projects.  Organizations performing engineering include: engineering or architectural design firms; natural resource companies; manufacturers of technology-based products; governmental organizations; and, other types of applied science companies.  The types of employees that would perform ERWA's are engineers, architects, applied scientists, laboratory or field technicians, drafters, and related support staff.

Best practices for the management of ERWA's include best practices for other types of work assignments but with some unique differences due to the complex nature of engineering projects and the fact that small mistakes can cause failures with catastrophic consequences.  Engineering is the application of scientific and mathematical theories to the design of structures, machines, devices, systems or processes to address the needs of humanity.  Mistakes occur in engineering projects.  It is the goal of any successful engineering organization to put in place a sufficient number of processes to catch these mistakes and correct them before they become critical to the success of their projects.

Best practices for ERWA's can form the basis for a well-designed engineering mistake capture process and can significantly increase productivity and profitability.  These best practices be classified in terms of: 1) Scope Delivery; 2) Defining Success; 3) Controlling Schedule; 4) Controlling Cost; and 5) Archiving Results.

Scope Delivery

The scope of ERWA's should:

1)    be well-defined, self-contained and close-ended with buy-in from both the manager and staff;

2)    be built utilizing a work breakdown structure (WBS) technique beginning with project requirements and logically breaking it down until arriving at specific ERWA's;

3)    be limited to one technical manager and one staff;

4)    be documented for easy reference;

5)    use familiar technologies and techniques; and,

6)    be small and of short duration.

Defining Success

ERWA's should:

1)    clearly define success (i.e., how achievement will be measured) so that the staff know when they are complete; and,

2)    where applicable, provide a fully worked-out example of a similar ERWA that was successfully completed.

Controlling Schedule

ERWA's should:

1)    clearly identify due dates and provide slack time (float time) in the schedule for takeover by the technical manager if necessary;

2)    verify that all input data necessary to work it is available and has been transmitted to the staff;

3)    be provided with easily accessible training/review materials so that the staff can review the approach and process to be used when desired;

4)    be given by technical managers that are capable of performing the task themselves;

5)    include buy-in on the due dates by both the technical manager and staff; and,

6)    include penalties to the staff for missing due dates.

Controlling Cost

ERWA's should:

1)    be paid on a fixed price (lump sum) basis being completed correctly (same price regardless of time expended or person performing the work);

2)    include buy-in on cost by both the manager and staff; and,

3)    be given to staff whose motivation is focused on completing the task efficiently and correctly and away from working a certain number of billable hours.

Archiving Results

EWRA results should be archived for easy referral by quality control personnel and for future similar projects.  This archive should include:

1)    A complete description of the ERWA scope;

2)     All input provided;

3)    All output generated by the staff; and,

4)    References to all associated training/review materials used.
 

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

RE: Best Practices for Technical Work Assignments

(OP)
Thanks IRstuff:

Good video.  Perhaps I can summarize.

In order to properly motivate staff, the following should be in place:

1) Money - While money is not a good motivator for work that requires cognitive skills, it must be enough (in the eyes of the staff) or it will unmotivate.

2) Autonomous Environment - Staff would like to be self-directed, set their own priorities and have more responsibility for the outcome of the work.

3) Mastery - Staff are motivated by the challenge of being able to master difficult things.

4) Transcendent Purpose - Staff are motivated by having a purpose that transcends the actual work being done.

In terms of the list of "Best Practices" given above, the money motivation is not included except as a potential avenue if the organization wants to tie salaries to the lump sums determined for each task.

The autonomous working environment can be promoted by moving management away from policing hours and teaching people efficiency, to making the staff responsible for efficiency and work intensity.

Mastery of professional capabilities can be accelerated by providing specific and targeted training with each work assignment.

Fortunately, in the field of engineering our work transcends the actual products that we produce and many engineers already work for that higher purpose.
 

Glen R. Andersen, Sc.D., P.E.
Optimum Resource Engineering
San Antonio, Texas

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members! Already a Member? Login



News


Close Box

Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close