Getting More Success from Your Web Developer Contractor
For those of you who use contractors or outsource partners for your web development, you may occasionally have trouble getting the developer to give you an accurate expectation of hours or costs within at least a 20% margin of error. So, if your project budget is $4000 USD, and the contractor agrees, you don’t want to find the work unfinished and learn that he needs more than 20% more cash to complete the task. The hardest pill to swallow, however, is that the cost overrun might not be the web developer’s fault entirely. Here are some tips for getting better results.
Using the Right Type of Firm for the Task
There are usually differences between working with a firm that specializes purely in outsourcing, versus an agency or freelancer. The outsourcing keyword is usually applied to a section of the market that has workers on a small wage simply because the currency is weaker in that country than in many Western, developed countries. For instance, the Indian rupee trades at around $48 INR to every $1 USD. Now, that’s not exactly an apples-to-apples comparison, however, because $1 INR may not buy the same things as $1 USD. As a general rule of thumb in 2009 using an Indian outsource partner gets you about three to four times less cost on a project. However, outsource firms are not typically known for being the best quality solution for very large projects or very large project estimation. Instead, outsource firms have two fundamental strengths, and those are (a) broad diversity of skill, and (b) inexpensive quality in smaller tasks. I have worked with many international clients over a three year period, and I typically hear about quality deficiencies in very large projects such as an entire website project, or even task abandonment. However, I do not hear this regarding outsourcing for smaller tasks. In fact, my experience has shown that outsource partners perform better than other kinds of firms at doing smaller tasks. On the other hand, an agency or freelancer may have a higher rate, but so too will they likely have higher quality, better large cost estimation, better communication skills, and fewer cost overruns or abandoned tasks. Their main deficiency, however, is smaller diversity of skill unless they utilize outsource partners.
Communication Clarity and Functional Specifications
Regardless of whether you use an outsource firm, an agency, or a freelancer, the hardest pill for clients to swallow is that cost overruns might be largely due to their own doing. The largest reason for that issue is a lack of communication clarity on what was required. This reveals itself as feature creep as well as project expectation misunderstandings, which then leads to frustration, communication breakdown, and/or cost overruns. Simply put, many clients do not understand how to detail their requirements close enough that the web developer fully understands. Not knowing enough about web development, many other clients assume way too much about how easy it is to slip in extra features. Last, many clients do not think of all the aspects necessary in website development when seeking project bids. It is remarkable how many clients are out there who do not consider time required on areas of testing, hosting, follow-up customer support, systems administration, features in the site administration, scalability, the burden of handling eCommerce chores, site documentation, site monetization, and marketing.
Many clients new to the world of web development do not understand the functional specification process. The functional specification is your list of requirements for the project. This may or may not also include system diagrams showing workflow, user experiences, database diagrams, and server intercommunication. Also, this may include mockup wireframe screens of the website to show what the page functionality should be. Actually, the more that can be put into this document, the better. This is a document that either you construct yourself, or have your web developer ask you questions and compose, or you collaborate with your web developer. Usually if the process requires the web developer to ask many questions and then build the functional specification for you, this has a fee associated with it.
When building one of these documents for the first time, you start with a 1000 foot outline of what takes place in your new web project. Usually that outline looks like so:
- Executive Summary
II. Front-End Requirements
II.A. Overall Experience
II.B. Visitor Experience
II.C. Registered User Experience
II.D. Administrator Experience
III. Back-End Requirements
IV. Other Requirements
V. Risks and Mitigation
The document starts with a short, one-page executive summary that describes the general nature of the project. Next comes the front-end and back-end requirements. The front-end should be divided into 4 or more sections. The first section is a catch-all to explain the overall experience of the website that may not pertain to the visitor role, the registered user role, or any administration role. This is followed with role-specific experience requirements. Next comes the back-end requirements which can be outlined in many ways but it is a good idea to also include these topics:
- software requirements
- hardware requirements
- web hosting
- mail configuration
- specialized device configuration
- database diagrams
- server intercommunication diagrams or service intercommunication diagrams
- features in the site administration
- scalability configuration
- eCommerce configuration
- tape backup configuration
- system alert configuration
This is followed by the Other Requirements catch-all, which usually contains topics such as the following or more:
- testing requirements
- security requirements, including such topics as SQL Injection, XSS, Password Hacking, and so on
- warranty expectations
- bug reporting process
- code check-in process
- systems administration chore expectations
- eCommerce chore expectations
- site monetization plans
- marketing plans
- site documentation requirements
- customer support chore expectations
- system maintenance schedules
- third-party interaction or other issues
- any other requirements
These Other Requirements should also specify whether the web developer role services these items in the project or whether another employee or contractor is to service these requirements.
Next we have Risks and Mitigation, because all projects have risks. One known risk could be that the contractor you have hired may or may not understand a technology component, but is still worthwhile to be used on the project. Another risk might be that you might be uncertain a key piece of functionality will work. Many other risks may revolve around system maintenance, unexpected outages, scalability, and system communication disconnections. The thing to note is that it is not a sin to list these risks. It is better to get those out, up-front, and then work on plans to mitigate those risks as the project proceeds. Usually it is best to push the risk mitigation to the start of the project, which usually involves something called Proofs of Concept. The web developer is usually paid to perform these short tasks before the larger project engages, and that helps you mitigate the risk of assigning the developer to a project that cannot work for one or more reasons.
So, as you see how the functional specification is written, realize that it is not set in stone on this process. Obviously it helps to be as detailed as possible, and to pay your web developer to help you get to a finer detail. Sometimes web developers may in turn create something called a Technical Specification, which goes even deeper into the functional specification if the client chooses to have a lighter-weight functional specification for reasons such as office politics or any other reason.
It should be noted, however, that time is money for your web developer. So, if you ask your web developer to spend like two or three days asking you questions to complete a thorough specification, it is a good idea to pay him for it. Besides, even if you do not choose that developer, you should feel confident on time well-spent to build a great document that can be used for this developer or any other developer. This document will save you money in the long run because you are being clear on what is required.
As well, changing your mind is usually an expensive thing when a project engages, so it is worth it to you to spend a couple days to reflect on your functional specification before passing to your developers.
One accelerator on a project is if the web developer can already receive either the main theme page template of the site either as TIFF or PSD images, or as XHTML/CSS website files. If you more than the main page template, that’s even more ideal. However, this is the ideal solution, but you may not have already outsourced that, or may want your web developer to handle this. In that case, you need wireframes.
Wireframes are simplistic screen mockups that visually show to your developer how you want functionality laid out on the page. A great way to do this rapidly is to start with white sheets of paper, draw very lightly in pencil with an eraser to sketch out what you want, and then go back over it with a medium point black marker to make the lines more clear. Now erase any remaining, visible pencil marks. Sometimes it might even be suitable to make a photocopy of these drawings if it makes the page look more clear. Then, get a scanner and scan the documents into either bitmaps or PDF documents so that they can be emailed to your developer during the functional specification stage.
If this is too much for you to do on the project, then consider paying either your developer or a web designer who specializes in wireframe mockups and page design to build this for you.
Understanding the Web Development Project Workflow
Many new clients do not understand the typical web development workflow. This usually moves in this order:
- Identify initial requirements in brief and build your project request. This project request actually has a formal name called a Request for Proposal, or RFP.
- Put your RFP out for bids. Often this means paying to advertise on marketplace job boards such as SitePoint.
- The bids will drive questions from multiple development individuals or groups. Answer these questions and provide a little more detail, but hold your proprietary competitive information for a later step.
- Once you settle on your final shortlist of developers to your linking, distribute your Non-Disclosure Agreement (NDA) to them to ensure that they will not share proprietary competitive information to other clients before your project is launched, and will not share valuable trade secrets that are only used by your system.
- Optionally, you may exchange contracts if the project is large or the risks are large. You (as client) may exchange a contract with your web developer, but he may also issue one to you as well.
- Once your shortlist of developers and development groups have passed the NDA screening, you begin to list your requirements. If you are a new at this step, then it is a usual practice to pay anyone a small fee to ask you questions and build a functional specification. This is why it is key for you to try and do much of this yourself in order to keep your costs down. You should not expect that development teams would continue spending a full week, unpaid, helping you make up your mind on a functional list of requirements.
- Once the developer teams understand your requirements, each will present to you a Statement of Work proposal, known as a SOW or as a Development Proposal. This also comes with a project cost estimation with milestones.
- From the list of SOWs, you clarify any misunderstandings, which might mean revised SOWs or a revised RFP to initiate new SOWs.
- Now you can sort out which SOWs meet your expectations and determine the proper developer or developer group for the task. You notify which developer or developer group has won the project and individually thank the others for their participation.
- At this point, you exchange greetings and get the web-based project management tool online, even for small projects. (This is described further in this article.)
- The developer is usually paid a small non-refundable deposit to begin the project and is considered “honest money” so that he knows you are serious about paying the developer. Various schemes exist for this deposit but the most common one is 15% to 20% of the project estimation cost up to about $2000 USD.
- You interact with the developer and perform check-ins (usually every 3 days) to see a status update and judge how close you are to hitting milestones on time, or to identify any unexpected results and mitigate those risks. As well, you participate in the testing or assign a tester to assist the developer in testing.
- The project is finished and goes through final testing. Any problems that arise are also resolved here.
- The project is hosted and load tested. Any problems with the hosting or load testing are resolved here.
- The project is security tested. Resolve any security issues here.
- Any final issues are logged and resolved, or marked down as to be tabled for a future phase.
- Along the way, the developer or development group is usually paid every 2 weeks or every month, or you may choose to pay at each third of the project.
- The developer or development group usually satisfies a 30 day warranty period here where any further bug reports are filed and fixed. One cannot expect development teams to keep fixing bugs or doing any kind of website chores past 30 days for an infinite period of time — one cannot work for free. This is why it is very important for clients to try and identify any remaining bugs and get them fixed before the 30 days are up.
- Your developer may ask for authorization to list your site in his portfolio. This is actually a good idea for you because it provides yet one more avenue for traffic to your site. Consider this here, or even offer it to your developer, and even if you think you need to have strings attached to that authorization.
- At this point, the project is yours to identify any future phases. This means the workflow begins again in a cycle.
- It might be good here to provide a good recommendation for your developer, or let other business associates know of how pleased you are with him if this is the case. It benefits you both because if he has a steady workflow, he can potentially lower his rates on your next project, it increases his skill level with each new project, and it increases your stature with him to want to accept more projects with you.
Not Like Building a House
So then comes the issue of estimating project time. One thing to understand about website development is that it’s not like building a house when it comes to forecasting accurate costs. Typically a house builder can forecast accurate costs because his materials cost do not fluctuate rapidly, and because after a few years of experience he has done most tasks and is not often presented with new levels of difficulty. This is not so with web development. In web development, the technology changes rapidly, and developers must evolve rapidly to that market trend or they lose business. This means that web developers must spend at least 10% to 20% of their week focused on learning new APIs, frameworks, or development styles to meet market trends. As well, because some may outsource parts of the development, and because currency can fluctuate, their costs may need to move up or down to accommodate.
Another problem is that web developers may have done a previous task such as on a prior year, but this year they may do that task entirely differently because they have become better developers, and so code snippets cannot always be reused that might have saved time. This comes into play if you have asked a developer to do a task for you on one year, and then expect to reuse that code on the next year for a different kind of site — some things can be salvaged, but as the developer grows his skills, some things are not salvageable because he may feel that there are better ways of doing this.
Accepting a Margin of Error
Unfortunately, since web development project estimation is not like estimation for building a house, the process requires a 20% margin of error usually, and estimation is often a black art. To give effective estimations, web developers have to be stabilized a good bit on the platform you are seeking, and have kept work logs as they progressed through tasks so that they can record how many hours they might need on a similar task. Many clients new to this process, however, do not accept a 20% margin of error because they do not understand this process. They may still think that web development project estimation is like building a house, and that’s a problem that new clients need in order to get good results.
Factoring In Occasional, Brief Burnout
Another problem with very large projects (those requiring more than 2 months of development) is that web developers naturally have a sense of burnout every 3 months and their time may slow down for a week. Take you for instance, and let’s say you run a lawn mowing business. If you mow lawns and trim weeds and hedges every day, could you sustain yourself solid into your third month without needing a mental break where you work a little slower for one week? You probably would need that. So too would a web developer. This requires estimation padding to some small degree, but generally in these periods it is good for clients to catch it and switch a developer over to another aspect of the site for awhile until he recovers.
The Power of an MVC Framework
In web development, there are two ways to build a website — the organized way, or the unorganized way. The unorganized way might get your site up fast if it’s small, but delay larger sites, make it hard for your site tasks to be delegated out to teams of developers, and make it hard to extend the initial work. The organized way is the best approach. It gives you some small delay on small sites to get going, but has long-range advantages because it has none of the disadvantages of the unorganized way of web development.
On the other 50%, you see the organized way. At a minimum, this means that the XHTML and the server-side code are separated. However, taking this to its fullest extent, the developer may be using what is called an MVC Framework. This type of framework stands for Model, View, and Controller. As a client seeking developer help, you really don’t need to analyze what this means except to know that it separates XHTML from the server language (PHP, for instance), creates routes so that URLs call files in an organized fashion, and creates object models for database interaction so that the SQL language code is not as messy. That’s superb organization. In the PHP world of web development, some well-known frameworks are Zend Framework, CakePHP, Symfony, CodeIgniter, Kohana, and many others. Some are well-known, but difficult to use, such as Zend Framework. Some are full-featured but have somewhat of a learning curve because of it, such as CakePHP. Others are fairly lightweight and yet quite capable and powerful, such as Kohana.
Taking this down a notch, you can use a templating system instead of an MVC framework, although in many cases MVC is better. Still, it’s better than no organization at all. You may find that the template system in WordPress is quite easy to work with, and then build a site out of that. Or, you may hear of a template system like Smarty. If I don’t use WordPress for a site and extend it from there, then my favorite template system is called CCAPS, for Carefully Controlled Alternative PHP Syntax (see Resources). There are many template frameworks out there, should you wish to simply go that route instead of the full MVC framework system.
Good Project Management
When you work with your developer, one of you should be keeping track of issues and time, and have a central place where passwords are kept and files are exchanged. This place should be separate than your email because it keeps things better organized. An experienced client often is the one who has a web-based project management tool that they subscribe to such as Basecamp. However, a web developer working with an unexperienced client may be the one expected to subscribe to Basecamp for the project. In Basecamp you are provided with an intuitive system for tracking the full overview of the project status and previous tasks, outline tasks, list issues, leave messages in an area outside your email, store server passwords, and exchange files. However, there are many other web-based project tools out there. You should surf around for something you can afford yet is easy to use with a low learning curve.
Often in your web-based project management tool it is a good idea to create these default message groups:
- Status Update
Do this early and set the tone here. This keeps the project focused and not split out into a long list of separate discussions.
Good project management also means establishing hours and particular days when you are available and trying to have chat, Skype, email, or some other means available open for your developer. It only benefits you to be available. As well, it is a good idea to provide to your developer some kind of emergency contact information, but only when you have established some successful milestones with your developer and gotten to know him better.
It is also the norm to check in with your project management tool at least every 2 or 3 days to see a status update, even if it’s just a couple bullet points, and interact with your developer if this goes missing or if you feel nervous about a milestone deadline.
Although tough to work out, but it gets better as you do more websites, it is good to try and reserve judgment at first and try to have faith in your developer, giving him the benefit of the doubt. This is elastic to some degree and can break, but try to give every developer like a three strikes rule before reconsidering the contract. Sometimes just cooling off for a night or having a slow day of rest can help both developer and client realize the potential here to work better together and accomplish the goals of the contract.
Last, try not to be an irritant to your developer, and expect the same of him. Good interpersonal skills and netiquette is required here, such as lowering the unnecessary chatter of non-project-related news and other diversions, even if humorous. However, it is often good to break the ice at the start of a project, and during the tough times, with a small amount of humor or something cheerful to say, as long as it doesn’t try to introduce humorous sarcasm, which could backfire. Try to remain in the project tool and not use too much email, which can create potentials of lost communication. You should also try to reward your developer with praise during milestones where appropriate. You should also ensure you avoid typing in caps for any reason, no matter how mad you are, because this is unprofessional and not acceptable by any means, and merely escalates the problem.
Win-Win Money Arrangements
One thing that will make your developer not want to work with you are the level of freebies you request. Simply put, time is money, and your developer needs to pay bills. He sincerely wants to give you the lowest cost possible, but cannot if he’s being asked to provide several things for free that make his own bill-paying budget slip. For instance, if you can’t make up your mind on a functional specification and require your developer to spend more than 2 days unpaid to help you clear your mind, that’s crossing the line. If you like how something was implemented to the functional specification and want to add some extra features, you should never ask the developer to add those in for free — there should be a price on everything, including something small, once the project begins.
With the issue of freebies aside, the ideal arrangement for most web developers is a 15% or 20% non-refundable deposit to start the project. This ensures you are serious about the project. It also helps a developer get back on track with his own bills while he was doing his sales and marketing period.
Once the project is started, it is often acceptable to pay the developer either every two weeks or every $2000 USD (on 2009 prices), or no less than every month. There’s a very important reason for this. Imagine if one of those payments was for $4000 USD on wire-transfer, and went missing! Yes, it happens to every developer some day, and it can sometimes take as much as two entire weeks or a month to get rectified through the banking systems. Therefore, it is better to have these financial accidents contained into smaller packages.
As well, just because 80 hours may have passed on a project, that may not mean 80 billable hours. It depends on how much work was accomplished, and unfortunately this is a touchy area here that requires finesse on both the client and the developer to determine how much of those 80 hours is actually billable. Be careful, though, because it could mean that you lose a developer and must do the difficult task of finding another one, should you not find a good contractual agreement here on payment.
Do not assume that your project is too small and cannot benefit from many of these steps. In fact, if at the very least, I recommend you follow the monetary aspects of this guideline, use a functional specification even if you have to pay your developer for 3 or more days to develop a good one, consider at the very least using a template system for better organization of site code, and use some kind of web-based project management tool for organization. Remember also that small projects can become large ones.
The tips listed here should provide more comfort to yourself as the client, and to your developer, make your expectations clear, keep your projects on track, and keep your budget as low as possible.
Basecamp Web-Based Project Management Tool
Kohana MVC Platform for PHP
CCAPS Template Guideline for PHP
Smarty Template System for PHP
The MVC Model of Programming Design