Requirements: Aim to hit the expected Quality, not higher or lower.
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 all of these projects; since nothing was defined, the result was unpredictable and heavily influenced by the conditions later. I’ve learned from those projects a lot.
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’ve written, 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.
Some may think Quality must be as high as possible, so they expect everyone in the team to aim as well as possible to reach the best outcome achievable, so Quality must not be defined. Just do the best possible, right?
But that’s a wrong interpretation. Instead, Quality is a definition defined by the stakeholders to meet requirements and demands from employees, clients, or users. Quality doesn’t mean 100% perfection since you cannot reach this level. You will discover things during the development that no one could have foreseen initially.
Quality doesn’t mean 100% perfection
Define Quality yourself, not let the project do this for you
When you don’t take the responsibility in the beginning to define the outcome, you end up accepting 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. Be an example and specify what you expect.
Don’t blame employees for not delivering the grade when you haven’t defined it
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, 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?
A product does not end with the project. There is always room for improvement later; never forget that!
If this was an interesting article to read, consider to subscribe for my CTO Newsletter on https://adrianstanek.dev
