Improving mechanical design department 5

[dejan95]

Hello fellow engineers!

I'm looking at ways to improve our mechanical design department. We build different type of machines - automation lines.

We are a large firm, but this department is fairly new and I was hoping you may have any tips on how to improve productivity, communication, project leading...

Some problems which seems the most obvious to me are:
1.) The designers in the mechanical design department aren't motivated enough. They are good engineers, but they work at 50% productivity. How could we motivate them to do more work?

2.) Project leading is sometimes a problem. We use excel and confluence to manage projects. There are four main departments; mechanical design, assembly, programming and technology. What is the best way to connect this four departments for a specific projekt. Would it make sense to consider MS Project or some similar project managing tools?

3.) This one is specific to our mechanical design department. How could we improve productivity in a sense of automating tasks? We try to standardise designs, but are there any more useful tricks?

Or does anybody know any good books on this topics?

Thank you in advance!

 

[desertfox]

Hi dejan95

Have you considered asking the designers themselves how they could improve efficiency, they are probably the best people to ask because they do the day to day work, they will be able to say which tasks could be automated and will probably suggest some software, the problem is that its often the cost of software or hardware that the company won't invest the money.
Talking of motivation, again involve them in the process you are trying to improve, I find if you ask people what they think it makes them feel apart of something. there's nothing worse for moral than a bunch of managers who have never designed anything deciding whats the best system or tools for the people that do.

I'm not sure how you quantify designers working at 50%, however I wish I had a pound for every time I have heard the statement "a drawing, oh thats just lines on paper" whilst that is perfectly true what these people don't see is the thought process which results in those lines on paper.

“Do not worry about your problems with mathematics, I assure you mine are far greater.” Albert Einstein

 

[mfgenggear]

Incentives and bonuses. are great motivation.
also team management skills are a must, how to include every one in a weekly meeting. and mentoring
agree ask for input from them what they need.
organization skills taught to the employees, how to manage projects, increasing skills such as up to date software
and hardware,

 

[drawoh]

dejan95,

What does "50% productivity" mean?

--
JHG

 

[drawoh]

dejan95,

Forget the software. Do your departments talk to each other? All sorts of tools are functional in the hands of people who want to communicate and work as a team. Do you have any office politics going on?

--
JHG

 

[CWB1]

Most companies use MS Project or other PM software to track standardized design tasks across multiple projects. Not only does that allow you to predict project timelines and cost for quoting/management purposes, but it also allows you to hold individual team members accountable for their workload/efficiency.

 

[3DDave]

The companies that do best have their CEOs on the floor. They talk to engineers, assemblers, ask what they want or need to do a better job. It's not software and it's not procedures. It's motivated leaders.

OTOH if you are only getting 50%, I suggest they are only paid 50% of what effort you want from them. That is also a leadership problem.

An example problem that leadership fixed: our factory had numerous complaints that welded assemblies were in short supply so the assembly line was idle too much. Go to the weld shop and ask and they say they don't have all the pieces to complete the assemblies. Ask the machine shop and they say they only do batch operations for the full order, so all of one part, then all of the next, and so on because it is more efficient for them.

Leadership says - great, the machine shop shows really good productivity and is killing the company.

If not for a true leader going to the floor, the top management says, "The machine shop is the only area meeting the goals. Punish everyone else."

 

[rb1957]

IMHO incentives are not a good motivator.

I agree with the question "what does 50% mean ?" ... maybe it means that mgmt expectations are 200% ? (nah, couldn't be !!)

I agree ... talk to the guys.

But maybe they are being lazy ... then sort and cut the bottom 10%.

Maybe they've been "flogged" for too long now and don't give a cr@p anymore ?

maybe you've got square pegs in round holes ? (ie people's skills are not aligned with their tasks).

Maybe its a case of "order, counter-order, disorder" ?

I personally disagree with the CEO on the floor, but he must be able to see the floor and to appreciate what he's seeing (as his own gauge on whatever BS he's being told. (BS? nah, never; well, hardly ever)

If you're managing them, what's your experience (in mgmt) ? Mgmt is a skill, separate for good technical skill. have you been brought in the "straighten the ship" ?

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

 

[SWComposites]

Re 1) how EXACTLY are you measuring productivity??? Opinions? Real data (I doubt it)?

Re 2) IMO MSProject is the biggest time sink and anti-productivity tool ever invented. Keeping a giant MSProject file up to date and accurate is an enormous effort.

As mentioned above, fix any communication issues between groups first. This can be helped by colocating project team members together. And have frequent short status meetings (and this is not diving into a giant schedule file).

 

