Subscribe to Sergio Tapia - Lost in the GC.        RSS Feed
-----

How to Effectively Deal With Clients When Freelancing

Icon 6 Comments
Tomorrow is a big day for me. As you may or may not know, I've built a system for a school here in Bolivia. It's the whole shebang, CRUD, reports, stats and more.

Tomorrow I head out to two different schools and pitch my software to them. The great thing is, since the application is already in production in another school, it'll feel more 'tested' and 'reliable'. Plus I look good in casual business. :)

When I look at it done, from a birds eye view, it seems it's not that complex. But then I remember some of the things that contributed to the effort I had to make to finish it.

  • It was my first ever freelance project that I had to finish from top to bottom. That's a lot of pressure.
  • I didn't fully appreciate the scope of the project when I first took it.
  • I didn't quite understand what the client wanted, and it seems in retrospect nether did the client!
  • I had to learn certain things hitting the ground running.
  • I had to design the applications GUI. I made a conscious effort to make it pretty.


I've learned a lot in these past 4 months. So I've decided to try to write them up here and share some of the things that they don't tell you in college.

Clients don't know what they want half the time.

It's your job as a developer to identify the problems a client faces on a daily basis and identify your role in solving that problem. Remember, they're buying your code, your software, because they think it'll help them work faster. They couldn't care less if you use IoC.

Try to ask the right questions that will get them to think your way and see things in your light. A good developer follows orders, a great developer injects orders into the clients subconscious. Give them the illusion of choice. :) After all, would you tell your doctor what to do? No, they're the professional and they need to do their job.

Identify where your application is going to run.

If your software is meant to be a client server application, does the business have a local area network in place? Does it have infrastructure or do you have to provide it via a third party? How about current IT policies? Take into account what the ecosystem is like where you're heading and make sure your application is ready to fit right in.

Target OS's - do they run Windows XP or Windows 7? Are the machines slow or new generation?

Take these into account from the get go, or trust me, they'll bite you right in the ass.

Learn to say 'no'.

"Sergio, can you change the size of this font?" "Sergio, can you make these textboxes a bit higher?" These little changes add up, and time is money.

One solution you can attempt is to take note of all these requested changes and when they get a certain amount offer to sell them an update. Don't try to get too much juice out of it, it would be dumb to sell a 400$ update to a 1200$ application.

Also offer a grace period of 30 days where they can request reasonable changes, but learn to say 'No, that is a major change'. Done.

Always use a contract!

I made the mistake of making a 'verbal contract' with my first school. Since it was the place of business where an aunt works, they seemed to trust me. I'll never do this again though, and you shouldn't either.

Contracts, contracts, contracts. Hire a lawyer, invest. If you don't have a lawyer or can't afford one, hit your local law school and ask for legal aid. One of the students will gladly help you for free because it might count for extra credit.

But why do you need a contract?

  • It protects both parties. You and them.
  • You are able to clearly define when the project beings and ends. No more scope creep.
  • You define milestones and payment options.


Protect yourself and your sanity, get a contract. Always!

What are some of the things you've learned on your freelance journeys?

6 Comments On This Entry

Page 1 of 1

jon.kiparsky Icon

23 May 2011 - 10:17 PM
Regarding "Learn to Say No" - this is a good reason to build in flexibility from the start. Things like fonts and such like should be as customizable as possible. This sort of thing is usually pretty easy to include, and you can add it in without substantial effort on your part once you know how to do it. A sensible client will see this as a feature, but don't charge extra for it or they'll want to leave it out to save money. The money you make re-working the presentation layer will never be worth the aggravation it entails. Let them set the background colors, the font sizes, and all that. Just put an easily-discoverable "defaults" button somewhere so they can get it back to what you gave them in the first place.

This sort of thing can be pretty much the same for any Swing application, so it'll be recycled code all the way. Just include it and move on.

Likewise, any literal strings in the application should be exernalized in properties files, so they can edit them without calling you, and anything that you can make customizable, you should. Is there a logo on the splash screen? let them change it. Is there a little midi file that plays while the software is loading? Let them change it. Why not? There's no fun and no profit in micro-level updates, and the client will enjoy "customizing" their new application.
0

codeprada Icon

24 May 2011 - 04:55 AM
I've had my share of experiences when dealing with clients. My policy after a few bad experiences was that no work at all is started until a contract is signed. It's not only because of legal reasons but some clients like to call off projects for many reasons. Once you've stated on the contract the necessary conditions you will get paid for your time if they do decide to call if off.
Contracts also help you keep track of when and what you did.
0

Luckless Icon

24 May 2011 - 09:18 AM
This is perfect advice! I'm looking to get into the freelancing spectrum over the summer. Much appreciated!
0

Curtis Rutland Icon

24 May 2011 - 10:10 PM
Well, I haven't spent a lot of time freelancing, but I have been interacting with customers for a while (internal customers). They rarely know what they want. And really, why should they? They haven't had to think about it before. If you're freelancing, chances are you don't have a Business Analyst and Quality Assurance people to help you out. So you have to learn to think like a BA. Learn to ask leading questions that are designed to make the client think harder. Work out a true business process workflow, not just a "it does this and this." This is huge. Half the time, the clients don't actually understand the scope of their business processes, since they're so used to them. They'll tell you the "80% case", but forget all the exceptions and special cases that just come natural to them from use. And these are usually the most difficult to work around after you engineer your application.

I just can't stress that enough: business process workflow. Make them walk you through each step. Document it. Ask about special cases. And then get them to sign off on it, so three months later when they ask why this one-off situation isn't handled properly, you can say "you never mentioned that, and here's it in writing!"

Other than that, go read clientsfromhell.com for a while. You'll never *ever* work without a contract again. So many people seem to think they can just decide that you're not worth what they agreed, and that gives them the right to not pay you.

And last, if you're doing a website with server pages, don't give them the source, if possible. Compile it into a deployment package. Then they'll have to come back to you for upgrades. If, at that time, you don't want another contract, then you can give them the source if you want to be nice, or tell them they're SOL.
0

Hiram Icon

26 May 2011 - 05:22 AM
@Curtis, I think you meant clientsfromhell.net :)

Great advice through all of this! I have a friend who's working without contracts now, I'll be sure to tell him about the website.

I haven't had a lot of time freelancing, but the little experience I have is to try and actually do the jobs you're trying to simplify, when you can. Say you're writing accounting software, you could spend a day or two learning some basic accounting principles, and do some work with the accountants and their current software to get a feel for what you're trying to improve.

Like Curtis said about clients telling you the "80% case", but sometimes employees do it on purpose. Why? Because they think you're there to make them redundant, and don't want to give away everything that makes them worth employing. Sometimes with those employees, it's worth taking the time to assure them that you're there to make their job easier, and not a machine sent back in time to get everyone fired.
0

NotarySojac Icon

31 May 2011 - 12:55 PM

Quote

After all, would you tell your doctor what to do? No, they're the professional and they need to do their job.


Good article, but I gotta say, I tell my doctor what to do all the time. Doctors in my country just don't take their jobs as seriously as programmers do =P
0
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)

About Me

Posted Image


Bienvenidos! I'm a USA ex-pat living in Bolivia for the past 10 years. Web development is my forte with a heavy lean for usability and optimization. I'm fluent in both English and Spanish. I guest write for the popular Python website Python Central. Visit my website.

Categories