CAD Dept. Management Challenge!! (Productivity)

[ckidd]

I don't know how much I can add to the discussion, as the above responses have been very well thought, but here's my $.02:

The entire goal for the OP is accountability. With a metric of productivity, he will be able to prove who has and who has not been working the way they should.

Here's what I don't understand:

But the situation is that we have a poor performing engineering drafting team, we know it! They talk to each other and they even plan to delay the work so then they get paid extra when we are running out of time to meet the schedule.

How do you know the team members are talking to each other and making plans to delay work? If you can prove this, why not address the sloth that is already plaguing the company?
If you have proved the internal conspiracy to pilfer extra money from the company and risk missing deadlines for the customers, and that hasn't gone anywhere, then why would tracking drafting hours offer any more accountability among the team?

An entire department colluding to sabotage projects with unnecessary delays is a problem that should be dealt with first, IMO.

[jaberwok]

... Most organizations ... relying on the oldest guy in the design department to remember what was done for who back when...

This is so often true.

... I find that engineers often just want something drawn first, and only when something has been drafted up will they spend any level of effort determining what a usable design could be.

I have long taught that the drafter's first job is to be "wrong"; you draw what is asked for and thereby demonstrate that what was asked for is NOT what was wanted.
This does nothing to help the poor estimator.

[Brian Myers]

OK, we'll keep this a metrics discussion.

A project in an ideal environment will total "X" number of man hours.

A project in the current environment takes "Z" number of man hours.

Man hours = The amount of time to model, dimension & note the drawings, including the entire revision process and the communication of those changes to the individual drawing it.

To create a standard we will need to know the time it takes to draw each type of condition. From there we will need to total each revision that will be made (quantity). For each of these revisions an amount of time will need to be quantified and added to the estimated length of the project. For example: Bolt "A" goes in holes A & B. If the size of the bolt changes then we need to quantify the length of time it would normally take to change the size of this bolt. Next we'll need to quantify the amount of time it will take to change the size of the two holes the bolt is inserted into plus the time (if modeled) required to adjust any interior threads. This may require a design decision if the diameter of the hole "B" comes too close to the edge of one of these objects and compromises the structural integrity of the object being bolted. Thus we need to estimate more time for hole "B" as the design solution is considered. To solve perhaps we figure in a standard deviation that gets applied and if the process takes longer than the deviation then we investigate that step and adjust accordingly.

In the end we'll have created a standard metric to determine the approximate time it will take to complete a project based on the total time of drawing vs complexities and total of changes being requested.

Actually, I would advocate instead the Toyota process of Lean production where deadlines and project goals are put in place and achieved. It's less about "punching a time clock" and more about efficiency, mentoring and meeting schedules. The Toyota Product Development System is a classic and proven method.

http://www.appliancemagazine.com/edi...zone=1&first=1

http://www.shmula.com/the-toyota-pro...nt-system/344/

http://en.wikipedia.org/wiki/Lean_manufacturing

The difficult part with the system you suggest is going to be in quantifying these variables, particularly since another variable is the actual design component and deducing if a problem exists during the design process and if that process too can be made more efficient. I'm all for quantifying, but that doesn't change the fact that an employee may be called out for not falling into the standard deviation for the time normally required to do the project. At that point a human interaction will take place and blame will be shifted to others for delay or perhaps the figures used to decide on time taken will be adjusted to compensate.

Regardless, the point still stands. With a metric or without a metric there is still a breakdown in your current processes. True, the metric will then be used to pinpoint these issues and then you will work to improve upon them. But it will take serious man hours and project supervision to develop this metric and then analyze each part of production to pinpoint these areas of weakness. But as described earlier this is a small company where everyone seems busy, so the heavy man hours involved in this process will be a cost as well to do correctly. These are man hours which are questionable for availability. I make this hypothesis since your company has employees taking their time and management doesn't currently have the time to supervise them to directly verify this claim. So I'm not stating that what you are attempting to do is bad, but the advantages of developing, analyzing and enforcing these metrics will need to be compared to the cost savings and time to analyze / productivity lost by supervisors involved in this process.

[dherbstr]

Lengthy, I apologize, but a good anecdotal lesson for people with problem production teams.


I had a similar problem with a remote office years back when working for an architecture firm. We had eight drafters in the remote office and production was notoriously slow from them. Our estimation was 10 hours of remote drafting time = 1 hour of local drafting time.

That meant what should have taken 1 hour, was taking 10 from the remote employees.

I worked hard with our VP of IT to solve all the technical problems, newer computers, remote servers for both log-in and file storage/sharing, etc. With all of the technical problems solved we were still experiencing the 10:1 ratio.

So next we worked on training for the remote employees. Teaching them the "best methods and practices" for drafting, getting them hands on with the nifty tools available in AutoCAD, etc. We had improvement.

Now our ratio was 9:1.

After eliminating the technical problems and the knowledge problems we began to look for other problems. One concern that I noticed while working in the remote office was a delay with AutoCAD. Every time I would enter a command there was a 5 second lag between hitting enter and the program "catching up". Some commands were in the 30 second range. (We determined this was the remote computers and server trying to read the support files on our local servers.)

To figure out how bad the delay was we (the IT manager and I) wrote a SQL database that would track the commands used in AutoCAD including: command entered, time of command start, time of command stop, user entering the command, date entered, etc. We could then query the database for almost any metric of information we wanted. That would tell us how long it was taking each user to save, close, and open files to help track the overall lost time due to technological problems.

We tracked the AutoCAD command usage of the eight remote employees as well as myself and one other local employee (our power user). Turns out that in a given day of drafting the power user and I called about 2000 commands, and our eight remote drafters were calling 600 commands (average).

