Integrating into the work environment of your client is often a crucial part of maximizing your effectiveness. (For remote workers, this is important as well. Please see the ‘remote working’ section.) Being able and willing to integrate means that you’ll have less friction with employees, be able to pick up undocumented but important norms, and move more adeptly around the political structure of the client. This section presupposes you’ll be working with a team of some kind–if you are independently delivering software, integration is much less of a concern.
Before the first day
Before you even start a contract, but after you and the client have agreed that you will do the work, ask these questions:
1. Is there an expected level of dress?
2. Is there an intellectual property agreement you’ll need to sign? Can you get a copy of it before work starts, so you can have it reviewed by a lawyer if need be?
3. How would the client prefer to be invoiced? If you have a preferred timeframe, let the client know that too.
4. Should the project work be viewed in light of any larger goals?
5. When should you arrive on the first day?
6. Should you bring your own computer, or will they provide one?
7. What tools does the team use? How can you get them?
On the first day
Getting the above questions out of the way before you start working lets you arrive on the first day ready to work. Coming in 5-10 minutes early can help kick start the day and shows that you are enthusastic about the work. The client may need a little extra time on the first day; be aware that, depending on their experience with contractors, they may not be ready for you. Be patient, but never forget that you’re being paid to produce. Coming in with these questions can help you move the process forward:
1. How do I get the code I’ll be modifying and environment that I’ll be building in?
2. How do I make changes available to others?
3. Where do you get the tools others use? If you haven’t gotten them beforehand.
4. Who is on the team? What are their roles? Make sure to ask for formal introductions, at the least, to the other developers and QA.
After the first day
Getting to know the team you’ll be working with can help you integrate. You want to do this both formally, on the first day or as soon as possible, and informally, which generally takes more time. Informal connections can be quite useful and informative; the best way to cultivate those can be attending lunch. Additionally, clients sometime have company events and may invite you to them. Be open to attending, though always be professional. When you attend such events, be friendly and ask each person you interact with what they do for the company; be interested in their answers.
As you get to know the team through formal and informal channels, begin to note each individual’s strengths and weaknesses. Never share this opinion, but use it to determine your course of action. For example, if Megan has a strong grasp of the data model and its history, but a poor grasp of the UI requirements, go to her with data model questions, but don’t ask her about button placement. You can also gain knowledge of who the decision makers are, which can be useful whne conflict or uncertainty occurs. However, try to never offend anyone, since, as a contractor, you have less knowledge of the inner politics in the client than most employees.
On a more technical level, try to use the same tools as the team. This will help you, because you’ll be able to use the same terminology as the team, as well as leverage their experience and knowledge. It also makes it clearer that you’re interested in integrating with their setup, rather than the other way around. When setting up a development environment, using a virtualization tool like VMWare helps you keep different client environments separate, and your machine clean from unneeded software installs. If the company uses expensive tools, finding out beforehand can help you prepare. You may be able to get by with evaluation copies, if the client will not provide you the tools. In an extreme case, you may discuss buying the tool and billing the client for it.
Integrating into the team doesn’t mean blindly following their suggestions, however. Just as when you’re a ‘hired hand’, your experience with other environments can be a source of real value for your client. Make suggestions from a technical or business standpoint when you feel you have knowledge that could be useful, whether it enhances the technical environment or helps the client avoid a mistake. However, be careful not to appear a ‘know it all’. One easy way to do that is to frame your knowledge in terms of making the current project succeed. For example, ‘You know, I think if we used a build tool, deploying the application would take less time.’ If your suggestions are turned down, you need to decide, based on the severity of the issue, how hard you should push your agenda. At the end of the day, it’s the client and the employees who have to live with the issues inherent in any piece of software, so be gentle when suggesting change.
Conclusion
This section outlined ways that any contractor can integrate themselves into an existing technical team. This may force you out of your comfort zone, but the benefits can be great, as the team will tend to resent you less and may be more able and willing to share knowledge about the project.
Friday, January 4, 2008
Saturday, December 8, 2007
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.
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.
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.
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.
Sunday, December 2, 2007
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.
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.
Thursday, November 29, 2007
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).
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).
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.
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.
Wednesday, November 28, 2007
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
I'm going to be putting up bits and pieces of what was written. Please enjoy.
Dan Moore
Other contributors:
Corey Snipes
Andy Pai
Subscribe to:
Posts (Atom)