In every project you have to decide the priority order for the following:
Whichever you choose as the first is "fixed", the second is "managed", and the third is "mitigated".
Fixed feature means you have to have all the functionality (features) for the project before you can ship. Fixed schedule means you have to ship on a specific date. Fixed quality means you won't accept shipping anything that doesn't meet you quality bar.
Fixed really should mean fixed. Not we can wiggle a bit, or fudge it. You select your fixed priority for your project based on business costs, not hope and wishful thinking. Will shipping a week late cost you anything contractually? Will a missing feature cost you sales? How many sales? Will a bug cost you customers? Will the support cost of the bugs cost you more than lost sales from missing features? etc. Get metrics and prove that your choice was the right choice, or figure out how next time you can choose better. If there is no reason to have one of F,S, or Q fixed then you probably should be working on a different project that matters more to your business.
Managed means you're going to actively attempt to meet the requirements but will communicate with and involve (manage) the stakeholders whenever it looks like the requirements (F, S, or Q) will not be met.
Mitigated means you're going to do you best to ensure you do as little long term damage as possible by relegating something to the bottom of the priority list.
This boils down to each project being one of: FSQ, FQS, SFQ, SQF, QFS, or QSF. Each of these rankings has there place, and your project may change from one to another over time as your business needs change. Communicating changes to these priorities to all stakeholders is vital in preventing problems with a project, and ensuring a consistent message around these priorities will go a long way to helping prevent frustrations and misunderstandings that waste time better spent building the project.
FSQ typically arises from projects with a contractual obligation to deliver a fixed set of well understood features by a deadline. The product requires all features in the project to be useful (e.g. a first release with minimal set of features) and thus features out rank schedule. Quality could be last because the project is only a proof of concept for a demo that will garner more funding, or a cost analysis has shown that time to market is more critical than the support costs incurred by lower quality which will be mitigated with follow on patches.
FQS typically arises from projects with minimal feature sets (perhaps as low as one) where schedule pressure is low and the intent is to have a follow on project to correct issues. E.g. prototypes and canned demonstrations.
SFQ typically arises from projects with a contractually fixed deliver date, or an extremely sensitive time to market requirement (e.g. a competitor is going to release the feature before you can scoop the market). Missing the date will cost the company dearly, or having the feature after the date will produce much less money. (e.g. rolling out a website for a related event after the event has happened.) Quality is mitigated by follow on patching and support costs do to bugs is expected to be low.
SQF can arise from mistrust between parties. The consumer of the project wants too see regular high quality progress at at least some features. Many projects may start here until enough trust is established to move to QSF.
QFS is the artisan approach. Build the best you can and worry about shipping it when it's done. If you can get away with it should lead to the best possible result, but it may take a very long time to get there. Having a client with lots of patience and a willingness to pay by the hour helps.
QSF is the reasonable compromise. Things must work (high quality), and something must ship by a certain date, but exactly what ships is flexible. This is often the best model to use for most business as it focuses on making a few things very well and delivering them to customers. Most customers that see high quality product coming from a business on a regular schedule are then willing to wait a bit longer for features to come down the pipe.
My personal preference if towards QSF. Work on one feature at a time, build it to the highest quality, and get it into customers hands in a reasonable amount of time. Measure time from a feature being requested to when a customer actually has it in hand and you'll start to be able to predict your releases reasonably well because you only work on a single feature at a time. This is basically what Kanban ends up doing.
Software Management >