Additionally we found that the power user and I called UNDO less than 5% of the time. Our remote drafters were calling UNDO about 40% of the time (training problem). When we examined the commands the remote employees were using more closely, we found that 90% of the commands were input in the first or last hours of the work day.

With that, we were fairly certain we had found the reason for the delay. So we deployed a "malware protection software" that would take a screen-shot every time the active window was switched. The software was designed to catch those little pop-ups that disappear before you can see what they say, to help IT track down problems.

The side effect of the software is the creation of a "flip book" of screen shots from a given computer. When reviewed, we found these eight employees would open AutoCAD in the morning and input commands for an hour. Then they would spend six hours in internet explorer. Finally the last hour of the day was spent in AutoCAD.

That was an easy problem to fix.

[jaberwok]

Hmm.

I was once one of three contract drafters in an office that also held 3 staff guys.
We used AutoCAD, they used MicroStation.
We produced approximately five times as many drawings as they did.

The software?
The attitude of the workers?
Who knows? ~shrug~

[BlackBox]

Hmm.

I was once one of three contract drafters in an office that also held 3 staff guys.
We used AutoCAD, they used MicroStation.
We produced approximately five times as many drawings as they did.

The software?
The attitude of the workers?
Who knows? ~shrug~

I work in Transportation, and my AutoCAD team has finished our workloads faster than required, and are now cross training on Microstation to ensure that the Microstation team's projects back on schedule. :eyeroll:

[jaberwok]

I work in Transportation, and my AutoCAD team has finished our workloads faster than required, and are now cross training on Microstation to ensure that the Microstation team's projects back on schedule. :eyeroll:

[LBuck]

Hans,

Perhaps the answer is not in quantifying the time it takes for the operators to complete the task, but incentives to get them to complete it earlier. Since your projects are so varied, it (as pointed out previously) is going to be almost impossible to estimate time per drawing. If your users are intentionally dragging their mouses to increase their salaries, then maybe enough costs could be recovered (total project costs based on your statement of losses) through small monetary bonuses for earlier completion?

If your project is on the course of losing $100,000 and you offer incentives of $5,000, then you're still ahead.

This is just an alternative to keep you from driving yourself crazy trying to come up with the elusive time-table.

It may or may not work, but it sounds like your users are competent, but wanting additional funds.

[tsigler]

I haven't read through all the replies to this thread so if I reiterate something that has already been stated please forgive me.

My company composes a proposal for every project we have. We send it to the client and request a signed copy be returned to us. This way the client and the drafting staff know exactly what it will cost and how many hours can be spent accomplishing it. I'm not saying you necessarily need to get a client involved but if you do a time estimate for each project before starting and then let the draftsperson know at the out set that he/she has X hours to complete it. Failure to meet this goal consistently could be grounds for replacement. You don't always have to adhere to the schedule (there are always things that come up) but at least the drafting staff will know what is expected of them. At first you will probably estimate your time incorrectly (one of the extenuating things that come up) but eventually you will start hitting it pretty close. It is a good exercise for you and a great one for your company.

I keep a spreadsheet that I update after each project listing the estimated time and the actual time required. I break that down into Admin, Supervisor and Drafting hours just to see where the time goes. I further break the spreadsheet down into different types of project so I can compare apples to apples. It helps me a lot with my estimating.

In the end, it all comes down to your ability to assess the various projects. Oh, another thing I have been doing is getting the draftsperson involved in the estimating portion of this. I ask him/her assess the project and tell me ow many hours will be need for completion. Then we compare take offs and we agree on how long it should take. It is a skill that any drafter needs to acquire eventually and it makes them feel more involved in the process. I find that I usually have to add hours to their estimate. In any event when deadline time comes there are no excuses for not being done. They had already agreed on it.

FWIW

Tom

[karalon10]

I dont agree that you can hold your draftsman to a time that they quote.
As you expressed you are adding time or taking time off perhaps what they have estimated.
An estimate is an estimate - not a quote, there is a big difference.
Secondly, you need to assess on a case by case basis what might be the cause of any hold ups.

Drafters in most cases, are at the end of your information chain, and are usually the ones wearing compounded time blowouts from further up the chain. They are usually the ones staying back because of these time delays which are not their fault necessarily.

The only way to increase productivity (keep in mind I am not a manager but a worker) is to offer incentive based rewards, not punitive measures for delays. The best method is always positive reinforcement rather than negative reinforcement. If you are constantly harping on about deadlines not being met and the negative connotations regarding that I guarantee you your staff will focus on the negative (eg: Jimmy f'd this up further up the chain and I am having to stay back and I will get in trouble for someone elses stuff up)

You are not going to get results based outcomes if you offer no incentive, if the only incentive is to avoid punishment your staff retention is going to suffer.

Productivity vs other team members is also not great, because someone else might have a simpler project requiring less detail, and also handled by a different and better project management team which means Drafter A gets better looking productivity than Drafter B, however Drafter B has saved you a bunch of rework and added cost by being thorough and checking his work because he knows that the PM team is useless. Everything is relative. Everything. Is Drafter B cleaning up someone else mistakes in the name of accuracy and therefore taking longer? An external and time based productivity assessment system is never going to identify these issues.

This is the problem with any kind of locked down measurement system, its not going to consider variables at all. Nor is it going to consider things like accuracy, detail level required, or time delays up the chain.

The carrot on the stick is something I always look at with scepticism, because all too often that carrot is taken off it's string and inserted up the backside rather than given as a treat.