Honestly, that flow chart is simplified to the point that if that is really what is going on at your particular workplace, you either don't get anything done, or what gets "done" is poor quality and/or difficult to impossible to maintain.
What should happen at all stages are various code reviews and meetings with the client where, if they should change the requirements, are required to sign-off (with a physical, on-paper signature and date) on the changes, perhaps with the understanding that there would be time and cost increases which they -will- be billed for.
Furthermore, there need to be team code reviews, presumably to ensure that the code produced by all team members follows the company's (or team's) agreed-upon coding standards. It should be noted that if there are multiple teams in a company, that there is one coding standard for the company, regardless of which team is doing the coding - because in the future maintenance of the code-base is going to require clear and set standards - which of course also need maintenance, so it should be clear in the code which version of the standards are being used; sometimes in the course of a long project, it may be useful to refactor the code to use the latest standards as well.
These standards should emphasize upon a clear and concise method of coding, with strict formatting rules, variable naming conventions, and commenting practices (a doxygen-based commenting style can do wonders - especially for coding documentation). Failure to follow the practices as laid out in the convention should flag a return to the developer(s) involved, so that they can refactor the code to adhere to the standard and pass the review.
One thing I have found for maintainability of code: Consistent spacing improves readability. An extra space or line break, used consistently, can have a dramatic effect on the understanding of the flow of code. The compiler or interpretor isn't going to care in the majority of cases (Python may be an exception - but its strict rules on spacing and formatting will likely make the code more readable anyhow; anything extra likely won't break much if anything).
The key is "consistency" - all the rules in the world mean nothing if they aren't applied uniformly throughout a process.
Finally - I must interject one other thing I have noticed quite often as a professional software developer is this tendency in some organizations and by some clients to think that design doesn't matter; that software is somehow "magic". In some cases, it has felt akin to being asked by a client to build a skyscraper, but start the building of it from the 20th floor, with no plans. Rarely do such projects turn out to be successful; should they work at all, they likely resemble (internally, from a maintenance perspective) a building from Terry Gilliam's "Brazil", with about the same attendant level of maintenance ease.
Software should be architected; it should be engineered and designed. Ideally, solid frameworks and functionality should come first, with all testing done at these low levels to verify that the functionality is solid and won't cause the collapse of the edifice once it is completed. With such proper architecture, it should be possible to have a design from which pieces can be easily removed and recombined on other projects with little effort (indeed, in the Arduino world, this is the whole point, what with the various libraries and such). Code reuse should be paramount; however, in order to facilitate this, the interfaces to those reused objects should be clear, defined, and consistent across the code base (or at worst, within the library).
Logic flow of the entire process, whatever the process is, should be specified and "run" as a "simulation" by the entire team; this can be accomplished using nothing more than a lot of flowcharts and a whiteboard, some pencils and paper; parts could be augmented using a computer and other tools, but aren't strictly necessary. Indeed, depending on the process being studied, you might end up finding parts of it which are "assumed" and handled by humans - but not detailed in any actual part of the flow. Sometimes things like these are found during the conversion of a manual business process into an automated workflow; as you study and question the individuals involved, you sometimes find that they perform functions which are a part of the process, but aren't defined as such, but are needed to "smooth" the flow. Some of these can be automated, some can't - but they need to be taken into account in the entire process, because the rest of the process may rely on the success or failure of their output into succeeding stages.
Most of the time for many businesses (perhaps most, especially small businesses) these processes (whether internal, or of some software or such) are never defined or architected in some way, likely due to money and time. Somehow, things seem to work - until the burden to the system becomes so large that it fails. Then another bandaid is applied and its hoped that it fixes it, when the reality is that the entire process needs to be understood by people at both a macro and micro level.
/realized I'm rambling, so I'll stop here...