My OperaLet quality be the priority!
Tuesday, April 24, 2012 6:20:00 PM
In every software development project occurs a dilemma: time+cost vs. scope+quality. These parameters can be aligned in a Project Triangle, but for the purpose of this article I will reduce them to time vs. quality, as the other two can be considered derived from them - longer time inevitably means higher cost, while too small scope can result in less satisfactory total quality.
Time is the easiest factor to measure - one sets a deadline and the software must be delivered before this deadline.
Measuring quality is much more complex, subjective and intangible. To measure it well, one have to understand and compare a long list of needs of stakeholders and users with the planned functionality and how they relate to each other on a detailed level.
This causes project managers to focus on the most visible measure for the project to be seen as success or failure, which can be summed up as the following thinking approach:
In my professional experience, both as a business analyst and project manager, I tend to follow the latter rule. And with every project finished I am receiving confirmation that stakeholders and users are impressed with the outstanding quality, being easily forgiving even if the project sometimes took a bit longer than it was assumed to.
The point is - the moment of software delivery is temporary - everybody will forget about it once it happens.
There is one more catch here - if one wants to keep the deadline while sacrificing quality, there will be mistakes and overlooks made, which will brutally retaliate when the software is near to shipment. In the effect, the project manager is likely to hear from stakeholders that the product does not meet their needs and there will occur an unnecessary stiff atmosphere of scramble between the sides about what can be improved before the shipment to make the quality acceptable.
At the end of a day, from these reasons the project will slip by the time equal or even longer time than when it was done from the beginning with focus on quality. Moreover - in the other scenario the quality would be better, when the project was not done with too much hurry through most of its timeline.
The quality lasts forever and people will be impacted by it every single day. If they will be impacted positively, they will praise the software and its creators. Especially that there is a lot of poorly designed software they have to use everyday. So why not deliver something contrary to that, that will distinguish, fulfilling the needs in a superior way. I strongly encourage you to.
*To briefly mention, as the key to make a good software I consider deep and broad enough eliciting real needs of users and stakeholders, which includes understanding context of their needs to be able to advise them in the process. Also on the design and testing phase, one should be prepared to listen and implement various requests for changes. I will cover this topics in separate posts.
Time is the easiest factor to measure - one sets a deadline and the software must be delivered before this deadline.
Measuring quality is much more complex, subjective and intangible. To measure it well, one have to understand and compare a long list of needs of stakeholders and users with the planned functionality and how they relate to each other on a detailed level.
This causes project managers to focus on the most visible measure for the project to be seen as success or failure, which can be summed up as the following thinking approach:
Such approach puts quality on second place - the focus is to finish project on time. I boldly encourage you to reverse the thinking approach to:Make software in expected time within acceptable quality.
When you approach it this way, the time frame is still important, but you work with focus to deliver a really good* product and less pressure that you have to sacrifice quality to keep the target release date.Make software in expected high quality within acceptable time.
In my professional experience, both as a business analyst and project manager, I tend to follow the latter rule. And with every project finished I am receiving confirmation that stakeholders and users are impressed with the outstanding quality, being easily forgiving even if the project sometimes took a bit longer than it was assumed to.
The point is - the moment of software delivery is temporary - everybody will forget about it once it happens.
There is one more catch here - if one wants to keep the deadline while sacrificing quality, there will be mistakes and overlooks made, which will brutally retaliate when the software is near to shipment. In the effect, the project manager is likely to hear from stakeholders that the product does not meet their needs and there will occur an unnecessary stiff atmosphere of scramble between the sides about what can be improved before the shipment to make the quality acceptable.
At the end of a day, from these reasons the project will slip by the time equal or even longer time than when it was done from the beginning with focus on quality. Moreover - in the other scenario the quality would be better, when the project was not done with too much hurry through most of its timeline.
The quality lasts forever and people will be impacted by it every single day. If they will be impacted positively, they will praise the software and its creators. Especially that there is a lot of poorly designed software they have to use everyday. So why not deliver something contrary to that, that will distinguish, fulfilling the needs in a superior way. I strongly encourage you to.
*To briefly mention, as the key to make a good software I consider deep and broad enough eliciting real needs of users and stakeholders, which includes understanding context of their needs to be able to advise them in the process. Also on the design and testing phase, one should be prepared to listen and implement various requests for changes. I will cover this topics in separate posts.
