Help The Client Help You

Another way to maximize your effectiveness is helping the client help you. The first step is to understand the client’s needs. Throughout this book, the client is addressed as though he or she is a single individual, and to some extent that is true. The person who signs your check is your client, and at the end of the day, you want to deliver what that person hired you for. Employees in the trenches will probably have different ideas about what needs to happen than the hiring manager. Acknowledge these ideas and navigate these needs carefully, because of the political and technical knowledge of the employees. However, keep your eye on what you were explicitly contracted to do.

Remember, it is in the client’s interest to maximize your productivity. However, the client will not take initiative in helping you; they’re pretty busy, otherwise they wouldn’t have hired you. You can be a standout consultant if you look beyond ‘getting the work done’ and really think about the larger picture and the client’s business, including competitors, new technology and the cost of hiring you. Once you let them know about anything that affects your productivity, clients are almost always willing to help. Make sure you alert the client to anything that may be hindering you. This includes lack of access to people or systems, as well as lack of understanding of the business, project or systems.

In certain organizations, contractors may be brought in not to do work, but to empire build. Dan was in a certain large company who hired him via a consulting company, but didn’t really give him anything to do. If you’re a developer who likes building software, this is going to be a frustrating position, since your skills and motivation will be wasting away. Make your concerns known, politely but repeatedly, to both the client and other employees. If you are going through a consulting company, let them know too. Make every effort to fulfill the contract, but if things don’t seem to be getting better, leave.

Beyond keeping your eye on what you were hired for, another valuable thing is to watch for needs that a client doesn’t even know they have. For example, using an open source database to cut costs, or using version control. This is secondary to getting your job done, but you can plant seeds for more work and build trust. It also might save the client money, and save you from doing scutwork, like writing yet another O/R mapping layer.

Techniques To Help The Client Help You

Some specific actions you can take to help the client help you include asking questions, figuring things out yourself, enabling the best communication possible, and approaching problems from a non technical viewpoint.

It’s fine to ask questions throughout a contract, especially at the beginning. Though you were hired for your technical competency, no one expects you to come into an entirely new situation and immediately understand how all the pieces fit together. However, there are techniques that make it more likely your questions will be answered. As you explore the system, begin to jot down questions. Then, find out how the client would prefer to answer your questions, be it email, phone, instant messenger or face to face discussions. Also, find out who should answer or dispatch your questions–the right person may be different for each question, but a technical person as initial contact works best. When you have a significant batch of questions, or you’ve run into a show stopper, use the client’s preferred method to ask the questions. Also, make sure you are polite, patient and persistent. Very often, the person with the knowledge to answer your question is the busiest person. Be polite, and ask them when you can expect an answer. Note that time and if it comes and your question has not been answered, ping that person again. Exploring the system and figuring out things for yourself can be useful as well. Before you embark on this, discuss how long you should spend with the client–it can be a poor use of time for you to figure out something that someone else knows by heard. Exploration can and should be used concurrently with asking questions; when you’ve sent off that batch of questions, see if you can figure some of them out yourself (given the consent of the client).

Additionally, make sure that information is communicated well. Written documentation is best. If you are having trouble getting written requirements, offer to write them yourself. Here's a good article on how to write requirements; he calls them ‘functional specifications’. These documents don’t need to be formal; wikis have worked well for two of the authors. Point out the benefits for the clients: you will be able to head off and work more independently, rather than asking clarifying questions all the time. If you can’t get the client to agree to write requirements, you should still avoid verbal requirements, which lead to misunderstandings. Rather, rephrase what you think you heard the client say, and then write the requirements yourself. Share them with the client if appropriate. Again, no need for formality, a simple email or text note can be enough. Beyond requirements, writing down other information, or getting the client to do so, is a great way to ensure that you have it in the future. Whether you send emails to yourself, keep a developers notebook, or have a personal wiki, having information in a written form will save you grief when you forget it.

