Communication problems with manufacturers 5

[CJ Cassar]

Hey folks,

Just wondering if anyone else has communication problems with stakeholders (manufacturers, non-eng staff, other eng disciplines)?

What solutions (tech or non-tech) have you found to help solve this?

Also, does anyone else find that these communication issues stall their projects unnecessarily?

Kind regards,
CJ

 

[SWComposites]

Yes, all the time.
Get everything in writing. Insist on frequent clear communication.
Yep.

 

[CJ Cassar]

Thanks,

I'm trying to make sure that this doesn't slow down the project too much.

Really annoying how often the solution is to send back a PowerPoint with some notes written on top of it.

Wondering if taking advantage of something like slack but with design sharing is possible.

Any suggestions?

 

[GregLocock]

We're vaguely discussing whether github would be a better place for storing our models.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

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

 

[CJ Cassar]

When I swapped from structural to maritime design this problem kept following me. What's the annoying bit is when I tell my PM sometimes they think I'm coming up with some excuse but I'm honestly just waiting around trying to balance not enraging the stakeholder but still trying to hurry them up.

What's the best advice for keeping everyone happy?

 

[3DDave]

This sort of Program/Project Manager always seemed toxic to me. I can be responsible for my work and throughput, but it's the PM who is responsible for the majority of externalities to my job.

Plenty of CYA memos seems to be the best antidote, combined with doing the PM's job when they have disavowed their responsibility. If people won't put decisions and promises in writing - do it for them as "If I understand correctly, this is your position and this is what you promised to deliver and when you promised to deliver it based on access to whatever resource you said. If I am mistaken in this, my apologies, and please send corrections." Of course, do the same for your work. Prepare to apologize a lot and always emphasize an understanding that while circumstances can change, it is imperative to communicate changes as soon as possible.

My wife does estimating on large projects and deals with this sort of thing often. Instead of waiting for inputs she drafts an estimate that will be uncomfortable to perform to and send it to the party for approval. Where they will dither forever on creating their own, they will suddenly find flaws with the intentionally flawed one she creates. Stunning really.

 

[BrianPetersen]

I'm frequently asked to hold off with things-to-do punch lists until someone gets me a document showing that some issue that's on the list has been resolved. Nope, been burned too many times, that's not how I roll. The punch list (and the invoice for my time and expenses) gets issued as-is with that item on it, I'll revise it later when (or if) said documentation shows up. For small projects, life is much easier when said invoice includes a built-in allowance for doing that revision, because then I can just do it without troubling the accounting department again if someone gets around to sending me what I need.

And when they send me that information, I don't sit on it. I do my part straight away.

Any official or important communication has to go by email so that there's a record of it.

 

[CJ Cassar]

We're vaguely discussing whether github would be a better place for storing our models.

What were the negatives that you guys found with using GH?

Must be some security issue push back, no?

 

[zeusfaber]

Remembering to show that you're listening to the stakeholders goes a long way too.

A.

 

[3DDave]

Github should be as secure as any software used to distribute information. The free/public areas are open, but it would not be a business if that's all there was. See

https://github.com/security

My preference would be a Wiki, but they may not fit the requirements as well as Github, or Dropbox for that matter.

 

[r13]

1) Involve all stake holders with sufficient information - for instance, send inquiry email with attachment to all affected persons/business, so keep everybody on the same page.
2) State the issue as clear as possible, and demand a timely response.
3) Compile the responses, draw conclusion, or identify further action, and notify all stake holders in the follow up emails.

 

[Sparweb]

Instead of waiting for inputs she drafts an estimate that will be uncomfortable to perform to and send it to the party for approval. Where they will dither forever on creating their own, they will suddenly find flaws with the intentionally flawed one she creates. Stunning really.

Ha, I thought I was the only one who did that.

http://www.sparweb.ca

 

[Sparweb]

Any official or important communication has to go by email so that there's a record of it.

How often do I type things that were said in a telephone call into an e-mail and send it back to the people on the call, just to make sure it's on record?

http://www.sparweb.ca

 

[drawoh]

CJ Cassar,

You have two very similar posts here. It sounds like you are having problems.

thread404-476410

If people are trying to communicate, just about everything works, up to and including walking over to the other guy's desk and saying "Hi". I go back to the days when we sent around memorandums on paper. That worked, as does email.

If your people are not willing to communicate, or they hate each other's guts, or just don't respect each other, you have an office politics problem. I don't see you solving this with software.

It sounds like you are a computer guy trying to talk to mechanicals. A good crude rule of thumb is that if someone cannot explain some technical issue in plain English, they probably do not understand the issue.

--
JHG

 

[CJ Cassar]

If people are trying to communicate, just about everything works, up to and including walking over to the other guy's desk and saying "Hi". I go back to the days when we sent around memorandums on paper. That worked, as does email.

If your people are not willing to communicate, or they hate each other's guts, or just don't respect each other, you have an office politics problem. I don't see you solving this with software.

It sounds like you are a computer guy trying to talk to mechanicals. A good crude rule of thumb is that if someone cannot explain some technical issue in plain English, they probably do not understand the issue.

Thanks for the pointers. I was recently a mech-eng guy that transitioned into a software role. My problem isn't that I don't talk in plain english (even though i definitely won't doubt I'm messing up there) but that the feedback loop is painfully long sometimes. What I was hoping to gather was how common this was for folks and hopefully get some tech-solutions of how to solve this in order to justify my role transition.

Everyone's answers were extremely helpful though. It does sound like there could be some sort of way to force zoom calls or something to shorten these feedback loops.