If you’ve ever hired a developer, or development company, to perform a web based service for you or your company, more than once or twice, there’s a good chance you’ve experienced one of the most frustrating situations that can avail us: The Nightmare Development Project. Now, I have no idea who was to blame for your particular Nightmare Project, but there is one thing I can guarantee – the developer would say it was your fault, and you would say it was their fault. In most cases, both are true. Of course there are those exceptions, where you truly did get a very wicked seed and there may not of been much you could’ve done about it, but for the most part, these Nightmare Projects are a lot easier to avoid than most people, Developers and Clients alike, realize.
That being said, I myself have been on the receiving end of some Nightmare Projects and in the many years of experience I’ve wracked up, I’ve learned a pretty good strategy for ensuring all of our Projects are the right kind of dream – and NOT a Nightmare. 😀 So I thought I’d share my insights with anyone out there on either side of the spectrum; because Developer or Client, none of us deserve to go through the frustration, anxiety and immense extremes a Nightmare Project will bring.
- Be Choosy! – This is NOT the type of industry to automatically go with the low-ballers because they’re the cheapest. Pay peanuts, get monkeys – period. I believe we all know this one well enough that a detailed explanation is not necessary here. You know better – don’t do it! Carefully interview and choose your developers, paying attention to past reviews, ratings, proposal quality, cost and expertise.
- Project Listings – Now a days more and more clients are selecting their developers from websites such as Elance, ODesk and Freelancer. This is fine and can work for you well, but remember that a third party set up is never a substitute for due diligence, in any area of the project life. When listing your project, be very specific, professional and thorough. Creating a nice, sweet listing to entice more applicants is a horrible mistake. Your listing will set the tone for the type of applicants that respond to you. Therefore be detailed, thoughtful, professional, precise and firm in your needs and expectations; doing so will attract more of the same types of workers, which will be to your advantage.
- Communication – I can not tell you how many times I have responded to a project listing, with a proposal on sites like Elance, only to find an award in my in-box the next day – the client having hired me without ever exchanging an actual conversation! A good proposal, is a good first step. However, it is only that – a first step, there are many more things to consider, and having a conversation to establish whether or not good communication is possible, should always be the very next step. Another big mistake made here – is conducting this extremely important communication foundation through email or IM. DO NOT DO THIS. Have a telephone conversation! Hear your applicant’s voice, sense their demeanor, learn their attitude; communicate. This will tell you so much about your applicant, and will establish a great foundation for your expectation of an involved project communication line. I have had many clients tell me they avoid this because a lot of their developers live in different countries and do not speak English very well. This is a horrible excuse in my opinion: if someone is able to understand and respond to the English language in an email, they can do the same over the telephone. A language barrier, if bad enough, can cause a big problem in communications and should be heavily weighed; that being said, a phone conversation can be a great way to gauge the severity of this issue.
- Requirements, Requirements, Requirements! – It is imperative that your developer put together a set of Requirements for your project. So many people think because they’re on a third party site, or because they already explained everything in their project listing that this step is not necessary. Nothing could be further from the truth. Requirements are the back-bone of every project. Of every item on this list – this is the most important rule to follow. A set of Requirements is the governing document for your project; the instruction manual, the expectation guide and the deciding factor should scope questions arise. This document is way too important to gloss over, I can not stress this enough! Over in our FAQ Section, I have laid out a very detailed answer to what a set of Requirements should entail – please take a moment to read this, as it will save your projects later – I guarantee it. Make sure your developer prepares a set of Requirements, a proper set of Requirements, that you are given an opportunity to approve and/or request changes in. Never allow your developer to skip this step and never approve a set of Requirements you’re not 100% comfortable with.
- Cool, Calm, Collected Behavior – This one can basically be summed up in one word: Respect. Mutual respect between you and your developer is essential to ensuring a smooth project. If your developer does something, or doesn’t do something, that upsets you, frustrates you or even irritates you beyond all comparison, it’s perfectly understandable that you would say so; however, saying so in a nasty, rude or unprofessional manner, or even with just a slight attitude, is never going to work to your benefit. I once had a client who spoke to me like this: “Nicole, thank you so much for all your hard work on the project, we really appreciate it! I’ve noticed that you haven’t implemented the contact page exactly as it was proposed within the mock, though it is really close and looking well – would you mind getting that completed this afternoon? Thanks!”. Now, I know that’s going a bit over board for some people, however – let me just state for the record, I would’ve lassoed the moon for that client if asked to. Kindness and appreciation, together with a request or even a complaint, does wonders for your developer, I promise. 🙂
- Expectation Management – This is a very important, very often over-looked aspect of any business relationship. You must always be constantly handling expectations in such a way as to prepare your developer for their expected behavior. Case in point: Your developer misses a deadline by a few days. It’s a small deadline, not a big deal, so you don’t mention it and just handle it graciously. Very bad idea. That particular milestone/deadline may well have not been very important, but you have now set an expectation on the part of your developer, that it’s not a big deal to miss a deadline. This isn’t to say flying off the handle is appropriate either, of course. A small, calm statement of the missed deadline, the accountability of the developer and the expectation for the behavior to not be repeated, again in a respectful manner, will let the developer know that you have an expectation of him/her to be on time, and he/she should have an expectation of knowing this is not acceptable to you.
Those are my Top 6 rules for a dream boat project. I know what you’re thinking, “What a cinch!” right? Not so fast! The above are great rules to go by during any development project, but it’s a lot easier than you think to be tricked into throwing them out. I’m going to list a few of the most common situations which make it seem like a good idea to bypass all, or some, of the above policies. One thing to remember; these traps, as I call them, are most often not orchestrated or planned – I don’t aim to paint the picture of an evil developer, twisting his mustache and laughing hysterically while planning your eventual demise. More often than not, these situations are never planned or deliberate, rather someone makes a bad judgement, which leads to a crisis for everyone involved later in the project life. Don’t think of it as everyone being out to get you; think of it more like this: we’re humans, our nature is to gravitate towards a friendly and casual dealing with people, this has a tendency to create many bad decisions which collide into a Perfect Storm situation and destroy our Project later on – it is not a deliberate, blame game type of deal – it’s just a situation which, due to the nature of the work and business, needs extra attention to ensure smooth sailing for everyone. There is nothing wrong with having a friendly relationship in business, just remember what I will repeat below and what should never leave your mind: “You are conducting friendly business, not conducting business with a friend”.
- The Friend Trap – We’ve all been there. “Nicole, come one – you’ve done many projects for me before, we’re old buddies….no need for all the red tape – let’s just jump into it!” It is very easy to slip into a working relationship, in which you become so comfortable, that you let both your guard, and often times, your good judgement, down. This will almost always come back to haunt you, no matter the closeness of the developer to you. Never forget the first rule of business; your business acquaintances, are not your friends. There isn’t a thing wrong with being friendly, of course – but understand that you are conducting friendly business, not conducting business with a friend – the two are quite different. Follow all your procedures and all of the above rules, ALWAYS.
- The “Just Real Quick” Trap – Often times, especially with repeat business dealings, we get into a situation where we want a small, insignificant, low cost project completed, and fall into the trap of thinking that because it’s so small an amount of money and/or work, that it’s down right silly and a waste of time to follow all the procedures. I’ll just do this really quick and it’ll save us both time and money. This is always a very bad idea. Not so much because the actual small or low cost project may itself be at jeopardy, but more so because it sets a casual expectation for future dealings. Remember #6 above – Expectation Management – this one rule is the easiest and quickest to destroy a project than the others combined. Always manage expectations within the project, on both sides: yours and theirs.
- The Circumstantial Trap – This is the one that always used to claim me as a victim. So many times, instead of following each of the above policies, I allowed a particular circumstance to over write them. Someone had a personal crisis, a time delay which was no one’s fault happened so the policy standards became unfair, the other party performed a favor for me, so I felt guilty standing firm to a policy afterwards – you get the picture. You must always remember to tell yourself: a special circumstance does not make your policies null and void – ever. If the policies were something that could be changed or thrown out from circumstance to circumstance, they wouldn’t be policies; a policy is something in place because past experience has shown you that not adhering to it causes significant problems. Do not allow sympathy or a guilt trip over favors/freebies to persuade you that your policies can be over-looked just this one time. Be a good person, show sympathy and understanding for a person’s situation if needed, give thanks and praise for an extra effort or free service offered; draw the line there. A reasonable person will never expect you to compromise your policies for their own crisis or generosity. Period. If a situation is not one of the above two traps – it will most likely fall into this one. I learned the hard way (the very, very hard way), that a change in circumstance never constitutes a change in policy. Remember it, practice it, repeat it.
Well folks, there you have it: a developer giving you the secrets to maintaining a great Development Project. Although, the real point here, is that the path to a truly successful and smooth project, comes not through a set of secret rules, or a magic potion – it comes through diligence of principles and policies we all should be aware of. I believe most of us are aware of the necessary policies to follow, it is the diligence in sticking to these policies under pressure, guilt and circumstance that really make the difference.