Developers have a tendency to approach issues from a technical standpoint, often focusing on how to solve problems via software. You’ll be more valuable if you can ask questions and think about problems from different points of view. Some other viewpoints to consider: user, management, deployment, designer and DBA. Doing this will put you in the client’s position, and lets you know what questions to ask to help the client help you. Using these points of view, try to diplomatically point out solutions. Sometimes a fresh set of eyes can see new or existing problems, but, other times, everyone at the company knows about those issues – there may be political, historical, technical or business reasons for not addressing them. Be diplomatic; the new guy who rails about how crappy everything is has often not given much thought to how things came to be that way. His opinion may be discounted in the future, even when he has valid points. An example of a diplomatic way to approach changing the build process would be: “I notice that our deployment process has a lot of manual steps. I’m sure there are good reasons we’re doing it that way, and I wonder if you can help me understand why.” Do your best to understand the situation first, then if there’s room for improvement or education after you’ve found out all you can, propose it.

One time Dan was at lunch with a possible client, who had a crufty old user training system that was humming along. It was getting harder to maintain, but there was limited business value in rewriting the entire system. One of the employees of the client almost fell off his seat when Dan stated that as long as the system still had business value, it should not be rewritten: ‘I’ve never heard a developer say that!’ Dan was offered the contract.

Conclusion

In general, contractors need to be aware that they have the onus for being productive. The client will benefit and appriciate their productivity, but the contractor needs to be proactive in pursuing whatever information and access he or she needs. Think about the work you’ve been hired to do in terms of the larger picture and from different points of view, as that will help you do so.

Know What an Employer is Looking For

Being effective at your tasks increases the chances that you’ll be retained or referred, and makes the job more enjoyable, because you’ll be getting things done. Contractors are hired by clients for a number of reasons, but there are three broad categories. Knowing why you were hired lets you focus on what the client wants, and can let you know if the contract is going to be a good fit for both of you. The three broad categories are: hired hand, hired gun, or country doctor.

When an organization is understaffed, ofttimes hired hands are brought in. Hiring contractors allows for temporary staff-up without long-term payroll liability. You just do what you’re told with a minimum of fuss. In a well organized company, you’ll be handed a requirements or design document when you start. In other organizations, you might have to do some hunting to find the work for which you were hired. Either way, you are not going to have a long term effect on the corporation–you’re being hired for the hours of work you can provide. For that reason, these types of contracts tend to want you full time.

Hired guns, on the other hand, are contracted solely for specialized knowledge. For example, an Oracle expert might be hired to tune a database for performance. These jobs will typically not be forty plus hour a week positions. The client will expect you to transfer skills to employees; be sure to provide plenty of documentation and be a willing resource.

Back in the day, country doctors were the only medical resource for miles around; they had to do everything, including communicate effectively with people who had no medical background. Small companies and startups often hire people in such roles. The organization typically has little or no technical experience and is looking for help with minimal payroll liability. They’ll expect some attributes of employees, such as loyalty, even though both parties still have the understanding that you could be gone tomorrow. In this situation, try to view problems through the lense of the company, especially in terms of money. The clients are typically small and have less money, so do what you can to save money. This includes documenting possible corners that could be cut during requirements gathering. Communicate loudly about both present and future costs. It is far better to have this type of client know about the costs and choose not to spend the money than for you to spend the time without their buy in. (See the money section for more about getting paid.)

How do you know in which role you are being placed? Be aware of clues: ask about other technical resources; if they don’t have any, you’re probably a country doctor. If the client drops written requirements documents on your desk on your first day, you’re probably a hired hand. Knowing when you’re a hired gun is easy: did they have certain, drop dead, esoteric requirements for the job; “talk to us about an instance when you troubleshot Weblogic 8.1 while using SSL and Weblogic Portal Server.”

On the other hand, always be willing to offer advice. Even in the ‘hired hand’ role, you are still being paid for your ability to deliver software, and that means you’re still being paid to think. Offer advice humbly and know that some things may not make sense from your limited viewpoint. Some technology decisions may have political, legacy or technical justifications that you’ll not understand, and that the employer may not want to take the time to explain to you.

