Enough quality - what's that?

This week we experience a big IT scandal in Norway. The central system Altinn went down because of the big load that came because of the Tax return for wage earners. Several hundred thousand users tried to check there tax return, this was too much for the system, it went down and it took several days to get it fully functional again.

Why did this happen?

• Of course there is no simple answer to that, but I would like to focus on one thing:

QUALITY

• How do you measure that a system has the correct Quality? 
• How do plan for the correct quality?

This has something to do with the complete project process. It's not possible to ensure the correct quality through testing alone or through requirment's alone. You need a focus on quality from start to finish.

The last year as a project manager/scrum master for the software development in the Norwegian national eID program has given me the possibility to learn a lot about quality.
We have spent a lot of time, resources and money on this subject and it's now not an exclusive focus on delivering functionality on time.
We strive to make the process, product and deliveries better for each iteration. We strive to deliver quality in every sprint. We strive to make sure that the product owner, architects, developers and testers has the same understanding on what's the correct quality.

I've always learn that as a project manager your responsible to deliver the correct functionality on time within the budget. But I'm not agreeing any more.
I proclaim that as a project manager you should be responsible for:

Delivering the correct quality on time within budget.

• It's better to lose out some of the functionality than to deliver a bad product.
• It's easier to add functionality later, then to improve and fix a product that lacks quality.