A fixed-price project almost always come with a deadline. How can Developers estimate and promise in the contract how long a project is gonna take, before the project even starts? And more importantly, how Developers can keep that promise?
The bigger the project, the more difficult it becomes.
There are many advices on how Developers can keep deadline promised, eg. include extra buffer days when estimating, or if the project is already in progress, add extra developers when urgent, or negotiate new deadline.
Most of these advices are not time and cost efficient, either for the Developer, or for the Client, or both.
We might think that the main cause is inaccuracy in estimating a project, because forecasting how long a project takes is nearly impossible. But that might not be the case. A Developer can estimate a project accurately for proposal, but the project still has a large probability of delay, for many reasons (such as unexpected absencies), the most important of which is miscommunication / misunderstanding of Client’s wants.
How many times a Developer get a vague spec in RFP, and as the project being developed and progress is shown to Client, the Client notices things that are missing, or that are not exactly what they envision, so the Developer has to make modifications?
Getting a vague spec is a given. Developers have to understand. Furthermore, I have come to learn that the best ‘specification’ for Developers is a complete prototype of the software (this includes database design, test plan, and staging server set up).
Prototype is written in a code framework, with finalized HTML, and clickable as if it’s the real software. We should be able to use it for demo / presentation purpose. Test plan is a simple Excel file, with complete user test cases to go through when testing.
Building prototype before the project starts actually saves time. Our project manager and his team can just develop the software with the most familiar and detailed ‘specification’ he can expect. And it takes the bulk of time necessary for requirement gathering outside project time. And it greatly minimizes change requests from Client.
My conclusion is, both Clients and Developers should always try to make time to build prototype before actually starting a software project, because it benefits both parties, and maximizes chance to achieve the deadline promised.