Bad Business – Avoiding It
Most clients and potential clients that contact me have a pretty solid idea of what they would like to do, and how much they want to spend to do it. We spend time up front to flesh out ideas and explore possible solutions that the client may not have considered, or maybe isn’t even aware of. I love the start of new projects – new projects are all about possibilities, and I am a 100% a possibilities type of person. But once in a while at the start of a project the spider senses start to tingle…
Long before I went freelance in the mid 90′s, I acquired the mantra “Don’t take on bad business.” That phrase is my “tingle.” Early on I had a handful of specific things that I kept an eye out for, but over time it became more part of intuition rather than conscious thought, and I stopped thinking about the specifics so much. “Bad business” is a project that has a higher risk of failure than I would like to take on. I’ve been fortunate over the years to have had only a couple of projects go seriously awry, but they were incredibly painful to go through. I find that it takes time to recover mentally, and you lose money to boot. It is absolutely acceptable – no, it’s imperative – that freelancers and agencies turn away bad business. It can be difficult to turn away potential income, especially if work is slow, but the downsides are simply not worth it.
I read an article on Mashable by Brett Miller that does a nice job of explaining many of the potential problem spots. The article focuses on software development, but the points hold for any project that a developer, designer or agency takes on. We’ve all come across most of the issues highlighted in the article, but one stands out for me:
Too many cooks – this is the “Deal with Decision Makers” item on Mr. Miller’s list, and is by far the number one concern for me. It has manifested itself in a variety of ways, but there is one project kickoff scenario that terrifies me: If I walk into a conference room with a big group of people, my warning bells immediately go off. If during the meeting it is clear they don’t agree on what the final product should be I’ll hear everything out, and if a common vision can’t be agreed on by the end of the meeting, they’re not ready for me yet. I advise them to work together to define what they need and then bring me in. Any potential project that brings in a designer or developer that has various factions in disagreement is simply not ready for development yet. There are certainly options for getting involved and helping drive the group to a set of requirements, but I have found that too often the client then thinks “real work” has started (and the project clock is ticking), when in fact from my perspective the project can’t start prior to requirements definition.
Unclear requirements is probably the second most critical item on my personal “Bad Business” list, but that can often be worked through with a client. Mr. Miller is right in pointing out that time is valuable, so if I’m getting involved in helping define requirements, I need to see some money up front. That does two things: First, it ensures the client has some “skin in the game” – they are much more likely to follow through on a project that they’ve already invested in, and second, it lets them know that my time is valuable, and that defining requirements and specs is an important part of the work. A freelancer is a professional, and should be treated as such.