[dejan95]

I'm not in management. I'm part of the design department. That is how I know about the productivity and the lack of it. We are really good friends with my coworkers, but by reading a lot of books (atomic habits)I believe we can become much better department. That is why I was asking for your help.

 

[3DDave]

Sure - read "The Mythical Man Month" by Brooks.

 

[geesaman.d]

1) Books written for management and self-help have very limited applicability to highly technical, information-driven work. I have a copy of Atomic Habits but I haven't cracked into it so unfortunately I cannot comment specifically on that book. I *can* say that many common office productivity volumes are exactly the wrong thing to apply to engineering design, where deep work and freedom from interruptions is crucial to productivity. There is a vast portion of the business self improvement books that are written for an audience of managers / executives who bounce from one fad self-improvement method to another, and a successful book reinforces all of their happy business instincts. Another internal task force. Another LinkedIn post about how wonderful this concept is and how it's propelling them to their next stage of thought leadership. </retch> Which is to say, I don't think highly of this genre of books as a whole. Read them, consider them, apply a little bit to your personal life where it makes sense. Knowing where to apply a new idea is 100x more impactful than applying things just to see if they work.

2) I agree with the statement about 50% productivity means little until it's clearly defined. Do you have engineers operating at 100% productivity for comparison? How do you define 100% productivity?

3) What is the accuracy of the teams output? What is the (real) cost of errors? Are the errors discovered within the same facility or do they hide until the components are manufactured elsewhere before they are discovered at assembly? I work in a department that generates one-off designs and all components are manufactured by subcontractors. We invest more time in checking our work because it's very costly to discover an error at assembly. Make sure your productivity considers accuracy appropriately.

4) Discuss productivity issues with the team. In my experience, engineering teams are pushed to perform design before they have adequate information in hand. Is Sales providing adequate detail of what is required? Are the "productive" engineers just making assumptions to keep moving forward (and what impact does that have when the assumptions are not accurate)? Are design changes impacting total engineering time? Are the designs being reviewed and stage-gated at the appropriate intervals? Are all of the designs getting the benefit of the collective experience within the team?

5) Re-use of design data is very valuable in these situations but only if you can find the right design to re-use. Do you have well-organized part master data, such that you can search the existing part masters and quickly collect the closest existing designs?

6) Automate. Automate what? I hear this all of the time - but it only take one or two additional variables to water down the value of automation. Talk to the team, get their input because odds are, they don't enjoy doing the tasks that really are suitable for automation already.

7) I agree that incentives usually don't work. It' hilarious and tragic when management thinks they can craft a system that incentivizes engineering to be 'better' and then management's myopic incentive makes things worse - and splits the engineering team between those who chase the incentives and let the consequences fall later and those who see a different big picture and won't let the incentives sway them.

8) What other departments does the engineering team support, and how much of their time is going to those tasks? At many technical companies, engineering is the catch-all starting point for all of the other departments to begin solving a problem - whether or not it requires engineering support. It could be that the most 'productive' engineers are also the most supportive to the company. It's not necessarily a bad thing, but it needs to be in the team time budget and considered for what it is.

9) How do you manage the multi-disciplined aspect of the design? Does it go through mechanical first, then software, and so on? Or are the design teams working concurrently? And how well is that working?

10) Talk to the most experienced engineers - there are very likely excellent design practices in the past that were abandoned at some point but could be brought back into current practice for quick wins.

11) How are new projects documented and brought into the engineering department? If the information is not presented in a consistent way, then it becomes a mess and much of the engineering time goes into investigating and constructing the actual project requirements. The team ahead of engineering needs to know exactly what they sold and engineering should not proceed until *engineering* agrees they understand what that is.

 

[rb1957]

how big is your organisation ? your Engineering department ?

If you're "on the floor, in the trenches, at the coal face", then why (do you think) is productivity so bad ?

what is inefficient to you ? Are drwgs taking too long to get done ? Is there a lot of rework ??

what does your organisation do ? Repetitive build (like production runs) or prototyping (each job for a limited number of builds) ?

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

 

[LittleInch]

"The department is fairly new" - How New? 6 months, 1 yr, 5 yrs?

What did the company do before this new department turned up?
Why did it decide to create this department?
Did it have a mentor in higher management? Is that person still there?

What type of work does it do? Innovative / creative concept engineering type stuff or lots of "turn the handle2 type design work where each thing is only slightly different to the last one?

What is your experience mix of experience / age / background? Too many of one type leads to an imbalance.

