CAD Dept. Management Challenge!! (Productivity)

[jaberwok]

Am I the only one that finds this conversation a bit disturbing?

+2.

It appears that management have no appreciation or understanding of the tasks they are supposed to be managing so the answer is to employ a manager who has been there and done that.

[duhvinci]

1+

Without someone IN the CAD group who knows what work being done actually contributes to the project's completion, your metric is meaningless.

A CAD user can run commands all day long, drawing lines, being productive, and then delete all their work before closing their AutoCAD session... 0% productivity, 100% utilization.

Software is good for many, many things (nothing against CadTempo)... however, resolving this issue in an equitable, sustainable manor, requires human beings working together as professionals. Management needs to know what it is that they're managing, every bit as much as the CAD users need to understand (and adhere) to an comprehensive CAD standard.

I would have to 1+ Brian's post as well but I would like to add that without the measurement you have no basis to establish a goal, nothing to work from, no idea where you are currently at. Perhaps the current department is running at dung speed, how can you tell when the department is running at not-so-dung speed?

If you don't know where you're at you don't know where you're going.

So let's say you are at 50% efficiency but you don't know it. It is easy to establish a goal of 75% efficiency and in two weeks you can proclaim that due to cracking the whip (or offering some incentive) you've now brought the efficiency up to 80% even though you still don't know that to be true.

Now, true, a system can be gamed as you point out, but if someone is looking at the output of a 100% utilization and seeing a productivity of 0 there is some pretty good ammunition for corrective action. Just being made aware of the potential for catching that gamesmanship can be incentive enough for an individual to make his own corrective action. Or maybe they'll just get tired of playing games and finally do their work.

I hope to develop CadTempo to provide a means for users in various industries to make comparisons between their own dept. against a norm for a particular industry. I'm certain there are pitfalls.

BTW, are you the same RenderMan over at CadTudor?

[BlackBox]

I would have to 1+ Brian's post as well but I would like to add that without the measurement you have no basis to establish a goal, nothing to work from, no idea where you are currently at. Perhaps the current department is running at dung speed, how can you tell when the department is running at not-so-dung speed?

If you don't know where you're at you don't know where you're going.

So let's say you are at 50% efficiency but you don't know it. It is easy to establish a goal of 75% efficiency and in two weeks you can proclaim that due to cracking the whip (or offering some incentive) you've now brought the efficiency up to 80% even though you still don't know that to be true.

Now, true, a system can be gamed as you point out, but if someone is looking at the output of a 100% utilization and seeing a productivity of 0 there is some pretty good ammunition for corrective action. Just being made aware of the potential for catching that gamesmanship can be incentive enough for an individual to make his own corrective action. Or maybe they'll just get tired of playing games and finally do their work.

I hope to develop CadTempo to provide a means for users in various industries to make comparisons between their own dept. against a norm for a particular industry. I'm certain there are pitfalls.

Firstly, as I stated in my last post, I mean no offense to you, CadTempo. The ability to accurately measure productivity is a highly desirable capability. I have not visited your site, nor do I have any opinions on the quality of the product.

Secondly, the root issue for the OP's situation (IMO) is a human problem, which supersedes the ability to measure performance through software. The humans involved *seemingly* are unable to anticipate and execute the requirements necessary to complete their work, either due to neglegence, or a lack of understanding. The software should enhance management's abilities to make decisions... Decisions which cannot obviously be made under their current conditions.

My point is that employing software to report on information that the management doesn't understand prior to the software being implemented is the metaphorical cart before the horse. Fundamental understanding of the milestones to be hit, and a loose understanding of the relative workflows being performed by the cad staff is required before the reporting data can be correctly analyzed.

Formulating decisions without this level of understanding is a poor business decision (to be blunt), and would be a real-world example of setting one's self up for failure.

I hope that I've clearly communicated my point; which is to say that these are simply my opinions on the information that has been discussed here, and nothing more.

