Nomenclature

Project: “Project” in this case is a software development project, whether a simple Flash banner ad to an Enterprise grade business to business software product.

Gig: Refers to a contracting job.  These are usually less than 3 months in length, and often Flash.

Engagement: Refers to a consulting job.  These are usually 4 month or longer in length, in Flex, and involve either 1 person sent in to help a company get out of a mess, or a team of consultants sent in to help a company build something… or a combination of the two.

Pricing Types

There are basically 3 types of project pricing:

1. Time & Materials
2. Fixed Bid
3. Incentive

Time & Materials

Time and Materials, also known as T&M, stands for all time and materials being factored into the cost of the project as it progresses.  This means, if you work 8 hours today, you then charge the client for 8 hours of work.  If you have to travel by plane to the client’s location, you’ll charge them for the plane ticket, the taxi ride, and the hotel.  For longer engagements, you’ll often work out a deal for a daily allowance to spend towards food, such as $40.  This is a flat fee, and you’re responsible for whatever you go over.  This also sometimes called “Per Diem”.

You typically charge an hourly rate for T&M.  Some clients will try to get you to charge them for “8 hour days” to lower their costs.  It is difficult for companies to control & project future programming costs because some weeks programmers will work 35, and other works 60 so this is why “8 hour flat rate days” are preferred.  The theory is, it evens out for you as the contractor, and helps them control costs.

Certain costs aren’t paid for by the company.  For example, if you are working remotely, also called telecommuting, and decide to drive out to eat for lunch, that isn’t covered (although is usually tax deductible, ask your CPA).  It’s only when you are on-site at the client’s location that per diem goes into affect.  Additionally, we’re not lawyers.  So, while you’re sitting in coach on the plane flying to the client’s site, you can’t charge your hourly rate just for traveling.  If you are in fact working on the plane, then you absolutely can.

T&M is why I went into freelancing.  A lot of companies started to not pay overtime for W2 programmers because programmers often work overtime.  Additionally, I perceived a lot of the reasons I was working overtime was the company’s fault, not mine, yet they weren’t compensating me for their mistakes, some of which I warned them about and tried to prevent.  T&M is perceived as the most profitable, which isn’t always true (see Incentive below).  T&M IS the least risk to you, especially in a consulting role.  For a weekend Flash widget project, T&M and Fixed Bid have the same risk; you’re filing one, small invoice on a rush job.  T&M is sometimes more dangerous for smaller clients who are not adequately equipped to track costs.  While working 8 hours a day on a Flex project may be normal, for some Flash clients, they may only have budget for 3 hours (see Fixed Bid on how to fix this).

While T&M basically allows you to “charge on the fly”, almost all clients still need a Proposal or Statement of Work (SOW) before the project starts.  This means, you still need to do research on what it is they need, read their requirements if any, and ask questions to get a better understanding of the project scope and resources you’ll need.  All of this initial time isn’t charged for; you do it for free, and it’s factored into the “cost of doing business”.  This is where Qualifying Leads is important.  If the client doesn’t have any money, or is making you feel uncomfortable, raising red flags that they may not be the best client to work for, you shouldn’t waste time & money getting them an SOW.

The Proposal/SOW allows the client to have some understanding of total costs.  Yes, software traditionally is way over budget.  Regardless, you need to help the client understand is it in the $2,000, $20,200, or $200,000 ball park.  Budgets are companies are often handed out; Stakeholders don’t always get blank checks.  So while you & your client may be comfortable with T&M, your client’s boss/CFO may (should) not.

T&M is where you charge hourly as well as expensing all travel, lodging, and (reasonable) food to the client.

T&M with Flash Clients & Small Design Agencies

