I checked out your post and you’ve got some great thoughts there. I’ve been given some of those BDUF software projects in the past and they’re definitely painf

I checked out your post and you’ve got some great thoughts there. I’ve been given some of those BDUF software projects in the past and they’re definitely painful - if not impossible to deliver. The only reasons they were successful were that the clients were enormous and ultimately paid for us to keep modifying spec documents as we went along. We planned for that going in and the fixed price agreement was loaded up with all kinds of contingency (read, lots of extra cost to the client). In the end, it cost them more and delivered less. Sure, they got a great “as-built” plan showing exactly where things were different from the original blueprint - but having a great looking plan wasn’t the real goal. The sad part was that we could have done so much more feature development with that extra money. Early stage entrepreneurs (which is who the post is about) are different. They don’t have the time or the money for that kind of inefficiency. They need an app that works. Now. We do some up front work with them to lay out the flow of the major features. Then the client prioritizes them and we start with the most important thing first. We push new code very regularly and they tell us when they think it is working well enough for us to go to the next feature. Not sure that would be realistic in a fixed price model. I like your final point in the BDUF post - that the development of the software is organic and ultimately determined by the process. Sounds like a great rationale for T&M vs. fixed price!