Project management is much more than simply recording and planning tasks, but Excel is only good for relatively small projects with a handful of people.
But any system I've ever worked with seems to be written by software engineers in order to do software type projects as its all they know. Other types get shoehorned into their way of doing projects. Also setting up and running these systems takes a huge amount of time which is rarely include din the budget.

How are projects set up, budgeted, resource allocated? All this is key to setting the whole thing up right. Get the basics right and the projects work well.

Are there multiple design changes? Again - set a basis of design and stick to it or pay, literally, the consequences of chopping and changing.

Some more information would help a lot.

Remember - More details = better answers
Also: If you get a response it's polite to respond to it.

 

[mfgenggear]

A good manager, who has been in the applicable line of work, and knows how long a new green start from nothing project take to complete.
and knows that jobs have to be scheduled as such the a sometimes it requires working several projects, and releasing
partial work as the project progresses. so ya that's how an employee gets tracked. and how he or she is projected progress and is on schedule. Engineers make terrible schedulers, but sometimes unrealistic schedules are given, but that is life.

so to my opinion if the manager is lost and does not have enough experience, there is no magic wand, it takes years and years of experience. I tried to sugar coat it and I recommend for moral give perks, most but not all employees want to do a great job.
but to my experience they lack support from the management, it takes training, moral boosters, and a manager who takes care of his
employees,

 

[CWB1]

I'm rather surprised by most of the responses given. IME engineers are usually focused on quantifying and mathematically analyzing everything, and usually abhor qualitative guessing, arbitrary meetings/discussions, and other tasks with no measurable outcome or clear purpose.

Scientific management has been around more than a century with libraries of books published on everything/everybody from Taylor and his predecessors to Toyota, Lean, and Agile methodologies. Its generally accepted as being a misnomer tho in that project teams self-organized under a project "manager" are far more efficient than dept teams with engineering managers doling out tasks. The engineering managers should always be behind the scenes ready to support, but not involved in most projects beyond challenging the work/timeline/budget presented in design and project reviews.

On a well-run project the engineer should be dividing his work into various standard/generic tasks up front and publishing them into a project plan in MS Project or otherwise. Size electric motor, design support bracket CAD, 2x bolted joint analyses, run bracket FEA, etc. The time allowed for each task is the mean time to complete those tasks on other projects, so building/maintaining a task library is needed. Project managers support these administrative and process tasks, they're data analytics nerds who create/maintain the systems/libraries/processes, help the team organize its timeline and budget, and monitor time and budget burn throughout the project.

 

[mfgenggear]

CWB1

there are so many different categories of design, it would take a library to house them all, A senior manager with years of experience needs to be involved. mentoring young Engineers, and leading the way, now a seasoned well experience person, needs to be handled differently. Managers job is to report they are on schedule, and in budget. and quality of design. my two cents

 

[rb1957]

whilst I agree with "abhor ... arbitrary meetings/discussions, and other tasks with no measurable outcome or clear purpose", 90% of my technical job is making decisions based often on little or no data. Of course I see the value of mathematical analysis, but when the inputs are mainly judgement, then there's no real reason for "excessive" precision.

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

 

[geesaman.d]

IME engineers are usually focused on quantifying and mathematically analyzing everything, ... and other tasks with no measurable outcome or clear purpose.

Apologies if this is nit-picky, but...

If they were quantifying and mathematically analyzing everything, they'd be scientists and/or analysts. Engineering is often solving problems without complete quantification and analysis. Follow existing designs / choose reasonable material sizes / repurpose components where the new application has the same or less loading - and keep moving along. There are subsections within Engineering where everything does get full-blown analysis (aerospace for example) but even there you must feed the analyses with imperfect data and assumptions. Some engineers twitch visibly at the notion of not throwing their most advanced analytical tools at every component, every time. In my world, perfection is the enemy of the next order / next paycheck and so the majority of the engineers need to sleep well without analyzing every little thing.

Circling back to the original post, managers who believe they are quantifying performance accurately, usually are not. It takes a particularly ideal circumstance or a particularly experienced and well-nuanced manager to measure engineering performance well and still foster a cooperative and supportive culture.

(ETA: I'm not against metrics. But in my experience bad ones are more harmful than good. Performance metrics need to be agreed by the engineering team as fair and the metrics cannot encourage a 'not my job' attitude and they need to allow the cross-functional work and support to continue to thrive. HR and upper management needs to understand that strict metrication will lead to team members having to choose between measuring well/ignoring all other needs or supporting everyone that needs engineering support to keep the business productive)

 

[Tmoose]

This is one of the very best threads I've seen.
Several truly insightful posts, in my opinion.