T&M is a challenging with Flash based clients.  Often the projects are shorter, and the rates aren’t as high.  More importantly, the budgets are smaller.  Therefore, racking up a lot of hours is actually horrible for the client.  This is why a lot of bad Flash code is often written.  It’s not from bad Flash Developers, but rather, driven by the inability to really tackle the problem without insecurity and confidence.  Instead, hours, costs, and short time are weighed heavily upon the Flash Dev to ensure they get it done as quickly as possible.  While this creates immense Technical Debt, it allows the project to get done within the budget.  Since a lot of Flash work has a short shelf life, the Technical Debt is often never seen, and thus validates there is nothing wrong with developing Flash code the way the company has been developing it.

A lot of Flash devs have elaborate processes they stick to ensuring that the client never gets sticker shock; getting an invoice for way more money than the client expected.  Daily reports of hours spent, as much transparency into the project given as possible, and other constant communications to ensure no one gets surprised, and no invoice goes unpaid.

In my experience, Flash clients and design agencies don’t like T&M.  They simply can’t afford it since the deadlines are short and the budgets small.  Since the projects are short, there isn’t a strong sense of project management around them since there isn’t a lot to manage.  This fallacy allows a lot of design agencies to get into software development, yet adopt none of the accepted processes around software development.  Chaos then ensues, which leads to a lot of hours.  Agencies, while knowing this, don’t change, thus aren’t hip to going T&M with contractors.

T&M is pretty much the standard with Flex clients.

Fixed Bid

Fixed bid is where you assign a flat amount of money to complete a project.  If the project takes 40 hours, or 40 days, you still get paid the same amount of money.  I hate fixed bid because software development, in my experience, is never on time.  Worse, the longer you work, the less you get paid.  The less you get paid, the more frustrated you get.  Cost & time aren’t mutually exclusive for some projects.  While you may not be charging the client any more money, the client may be losing money because their project isn’t completed yet.  This doesn’t help the client get a great product.  There is little worse than getting paid less than a fast food worker while getting yelled at by a client for their uber-complex software not working that you didn’t originally write.

Clients love fixed bid.  They know “exactly” what something costs and have a false perception of when it’ll get done.  They can easily understand where it fits into their budgets.  They don’t have to worry some non-deadline projects if it takes you longer.  Startups love this too.  If it’s boot strapped, meaning someone, or a group of his/her friends get together and pool money, that money doesn’t magically grow; the $6,000 dollars they collectively got together is exactly that: $6,000 dollars.  No more, no less.  Take it or leave it.

I almost never take on fixed bid.  They are simply unprofitable, risk producing low quality work, and potentially risk having a negative client relationship.  While the temptation to do so is higher for higher budgets, it’s actually a higher risk to get hurt badly.  Taking $600 dollars worth of hours for a $400 dollar Flash widget isn’t so bad, but committing to a $30,000 dollar fixed bid Flex project that ends up taking you $60,000 is THE WORST experience.

“Almost never”?  Yes.  There are a lot of bad programmers out there, in both Flash and Flex.  These clients will then come to me and ask me to fix it.  They want it fixed with way less budget than the original bad developer got to mess it up, and way less time.  They can’t afford T&M, or just aren’t willing to because they are mentally scarred because of the previous relationship.  You could easily turn them away without losing sleep, but there are 3 opportunities of note here.  First, it’s guaranteed money.  The client is in dire straights, and has no choice to get your help.  You can leverage this in negotiations, and take a verbal flame thrower to scope creep with ease.  Second, if you need the money, you can at least commit to only one small portion.  Third, you have the potential to score a good, positive client relationship & networking contact.

I need to elaborate on the second part here.  My brand, Jesse Warden, is based on getting things done right, quickly.  I produce quality work.  If that brand is undermined by my own doing, that’s career suicide.  Taking on savior projects like the above can be dangerous.  You’re basically associating yourself with bad quality code.  Over time, the client may even start to perceive the application’s problems as something you’re beholden to, even if it’s random spaghetti code making explosions that aren’t your fault.  You need to be very clear to the client, as well as future clients who know about it that your role was specifically to fix someone else’s pile of broken rubble.  Additionally, if you need money, but the client isn’t amenable to doing a T&M contract, you can only commit to what you feel comfortable with.  While the client may be in deep trouble and frustrated, providing a fixed amount of money to fix it actually makes them feel better.  If you have 3 Air Conditioning repair guys over 3 years attempt to fix your failing Air Conditioning unit, you’ll gladly pay any amount of money, 1 time, to never have to worry about it again.

