"With or without religion, you would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion." - Steven Weinberg.
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?
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.
"Potential has a shelf life." - Margaret Atwood
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!
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.
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?
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.
Real pirates wear silk suits & ties, and write EULAs
The only thing more dangerous to the liberty of a free people than big government, is big business.
Well said, Cadtag - examples are always helpful.
"Potential has a shelf life." - Margaret Atwood