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.

 

[IRstuff]

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

TTFN

FAQ731-376

 

[gandersen]

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

 

[IRstuff]

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

 

[KENAT]

The first commandant for me would probably be:

KNOWEST THY REQUIREMENT.

Posting guidelines faq731-376

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

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

 

[gandersen]

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.

 

[KENAT]

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

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

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

 

[KENAT]

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

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

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

 

[IRstuff]

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

 

[jmcaero]

>>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

 

[gandersen]

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

 

[IRstuff]

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

 

[gandersen]

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

 

[IRstuff]

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

 

[gandersen]

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

 

[gandersen]

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

 

[IRstuff]

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

 

[KENAT]

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

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

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

 

[gandersen]

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

 

[KENAT]

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

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

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