No matter how successful a freelancer you are, there are times when things go south; especially when you work online and are limited to mere chat lines as one major form of communication. Sometimes you may get crucified for some minor mistake in communication or perhaps it is not your fault at all in real. Sometimes you don’t even know what hit you. The worst is not knowing and not getting any feedback from the client, which hinders learning from mistakes.
“Always look on the bright side of life” applies all too well to freelancing. Even if you feel you’re being crucified, there’s always light at the end of the freelancing sales funnel. Just learn and keep going.
In this story, I demonstrate a few misses that I have had in order to give you an example of how south things can go and how you can try to recover from tight spots and learn from your mistakes. The smartest ones can even learn from the mistakes of others. That is the best (and especially cheapest) way forward. In the life of a freelancer, it is essential to know how to manage freelancing failures just like managing disappointments in The Life of Brian. 😉
“The client vanished” – Then what?
A complete vanishing act by a client is one of the nastiest things that can happen. OK, maybe a lawsuit would be worse. But I have no experience with lawsuits, so you’d need to ask someone else for that kind of lesson learned.
The only client I’ve ever had vanish was on my second year of freelancing on those online freelance sites. The first three online clients were just great. Even a freelance newbie like me then was able to satisfy their Kinect app development needs. (Kinect was the only thing I did online the first couple of years.)
The fourth one was a challenge in terms of communication. And I failed badly (I still think).
This was one of those project posts for which I was still actively applying. No problem getting the client convinced I was the best applicant. The beginning went really well, as I thought then. The client wanted a rather complicated application with a budget of a few thousand U.S. dollars. Something like that requires quite a convincing-looking avatar movement using Kinect to track the user.
The client’s example shared as a YouTube link was nothing like what is usually achieved with this real-time technology stack, but made with video editing techniques afterward. Unity was the chosen platform, as the client appeared to know the basics of it. It was a small design house doing small advertising installations for its customers.
What exactly happened
All of the following was communicated over the site’s chat system with one exception when we had a very short Skype call. (The 4000-word chat logs are simply too detailed to be shared here, so I settled for just summarizing the main steps.) We literally were half a world apart in terms of time zones.
Day 1: The client thanked me for the application and expressed the will to start spec’ing the project in detail. Listed were the concept and specifics of the implementation he wanted. There were some details of 3D avatar models to be used and such usual things. I had posed a number of high-level questions about his intended installation so I could understand the exact aim. The client answered all of my questions, bullet by bullet.
Day 2-3: I went to great lengths in explaining what parts can be done with the budget and how well it is going to work. I gave examples of the tracking issues that limit the concept that required rather perfect tracking of the human movement, which now in 2019 is still nowhere near the offering of any 3D sensor or tracking algorithm library.
Even there were persistent hardware-related limitations in question as well as the limits on the SDK level. The client had a lot of questions for me to describe exactly what he will get: how many changeable avatars, graphics skins, and similar visible work items.
Day 4-7: I replied to each of his questions, bullet by bullet, and we both thought the project is getting pretty well spec’ed in this way. I had listed all hardware requirements and realized at this point that the client had bought the sensor but not really tested its limits on any real use case. So, I had to list the limits that I knew (which by then already were numerous). Unfortunately, these kinds of things are hard to explain by words alone.
Day 8: Project started. The client paid my advance fee, which then was a mere 20%. Things looked pretty good at this point. We listed three other milestones for the actual work, with a reasonable schedule to which I could easily hold. I defined the order of the milestones so that the challenging part is tackled first and the easy parts, the final graphics, come in later.
The first delivery was to be at the end of the starting week. I had highlighted that the original concept he mentioned was done with video-editing techniques, not using any real-time tracking system such as Kinect. We agreed to get a system as good as it can get and settle for that. Then, we both started the project with positive expectations (which showed clearly in the chat log).
Day 9-16: The schedule was not a big challenge to me and my client didn’t seem to have a big hurry for this. The client sent me some graphics of his own that he wanted to be included, so I punched them in. I prepared the first version (V1.0) of the software for him to demonstrate the bottlenecks in tracking the user’s movements, which was the first logical part to go through together.
This video shows the basic problem. When Kinect cannot really track the feet properly, some of the information about joint positions is lost and the result is a really unnatural-looking movement. The graphics parts were rather easy to get done.
Shortcomings of tracking human movement with Kinect for Windows SDK 2.0. In some poses, the feet and the legs are just lost. The problems I knew all too well, but couldn’t communicate effectively because I didn’t figure out that being one of the main issues for the client.
Day 17: I delivered the package of V1.0 to the client and asked which image resolution would work best for its final installation so that I could optimize the visual parts for the next version. No immediate reply.
Day 22: The client had not sent any reply, so I feared I had made some unknown mistake already at this point. I had to ping him for a reply. And I got it. Their company had moved a location and busy with that the past few days. So, I had worried for nothing. The client even expressed his enthusiasm for getting the first look at the version I made. So far so good, that is. But again, no message for almost two weeks.
Day 34: Again I pinged my client and reminded him kindly that it was now seventeen days without any feedback or instructions on what to do next.
Day 40: The reply finally came with apologies from their side. He appeared to be late for some other project, so I thought still at this point that there wasn’t really any big issue here. Now the reply was comprehensive with three points on V1.0 for me to address:
- What can be done to improve tracking of the legs and feet?
- Can recognizing new users take effect faster?
- What options do we have for deciding which user is tracked?
Also, he shared the video with specific details annotated to it in a very nice and clear way. I thought the points he was asking could be simply explained and we just keep going. After all, I had highlighted the numerous shortcomings of Kinect’s tracking algorithm. All of the three points fall into the category of “device limitations.”
Also, the client listed three new ideas that we hadn’t discuss yet and all of them sounded like good features to be added to the next version. So, I started to expect the milestone payment with quite a restful mind.
My reply was very long, accompanied by an apology for the length. I clarified the fundamental problems with tracking and explained how we can develop new filters for improving the tracking of the legs and what it takes to create such filters. I stated that the budget is a different order of magnitude compared to what he was asking, so we were stuck with having the application development level of tasks only in the project, due to the budget.
The start of that process would involve his company recording the most problematic issues with the tracking of the legs with Kinect Studio and I would then need to record more samples of similar movements of my own. Then a good algorithm could be developed.
I also replied to each of their points on new features and asked a few more specific questions on how exactly I should implement them. Also, I reminded him kindly to make the milestone payment (since indeed it was now 23 days since I delivered V1.0).
Day 45: Again it took days, but I got a proper reply. It was not at all answering my query about the milestone payment and went straight into planning the additional features in detail. Some of the design choices should be reviewed by his business partner, who was at the moment traveling. I replied quickly and speculated on the price of the new features, which wasn’t more than 30% of the project price we had agreed. But, still, on Day 45 the only thing paid was my advance fee.
Day 46: Another reply from the client. He should check with his partner and finalize what we are going to have as the end result of the project. He confirmed the small improvements. I could do a small update, V1.1, with the most trivial changes for which he had wished.
Day 49: I made the small changes and sent V1.1. This version still didn’t have much more than one avatar showing on the screen with Kinect’s default tracking. Issues with tracking the legs. No changeable avatars. A simple way to change the background was in, only. The rest was still just bare bones.
Unfortunately, this is where the messages ended. No payment other than my advance fee was ever made. A few pings on Skype didn’t result in any reaction.
What the hell just happened?
I was puzzled about the sudden end of the communication. I thought things were going fine and the issues listed by the client were unrealistic, and I had proposed simple workarounds to reduce the scope and keep the project within a reasonable budget.
Afterward, I spent quite some time thinking about what went wrong. The reflection phase is important to me. There were several possibilities.
Explanation #1: At first, of course, I blamed myself for giving the client very strict limitations that required the client’s side to do quite a bit of work on its own, namely to record sample movements with Kinect Studio. As I had done this kind of thing earlier, I knew how much work it would have been. Maybe that statement scared him and the rest was only about coming up with excuses.
I should have written a more vague reply in a more positive tone, maybe … The way to explain to yourself it is all your fault needs sometimes a good chunk of imagination.
Self-pity is an inevitable part of experiencing total failure. But it should not take too long to overcome that phase.
Explanation #2: Perhaps the client only wanted some cheap code in his hands. As I went back to read the chat logs again, I noticed a clear tendency on delaying the payment, and the delays in replying were always somehow related to someone else, i.e., the client’s business partner. If this was a hoax, it was a bad one. The code they got didn’t do that much yet in V1.1.
The advance fee paid covered the technical parts of the work that I had done, but it certainly didn’t cover the hours of replying to the questions and coming up with solutions that would fit his budget. And the amount of detail in the client’s reply indicated he had spent a considerable amount of time thinking and typing it down. After more consideration, this explanation seemed unlikely. Why would he go that far if it was just a lie?
Was it a hoax as big as The Matrix? Maybe, but I doubt I’m Neo.
Explanation #3: Maybe the client faced a complete disaster, which is an all-time favorite excuse for people to end projects without saying there was an issue on their side. It’s the classic “the dog ate my homework” excuse given to schoolteachers. But since the only issue stated was just moving the office location and traveling by the business partner, this explanation didn’t sound right either.
When facing tough times, people tend to make all kinds of excuses. In some cases, the man’s best friend can really save the day! 🙂 Was this the case when “the client vanished”?
Explanation #4: The client’s company faced some more urgent issues and just dropped the project for good. After all, there were so many fundamental issues with the tracking, it hoped to be perfect, which I quickly proved to be otherwise.
He only paid a minor advance fee, so if the plan was not that convincing anymore, the price was only getting higher than expected, and there were better projects to be done for possibly bigger customers, I could imagine the rationale of dropping the project altogether. But to be professional, it would have been good to settle the business deal, of course.
Sometimes people change their plans and there’s absolutely nothing you can do about it. Except get used to it.
Eventually, after going through these plausible explanations in a Sherlock Holmes-style manner, I came to the conclusion that Explanation #4 was the most likely cause of my client’s vanishing act. But I will never know.
The only thing I know for sure is I spent a couple of half-days doing the work and got paid for it more or less properly. And I lost time in communications. And I definitely lost confidence in getting into a new project without a 50% advance fee. It became my strict policy for all new clients asking for small-sized projects.
I lost a client and I didn’t get paid according to the deal. But did I really lose much? Nahh… I just gained experience! (Or at least that’s what I have to think.) And a story to tell here, hahah. 🙂
My poor ratings!
There was a more important thing than the small amount of cash at stake in this freelancing failure. Since I had no idea how the freelance site would rate this kind of mishap, I didn’t do anything about it. I just let the project hang and stay active on the system. It took over a year (!) when I realized this project was still active in the system so I took a calculated risk and closed it officially.
Projects closed by the freelancer were known to raise some red flags in the system when I looked through the site’s user forums. I had to mark the project truthfully to have ended without being successful with the brief note “the client vanished.” I couldn’t really figure out anything else to do. Later, I realized I should probably have done that much earlier so my ratings would not have been affected because I took a minor hit for a month or two right after closing this project.
But there was nothing more than that, actually. From the perspective of having good ratings on my freelancer profile, this story ended surprisingly well.
What I could and should have done
No matter how good you (think you) are, eventually you’ll get a client who just doesn’t care about you or about being professional or anything at all. They just go. By the way, that client’s profile is no longer active on the freelance site in question, in case you were wondering.
What could I have done better? Well, I could have:
- Called first before accepting the project offer and talked through the limitations. But the slowness of the replies didn’t indicate this being a realistic option.
- Tried to foresee the tracking challenge and understand the client’s perspective better, if that was indeed the biggest issue in Explanation #1. Maybe I underestimated how important smooth tracking of human movement was to the client in comparison to the trivial features that he requested.
- Expressed my concerns on the feasibility of the client’s original idea much more strongly. I really thought he accepted my offer to develop the software parts only on top of the given SDK. Especially since he had the sensor already with him, I assumed he had played with it to see what it can do.
- Closed the project earlier on the freelance site. Letting it hang for over a year felt ridiculous afterward.
- Reject the offer as I still saw some uncertainties remaining after extensive discussion.
- Charged a high advance fee to make the client commit to the project.
The only thing I changed in my approach was the last part, a 50% advance fee. That’s been working well throughout the following years. What the advance fee does is effectively filter the less serious shopper clients and definitely all the shady ones. But it also makes you deliver the maximum for the first milestone to avoid disappointing the client, so the projects need to go faster in the beginning. This has worked really well for me and for the clients, too.
Perhaps the other parts became something about which I was more or less subconsciously aware since I haven’t had any mishaps ever since. Lucky me! It is just that I don’t really believe in luck, at least not when it comes to long-term success. There are far too many other, more critical factors. One is, of course, systematic learning from failures through objective analytical reflection.
Did I let the failure affect my enthusiasm as a freelancer? Definitely not. I could never have gone that way then, nor can I go that way now. Of course, it felt miserable for a while, especially when I didn’t have that many projects in my work history or much of a project portfolio by then. But, once I had done my failure analysis, it didn’t feel that bad anymore … Just more of a lessons-learned kind of thing. It could have been worse.
Things could always be worse.
Interested in hearing more about glorious freelancing failures as a software developer? Stay posted on new articles in this category, e.g. Why and How New Freelancers Keep Failing: Part 1 and Part 2. And if you’re facing similar issues, feel free to contact Dr. Mike, your therapist in freelancing failures, and get some professional help when you most need it! 🙂
