Another emotional and tense meeting, this time on how to "get back on track " for the now important project - which is already weeks past its planned completion date. Does all of these scenarios sound familiar? What I'm trying to say is that project overdue is a common occurrence in any industry. In the software industry, however, this seems to be more likely to happen.
How did we get to this point? This also starts from where our dreams begin. All starts with energy and energy. A beautiful idea, this time we swear we will never repeat the mistakes of the last time, we will not make the mistakes of the last time. This time, we told ourselves that the plan this time will be executed "correctly", not to save trouble, and not to change halfway. There are often times when we feel like the dream is going in the right direction, the design is successful, everyone is upbeat and the reviews are good. Then, nightmares begin to come, as various blows begin to appear.
The easiest part of the system takes all of your time. A slight oversight can mean that a series of simple assumptions no longer hold. Incorrect assumptions have a knock-on effect, leading to a dead end for system design. Design modifications are required to correct these problems. The hope remains that with enough sleepless nights and weekend work, we can still get the project "back on track."
The landmark prototype was finally born, and everyone was confident that the prototype was doing so well. Outsiders do not know how many all-night hard work this is in exchange for. Soon, "small needs" began to appear. The usual rhetoric starts with "What's so hard about this?" or "It's really easy!", or more classically, "If we could...it would be amazing". Through the exchange of opinions, these new small functional features not only look "simple", but actually can be done. Of course, you would never say no, however, the tragedy of history is about to repeat itself.
Now that you and your team are finally back in the real world, check out these new requirements again. After taking a closer look at these "very simple functional features", it suddenly dawned on me that they were not as simple as they first sounded. But it's too late, you've already promised these new modifications.
"Bah!" Your mailbox notifies you of a new email, adding fuel to the fire that the sale has already promised the customer. Sales talk to customers about these "simple" new features, and customers come up with more "simpler" new features they want. The sale is full because these new demands sound simpler than those at first. 
Programmers, please don't
stop
, don't do it. During the 80's and 90's there was a very popular campaign slogan: " Just Say No ", which was used to promote keeping kids away from drugs. Whether you remember the movement or not, its message is very powerful. Similarly, we should use the same tone to face the problems we encounter.
Of course, I'm not urging a resistance to any change in requirements. From my point of view, any new additions that require coding development I'll delineate them with a red line. But modifications such as interface or front-end content are not included.
Any new demand must be determined before accepting the corresponding sufficient additional time. The default internal response to a new requirement should be "just say no". Of course, this reaction need not be superficially exposed and can be achieved with appropriate diplomacy. Any "requirements change" that was not originally planned should be considered carefully on the project start date. Any later added features must adhere to this principle. With this principle it's easy to say "no". Because this is a ruler, everyone understands that new features added later will take extra time. Put that pressure on the client and boss to either delay the completion date or drop another feature for replacement.
Conclusion
There are various reasons why a software project may not be completed on time. Projects progress slowly, and programmers continue to work under high pressure, making it more difficult to estimate project development time. Programmers should be mentally prepared, and new demands will definitely appear. Keeping "just say no" in mind will prevent you from saying "yes" when you open your mouth. Playing with a gun is very dangerous. Putting a safety device on the gun can at least prevent you from hurting your feet.