I started writing this post a few years ago; after I failed to come to terms with a new client. I finished it for September's Flextras/DotComIt newsletter. I realized that I seem to pass on more opportunities than I take on. Part of the problem is me, of course, because I can be picky about the type of work I take on. But, there does seem to be a common thread running through these rejections. This newsletter collects my thoughts on why I wasn't a fit for the project you wanted to hire me for.
How I WorkBefore going into why we didn't come to an agreement, I thought I'd explain how I usually work. There are usually two different approaches I can take to a project contract: either by the hour, or by the project. I'll explain a bit about each approach.
By the HourWorking by the hour means that the client pays me for each hour I work for them. This includes everything from meetings, email management, documentation, system maintenance, and writing code. Some important aspects of an hourly contract:
- They are great if a client wants to get me in the door to have me start working as quickly as possible.
- They are very flexible and allow for a constant change in requirements, priorities, and focus. This is good for the client because it allows for a fluid approach to development.
- The deliverables are delivered when they are ready, and functionality usually comes in small, quick chunks.
- If the client wants to manage me as one of their resources, then this is the way to go. Usually we have weekly planning session to discuss the progress made and the plan for the week. I expect that the client is involved every step of the way; and will direct where my efforts should go. This gets a very tight feedback loop and the client and problems can be addressed quickly.
- The client can terminate at any time, usually with minimal commitment.
- The client is responsible for managing the budget and schedule; and none of the responsibility is passed onto us. I will provide a client with weekly breakdowns known as time sheets that they must approve.
Some of these items are considered 'double edged' swords. The fluid nature of development means we often code for speed and not architecture elegance. It is tough for the developer to budget our time and finances without said commitments. Some clients are more comfortable by limiting their own commitment.
By the ProjectWorking by the project contracts usually means with a fixed fee. The client hires the developer for a specific period of time for a specific amount of money to complete a specific scope of work. Some aspects of a project contract are:
- They are great for a client working within a fixed budget or under a deadline. This is also good for both the developer, who gets guaranteed work and the client who gets a guarantee on the project being complete in their limitations.
- The budget is all inclusive, which means every aspect of our time is included in the budget.
- A project plan is created, which will include fixed milestones with detailed descriptions of functionality. The down side of this is that this requires a lot of paperwork up front in order to define the scope. Sometimes it is hard for a client to create the documentation in enough detail needed to code something.
- Changes to the focus or priorities can be very costly; and require additional paperwork. When changing a fixed fee bid; we have clients sign a change request that includes a description of the changes, the additional cost, and the new timeline.
- We act as the project manager and balance our own time, budget, and development tasks against project milestones. This relieves the client of some responsibility, but the client usually gets more functionality in a single deliverable than they would in an hourly contract. Milestones are often 2-8 weeks apart.
A lot of developers don't like working on fixed fee bids; and I can understand why. The requirements are very rarely carved in stone and often change. It is tough to manage those changes in the context of a project bid. I, personally, love fixed fee projects because, like many small business owners, I like to look out at least three months ahead to see that we have a plan.
Reasons we Couldn't Come to TermsUnderstanding the two approaches that I can take to project development, here are some of the reasons why I often don't come to terms:
- No Contract: Some clients have insisted that we work without having a contract in place. A contract will define the terms of the full relationship including payment terms, code ownership, lawsuit liability, termination terms, and what one party can do if the other party is in default. I like to have the contract in place to avoid any ambiguity. In my early days it was to make sure I could get paid. These days, it also makes sure they can't claim ownership on work I do not do for them.
- Intellectual Property Rights: Ownership of the project's output is a big deal for many companies. They want to make sure they own the project and source code, and are able to maintain it without coming back to us. They also want to make sure that the source code I provide them is not violating the IP rights of any other organizations or developers. This is all fine. However, I have seen IP clauses are too over-reaching for my tastes. I am very careful not to transfer ownership to the client of anything I do not build for them. I maybe building something for other clients; or I may be writing newsletters like this one, or I may be creating podcasts, or creating for my own projects, such as Flextras. I am very careful not to transfer ownership of everything I create.
- Work with Jeffry Houser, not DotComIt: I've lost projects because I only work through DotComIt. Some people insist I must personally sign contracts as an individual instead of as a representative of DotComIt. I never do that. Issues such as insurance, liability, and accounting all go through DotComIt. As a compromise; I may suggest a 'key person' clause to the contract which says I will be the primary contact, or developer, on a client's project.
- Mixing Project types: I don't like it when a client tries to mix our two approaches to development; and I'm undecided if that is me being inflexible or not. I have had clients request explicit deliverables in an hourly contract. Sometimes hourly contracts includes a limit on the amount of hours worked; so a list of deliverables could put me in a position where I am contractually obligated to complete said deliverables without pay. I do not want to be in that situation. Likewise, I have had clients request an hourly breakdown in a fixed fee project. I understand the client doesn't want to pay me for time I am not working, but in such cases, they should focus on the bottom line, functionality, and delivery dates. The micromanagement gives me a pause.
- Non-Compete: I understand that a client doesn't want to hire me and then have me steal their client list, or source code, and use it to help, or become, a competitor. However, some non-competes are more far reaching than that. In one contract, with a web development firm that wanted to subcontract work out to me; a clause said I couldn't work in a similar industry. I feel every client I had before and after them would have violated that clause. Another contract had a guarantee I had not worked for any of their clients two years prior to signing. Without their client list; how could I make that promise? I'm fine with a company protecting their proprietary information, but I'm very careful not to sign away my right to continue to do what I do.
- No-Advance: I always like to ask clients for an advance at the start of the project. Some clients insist on not paying anything until they have the final results, and that is a red flag for me. I do not want to spend weeks, or months, building something only to find out the client can't, or won't, pay. For fixed fee projects; I am usually able to successfully negotiate some type of an advance. For hourly projects, I am not always so lucky.
Any contract with a client will have a dozen different little things that will cover the working arrangement with the client. Usually many of these things are no-issue or easily dealt with, but the items above are the main reasons why I often walk away from a contract.