About PM4Web

The PM4Web blog was born as an outlet to return knowledge back to the web development community. My goal is to share my experiences as a project manager from over the years in a manner which helps you succeed with your own projects.

25 March, 2009

10 Common Problems Web Developers Encounter

Solutions to common problems web developers deal with during a project

After spending a few years developing websites both big and small, certain patterns seem to have revealed themselves. Over time, you adapt to these issues and forget about them, but the reality is other people will encounter these problems in due course. For that reason, i thought a quick treatise of these common problems was called for.

Considering the same challenges crop up again and again for everyone in web development, it’s interesting to note that different people come up with different solutions to the same issue. The context often defines what an appropriate solution is, so what works for one business may not work for another. Obviously, I can only talk about strategies I myself have used, or ones suggested to me by my peers (nb. there may be other solutions I haven’t considered).

Without further delay, let’s have a look at some challenges, and more importantly, some solutions:

1. Content issues – this happens when a customer either takes too long to supply their content, or what they do supply is amateurish or lacklustre. The most common way I deal with this is to use some place-holder text, with the intent of having the client say “hey, that’s not my text”; this can prompt them to put in their correct content. Another trick is to use a questionnaire to illicit responses from the client. This can be used as the basis for writing rudimentary content (e.g. “what does your company do?”, “who are your customers?” etc). A technique I have used in the past is to turn off pages which are empty (e.g. client: “where’s my press releases page?”, developer: “the page hides itself if there is no text on it”). I recall reading an article some time back which suggested getting a copywriter involved from the start of the project. Having someone work closely with the client at an early stage is a good method for ensuring copy is ready prior to launch.

2. Delays in obtaining the company logo or graphics files – it’s pretty hard to start on a website when you don’t have the client’s logo. Often this is just a case of getting the client to contact their graphic designer to get you the files you need. This isn’t a major issue, but it can cause a small delay which is unnecessary. All you have to do is give the client forewarning that this material is required. This is why one of the questions I have on my Needs Analysis form is “is your logo & branding material ready?”

3. Vague feedback and indecisiveness – this is a situation which can result in not only delays, but rework which isn’t billed for. This really boils down to ineffective communication. A classic example of vague feedback is “I don’t like the design” (a more helpful version would be something like “the design doesn’t communicate the fun and relaxed nature of our company”). The evil brother of vague feedback is indecisiveness, or when a client is unwilling to make a firm decision on how something should be. With vague feedback, patients is the remedy. Some would say it’s a matter of ‘educating the client’, I find that term to be somewhat condescending. If I get feedback like “I don’t like the design”, I would respond with “what in particular don’t you like?” or “can you be a bit more specific, I need more detail in order to get your design right” (the response depends on the client’s personality, understanding the DISC model helps). In the case of indecisiveness, if it’s related to a feature, I will make it an option in the admin module (e.g. an option to show a group of company logos horizontally or vertically). With this approach, the client can set it whichever way they want.

4. Scope creep – the bane of a developer’s existence. This topic alone could span many pages, however I will try keep it simple. Scope creep occurs when a client asks for features which weren’t originally agreed upon. This can be problematic as it can cause delivery dates to shift and displace other work, it can introduce new bugs in established features, and impact on momentum. Some people take a hard line on this matter, suggesting that you should just say ‘No’ to the client. I have a personal philosophy which goes like this “there is no such thing as no, it’s yes – and this is how much it’s going to cost”. At the end of the day, it’s about business, if a client is willing to pay for the work, it’s simply a matter of project management and version control. One technique I use when developing large web applications is to group features together into a ‘mini-spec’. These features would be added to the system after launch and thus constitute a point upgrade (i.e. v1 ;rarr; v1.1). A good suggestion I have also seen is to create a cost-to-benefit spreadsheet in consultation with the client, that way they can prioritize and understand added costs.

5. Undescriptive bug reports – client: “the system crashed” or “the system is buggy”, developer (thinking to himself): “gee, thanks for all the information”. Explaining to a person that a bug can’t be fixed unless they give more detail usually solves this problem. When logging a bug, it’s essential that the person says where the bug occurred, and gives step-by-step instructions on what they did when the bug appeared. If a client knows how to take screenshots and annotate them, even better.

