Thanks for your comment. I see that you’ve probably worked on a few happier proposals than me. It always feels like the times I’ve worked on offers, it has spiralled into a fear-driven hole of documentation. 90 % of what paperwork I’ve helped create could easily have been thrown away without hurting the final proposal. It’s mostly bull* anyway. I’m happy to hear that your experience is different.

I agree that your initial velocity cannot be applied blindly to create estimates, but it’s provides a better foundation than any other estimation process I’ve seen practiced. At any rate, my hope is to move from the mindset of estimates to that of forecasts.

My goal is to open the door and estabilish a dialogue with the customer. In my experience, no real conversation starts when nothing is developed. The paperwork only creates good breeding ground for veiled misunderstandings.

Velocity on some selected use cases only tell you … the velocity on those use cases. The problem is finding how many function points (or whatevers) there actually are in the specification, and velocity won’t help you with that.

Usually you are supposed to supply a complete proposal for the whole spec, not just implement some selected use cases. So you still have to write the complete proposal, the “paperwork” that is supposed to be replaced by the mockup. In a bid you might include som “sugar”, like screenshots and a detailed narrative on selected parts of the solution, but that doesn’t take more than a day or two. This could be replaced by a mockup, but you might still want to write a description to explain to the customer how great this mockup is.

I just don’t see how a mockup/proof-of-concept of part of the solution can help answering the questions asked by the customer in a fixed-price bid.

Thanks for your comment. I see that you've probably worked on a few happier proposals than me. It always feels like the times I've worked on offers, it has spiralled into a fear-driven hole of documentation. 90 % of what paperwork I've helped create could easily have been thrown away without hurting the final proposal. It's mostly bull* anyway. I'm happy to hear that your experience is different.

I agree that your initial velocity cannot be applied blindly to create estimates, but it's provides a better foundation than any other estimation process I've seen practiced. At any rate, my hope is to move from the mindset of estimates to that of forecasts.

My goal is to open the door and estabilish a dialogue with the customer. In my experience, no real conversation starts when nothing is developed. The paperwork only creates good breeding ground for veiled misunderstandings.

Velocity on some selected use cases only tell you … the velocity on those use cases. The problem is finding how many function points (or whatevers) there actually are in the specification, and velocity won't help you with that.

Usually you are supposed to supply a complete proposal for the whole spec, not just implement some selected use cases. So you still have to write the complete proposal, the “paperwork” that is supposed to be replaced by the mockup. In a bid you might include som “sugar”, like screenshots and a detailed narrative on selected parts of the solution, but that doesn't take more than a day or two. This could be replaced by a mockup, but you might still want to write a description to explain to the customer how great this mockup is.

I just don't see how a mockup/proof-of-concept of part of the solution can help answering the questions asked by the customer in a fixed-price bid.