There have been more than a few blog articles written by both independents and agencies who have moved from a T&M to fixed bid model. Every single one I’ve read are ALL referring to web design, not Flash/Flex software development.  There is a huge difference here.  A lot of web development can be condensed down to repeatable processes, and all clients can be grouped easily as well into what they often need.  What you produce for them is often easily generated, and can be done in short time frames.  Wordpress/Drupal/Django, some customized templates, done.

Software development is nothing like that.  Just because you spend an extra money on requirements gathering doesn’t ensure your non-Agile project won’t go over budget by scope creep, late client resource deliverables, or “the client just doesn’t like how it looks & works”.  You’ll sometimes see junior to mid-level devs swear that their next project they’ll spend a year on the planning phase to ensure they don’t suffer the same problems since they’re often beholden to their fixed bid estimates they gave to the sales guy or Project Manager.  This is why Scrum and XP software development practices were invented; to embrace change.  Their accurate velocity metrics allow you to project T&M costs with a decent accuracy.

Fixed bid projects are where you put a flat fee on what it’ll take to complete a project.  If you do Flash or Flex, don’t do them.  …Unless you need the money or want to help the client out and score a life-long friend after saving them.

Incentive

Incentive prices are where incentives and penalties are put onto contracts.  I’ve never been involved in projects that have these, but have been very tempted to start using them with some of my consulting clients.  Basically, you say something like, “If we get the project done by November, it’ll cost you $120,000.  Every month late, we deduct $30,000.  If we get it done early, you’ll pay us $40,000 for each month we deliver before November.”  This is often done with larger contracts where the projects are time sensitive and serious business harm could occur if not delivered on time.  The risk is off-loaded by the client onto the contract to in theory provide incentive to get it done on time.  As you know, you can’t “code faster” too much without burning out and producing worst code, so I’m not really sure how this works with software.

Another more daring set of incentive’s I’ve seen is where clients have a project in dire straits.  Sales will offer to come in and fix it for a very high rate, and guarantee it’ll work by said date.  If it does not, no charges by the client are incurred.  That’s right, if you try to fix a pile of dung for 3 months, and fail to do so, you don’t get paid.  Often this is just lip service so the salesman can get in the door and get a more positive contract signed.

Incentive pricing is usually done to ensure the contractor has incentives & penalties to get things done on time, and reduce the risk to the client who is outsourcing something of extreme importance.

How to Price?

The pricing process usually goes like this:

1. qualify the lead
2. identify what the client wants
3. identify the deadline
4. identify the budget
5. identify the resources you’ll need
6. validate you have the time & resources to allocate
7. validate the client finds your initial assessment valid; adjust if possible

Whether you go T&M or Fixed Bid, you need to know what you’re building.  More importantly, you need to ensure your client can even afford you.  You don’t want to waste a lot of time talking to them over email/phone, and helping them flesh out requirements only to find out that they thought you’d work for $15 dollars an hour, and their $120,000 dollar project would only cost them $2,000… and you spent $1,200 dollars of your time finding out that frustrating fact.  While it may be tempting to just say your prices up front so you don’t waste time, some clients just need to be educated.  Over time, you’ll be able to feel these people out, even over email.  Phone is better.

Once you’ve qualified the lead, you need to ask questions.  Lots of questions.  You wan to ensure you have crystal clarity (as much as you can anyway), on what the client wants, and what they “think” they want.  I do this by asking questions over email and phone.  The phone is better if the client knows what they want, or you can’t tell if they have any money.  If the client doesn’t know, email is nice because it gives you a paper trail you can refer to, as well as the client.  It also gives the client a trail as well so they can go ask their team.  Finally, it allows you to multitask if you’re dealing with multiple clients.

