Several months back my friend and I embarked on a mission to start our own development and consultancy firm. This will hopefully resonate with plenty of Steemers, since this community is WAY above the average level of technical prowess!
My business partner is a full stack dev with tons of experience and the ability to find a solution to any problem, while I hail from a management background, so our skill sets combine nicely. Despite our excellent mix of technical and management skills, we've faced some big hurdles already.
It's been a few long years since I've worked directly with clients, and I've lost some of the polish I used to have at hand holding and reading between the lines. The definition of these two activities is pretty wooly. What exactly is "hand holding", or "reading between the lines" in the context of a software development project, and why has it kicked our butts? Let me explain what happened.
We recently landed highly customized website development project. Nothing too crazy, design seemed simple, the requirements seemed easy enough, and the client was adamant about they wanted... but that's where things started to go wrong. The client was particularly vocal about the direction of the project and how we should go about our business. We tried to steer them in a few different directions with soft questions like "what about this platform, or have you considered this option", but they appeared to know what they wanted.
The mistake we made was assuming they knew the whole picture. By making this assumption, we didn't "read between the lines". If we had looked a little closer, we would have found that the client actually had no idea what the different platforms were. They had such a simple understanding of how websites worked that we must have sounded like we were talking about Trifungulators and Hyper-warp speed fission engines.
By missing this step, we missed a crucial requirement; that they didn't want a new website at all. They wanted their old website with a new design. Looking back, it makes us sound like this was our first rodeo and we're completely at fault. We could argue that the client shouldn't have been so aggressive and they should have trusted us. The truth is, it's our responsibility to hold their hands through this process, even if they've got sweaty palms.
The second big mistake we made was thinking we didn't need to hold the client's hand. We had already made the assumption these guys were worth their salt and knew what was happening. So what happened next?
We finished the website and it looked GREAT. It ticked all the boxes. We ran through our test processes, tidied up the loose ends and prepared it to be tested by the client. One short email later and we were off and away.
Two days passed and no feedback arrived on our door. We were both high-fiving ourselves so hard that we almost dislocated our shoulders. Another couple of days passed and they client sent back minor feedback which we gobbled up and threw back out. Finally, we got the go ahead and deployed the website.
This is when the s#^t hit the fan. Because we didn't hand hold properly, the main stakeholders hadn't tested the website fully. They had only glanced at the customer facing site and neglected to look at the administrative area at all, so we received a panicked email asking where all of their old content, plugins, and customization had gone.... "huh"?
Right, so they hadn't told us they wanted a full migration of their old website. Or maybe we didn't ask. Either way, it didn't get done and no one was happy. I won't go into the messy details of what played out from here, but the moral of the story is we were blindsided because we didn't "read between the lines" or "hand hold".
So if you've read this far you're probably thinking; "that's all well and good TFDangerzone, but do you have a plan so you don't mess it up next time?". I do have a plan, and I'm beating myself up for not working it out sooner.
Reading between the lines:
Here's the thing about getting all the information, it's a collaborative process. Depending on the complexity of the project it can take hours of working together with someone to understand what they want. Even then you still might not have the full picture. A lot of business owners know they need something and have a general vision, but can't tell you specifically everything they want to see at the end of the project. So the solution to this is using an agile methodology to build a little bit of their vision at a time and verify that you're on track.
There are millions of articles on the web about running agile projects, so I won't break it down too far, but in a nutshell, the idea is to first define requirements in simple English like "As a user, I want to view everything I could buy so I have the whole picture". These requirements are broken down into easily executable tasks which give direction to the project. A handful of tasks is then packaged into a "sprint" of effort to build a specific set of features and get approval from the client before moving on. This way everyone agrees on the requirements and the client can see what's being built along the way.
In my example above, if we used a proper agile methodology the client would have told us something like "As an administrator, I want to edit my blog articles so they stay relevant" and we would have been on the same page.
Hand holding:
In the example above, even if we got all the requirements down there's still a chance that our understanding and the clients' would line up until something forced them to look at the website. Regular business owners are notorious for not testing software properly. So what's the solution?
My most effective approach so far has been using a tool called SweetProcess which acts as a glorified checklist. We prepare a series of test that they need to execute like "click on all the links", "read all the copy", "create a blog article", etc. This is the epitome of hand holding. We are literally telling the client what to do.
This kind of list works well for all stages of the project. If your client is completely green, you can set up a checklist to help them work out their requirements, give ongoing feedback, pay their bills, whatever you want.
On that note, I mention in the title that the ultimate goal is to get clients to pay you for your time. It's actually broader than that because technically you can force the client to pay you once you hit the terms and agreements of your contract. There's plenty of legal avenues to get this done, but the ideal situation is to have your client pay you on time AND be your biggest fan!
It's worth thinking about this part of the game as a negotiation. You want to convince the client to pay you as soon as possible and that you've done them a favor. I first stumbled across this theory after reading "Never Split the Difference" by Chris Voss. As an expert in negotiation, he talks about the psychological effect that is generated by giving favors and how humans feel a deep urge to reciprocate when they receive a favor. Think about a time when someone bought you a gift and you didn't have one to give in return. It's an uncomfortable feeling. You feel like you owe that person something, and you will often overdo the returning gesture.
To effective drive clients to pay you on time and go out of their way to refer you, you need to generate some non-defined tangible benefit that is highlighted clearly. This could be developing a close relationship with the client and giving them free expert advice on something outside of the project or building in a missing feature that the client didn't anticipate, or providing them free training. It helps to be creative here, but anytime you can solve a problem that they didn't have a quick answer for and you purposefully highlight it as a favor, you have bought yourself a psychological balance that will generate future interest. Of course, this approach doesn't work if you completely messed up their project, you didn't read between the lines or hold the client's hand.
I would love to know if this story held any value for you, and what your experiences are in messing up client projects! :D
Cheers,
TFDangerzone
Thanks for writing such a nice article. As a business owner, I'm constantly learning ways to improve, especially when there's been a mishap, so the ability to adjust is crucial.
The checklist seems like a great solution to keep everyone on the same page and to set healthy expectations for all sides.
Maybe you could take a look at my website & make suggestions of how you could improve. Thanks again
Sure thing Nathan, I'd love to check it out.