There is a famous tenet that applies to any project, be it tech or otherwise, although it has mostly been heard in the tech corridors for a while now.
If you want a speedy delivery, quality may not be optimal.
But, if the delivery needs to be stellar as well, costs will shoot up.
If you want to save on cost, it may take longer to deliver.
Basically, however you look at it, something’s got to give between cost, time and quality. Apparently, you can’t have all the three.
I beg to differ. It’s an old adage and many a project has been delivered and continues to be delivered in its guise.
I believe projects can and need to be delivered in earnest. In fact that’s the current market ask and if you do not respond to it, what you get to the market may be a tad bit too late to create any demand, for the market expectations have moved on a lot further due to the competition taking over.
Now, does speed really mean more cost? Not necessarily! It’s not about how complex the work at hand is, how enormous a job it is or how many resources will it consume. It’s about how well planned is execution, what kind of strategy and preparation have gone into the plan itself and what options are tapped to execute in an agile mode.
Also, does speed mean less optimal quality? And in order to ensure great quality, do you need to spend more money and need more time? I think that’s just regressive thinking.
Here’s a popular saying in the project management world, “Every birth takes nine months. Similarly, every project needs the time it deserves. You can’t deliver what takes nine months within a month just by adding more resources.”
I agree to the above to a certain extent. Throwing more resources at a problem doesn’t necessarily solve it. However, there is a threshold after which certain changes can be brought about, either by induction of the right resources, parallel processing where possible or taking productivity to a higher level by managing the team mechanics to deliver.
Speed to market or deliver doesn’t mean less optimal quality or more cost at all. When it comes to quality, how that’s perceived within the team at work and how it’s executed upon become very crucial. If there is a professional quality assurance team in place to handle that function for a project, then, it’s only viable if the scale of the project demands it. In such situations, it’s important to ensure that the whole project team clearly understands the precise objectives of the quality assurance team. From requirements gathering to the architecture design, every function has to be focused on simplicity and speedy delivery. Developers have to be on top of their game to ensure cutting edge code is going out and the quality is checked within their realm, before it goes out the door. QA should be more focused on functional review to meet market needs and push the envelope for a speedy delivery. If the team works in this fashion, orchestrating in high productivity modes, miracles are possible where costs are kept under control, and a high quality product reaches the market on time.
However, the truth of the matter is that, in more cases than not, the quality assurance team ends up being a gatekeeper for the work churned out by the development team and that’s where the issue rests. A top-notch development team should not need a quality assurance team behind its heels cross-checking each line of code being churned out. The development team should be accountable for what they deliver and should be proud of the job they do sans the quality team. The quality team, as I said before should be just focused on ensuring the market gets what it demands. In fact, their work should be non-existent.
And the day, we get there with minimalistic or non-existent quality teams, would be the day where cost and time also do not have as much bearing on projects and what gets delivered to the market. The best part, neither the creator nor the consumer would have any apprehension as to the product that has been put out in the market.
Image Courtesy of FreeDigitalPhotos.net