Once you have a good idea of what the client needs built, you need to get a sense of when they want it done by.  Some things cannot be built in some time frames, regardless of the amount of money thrown at it.  Some things can, but require more resources, and thus more money.  You should by this point in your career have a gut feeling already forming at how long it’ll take to build, what resources you’ll need, and if you need to travel on-site to the client.  Some clients need User Experience & Design work.  Some even need Business Analysts to actually verify if the product’s market is even worth going into, let alone exists.  If you don’t have these resources, you need to factor that into your time to actually find & hire (sub-contract) them first before your start the project.  This could be either partnering with a firm, or hiring people in your network.

If you’re a freelancer, you may not want to do this as the thought of doing anything beyond filing your taxes and coding seems icky.  If you want the bigger projects, however, you need to provide value to your clients.  This means not putting the onus on them to manage & get it done.  You’re more valuable as a project enabler than as a code resource.  They often just want it done, and will leave it up to you.  There is no reason they have to know that you hired the designer and UX from another firm, yet billed them through you.  As long as you get their job done right, no one cares.  That, and you can often take a cut for every hour they work.  If you’re perceived as freelancer, and bill yourself as such, you’ll never get this opportunity.  Most freelancers I know don’t want to do this anyway.

Once you’ve identified the client is good, has money, you know what they want, when they want it done by, and the resources needed, you need to put a time estimate to it.  You need to be careful here.  So far, none of the time you spent was billable.  Doing time time estimations can be extremely quick, or a long drawn out process depending on how you approach it; both of which aren’t making you any money.  I’m notorious for taking longer than any consultant should.  I like it.  I enjoy writing detailed proposals to ensure I’ve captured the client’s initial requirements, factored in all the parts of development that come into play, and broken down all price & time into transparent tasks that the client can easily understand.  I charge a lot of money for my services since I’m one of the best.  As such, my clients deserve to know exactly what they are paying for.  This requires detailed proposals showing the client I’ve thought hard about it and I care.

Bad ass proposals don’t ensure you’ll get the gig, hence why a lot of people don’t spend too much time here.  You can charge for “Discovery” phases of a project if it’s large enough and you’re helping the client out on this portion.  I won’t go into closing the deal since I’m not a salesman, but I will say don’t do more than 2 iterations of a proposal.  It’s ok for the larger ones to take months to get signed.  Long sales cycles lead to large projects.  That said, that’s usually in the contract realm, not in swag time estimate proposals.  A proposal is usually less accurate than a formal, mutually signed Statement of Work… sometimes not.

Meat of a Proposal/SOW

But what’s “really” in there?  Mine usually have the following:

1. My version of what the requirements are
2. My version of the problems the client has and how the software sill solve them
3. How my firm runs projects
4. What we’ll build
5. What resources are involved
6. What it costs

This is based on my experience of building software.  Sometimes I actually break it down in my head, or on paper, of what’s involved.  “I’m building a Flex app, it’ll use this framework, I have to hit these web services, parse this XML… the designs aren’t done yet, and there are dependencies there… hrm… I need 3 developers, one to handle the back-end, one to create these complicated charting views, and I’ll just work with them on sharing architecture.”.  This could take hours to arrive at a good guess (also called swag, swag estimate, ballpark, ballpark estimate).

Once I know all of what we’re building, who’s involved, and what they cost I can do the math.  Dev’s rate * time = price.  Do that for all devs.  Ensure time is allocated for Discovery & Deploy phase which may/may not fall under a Scrum process which is harder to track, but HAS to be allocated for.  Ensure budget is allocated for keeping designer on staff for iterations throughout the project.  Adjust for when people get sick, go to conferences, client is on holiday, etc.  You’re gut & experience will tell you where you need to pad, and where you do not.

