3 ms·
Explaining how you get buy in would be a much more interesting blog post. The person footing the bill usually wants some plan for reassurance sake. Something al
by nahname 14y ago
Explaining how you get buy in would be a much more interesting blog post. The person footing the bill usually wants some plan for reassurance sake. Something along the lines of, "Aha! Gotcha! You didn't do X! I'm not paying!"
- 13hours 14y agoI'll try to make the time to write up something. It's really a matter of explaining to them why our way of working ends up being faster and less expensive than the flat fee way. With our way of working, there's an assumption of trust, and we keep that trust through visibility of our progress. That way we share risk, and if we can share risk with the client, we can charge less, because we don't have to build in such a big margin in the price to cover our risks.
- nahname 14y agoCouple pain points from experience: Estimates in $$$ desired before start -> Leads into defining a complete feature set -> Desire for all estimates in time for all work (BS number, always) Guarantees on what will be delivered -> Getting the client on board with paying for time vs. paying for features -> Offer minimal feature set + what we can do? -> Dealing with scope creep Require clients time -> Feedback -> Showcases -> Many A) or B) given B) is 10 times more expensive
- mseebach 14y agoClients who think like that will find a way anyway, process or no process. They are toxic and are to be avoided at all cost.
- nahname 14y agoTry this one then, "Hey, we love what you are doing, but saw this new feature and think it is really cool. We are not saying you have to add it, but it would really make our day if you did..."
- mseebach 14y agoSpecifically, I was reacting to your "gotcha" client, the one that will even want to look for a way to not pay you. Of course, it's the nature of software projects to evolve like this over this, that is exactly the insight behind agile methodologies.