Project Meetings only happen in this day and age because Project
Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.
Project Meetings only happen in this day and age because Project Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.
And, if there were no project management meetings, we wouldn't need as many project managers...
One of my pet peeves is being stuck in meetings too long when I have work I'd rather be making progress on - especially if the meetings are set up by the same people who asked us to do the work, and especially if the meetings go longer than they were supposed to.
I thought about a project manager I worked with in the 90s who ran a meeting like a machine. He started every meeting on time, brought people in, got their input and excused them when they were no longer needed. In and out.
I strive to run my meetings like his.
Project Meetings only happen in this day and age because Project
Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.
And, if there were no project management meetings, we wouldn't need
as many project managers... --- SBBSecho 3.20-Win32 * Origin: realitycheckBBS.org -- information is power. (21:4/122)
Project Meetings only happen in this day and age because Project Managers would rather take up everyone's time going over an
Excel spreadsheet than to have people use modern collaborative
tools.
Tuggin' on my heartstrings over here!
Meetings...the bane of my existence. Sometimes it's nice to be
unemployed.
--- Mystic BBS v1.12 A49 2023/02/26 (Linux/64) * Origin: m O N T E R
E Y b B S . c O M (21:4/173)
One of my pet peeves is being stuck in meetings too long when I have
work I'd rather be making progress on - especially if the meetings
are set up by the same people who asked us to do the work, and
especially if the meetings go longer than they were supposed to.
Nightfox --- SBBSecho 3.20-Linux * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
Commodore Clifford wrote to Nightfox <=-
My favorites are the ones where we have a four hour meeting to discuss
an incident, listening to someone prattle on about how they want to be "fair to the devs"... in the meantime, the problem isn't even with our code, but with another system entirely and once the correct people
figured it out, I doubt it even took that long to fix it.
Commodore Clifford wrote to Nightfox <=-
My favorites are the ones where we have a four hour meeting to
discuss an incident, listening to someone prattle on about how
they want to be "fair to the devs"... in the meantime, the
problem isn't even with our code, but with another system
entirely and once the correct people figured it out, I doubt it
even took that long to fix it.
I remember a prticularly spicy post-issue meeting after my company's
web site was down for an extended period. teams were trying to find
the root cause, our DB said it wasn't the DB, and when he was
questioned further, he quit, because he wouldn't work somewhere
where his expertise was questioned.
If memory serves, it was the DB.
On 21 Dec 23 16:06:00 poindexter FORTRAN wrote...
Commodore Clifford wrote to Nightfox <=-
My favorites are the ones where we have a four hour meeting
to discuss an incident, listening to someone prattle on
about how they want to be "fair to the devs"... in the
meantime, the problem isn't even with our code, but with
another system entirely and once the correct people figured
it out, I doubt it even took that long to fix it.
I remember a prticularly spicy post-issue meeting after my
company's web site was down for an extended period. teams were
trying to find the root cause, our DB said it wasn't the DB, and
when he was questioned further, he quit, because he wouldn't
work somewhere where his expertise was questioned.
If memory serves, it was the DB.
To which Commodore Clifford replies...
In my case, we have the opposite problem. We have our huge meetings
when something goes wrong and they always blame us and want us to
"own" the problem because it's on the website where you see the error.
The problem is, it's rarely really our problem when it's something
big... it's usually one of the hundreds of service endpoints we have
to interact with. One of those fails, we have an error message
displayed. But it's not our code that is in error. Sometimes, we can
do a fix faster (this is usually the case when someone makes a change
to a service without actually testing it or notifying all consumers
of the service) but they still try to "blame" us.
It's getting old.
--- RATSoft/FIDO v09.14.95 [JetMail 1.01] * Origin: STar Fleet HQ -
Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
Whenever my customers have an issue with a 3rd party device, we ahve
to go in and solve the problem. They ahve no understanding of the
Siemens PLC controlling the machine, so every little problem is
blamed on Siemens and we have to fix it. This happens 80% of the
time... it is downright stupidity.
--- RATSoft/FIDO v09.14.95 [JetMail 1.01] * Origin: STar Fleet HQ -
Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
To which Commodore Clifford replies...I worked on the principle that if 50% liked it and the other 50% didn't, it was a win for me!
Right now, this week my biggest thing is "the business" reporting things as bugs because it's not how any given "individual" thinks it should
work.
It works as was indicated by the requirements.
They don't like that... they think it should "do this" instead.
Well, ok... but the other guy thinks it should work "that way" and the other woman over there thinks it should work "totally differently".
My answer.
THUNDERDOME!
| Sysop: | Eric Oulashin |
|---|---|
| Location: | Beaverton, Oregon, USA |
| Users: | 101 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 06:21:29 |
| Calls: | 3,515 |
| Calls today: | 3 |
| Files: | 8,462 |
| Messages: | 337,311 |