BTW, are you the same RenderMan over at CadTudor?

Yes, I participate in AUGI, CADTutor, and most recently TheSwamp forums.

[duhvinci]

Firstly, as I stated in my last post, I mean no offense to you, CadTempo. The ability to accurately measure productivity is a highly desirable capability. I have not visited your site, nor do I have any opinions on the quality of the product.

It's no problem, by no means was there offense taken by your comments. I agree that simply throwing software at a problem will not solve it. It takes human analysis of any gathered data to arrive at a possible solution. All CadTempo will do is assist in gathering that data - it likely is not for everyone. It does do something other time logging software doesn't, among other things providing the productivity percentage of selected document types by individual users. Sorry, I'm not trying to hard sell here.

Secondly, the root issue for the OP's situation (IMO) is a human problem, which supersedes the ability to measure performance through software. The humans involved *seemingly* are unable to anticipate and execute the requirements necessary to complete their work, either due to neglegence, or a lack of understanding. The software should enhance management's abilities to make decisions... Decisions which cannot obviously be made under their current conditions.

Again, I agree. In this case however The OP is beginning to look at the problem and define a course of action. Although Brian made some good points I disagree with the assessment that this is a depressing topic. It actually is an enlightening topic. The OP expressed his situation where satisfactory results are not evident. I'm confident that as he pursues his course of action that he will find some of his users are working diligently.

My point is that employing software to report on information that the management doesn't understand prior to the software being implemented is the metaphorical cart before the horse. Fundamental understanding of the milestones to be hit, and a loose understanding of the relative workflows being performed by the cad staff is required before the reporting data can be correctly analyzed.

Formulating decisions without this level of understanding is a poor business decision (to be blunt), and would be a real-world example of setting one's self up for failure.

This is where I depart from your line of reasoning. The OP does understand there is a problem. He is looking for a way to benchmark performance. Perhaps in many eyes it appears to be simplistic and unworthy of examination. That is something he will discover and perhaps make adjustment to. The key here however is the term benchmark. Ideally (IMO) you begin by benchmarking current performance using current workflows. Establishing milestones prior to knowing your current position is a nebulous affair. You're working in the dark. By determining the current state you can create a roadmap. Now you can examine and compare the changes that are put in place and decide if the change was effective. Rinse and repeat as often as needed until a milestone is reached. Then fix on another milestone.

I hope that I've clearly communicated my point; which is to say that these are simply my opinions on the information that has been discussed here, and nothing more.

You have, and valued points of view at that. I hope my thoughts have been as well.

[Hans_2011]

Firstly, as I stated in my last post, I mean no offense to you, CadTempo. The ability to accurately measure productivity is a highly desirable capability. I have not visited your site, nor do I have any opinions on the quality of the product.

Secondly, the root issue for the OP's situation (IMO) is a human problem, which supersedes the ability to measure performance through software. The humans involved *seemingly* are unable to anticipate and execute the requirements necessary to complete their work, either due to neglegence, or a lack of understanding. The software should enhance management's abilities to make decisions... Decisions which cannot obviously be made under their current conditions.

My point is that employing software to report on information that the management doesn't understand prior to the software being implemented is the metaphorical cart before the horse. Fundamental understanding of the milestones to be hit, and a loose understanding of the relative workflows being performed by the cad staff is required before the reporting data can be correctly analyzed.

Formulating decisions without this level of understanding is a poor business decision (to be blunt), and would be a real-world example of setting one's self up for failure.

I hope that I've clearly communicated my point; which is to say that these are simply my opinions on the information that has been discussed here, and nothing more.



Yes, I participate in AUGI, CADTutor, and most recently TheSwamp forums.

Dear Renderman,

