For each project we decide the priority order for the following:
Feature
Schedule
Quality
I will refer to choice of the first as "fixed", the second as "managed", and the third as "mitigated".
This boils down to each project being one of: FSQ, FQS, SFQ, SQF, QFS, or QSF.
NOTE: Not choosing an order for these trade-offs will lead to a lot of flip-flopping as it is effectively allowing the priorities to change on a whim. By picking, and communicating, an order we generate alignment across the team and hopefully avoid stakeholder confusion over why a project has made certain decisions that seem inconsistent with other projects and technology goals. As the old saying goes: If everything is top priority, nothing is top priority.
Fixed really should mean fixed. Not: we can wiggle a bit, or fudge it. You select which of F, S, or Q is the fixed priority for your project based on business costs, not hope and wishful thinking. Ask some hard questions, like:
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.
If unsure, get business metrics to validate your choice of which one to fix, and 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 the business, or default to Quality as that tends to reduces downstream costs (bugs).
This means you must have to have all the functionality (features) for the project before you can ship. Planning effort to minimize the feature set has been done and stakeholders agree the feature set can not be cut further and still result in a meaningful product.
This means you must ship on a specific date. This is usually tied to external events, conferences, holidays, etc. Missing the date is worse for the business than cutting scope or compromising quality.
This means you must not accept shipping anything that does not meet you quality bar. If the product fails to work correctly, or garners bad product reviews, it would severely impact the business.
Managed means you're going to actively attempt to meet the requirements but will communicate with, and involve the stakeholders whenever it looks like the requirements will not be met.
Features may be cut completely, or partially implemented. We can reasonably predict which features are likely to be affected and have time to plan for the impact of cutting or changing them. The impact of delaying delivering features to later has lesser impact to the business than one missing schedule (if S fixed) or lowering quality (if Q is fixed).
The business can accept some schedule flexibility if communicated early. Tracking of progress and regular communication with stakeholders is required to allow other areas of the business to plan around the eventual completion of the project.
The quality bar can be compromised some, but in general everything needs to be good enough or fixable without completely redoing work.
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. You'll drop nearly all features, ship eventually, or accept lots of bugs; potentially needing to completely rewrite whole sections of the product later.
Each of these rankings has its place, and projects may change from one ranking to another over time, as business needs change. Communicating changes to these priorities to all stakeholders is vital in preventing problems with a project. Ensuring consistent (and repetitive) messaging around the order of priorities will go a long way to helping prevent frustrations and misunderstandings that waste time and distract from doing actual work on 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 single feature), 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 delivery date, or having extremely sensitive time to market requirements (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 features 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 due 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 and 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, it should lead to the best possible result, but it may take a very long time to get there.
QSF is the reasonable compromise. Things must work (high quality), and something must ship regularly, but exactly what ships is flexible. This is often the best model to use for most businesses, as it focuses on making a few things very well, and delivering what has been completed to customers before starting on new features. Most customers that see high quality product being released on a regular schedule are then willing to wait a bit longer for features to come down the pipe.
Our preference is to default to QSF. Work on one feature at a time, build it to the highest quality, automate the testing, and get it into customers hands in a reasonable amount of time.