In general, larger organizations are more capable of handling contractors. They tend to be more used to contractors, have more team members to get you up to speed, and desire longer contracts. They also are slower to engage with you, and typically have large amounts of existing infrastructure that your code will have to leverage and fit into. Typically, you’ll be in the ‘hired hand’ or ‘hired gun’ role.

Small organizations, on the other hand, tend to be looking for individual contributors. There is little support infrastructure, and you might be the first contractor they have ever used; ‘country doctor’ is a typical role. There may be software already present, but it’s likely to be less extensive.

Either one of these situations can lead to a nightmare contract or a great experience. When you’re headed into a contract, the most important thing is to get to know the client’s expectations, which are shaped but in no way completely determined by the size of the company.

Billing Models

There aren’t that many different ways to actually bill a client. The two primary ones are: time and materials, where you bill for every hour you work, and fixed bid, where you and your client agree to an amount, and that’s what you’ll get paid. In addition, you may take payment in non monetary form, either barter or equity, in lieu of money or in addition to it.

Time and Materials

This is the most typical billing method, often abbreviated t&m. You exchange your ideas and your time for the client’s money.

The way that t&m typically works is that a client will have a project and will want an initial estimate, which means you’ll have to gather some kind of requirements (see requirements section above). Requirements are important because they also let you know when you are done. A schedule may also be required.

It’s important that you do your best with this estimate, and at the same time make clear that it is just a best guess estimate. As the work progresses, you’ll want to keep the client up to date with progress. As you approach 75-85% of your estimated hours, start communicating more with the customer. When you get to 90%, unless you know you can be done at or below 100% of your estimated time, communicate with the customer and make sure they want to spend more time. *Don’t move forward past 100% of estimated time without your client’s permission* unless you’re prepared to not bill for that time, or possibly leave a bad taste in the customer’s mouth. Even though it’s just an estimate, that doesn’t mean that the client hasn’t used that number in their budget planning.

If, on the other hand, they don’t want an estimate, let them know periodically what the percent completed is. Don’t forget to account for debugging and testing at the end of the project. Projects where you don’t need to provide an estimate are typically smaller, since estimated incurs overhead, or for a client who is comfortable with you.

Invoicing for t&m needs to be detailed enough that the client feels comfortable with what they’re paying for. You don’t want to surprise the client: the most important aspect of t&m is to communicate with them what you’re working on so when the bill comes there are no surprises. This obviously differs from client to client; be proactive and ask them if your invoices show enough detail. Remember, unless you have milestones in a contract, until the software is done, the words on your invoice get you paid.

T&m is good because most of the risk of the project is on the client. If they need changes, or if problems arise that were unforeseen at the start, the client pays for your extra time. From a client’s point of view, t&m is scary for that very reason: it’s a variable expense. However, the additional flexibility and quick startup time are often more important.

Fixed Bid

Fixed bid contracts are almost the opposite of t&m. Instead of getting paid for your time, you get paid for delivering software. Instead of the client possibly changing requirements mid project, you have a document specifying exactly what will be built. Instead of flexibility, the client gets a firm cost. Instead of the client bearing the risk, you bear the risk of time over runs. Of course, you also get the benefit if the project is finished in fewer hours than you thought it would take.

A typical fixed bid contract has a small requirements gathering period (which you should get paid for) where you and the client determine what needs to be built. Then you come up with an estimate (see estimating section). The client approves your number, and you build the software to the requirements. The client is happy, you get paid.

But, in the real world, the project scope can change, or the client may not have known all the requirements. Use formal change management to control such scope changes. You don’t want to avoid the change, because the client is requesting it and thus probably needs it, you just want to make sure that you get paid for any time you spend building software outside the scope of your bid. Make sure that’s part of the contractual understanding before you start. For any change, you should either be paid for every hour it takes you to make the changes, or go through all the steps needed to get a fixed price for the changes.

In addition, communicate all difficulties with the client as soon as possible. You should do this no matter what billing model you use, but it becomes imperative when you are working on a fixed bid. When the sysadmin won’t give you access to a needed system, it’s easier to chill out and spend time on a workaround when you’re on a t&m contract–it’s not coming out of your hide. On a fixed bid, wasted time costs you money.