6. deposits, pricing and payment problems – not taking a deposit when working with a new client is unprofessional and exposes you to unnecessary risk. However, deposits aren’t as much of an issue when dealing with long standing clients. Having a good pricing structure for small projects is also important (e.g. projects under $5,000). A good general structure is 20% deposit, 70% milestone payment when most of the work is done, and the final 10% when the client signs off. The 10% final payment is very helpful in situations where a project stalls for whatever reason. There is also the issue of clients saying “but another developer said they could do it cheaper”. In such a situation, you need to demonstrate the value you bring to the table above and beyond your competitors (e.g. quicker development time, face-to-face meetings as often as required, etc). Another major problem is clients that don’t pay their bills on time. The majority of clients are reasonable business people and will respond positively to a courteous reminder, for example: “hi Tom, just a friendly reminder, have you had a chance to pay the last invoice I sent? It was due one week ago. I would appreciate if you could pay this invoice as soon as possible. Let me know if you need to discuss it. Thank you” – will there still be people that attempt to take advantage of you? Of course, but you’d be surprised how far good manners will get you in the business world.

7. Project malaise and uncommitted stake-holders – this can bring a project to a grinding holt, quite literally. It occurs when a client loses interest in their own project or decides to focus their energies elsewhere (usually on more pressing areas of their business). There may be times when this is understandable, for instance if a client is about to launch a new product or needs to spend time on ‘disaster recovery’. I don’t have a sure-fire solution for this problem, other then being proactive (e.g. get on the phone, communicate). If you have the time and inclination, you can take onboard tasks which were originally assigned to the client (e.g. communicating with the graphic designer directly to get graphics files). That said, you have to be careful not to pressure the client too much, this can actually cause something of a backlash. At the end of the day, it’s up to the client if they want to stall their project. If you have a good payment structure in place, you won’t be unfairly penalized for the delay in project progress.

8. Dealing with third parties or vendors – adding a third party to the project introduces risk because your power to influence outcomes diminishes. Not only has an additional communication channel been added, but so have potential bottlenecks. Take for example a fully-fledged ecommerce enabled website. Here we have three additional third parties which need to be dealt with during the course of the project: 1) the client’s bank has to be consulted with to setup an Internet Merchant Account, 2) a SSL provider has to be contacted to setup a certificate to allow for secure shopping, and 3) a credit card gateway provider has to be involved to provide credit card clearing facilities. There’s a lot of potential for hold-ups there. The best answer for dealing with third parties is to get in early; arrange things which you have less control over towards the start of the project, before they are needed.

9. Best practice advice being ignored – for some people no amount of logic or statistics will satisfy them, they just want it their way (e.g. “there doesn’t need to be a home page” or “i want scrolling red text at the top of my page”). In situations where the request flies in the face of best practice standards, I say the following and then get on with the work: “my professional recommendation is... but it’s up to you how you would like it”. I am a firm believer that the customer is always right. That includes them having the right to make choices which diminish the effectiveness of their product. Some developers have a hard time ‘doing the wrong thing’ on a client’s project, but if it isn’t immoral or unethical – get over it.

10. “I want something like facebook, how much?” – this is an all too common request, any developer worth his salt will have the warning bells go off early when they hear something like this. It may not be facebook or Amazon which they want cloned, it can be any leading website with majority market share. The other tell-tale sign is a ridiculously low budget. Many developers will outright turn down these kinds of projects as they see it as a waste of their time (nb. the client may be ‘fishing’ for free system analysis consultation). Answering the ‘how much’ question can be dealt with by providing a ball-park estimate with a wide variance, for example: “the project could cost between $10,000 and $20,000, I can only provide you with a fixed price once a specification is written”. This brings us to another important strategy to weed out the time wasters. Have the client pay for the creation of a functional specification before agreeing on the final cost of the project.



I would have liked to cover some of these points in more detail, but this article is really meant as a brief treatment of commonly encountered problems. There have also been many other important items left off the list, so don’t be surprised if you see a sequel to this article in future.

Special thanks goes to the people of Stack Overflow forum for their valuable input.

13 March, 2009

Payment Structure on Small Projects

How much to invoice at various stages of a small project.

Note: the payment structures described in this article are most suitable for smaller projects (e.g. around a month in duration).

How much deposit should you take before starting a project? When should you ask for interim payments, and how much should those installments be? These are pertinent questions for anyone involved in software development contracting.

For those that want the short version, what I use is this structure: 20% deposit, a 70% interim payment when most of the work is done, and a final 10% payment on project completion. Unfortunately, this structure does have a flaw, but also a major protection that other structures don’t have.

Let’s take a closer look at some approaches for dividing up payments during a project’s life-span.

Method I, 20/70/10 – although not perfect, it’s the best system I’ve used so far. Let’s break it down and show an example:

20% deposit → before work begins
70% interim payment → when most of the work is done
10% final payment → when the project finishes (i.e. sign-off).

