@Grondhammar
Some random thoughts for you:
1. Process changes are rarely cheap.
You have to make sure there are no unintended consequences; you have to retrain the people who are involved (which always takes 2x or more time than expected); you often have to throw away some old or incomplete work, etc.
So even a good suggestion may be impractical in the moment. Project Completion should normally take precedence.
2. There's a concept where I live that translates to "sub-optimization" (might work in English too).
The implication is that optimizing something at a smaller scale can have larger negative effects when the "big picture" is considered.
This manifests in other contexts as "the law of unintended consequences" as mentioned above.
That doesn't mean that bottom-up "continuous improvement" is a bad thing of course. It's just a guideline for assessing any specific change.
3. Telling someone about a good idea that doesn't affect
their responsibilities and activities is not likely to work well. The natural audience is operational-level people who will benefit directly, and their immediate management
4. Colleagues who agree with a suggestion but are not paid to implement it
might support your ideas, but
should not help to "sell" the idea, or informally implement it (unless OFC it's a micro-scale, rapid payback improvement).
I've seen a
lot of money (tens of millions of USD) go up in smoke (in the form of large failed projects) because of people concentrating on the wrong things. It's quite common in IT, because it's so hard for management to know that work is being done efficiently.
A few of the underlying causes include:
* Developers who sneak in features and technology that will look good on their resume, but is "project negative"
* Tech people (all kinds) who prefer to create automation than just do their work
* "Artists" who over-spec so the result is "elegant", resulting in time and cost overruns, and sometimes cancellation.
I didn't put a line in for you, because
looking for improvement doesn't damage projects. If you enjoy it you should keep doing it.
But you definitely need to work on context (if you have something to say, who do you say it to, and how do you present it?). I think (from your latest post) you're working on this already, so just two simple guidelines:
* You need to be able to get "what" and "why" into one whiteboard or max five slides with one or two diagrams and
less than 20 lines of text in total. Plan for
max delivery time in both cases of 10 min for you, 5 min for questions.
A "win" is being asked to complete the documentation implied in the presentation
* Think about who benefits (including their operational management), and package everything for them.
Random chatty colleagues don't count.
Cui bono? - Wikipedia
(Not a great Wikipedia article, but I've heard it used informally IRL)