Here is a sample second version of one of the larger swag proposals I sent out 3 months ago to a client with some (blurred) design comps and made up prices – HTML | PDF

From there, some clients iterate, some say thanks and want a formalized SOW, and others suddenly realize how expensive software is.  Sometimes you wan work a deal with this people, but Jesse Warden doesn’t give discounts; just valid options.  Sometimes clients are willing to pay for your expertise, they’ll just have someone else run the project.  Fine, you want a Staff Augmentation instead of Consulting?  I can do that.  You should be flexible as sometimes clients are just figuring this all out, and its your responsibility to help them.  Again, though, if you’re about write Draft 4 of your Proposal, unless it’s a LARGE project, you may need to question if the client is just trying to get you down in price, or they truly are trying to be responsible about costs and learning what’s involved.  Keep in mind, doing what you’re doing is essentially free consulting.  Most clients get multiple bids, and can you use you to do a lot of upfront leg work that other firms may not.

Hybrid Approaches

For larger projects, some clients are extremely leery of having T&M applied to some portions, even if it’s a SCRUM run project.  In those cases, you can use a combination of T&M and Fixed Bid.  Basically, you identify portions of a project you know are easy to pin down to exact hours, and those that have high risk and deserve a T&M pricing structure.

An example is a Login Form.  You can create that in Flex easy, code up the service for it easy, and quickly wire it up to test.  As more and more web services come in, you know you can quickly validate if they work or not via the Login service.  Thus, it’s pretty easy to put “6 hours” or whatever time you know it takes to get this done, without worry it’ll suddenly take 5 days.

Things that are higher risk are things like hitting web services that don’t exist yet.  You don’t have a formalized data model, you have no clue what response type the server guys are sending back (JSON? XML? Fu)($@%ing SOAP?), nor what the error codes look like, nor if you’ll even have a separate dev & staging server.  As you develop, things will change.  This guarentee’s you’ll need focus a lot of time ensuring unit tests are up to date and thorough on this section, you’ll spend a lot of time debugging strange, brand new issues to not only fix bugs, but also to help the server team move forward.  This is a major sink and is a lie to put a Fixed Bid price on it.

The client gets a good estimate on what you feel is accurate, and what is risky.  That way, it’s not a leap of faith for them to sign off; they at least know partially what they are getting into, and are prepared for certain sections to change in cost, and can be proactive about it.  No surprises == happy client.

Miscellaneous Costs

This article was pretty high level, but there are a TON of costs you need to factor in.  I can’t stress enough how much knowing all of this comes from your experience, but I’ll try to state some here for totality’s sake.  There are the common ones like hours spent on a task, hours spent meeting the team & communicating with them, and hours spent iterating with client on designs and requirements.

There are other costs, too, like setting up your environment, setting up your build process, and most importantly maintaining it.  While a lot of these things are just factored into SCRUM Sprints, you may forget about these things while writing a Proposal.  SCRUM Sprints are setup to ensure a natural velocity evolves, but that’s a hindsight affect.  You need to ensure you make you remember all the things that detract from having a high story point value per Sprint, specifically your Eclipse or Java installation getting hosed costing you a day, SVN/GIT going down, or a developer just going AWOL.  It all happens.  It sucks, but it DOES happen and you need to factor that in.

Other things to factor too are the percentage of things you haven’t done.  You’ve built 50 Flex apps, but never once utilized the charting components.  You figure since they are Enterprise and as good as the rest of the Flex SDK, so you pad a tincy bit based on your lack of face time with ’em.  However, once the project starts, you realize they have no bounds limit for the amount of data you can feed them, do not utilize blitting, sometimes creating many DisplayObjects, and make no use of green threading.  You now have to create custom charts.

Granted, this is the classic “if we knew what we know now” problem with software.  You can’t see ghosts because no client would sign your insane fear-based estimates.  That said, you NEED to at least make an attempt to get your unknowns a little more known, and pad for it.  They are high risk.

Hiring Resources