Thank you for your post and your opinion.
For my particular case let me tell you that the current situation is that the Engineering Manager has about 20 years of experience in drafting in CAD and in the engineering of the equipment being designed. Same case for the employees below him.
This is people who really know what they are doing. The problem is on the management side... The lack of proper metrics has made it extremely difficult for this person to Manage until the point that there is no proper control other than "trend reports" with newly set dates which are never met. Whoever has real experience on both sides of the story will know that the issue is not as easy as it may seem.
Just for an example, there are frequent design changes requested by the clients (this is unavoidable), and then it is very difficult to estimate the new end dates because it is simply very difficult to know how much work it is to redesign a certain part of the drawing. In the end is estimation1 + estimation2 + estimation3 + ...= X + error1+ error 2+error3. Unfortunately, errors don't cancel each other and I really don't think it is a lack of experience from management, but maybe it is only that there is a variable which is currently undetected somewhere and is not being controlled...

So here I am trying to solve this issue step by step, and as Duhvinci mentions (although I understand the opinion is coming from someone who is sellling CADTempo, no disrespect Duhvinci!) you need to start getting concrete data in order to track times required to make some drawings. This will only give me a gross estimation at first, but when having a couple of projects tracked like this, the next estimation will be compared to past information and it will be easier to detect inconsistencies.

Additionally, from the HR perspective, having good metrics will compensate good workers and make the whole system run by itself in a happy way and not as currently, where workers are frustated because they are seem to be low performing, the managers are looked the same way and mood is very bad because of this! This by itself is a source of bad productivity...
Brian Myers, I thank you for your post, but I really don't agree to what you said. Your options are right, but I don't see how your post can help in managing better.

If there is any other suggestion, I am very open to everyone's opinion. Just try not to assume facts that are not here on the post.
And check the papers I suggested on my previous post. They are 90% the answer of what I was looking for. I just need to implement them.

Thank you everyone, I am really enjoying this discussion!

[Hans_2011]

It's no problem, by no means was there offense taken by your comments. I agree that simply throwing software at a problem will not solve it. It takes human analysis of any gathered data to arrive at a possible solution. All CadTempo will do is assist in gathering that data - it likely is not for everyone. It does do something other time logging software doesn't, among other things providing the productivity percentage of selected document types by individual users. Sorry, I'm not trying to hard sell here.



Again, I agree. In this case however The OP is beginning to look at the problem and define a course of action. Although Brian made some good points I disagree with the assessment that this is a depressing topic. It actually is an enlightening topic. The OP expressed his situation where satisfactory results are not evident. I'm confident that as he pursues his course of action that he will find some of his users are working diligently.



This is where I depart from your line of reasoning. The OP does understand there is a problem. He is looking for a way to benchmark performance. Perhaps in many eyes it appears to be simplistic and unworthy of examination. That is something he will discover and perhaps make adjustment to. The key here however is the term benchmark. Ideally (IMO) you begin by benchmarking current performance using current workflows. Establishing milestones prior to knowing your current position is a nebulous affair. You're working in the dark. By determining the current state you can create a roadmap. Now you can examine and compare the changes that are put in place and decide if the change was effective. Rinse and repeat as often as needed until a milestone is reached. Then fix on another milestone.



You have, and valued points of view at that. I hope my thoughts have been as well.

Duhvinci,

