3 ms·
> 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 y
by gav 12y ago
> 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.
- x0x0 12y agomy 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
- gav 12y agoI 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.