> If I had my way, I'd only ever take cases where things had gone really sideways.
I like taking on projects like this. The client won't fight with you about your bill-rate because they've seen what the result of being cheap is. The bar is set pretty low, it's already screwed up, you can only make it better.
my experience is very different: often problem projects are in that situation because of problem clients. How do you work out the difference before committing?
edit: though I bet not dealing with clients that quibble about billing rates excludes lots who didn't learn their lesson the last time
I like to only commit to a short elaboration, several weeks of documenting the state of the current project and coming up with a plan to get it on track. I then offer the client the option of continuing, almost always at T&M at this point, or they can take my write up and shop it around.
The plan generally starts with a "stop all new work and stabilize" phase; getting code metrics and an idea of technical debt; fixing processes, builds, making sure testing and QA is in place; and so on before any new work is done. Any client that isn't willing to pay for these things is just replacing one bad implementer with another.
I like taking on projects like this. The client won't fight with you about your bill-rate because they've seen what the result of being cheap is. The bar is set pretty low, it's already screwed up, you can only make it better.