I'm going to be honest. I'm expensive. But I can also save you a lot of money. Sounds like a contradiction, right? Let me explain why I say this. For starters, I charge $150 per hour for the time I spend on your project. This includes Software Consulting, Project Management, Business Analysis, Software Design, System Architecture, Phone Calls, Meetings, Training, etc. So how exactly do I save you money? Let me give you an example. A recent client approached me to build a pretty unique (and complex) website. This site would have taken thousands of hours (and many months) to build, had we done it from scratch. But I was able to mash up several related technologies to create a cutting-edge, cost-effective solution. The client got a mature product in less time, and for less money. It isn't just about what you pay. It's also what you get in return - and how quickly you get it.
Basically, all rates are not created equal.
Okay, for all tasks completed by our offshore team, we charge $35 per hour. This covers programming, testing, and other ancillary tasks. For onshore programmers we charge $75 per hour. This would include our onshore experts in RPG, SQL Server, AS/400, etc. So you won't be paying $150 for every hour spent on your project.
You might wonder why I don't program the entire application myself? Honestly, I'm too expensive. I wouldn't hire me to do all the programming. At least not for most jobs. Besides, my talents are best utilized helping you define and design the best solution, and then making sure the coding is done correctly. That's why I personally review all source code and program documentation, and test the application before you see it. I also manage the entire project, from concept through completion. And yes, occasionally I do get my hands dirty coding.
About Software Pricing
Let's be honest. Custom software is expensive. In reality, there just aren't that many people who can successfully define, design, develop and deploy complex software applications. Most companies rely on junior developers and mid-level personnel to keep costs in line, but more than likely your project is going to require much more than that. But how exactly is the cost of your project determined, and more importantly, how can you budget for it?
In the 20 years that I've been building custom software, I have rarely seen or heard of a project being completed within the stated time and budget established at the onset. Shocking, isn't it? But why is that? There are many factors, but let me list a few of them. Now you might wonder how this relates to the rates we charge? I'm getting to it. Be patient!
Imagine this. You are trying to determine the cost (and time) required to build something nobody else has done before, with few details to go by. What would you do to come up with an estimate? You might, for instance, think about other projects you've done that are similar. But with custom software, no two projects are ever the same. Otherwise, they wouldn't be custom! Here's another idea. Take the general scope of the project, add your gut feeling, and do some quick calculations. Whatever number you come up with, double it. Then double it again. Welcome to the world of custom software. You might have a future here. Alright, here's another approach. Figure out what you think your client can afford, and then estimate $1 below that. You keep thinking like that and you might be management material.
The truth is, all of these methods are bad. Really bad. I've seen people use dart boards to come up with numbers, and honestly, they are just as likely to be right as any of the other methods above. So how do we determine the cost of your software project? Fortunately, we use none of the above methods. We bill by the hour.
Well, right about now you might be thinking..."Rob, that's cheating". I would probably agree with you, but in reality, there is no real accurate way to estimate complex software projects. At least not in the beginning. In fact, the only accurate estimate you are ever going to get is the one that you calculate when the last invoice is received. With all that being said, we do give you an estimate at the start of the project, and then update it after completing the design stage. But we provide a wide range, not a fixed number. Let me explain why. But first, let me make one important point...
Fixed-Price Projects = Divorce
I am probably going to like you, and there is a decent chance you might like me, too. Why ruin our budding relationship with a fixed-price contract? I know it sounds comforting. "Fixed-price" just has a nice ring to it. But it is also a big deception, and it has ruined more relationships than infidelity and online gaming combined.
Here's why:
If we agree on a fixed price, we are going to do it very early on, after a cursory review of your project requirements. I cannot possibly know or anticipate all the changes that are going to occur, but I do know they will occur. So by providing a fixed-price contract, I am really deceiving you. Nice way to start our relationship, isn't it?
As the scope of your project becomes clearer, at some point I am going to start submitting change orders (i.e. requests for more money). After about the 3rd or 4th time (depending on your tolerance), we are going to have a long talk. Trust me, these talks are not going to help our budding relationship. You've got a problem because you got approval for the project based on a specific budget, and now you have to go back for more money again. It's starting to look like you don't know what you are doing, and that isn't going to enhance your career. My problem is that on each of these occasions, we've uncovered new requirements, new scope, and new work I have to do. Now don't get me wrong, I am a charitable person. Just not that charitable. So we both have a problem, and the divorce attorney vultures are starting to circle.
Fixed-price contracts are bad for other reasons, too. Software developers are an optimistic bunch. They rarely see the hidden problems or pitfalls of a project initially. What do you think your developer is going to do when that fixed-price project is 40% over budget? If they want to keep the lights on, and make payroll, they are going to have to get new projects and divert your resources somewhere else. That is a lousy situation for you to be in. So transparency is the next problem. With a fixed-price contract you have no idea how the resources are being used, or if they are being used, on your project. It's a black hole.
With a time and material contract, you know exactly how and when resources are being used, because you receive detailed reports showing it. But you might think, how do you know they are accurate? One peace of advice. If you don't trust your developer, fire them immediately. It only goes downhill from here. But you can usually tell when there are troubles because your project is not going anywhere. How could it be going anywhere? Your development team is working on another project!
The bottom line is, a fixed-price contract is a recipe for disaster. It is a bad situation for both sides, and it was artificially created using the wrong type of contract for the work being done. And it is an unethical way to price a service that cannot possibly be priced this way. So, as you may have guessed, we just don't use them. Period.
Why Time & Material Makes Sense
We invoice all our clients using the time and material method. Simply put, you are billed for the time we spend on your project for a specific period of time, based on our standard hourly rates. More specifically, we'll invoice you twice each month, and provide detailed time sheets for each activity performed. There are several advantages to this approach:
Reason #1: I Didn't Have To Lie To You
Our budding relationship is looking better already. I didn't have to give you the number you wanted to hear so I could get your project. Now I can sleep a lot better at night knowing I didn't deceive you. It also means I can focus on building the best solution, without worrying about how I am going to ask you for more money tomorrow.
Reason #2: Your Goal Is My Goal
Here's where most people get tripped up. Because you are paying me for the time I spend on your project, I generally have a pretty warm and fuzzy feeling about you. You are treating our relationship with respect, and I am very motivated to do the same. So I literally spend most of my waking hours pondering how to make you happy, and do my part to foster this wonderful relationship we have going. And this is how our goals become one in the same. Now you might be thinking..."Rob, how do I know you aren't milking it? What is to stop you from padding the hours, and putting my project in the slow lane?". I know what you are thinking. Rob's got a great comeback for this one. Well, here it is.
You will never really know.
Not exactly the answer you were expecting? Sorry. But if our relationship is going to blossom, we need to give each other the sort of honesty that stings on occasion. The only way you are ever going to know that I'm not milking it is by the progress I make. Period. Time sheets, project plans, work breakdown structures - they all can be cooked if the person creating them is a slug. And if you don't trust me to work honestly with you, you shouldn't hire me. Neither one of us need the grief.
Put more succinctly, the progress being made on your project is your only yardstick. We define the requirements, create the project plan, design the solution, and start programming. You should be able to tell very quickly if you've hired the right company or not.
In conclusion, a fixed-price contract is bad because it puts us at odds with each other, and ruins an otherwise wonderful relationship.
About Our Estimates
In a perfect world we would provide no estimate, and then just work until the project is completed, ignoring budget issues completely. That isn't the world we live in, so we do provide an estimate for each project. As I've mentioned above, estimating is a crap shoot at best. So how exactly do we do it?
Step 1: Estimate Define and Design Stages
Initially, it is much easier to estimate the time required to define and design an application (the first phase), because unforeseen changes have less impact than during development. So we focus on that portion of the project first. Based on the general scope of your project, including discussions, documents you provide, etc., we'll estimate it within a range. For example, 1 to 3 months, 2 to 4 months, etc. Most of our clients try to get budget approval for the full 3, 4, 5 months, and then look great when we beat it. And our goal is always to beat our estimates.
Step 2: Estimate Develop and Deploy Stages
At the same time, we give a broader range to develop and deploy the application (the second phase), but this comes with a disclaimer. Until we actually have had time to define and design your application, the risk is high that our estimates will be off significantly. To compensate for this, we give a broader range, such as 6 to 9 months, 9 to 12 months, etc.
Step 3: Reestimate Develop and Deploy Stages After Design Stage Completed
Once we've completed the design stage, we have a much better view of your application. We have Functional, Non Functional and Technical Specifications, ER Diagrams, Prototypes, and a slew of other details we can estimate with. We apply a modified Function Point Analysis (don't ask) system to determine the programming and testing effort, and then calculate project management and other tasks. After all this, we still provide a range, but the size of that range shrinks considerably.
Mitigating Strategies
Of course, there are strategies we employ to mitigate the risks to your project. For instance, every project has a scope czar, or gatekeeper. This person is responsible for determining need vs. want. Managing scope is a critical aspect of the project, and someone on your side is going to have to approve all changes to scope. Impact analysis is another tool we use. Want that cool feature added at the last minute? This is the cost and impact to the schedule. Still want it? Prioritizing is another crucial tool. How important is this new feature, and are you willing to give up this feature in exchange? And lastly, we set out to define the project budget early on. We don't want to design a $300,000 application when your budget is only $100,000.
Burn Rate
Some clients prefer to budget on a monthly basis, so we will setup a budgeted burn rate. For example, your company might be comfortable with $25,000 per month. We do our best to accommodate, provided the burn rate doesn't jeopardize the success of the project.