Best Practices for Technical Work Assignments 2

[gandersen]

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.

 

[gandersen]

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

 

[KENAT]

Sure, they are typically tasks with either poorly defined and/or unrealistic requirements, or lots of people that have a say in them, or somehow pushing the edges of familiar technology/techniques...

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[IRstuff]

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

 

[gandersen]

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

 

[KENAT]

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

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[IRstuff]

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

 

[gandersen]

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

 

[KENAT]

"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

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[gandersen]

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

 

[KENAT]

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

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[IRstuff]

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

 

[gandersen]

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

 

[IRstuff]

This is pretty interesting, both on the subject of motivations, and what makes people more productive:

http://www.youtube.com/watch?v=u6XAPnuFjJc

TTFN

FAQ731-376

 

[gandersen]

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