Keep in mind hiring resources (contractors you sub-contract through yourself) for your projects takes time to.  Even if you just need a mid-level Flash Developer to help you chop up graphics, you need to factor time into finding him/her, getting him/her to agree to a rate, hopefully lower than your charging your client.  For larger projects that require resources out of you technical domain, this can be a big deal.  You may need to go to industry meetings, network, meet people and size them up.  Most contractors hate shorter projects, and thus charge more for that.  You need to factor this in, and adjust price accordingly.

Pricing Philosophy

Making proposals can go 2 ways.  Either you compete on price or quality.  I compete on quality.  Others compete on price.  If you compete on price, you’ll sell the client on things like “Yeah, we can reduce the amount of hours there” or “yeah, we’ll cut you a deal on those design comps”.  You don’t sell value, you sell how little the client has to pay, and the perceived speed at which they’ll get it.

If you compete on quality, you don’t adjust price, and instead reaffirm what value the client gets for their money, and how they aren’t incurring technical debt.  You sell the quality you bring to the table, how you’ll get it done right.  For consulting gigs, you’re assuring the client you don’t want the project to extend indefinitely so you can make more money; you want to get in there, fix the problem, and get out.  Then, when the client has another problem with a separate project, you want them to call you again.

You’re either a Kia or a Porsche.  You’re either a Honda DX or a Honda EX.  If a client wants a Kia, you’ll be hard pressed to sell them on a Porsche.  Thus, don’t waste your time.  If a client wants a Porsche, and you sell them a Kia, they’ll end up calling my firm when you’re done with the project.  I can’t tell you not to compete on price and produce bad work because for some reason clients keep hiring you.

One final note: low price is not indicative of low quality, nor is high price indicative of high quality.  There are exceptions.  I know of 2 specific high profile Flash Developers how charge EXTREMELY low prices.  I’m not sure how they eat.  Regardless, if you see a high price, the perception is that it’s of high quality.  If you produce high quality, then charge for it.  If you want to compete on price, that’s a perfectly valid tactic too.  Both have their cons.  If you sell on quality, you’ve significantly raised the client’s expectations (BRING IT!).  If you sell on price, their expectations don’t really go down too much… “a deal” and “non-functioning software” just don’t go well together.  That said, some people work CHEAP.  There’s nothing wrong with bringing a good team together that works cheap and producing good work.  It’s just rare; good people are expensive.

Conclusions

As you can see, a lot of qualitative things go into pricing projects, not just quantitative.  Time & Materials allows you to charge by the hour, and make the client pay for all travel, lodging, and food.  Fixed Bid allows clients to control their costs, but is extremely risky in software.  It’s only effective for rescue gigs where the client has little money left, but you still want to get paid and develop a positive relationship.  Incentive pricing is a possibility for larger, time sensitive projects, or ballsy salesmen… or for clients who just can’t be budged, think of the client as a rusty hinge and your whack incentive as WD-40.

You can employ hybrid approaches with the above as needed.  Whether to cite specific portions of the project that are standard fare, and those that aren’t, really help the client get insight into what they are asking for, and are often used pricing structures for uncomfortable clients.

To develop a good proposal, you need to think about what it really takes to build the software, from all angles, from start to finish.  Athletes who are the best often say they visualize success before hand.  They see themselves performing that winning shot, then they go out and do it.  See yourself building the software, dealing with the myriad of challenges you often face, and then put time estimations to that.

Finally, remember that you are selling value.  While you’re welcome to use price as a selling point, I encourage you to sell you.  What value do you bring to the table?  Why is the client hiring you?  SELL THAT!  Explain to them what they are getting.  You love software, you take pride in your work, your goal is to win, not to leech the customer for money.  Write that in your proposal in a professional, short and sweet way.  Iterate, but not more than 3 times (unless your sales guy does it for you).

Remember, ensure the client has money and is looking for your quality before you go down this entire path.  Also, not all clients know software.  Have patience and educate as best you can.