Project Idealism
Over the next few weeks I'll be announcing some changes I'm making with Ideal Project Group, many of which are based on the following question: "If software can be a service, how can a service company be more like software?" A key component of answering this question is to charge a flat monthly fee for my services (and the results they help produce), as opposed to charging for my time by the hour.
This change is significant for more reasons than just answering the question above, and I think they're important to address in more detail.
Your supply of time is unknown
For a long time, and up until very recently, I subscribed to and bought into the notion that "time is money". I've realized lately however that this thinking is flawed.
Time is a finite resource, of which we all have unknown quantities, and it is therefore impossible to value accurately.
The simple economics of supply and demand can't even work because the supply is unknown. To make up for this, we guess at how much time we have and live our lives accordingly. We certainly try to put a dollar amount on it, but it's never really correct.
Saying "time is money" improperly devalues time by an extraordinary amount, as it's the one thing you can't make more of. You can make money, along with a host of other things, but you cannot make time.
Hourly pay penalizes efficiency and rewards inefficiency
Hopefully, as we become better at what we do, we also become more efficient. And if we're good, whatever it is we're producing is also of higher quality. The effect is we can produce better results with less effort and/or time being spent on a particular task.
This should be awesome, but if you're paid hourly, you're actually being penalized. You now need to continue spending the same amount of your one unknown resource just to remain in the same spot financially, even though you may have produced the same product/result.
Hourly pay is risky for people that are paying people hourly as well though. If you're paying someone to do a job, but paying them hourly, if they're prone to making mistakes or are just simply slow at what they do, you're being penalized. It's crazy, but there are multiple people I know who have told me stories of companies that let go of one person making $100/hr and ultimately ended up replacing them with 3 people that are paid $40/hr.
Value should be placed on what you help produce
The answer to all of this is to charge (and pay) for services the same way SaaS companies charge for their services. A flat monthly fee. By doing this, you place the value of your service where it belongs, on your results.
A month is still a unit of time of course, but instead of charging for the time itself, you begin charging for what you produce during a given time period. I think this is a world of difference.
If you're paying someone this way, then you don't need to care how much time they spend on whatever it is their working on. You only need to know that they produced what you were expecting and feel that you paid a fair amount for that result. If they were slow and it took them 50 hours a couple weeks you don't get penalized.
If they were fast, efficient, and produced a quality result, then they get a little more time to do whatever it is they please.
Aligned Incentives
The idea behind all this is that the incentives are more properly aligned. The person buying the services is protected a little more because they're buying a result, not a unit of time. And the person who's producing is being rewarded, as they should be, for doing quality work in a shorter period of time. Again, they're being paid for what they produce, not a unit of time.
This is not fixed bid
The last point I want to make about this is that it's not the same as fixed bid pricing. A lot of contractors are scared of fixed bids, with good reason, because it requires that everything about a project to be known up front which is pretty much impossible.
Instead, this pricing model simply embraces the new reality of software development (and other types of projects) by allowing two parties to agree on what the results of one's efforts should be over the course of a month and a dollar amount that those results are worth.
There are a host of other reasons I am moving to this model, including the way in which it helps provide greater clarity for a project team while also making it more flexible, that I intend to write about as well.
It is sufficient to say in the meantime however that I think this may very well be the future of the entire professional services industry, and it's the direction I'm taking my company. If you're intrigued, I hope you'll consider joining me.
This change is significant for more reasons than just answering the question above, and I think they're important to address in more detail.
Your supply of time is unknown
For a long time, and up until very recently, I subscribed to and bought into the notion that "time is money". I've realized lately however that this thinking is flawed.
Time is a finite resource, of which we all have unknown quantities, and it is therefore impossible to value accurately.
The simple economics of supply and demand can't even work because the supply is unknown. To make up for this, we guess at how much time we have and live our lives accordingly. We certainly try to put a dollar amount on it, but it's never really correct.
Saying "time is money" improperly devalues time by an extraordinary amount, as it's the one thing you can't make more of. You can make money, along with a host of other things, but you cannot make time.
Hourly pay penalizes efficiency and rewards inefficiency
Hopefully, as we become better at what we do, we also become more efficient. And if we're good, whatever it is we're producing is also of higher quality. The effect is we can produce better results with less effort and/or time being spent on a particular task.
This should be awesome, but if you're paid hourly, you're actually being penalized. You now need to continue spending the same amount of your one unknown resource just to remain in the same spot financially, even though you may have produced the same product/result.
Hourly pay is risky for people that are paying people hourly as well though. If you're paying someone to do a job, but paying them hourly, if they're prone to making mistakes or are just simply slow at what they do, you're being penalized. It's crazy, but there are multiple people I know who have told me stories of companies that let go of one person making $100/hr and ultimately ended up replacing them with 3 people that are paid $40/hr.
Value should be placed on what you help produce
The answer to all of this is to charge (and pay) for services the same way SaaS companies charge for their services. A flat monthly fee. By doing this, you place the value of your service where it belongs, on your results.
A month is still a unit of time of course, but instead of charging for the time itself, you begin charging for what you produce during a given time period. I think this is a world of difference.
If you're paying someone this way, then you don't need to care how much time they spend on whatever it is their working on. You only need to know that they produced what you were expecting and feel that you paid a fair amount for that result. If they were slow and it took them 50 hours a couple weeks you don't get penalized.
If they were fast, efficient, and produced a quality result, then they get a little more time to do whatever it is they please.
Aligned Incentives
The idea behind all this is that the incentives are more properly aligned. The person buying the services is protected a little more because they're buying a result, not a unit of time. And the person who's producing is being rewarded, as they should be, for doing quality work in a shorter period of time. Again, they're being paid for what they produce, not a unit of time.
This is not fixed bid
The last point I want to make about this is that it's not the same as fixed bid pricing. A lot of contractors are scared of fixed bids, with good reason, because it requires that everything about a project to be known up front which is pretty much impossible.
Instead, this pricing model simply embraces the new reality of software development (and other types of projects) by allowing two parties to agree on what the results of one's efforts should be over the course of a month and a dollar amount that those results are worth.
There are a host of other reasons I am moving to this model, including the way in which it helps provide greater clarity for a project team while also making it more flexible, that I intend to write about as well.
It is sufficient to say in the meantime however that I think this may very well be the future of the entire professional services industry, and it's the direction I'm taking my company. If you're intrigued, I hope you'll consider joining me.