I totally agree to what you say.
There is also more to do after I get these metrics for INPUT (=man-hours) though. The major difficulty is in measuring the Work Scope (or say: "amount of work") based on the OUTPUTS (=drawings, tons, # of pieces, etc.).

Please everyone remember the original objective of this post is to measure Productivity. This requires to measure INPUT and also "Amount of Work" to divide them and get the Productivity measured as "Units of Work"/Man-Hours.
I see how using softwares such as CADTempo I can better estimate the Man-Hours.
The big unsolved challenge (up to now) is to determine the "Amount of Work" for a specific project.

I have a good solution provided by the papers I mentioned before where you define a "unit of work" such as the "Plain Solid Cube" (similar to what I suggested in the beggining of this post). Then you estimate how much more it takes to draw a "Solid Cube with a hole in the middle". Then, after doing this with all the project parts, you can convert the whole project work in terms of how many equivalent "Plain Solid Cubes" of work it is. Then depending on the skills of the drafters you have, you can empirically calculate how much time it takes to draw the "Plain Solid Cube". Then you multiply this time by the total number of "Plain Solid Cubes" of work required and you can have an estimation of the total hours required to finish the project (a good place to start from at least). After lots of projects, this system can learn from history to become better and better....
Much more easy said than done, but with proper Fabrication Progress documents (which we always do) it is easy to implement since there you have the whole list of assemblies required. If I can have all the assemblies related to the # of "Plain Solid Cubes" of each one, then it is easy. It will take some time to map all the different types of objects needed though, but it is not impossible since already the drafters label parts when they draw.... (which is usually the case out there as well).
I hope someone there could understand this last paragraph...

Open to more suggestions.
Thank you everyone.

[BlackBox]

Dear Renderman,

Thank you for your post and your opinion.

You're welcome, Hans.

I too am enjoying this discussion, and the range of opinions being offered here.

[duhvinci]

Dear Renderman,


So here I am trying to solve this issue step by step, and as Duhvinci mentions (although I understand the opinion is coming from someone who is sellling CADTempo, no disrespect Duhvinci!) you need to start getting concrete data in order to track times required to make some drawings. This will only give me a gross estimation at first, but when having a couple of projects tracked like this, the next estimation will be compared to past information and it will be easier to detect inconsistencies.

It's ok Hans, I do not take offense easily and I try not to take any kind of defensive stance. Any comment good (and especially bad) I use constructively.

True, I am engaging in promotion of my product however I would like to mention that for the past 20 years I have been utilizing the techniques you are talking about to improve my own workflow and productivity.

I believe that the earlier critical comments made regarding measurement of the time it takes to as you describe "draw a plain solid cube" and compare that to a "solid cube with a hole" were merely a case of taking your words literally. In practice you will be examining a more complex scenario and I think you are on the right track.

Good luck with things,

PS Did you receive my PM?

[cadtag]

Hans,

I think you are missing some critical pieces in your approach to 'units of work as a solid cube'. That sounds fairly reasonable as a theory, but with 30 odd years of doing drafting, design, and CAD, I can tell you that neither the initial nor final level of complexity is all that directly related to the effort required to complete a job. That's good for rough ball park estimates, but.... not very germane to production metrics. Maybe a cube with two holes takes twelve minutes to draw up, but when the number of holes, location of the holes, and sizes of the holes changes a dozen times a day, that twelve minutes is meaningless.

First off, the 'unit of work metric' ignores the abiity to re-use and modify existing cad drawings and models for new projects. That's inherently one of the greatest strengths of CAD, but to be useful, you need to be able to identify and retrieve previous work efficiently. Most organizations deal with that poorly -- relying on the oldest guy in the design department to remember what was done for who back when. If you are a widget company, then looking at a real solution for a library of widget bits would be worthwhile.

Secondly, you're not considering either scope or design changes. The number of jobs I've worked on that did not have either or both of those factors impacting schedules has been pretty minimal. Scope creep is insidious, and that's something that the project manager can and must control. But if you don't have a handle on when, why, and how the project scope is changing, then metrics that focus work units are not measuring anything germane to the problem of higher engineering/design/drafting costs.

Design changes are always going to be a fact of life. The (relative) ease of changing a design using CAD tools usually means that the design decisions are changing much more often than is truly required. Instead of thinking through the requirements, 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. That's inefficient use of your drafter's skills and time, but seems to be endemic. The fix is non-trivial, and requires you to enforce a procedure for your design process that tightens up design decisions early in the process. The trend reports mentioned earlier in this thread could be useful there -- if you know how often design decisions are being re-made, you can start to understand how to improve your processes to improve early decision making.

[BlackBox]

Well said, Cadtag - examples are always helpful.