Example project, total budget: $5,000

Payment 1: $1,000
Payment 2: $3,500
Payment 3: $500

When do you send out the 70% invoice? I send out this invoice when my production checklist shows that 90% of all tasks have been completed.

The beauty of this structure is in the 10% final payment. This drastically alleviates the unfair penalty contractors suffer when a client ‘drags their heels’. One of the most common causes of this situation is when a client fails to provide content in a timely manner. This can also happen when a client decides to put their technology project on-hold in order to focus on another area of their business.

The biggest pitfall with this method is the large interim payment. Having to find such a big chunk of cash all of a sudden for a small business can be quite daunting.

Method II, 20/80 – there was a time years ago when I used this structure. An initial 20% deposit before the project started, then when the project finished, I got paid the rest of the money. Unfortunately, this method is fraught with peril.

For example, if a project has a budget of $5,000, suddenly asking a small business owner for $4,000 at the end of the project is just asking for trouble. There could also be serious cash-flow consequences for a contractor should a client decide to delay completion of their project.

Method III, 50/50 – I have worked at a company that used this structure. This doesn’t really need much by way of explanation; its just 50% up-front and 50% on project completion. The biggest advantage of this structure is the large up-front cash-injection it offers. This can be important for a small company which employs a handful of staff. However, there is also a major drawback. If the project drags on for any reason, a large portion of the budget gets locked in limbo.

Method IV, 20/75/5 – this is obviously very similar to method I. This is the structure used by a web development agency I worked for a few years back. It’s where I was first introduced to the notion of a small final payment as a contingency against stalled projects.

Method V, 25/50/25 – this percentage carve-up was suggested to me by one of my peers. This is quite a good structure in my opinion, the amount being asked for as a deposit is reasonable, the interim payment would appear less daunting to the client when it becomes due, and the final payment even if ‘held to ransom’ isn’t a massive portion of the project’s budget.

Method VI, 35/35/30 – another freelance contractor I consulted with described this structure. This particular method is interesting because of the points at which the installments are charged:

35% deposit → consultation, planning, design
35% interim payment → construction of prototype
30% final payment → completion

This approach takes some explaining. Because the client can hold off nearly 1/3 of the project’s value until completion, they can budget more effectively and also retain leverage to ensure satisfaction with the project.

The large deposit is obviously a boon for a freelance contractor in terms of cash-flow. However, the client does have the option of dropping out of the project at the second payment point and taking the prototype. Even if the client did decide to take the prototype as the final deliverable, the developer still gets 70% of the project’s total budget.

One of the great things about this method is that at no point is the client being hit with a massive invoice.

Method VII, 33/33/33 – this approach is used by another freelancer I consulted with. They mentioned that the last 33% usually balloons due to scope-creep. So in effect, the first two payments are of equal proportion, but the last one is commonly larger because of feature additions.

Method VIII, 80/20 – this unique structure was described to me by a freelance contractor. This developer collects 80% of the project’s value by the time the project is complete, via multiple installments along the way. The remaining 20% is charged two months after delivery; if the customer is satisfied. If the client is not satisfied, they are required to write up a half page reasoning to justify themselves. It is at the client’s discretion if they don’t want to pay that remaining 20% if they aren’t happy.

20% of a project’s budget can be a significant amount of money to lose should a client decide they aren’t happy with the end product. Nevertheless, this can be an effective strategy when developing a relationship with a new client. In affect, you are asking a new client to trust you when they don’t know you. So this acts as a statement of commitment to not only complete the project, but to complete it to the client’s satisfaction. Obviously, this does expose the developer to being taken advantage of by unscrupulous clients, but then again, you would know quickly not to work with that client in future.


By no means is this an exhaustive list of payment options, but hopefully it does give you some perspective on what others out there are doing.

You may notice a common theme with all these structures; they are generally in three stages (i.e. deposit, interim payment, final payment). The reason for this is because generating more then three invoices for a one month long project is overly bureaucratic. It also results in an unnecessary level of administrative overhead.

Dilbert in Collections

This discussion wouldn’t be complete without a quick word on the importance of deposits. Any savvy businessman will tell you to get a deposit before starting work, but not everybody does this. As a general rule, always get a deposit before the project starts in earnest. There are circumstances in which I will start work on a project before I’ve taken a deposit, but I will only do a few hours of work before stopping and waiting for the deposit to arrive. If it’s a new client, I won’t start any work at all until the deposit arrives, if it’s a long standing client with a good history of paying their bills on time, then I would happily start work on their project before their deposit arrives.