As illustrated above, the risk is much greater for a fixed bid project. Keep them as small as possible–about 100 hours is as much as I (Dan) feel comfortable with. Because of the overhead of the requirements gathering process, the client may want a larger project–you can counter this by pointing out the business flexibility gained by doing a number of smaller projects as opposed to one larger one, or doing milestone releases where you get paid and the client gets to verify that you’re actually building software they want.

While you can use the same estimation techniques for fixed bid as for t&m, you should multiply your estimate by a greater fudge factor (10-20%) to get a bid price. This percentage accounts for the tasks you missed, or underestimated the difficulty of, when gathering requirements and building your bid. If you can, keep track of your hours and, at the end of the project, compare how long you took to how long you thought you would take. This can be a learning process that will help you create more accurate estimates in the future, as well as letting you know if you made any money on this particular piece of work.

Non Monetary Payment

Both of the above billing methods implied that you were being paid in money, which is typical. Of course, it’s possible to exchange your time and knowledge for non monetary objects of value. Barter for goods and equity in a company tend to be the most common methods of non monetary exchange.

Barter works well when you and your client have complementary needs. For example, you may be able to build your mechanic’s website, and they may be able to give you free oil changes for a year. You still need to do the estimating and place a value on your time; requirments are even more important because when you’re not getting paid, you definitely want to know when you’re done. These kind of agreements can be easier to implement, as they may be more informal. In the USA, legally you must report the income from any barter exchange. Consult your tax advisor for more information.

Working for equity, i.e., shares of a company, can be quite profitable and is always risky. You can work for equity alone, or you can take only part of your payment in shares. Taking equity alone can be extremely risky, because it depends on those shares actually being worth something. Therefore, when taking equity, you’re investing in the company, while taking some equity in addition to money is obviously less risky. Make sure you believe in the business model and the team, and that the company actually has a chance of making money. This judgement is hard to make, especially since you typically won’t have complete control of the company. Therefore, you should be in a financially stable position before you contemplate trading your time for equity. However, if you do pursue this, realize that you may reap other rewards (see sidebar).

Dan worked for a startup of five people building a J2ME application for real estate professionals. He learned a ton about mobile phones and how a startup should work. For many reasons, among them device compatibility issues and employee time demands, the venture folded. Dan ended up with no monetary return on his thousands of dollars of invested time, but he did publish a paper documenting what he had learned, and made a few contacts in the mobile computing field.

Conclusion

How do you choose what billing model works best? Part of that depends on the client, and part of that depends on your appetite for risk. Take payment in barter or equity only in very narrow circumstances; either the client has a good or service that you need and is of comparable value, or you have faith in the business model and the team executing it. The following table sums up some of the variables you should consider (sorry for the formatting).

	Risk Bearer	Your knowledge of client and project environment	Size of project	Flexibility in Requirements	Overhead
Fixed Bid	You	High	Medium	Low	High
Time and Materials	The Client	Low	Small, or Large	High	Low

If the client has a good idea of what they want, or you’re intimately familiar with their systems, then a fixed bid model works well. If on the other hand, the client is hazy about their desires, the project is very large, or you are unfamiliar with how to make the changes, t&m works best. Fixed bid works well on medium sized projects, where the overhead of deciding what to do doesn’t exceed 10% of the time estimated to actually do it. Be careful of fixed bid large projects, because creating accurate estimates becomes harder the larger the system are. Conversely, the low overhead of t&m works well when the change is small, and the flexibility and lower risk of t&m works well when the project is large.

What's this about?

Some friends and I started writing a book, but then ran out of steam. However, I still think the topic is relevant: the book was about making a living as a software developer. Specifically, our audience is anyone interested in independent software contracting (ie, not working through an agency). This person might be considering making the switch from full-time employment to contracting, or they might be contracting on their own and considering going out as an independent, or they might already be contracting independently.

I'm going to be putting up bits and pieces of what was written. Please enjoy.

Dan Moore

Other contributors:

Corey Snipes

Andy Pai