It is tempting to start a project immediately without having requirements or a definition of Quality. However, I've done it myself quite often in the last two decades. There was a common problem in these projects; since nothing was defined, the result was unpredictable and heavily influenced by the conditions later. I've learned a lot from those projects.
Requirements and Quality are critical to avoid problems later.
Unhappy clients, technical debt, wasted budget, and overextended project duration are expected outcomes when working unprepared. In worst-case scenarios, the product is broken after release.
All of the results mentioned above happened to me at least once. Fortunately, it happened only in projects where the definition of Quality and Requirements wasn't adequately made before the start of development.
Why did I write, fortunately? Because there's an easy way to fix it in future projects. And we are here to learn how to improve for the future.
Quality represents the requirement for the result.
Contrary to the belief that Quality should be as high as possible, with team members striving for the best imaginable outcome, this approach is only sometimes correct. Stakeholders define Quality based on the requirements and expectations of employees, clients, or users. Aiming for "infinite perfection" is impractical, as you'll inevitably encounter unforeseen challenges during development.
Over-investing time and effort can lead to overengineering your product while skimping on these resources results in underengineering. The key is to meet the defined requirements; that's when you achieve the intended Quality. In this context, completing the set requirements equates to perfection—it is precisely as it should be.
✅ Hitting the defined requirements means to meet the Quality. It's perfect, then. It's like it's supposed to be.
Define Quality yourself, not let the project do this for you.
When you don't take the responsibility to define the outcome initially, you accept the result as it comes. No matter what it will be. In basically every case, the result will be worse than the expectation; thus, the Quality necessary to satisfy your clients and employees wasn't met — You failed.
The team needs to know the requirements and Quality as well.
To fulfill the requirements, your team in development or other areas needs to know about the level of Quality they are aiming for. Don't blame employees for not delivering the grade when you haven't defined it beforehand. This is a responsibility on the strategic level of the company, for example, the CTO or Product Owner. Be an example and specify what you expect.
Involve stakeholders in the process of definition.
Do not define Quality only for yourself because you think you know what every colleague, client, or investor might expect. Your ideas of requirements may differ a lot. The more stakeholders are involved, the more deltas you might get. Even if you define Quality yourself and the project meets the Quality, it doesn't necessarily mean that you will meet the expectations and, thus, the requirements.
Be honest with yourself and the product.
Quality is not a magic wish list. Instead, it is like a Christmas wish list where you know the limits and what you can possibly find under the tree on Christmas Eve.
It is better to revise the requirements and the Quality several times than to set the bar too high and eventually fail with the product. You can always change and add to it later. Lowering the quality level may be better than saying, "We can do the impossible." But what happens when you realize you haven't made it? Is it worth it to risk failing only to try to get just a bit better?