In general, I first try to find out what the solution is worth to the customer. This is not feasible in every case but often it's possible to arrive at a rough estimate as to how much additional revenue a solution could potentially generate (preferably) or how much money it would save the customer. It can also mean trying to find out what the customer's most urgent or painful problems are and what the result of alleviating these problems would be.
There are different ways of eliciting this kind of information. Learning to ask the right questions and then listen intently to what the customer has to say is key. There are more methodical approaches such as the Socratic method, which basically is a questioning technique that prompts the person you're talking to consider a matter from different perspectives in order to independently arrive at a conclusion.
Knowing about the benefit of a solution is tremendously useful because it allows you to anchor your price tag to customer value.
While this does not directly provide you with an easy way to estimate the cost of a project it achieves something far more important: Turning software from a cost centre into a profit centre and measuring projects in terms of something the customer actually cares about rather than your time.
As for estimating the actual cost for creating the proposed solution there unfortunately probably is no other way than by experience. However, the risk of giving an overall estimate that's way off can be mitigated by splitting a project into smaller components and deliverables if applicable.
Another approach that's particularly useful for projects of a more exploratory / agile (in the true sense of the word rather than the bromide it's become in many contexts) nature is setting a weekly or monthly budget. Rather than saying "You'll have X by this date." although neither you nor your customer know what X exactly is at that point this frames a project in terms of insights and incremental improvements generated along the way.
There are different ways of eliciting this kind of information. Learning to ask the right questions and then listen intently to what the customer has to say is key. There are more methodical approaches such as the Socratic method, which basically is a questioning technique that prompts the person you're talking to consider a matter from different perspectives in order to independently arrive at a conclusion.
Knowing about the benefit of a solution is tremendously useful because it allows you to anchor your price tag to customer value.
While this does not directly provide you with an easy way to estimate the cost of a project it achieves something far more important: Turning software from a cost centre into a profit centre and measuring projects in terms of something the customer actually cares about rather than your time.
As for estimating the actual cost for creating the proposed solution there unfortunately probably is no other way than by experience. However, the risk of giving an overall estimate that's way off can be mitigated by splitting a project into smaller components and deliverables if applicable.
Another approach that's particularly useful for projects of a more exploratory / agile (in the true sense of the word rather than the bromide it's become in many contexts) nature is setting a weekly or monthly budget. Rather than saying "You'll have X by this date." although neither you nor your customer know what X exactly is at that point this frames a project in terms of insights and incremental improvements generated along the way.