Don't hide any problem!
Article#: 00012
Date: 2020-05-09
Author: Radim
What is a problem?
A problem is a situation that is unsatisfactory and creates difficulties for people.
Why does a problem occur?
A problem is a consequence of something that was not done properly.
A problem arises because we didn't expect something or because we expected something else.
Who encounters a problem?
Anyone can encounter a problem.
A person who is responsible for the problem (causer of the problem) and also another involved person.
How should the encountered problem be handled?
Don't hide the problem and don't ignore it!
Communicate the problem.
Enter the problem in the task list.
If possible, find a permanent solution to the problem, not a temporary one.
Fix the problem promptly!
© Radim-Automation, 2020–2025. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).
Related previous articles:
Related next articles:
- Think on paper!
- Introduce the terminology and standardize it!
- Everything is difficult until it becomes easy
- Write a project diary!
- Don't make it worse!
- Define test scenarios and test cases continuously!
- Do the right things and do them right!
- Safety first!
- More than just start and stop
- I can see what you can not see
- Store email messages in the project folder!
- Do you really want to start with this?
- Is the way really the goal?
- Prepare a good project plan and keep it up to date!
- HMI and PLC applications should grow together
- Write down your best practices and processes!
- Set your goals for today, tommorow, this week ...
- Appoint a representative!
- Write and accept only readable code!
- Use a usefull styleguide!
- Functional and intuitive HMI
- Who will operate?
- Collect all the requirements and sort them!
- Why do automation projects fail?
- Project leader
- Learn from your journey!
- Design machines with a focus on user's abilities and needs
- Think critically!
- Are there also any disadvantages?
- A good concept = Complete set of suitable solutions
- Hardware concept
- Modular software architecture
- Knowledge gained from a completed project is priceless
- Documentation issues
- Event logger as the very first function implemented in the program
- Diagnostic tools
- My boss was a hero
- Maintain order in the program code
- Dedicated employees
- High Performance HMI
- An irreplaceable employee
- HMI - Don't overdo it with complex design
- Hidden dangers during commissioning
- HMI is not a web page
- The false illusion of rapid progress
- HMI - annoying pop-up windows
- What makes an HMI intuitive?
Comment#: 00001
Date: 2020-06-08
User:
Sometimes, the solution to a problem can be seen when the problem is clearly described.
Comment#: 00002
Date: 2021-01-20
User: Radim
"You don't solve problems by putting them on ice."
- Winston Churchill
Comment#: 00003
Date: 2021-11-29
User: Radim
"You’ll get much farther much quicker by admitting your mistakes than by asserting you can never make them."
- https://towardsdatascience.com/notes-on-software-construction-from-code-complete-8d2a8a959c69
Comment#: 00004
Date: 2022-04-10
User: Radim
Each problem must be dealt with separately.
1. What's the problem?
2. Why did it appear?
3. What are the options to fix the problem?
4. Which of the options do we want to choose?
5. How do we start?
Comment#: 00005
Date: 2022-06-03
User: Radim
Do we want to ignore/hide the problems?
... or
Do we want to talk about the problems?
... or
Do we want to solve the problems?
... or
Do we want to prevent the problems?
Comment#: 00006
Date: 2022-09-06
User: Radim
"It's better to endure the discomfort of the truth now than to suffer the discomfort of the lie later."
- Simon Sinek
Comment#: 00007
Date: 2022-11-16
User: Radim
"The later in the development cycle we discover a bug in the software, the more expensive it is to fix."
- https://www.linkedin.com/pulse/unit-testing-world-industrial-automation-jakob-sagatowski/?trackingId=8Il2af6t8cNMxCT2pRn76Q%3D%3D
Comment#: 00008
Date: 2022-12-26
User: Radim
"It is important to distinguish between adding resources to a project that is in trouble and simply reacting in a "knee-jerk" fashion by increasing funding. It is true that, conscientiously applied, additional resources in the form of personnel, support, and money can help a project. This is particularly true in situations in which initial funding was too low, throwing the project's completion into question from the beginning. Howerver, before simply reacting in a panic mode to project troubles, the first step is to conduct a realistic analysis of where the project currently is, how it got there, and how additional funding can bring it back on target."
- Jeffrey K. Pinto, Om P. Kharbanda. Business Horizons (1996). How to fail in project management (without really trying) (Page 50).
Comment#: 00009
Date: 2022-12-26
User: Radim
"A logical exercise in which project managers must engage is to continually ask a series of "What if?" questions. This forces the project manager and the team to search out likely problem areas actively rather than wait for trouble to find them.
An important side note: Research has demonstrated that the project managers who spend adequate up-front time developing a series of "What if?" scenarios and their responses to them are more successful than those who operate in a purely reactive manner, waiting until problems occur before weighing their various responses."
- Jeffrey K. Pinto, Om P. Kharbanda. Business Horizons (1996). How to fail in project management (without really trying) (Page 48).
Comment#: 00010
Date: 2022-12-26
User: Radim
"Problems are inevitable. However, successful project managers are those who are best able to adapt to the new situation with flexibility, look for opportunities, and bring their projects back up to speed rapidly."
- Jeffrey K. Pinto, Om P. Kharbanda. Business Horizons (1996). How to fail in project management (without really trying) (Page 48).
Comment#: 00011
Date: 2023-04-06
User: Radim
"Golden Rules for Living:
1. If you open it, close it.
2. If you turn it on, turn it off.
3. If you unlock it, lock it up.
4. If you break it, admit it.
5. If you can't fix it, call in someone who can.
6. If you borrow it, return it.
7. If you value it, take care of it.
8. If you make a mess, clean it up.
9. If you move it, put it back.
10. If it belongs to someone else, get permission to use it.
11. If you don't know how to operate it, leave it alone.
12. If it's none of your business, don't ask questions."
- https://www.appleseeds.org//Golden-Rule.htm
Comment#: 00012
Date: 2023-06-08
User: Radim
"Today, technical debt, also known as tech debt and code debt, usually occurs when development teams choose to write speedy code while building new features of a software development product. Speedy code delivery can help your team meet deadlines, and the debt you accrue may be worth it, though it could also lead to negative outcomes if managed incorrectly. These negative outcomes aren’t always avoidable once the decision to accrue technical debt has been made."
- https://asana.com/resources/technical-debt
Comment#: 00013
Date: 2023-08-11
User: Radim
"How to eliminate fifty percent of your business worries.
Everyone who wishes to present a problem to me must first prepare and submit a memorandum answering these four questions:
1. What is the problem?
2. What is the cause of the problem?
3. What are all the possible solutions of the problem?
4. What solution do you suggest?
My associates rarely come to me now with their problems. Why? Because they've discovered that in order to answer those four questions, they have to get all the facts and think their problems through. And they've done that, they find in three-fourths of the the cases they don't have to consult me at all because the proper solution has popped out like a piece o fbread popping up from an electric toaster. Even in those cases where consultation is snecessary the discussion takes about one-third of the time formely required because it proceeds along an orderly, logical path to a reason conclusion."
- Dale Carnegie. Crescent News (1944). How to Stop Worrying and Start Living.
- https://www.youtube.com/watch?v=fKzlc_N2yxw (01:07:50 - 01:09:53)
Comment#: 00014
Date: 2023-08-11
User: Radim
"Basic techniques in analysing worry:
Rule 1 - get the fact. Half the worry in the wold is caused by people trying to make decisions before they have sufficient knowledge on which to base a decision.
Rule 2 - after carefully weighing all the facts come to a decision.
Rule 3 - once a decision is carefully reached, act, get busy carrying out your decision and dismiss all enxiety about the outcome.
Rule 4 - when you or any of your associates are tempted to worry about a problem, write out and anser the following questions:
a) What is the problem?
b) What is the cause of the problem?
c) What are all possible solutions?
d) What is the best solution?"
- Dale Carnegie. Crescent News (1944). How to Stop Worrying and Start Living.
- https://www.youtube.com/watch?v=fKzlc_N2yxw (01:12:50 - 01:13:50)
Comment#: 00015
Date: 2023-08-17
User: Radim
Why is there never enough time to do it right the first time, but always enough time to do it over?
"The saying "There's never enough time to do it right the first time, but always enough time to do it over" reflects a common observation about human behavior and project management. It suggests that people often rush through tasks or projects initially, hoping to save time and effort, but end up making mistakes or producing subpar results. As a result, they eventually need to invest more time and resources to fix those mistakes or redo the work properly.
There are several reasons why this phenomenon occurs:
1. Underestimation of Complexity: People might underestimate the complexity or difficulty of a task or project at the outset. This can lead to inadequate planning and allocation of resources, resulting in mistakes or oversights.
2. Pressure to Meet Deadlines: There is often pressure to complete tasks or projects quickly to meet deadlines. This can lead to shortcuts being taken or important steps being skipped in the interest of saving time.
3. Lack of Attention to Detail: When rushing through a task, individuals might not pay enough attention to details, leading to errors that require corrections later.
4. Overconfidence: Sometimes, people might overestimate their abilities or knowledge, leading them to believe they can complete a task quickly without proper preparation or diligence.
5. Incomplete Information: In some cases, tasks or projects might be started without having all the necessary information or requirements. This can lead to incorrect assumptions and decisions.
6. Limited Resources: Constraints on resources such as time, money, or manpower might force people to cut corners initially, with the intention of fixing things later when more resources are available.
7. Learning Curve: Sometimes, tasks involve new skills or technologies that individuals need to learn along the way. Initial attempts might be suboptimal as people are still acquiring the necessary expertise.
The saying serves as a reminder that investing the necessary time and effort upfront to do a task properly can save more time and resources in the long run. Proper planning, attention to detail, and thorough execution can help prevent mistakes and the need for redoing work.
However, it's worth noting that the saying is not universally true. In some cases, rushing through tasks might yield acceptable results, and redoing work might not be necessary. It all depends on the nature of the task, the level of expertise involved, and the specific circumstances."
- https://chat.openai.com (Why is there never enough time to do it right the first time, but always enough time to do it over?)
Comment#: 00016
Date: 2023-08-18
User: Radim
"Don't dig deep into anything because it costs us money. Just pretend that we are experts and hope that the others gets the chestnuts out of the fire."
- unnamed user (own experiences leading to this ironic statement)
Comment#: 00018
Date: 2023-09-11
User: Radim
Does it make sense to think about digitalization if we don't see any use case?
"If you don't see any practical use case or clear benefit for digitalization in your specific situation, it may not make sense to pursue it blindly. Digitalization should always align with your organization's goals and needs. Here are some considerations:
1. Assess Business Objectives: Start by identifying your organization's objectives and challenges. Digitalization should align with your strategic goals, whether it's improving efficiency, reaching new markets, enhancing customer experiences, or reducing costs.
2. Customer Demands: Consider whether your customers or clients expect or would benefit from digital solutions. If there's no demand for digital services, investing in them may not provide a return on investment.
3. Competitive Landscape: Analyze your competition. If your competitors are effectively utilizing digital technologies to gain a competitive advantage, it might be necessary to explore digitalization to stay relevant.
4. Cost-Benefit Analysis: Conduct a thorough cost-benefit analysis to determine if the potential benefits of digitalization outweigh the costs. If the investment doesn't offer a reasonable return, it might not be justified.
5. Resource Availability: Evaluate whether you have the necessary resources, including financial resources, technical expertise, and staff training, to implement and sustain digital solutions effectively.
6. Future Growth: Consider the scalability of your organization. Even if you don't currently see a clear use case for digitalization, it's essential to think about your organization's future growth and whether digital technologies could play a role in that growth.
7. Technology Trends: Stay informed about industry trends and emerging technologies. While there may not be an immediate use case, technological advancements could create new opportunities down the line.
8. Customer Feedback: Engage with your customers or stakeholders to gather feedback on their needs and preferences. They may provide insights that could uncover potential use cases for digitalization.
9. Pilot Projects: Instead of a full-scale digital transformation, consider starting with smaller pilot projects to test the waters and assess the feasibility and impact of digital solutions in a controlled environment.
10. Consult Experts: Seek advice from digital transformation consultants or experts in your industry. They can provide insights into potential use cases and help you determine if digitalization is appropriate for your organization.
In some cases, it may indeed be the case that digitalization doesn't make sense for your organization at a given time. However, it's essential to regularly revisit this assessment as technology and business landscapes evolve. What might not be relevant today could become essential in the future. Ultimately, the decision to pursue digitalization should be guided by a thorough understanding of your organization's unique needs and circumstances."
- https://chat.openai.com (Does it make sense to think about digitalization if we don't see any use case?)
Comment#: 00019
Date: 2023-09-13
User: Radim
Often the person who knows the answer or the right way is closer than you think. All you have to do is ask.
Comment#: 00020
Date: 2023-09-15
User: Radim
Complaints and identified problems are good sources of innovation.
Comment#: 00021
Date: 2023-09-27
User: Radim
"By continuously improving the design of code, we make it easier and easier to work with.
This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently add new features.
If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code."
- Joshua Kerievsky. Addison-Wesley (2004). Refactoring to Patterns.
Comment#: 00022
Date: 2023-10-04
User: Radim
"Never discourage anyone who continually makes progress, no matter how slow."
- Plato
Comment#: 00023
Date: 2024-03-25
User: Radim
Remove the "ballast" from the program!
Only include things in the program that are really needed. Unnecessary parts of the code in the program become obsolete, untested, raise unnecessary questions and are a source of ambiguity.
Sometimes it is a good idea to try more than one way in practice to find out which way is the best. However, once we have decided on a particular approach, it is important to consolidate our methods and remove the outdated ones. By removing "ballast" from the program, we eliminate potential sources of confusion and improve the overall quality of the code.