A client may be too big, too small or even the wrong fit. A corrosive client is one who isn’t really doing your business any good.
While a lot is talked about the client being the most important person in any business, we spend more time on client acquisition and retention than almost anything else, the entire company is given seminars on how to be a client-centric organisation, right from CEO all the way to the junior-most staff, and on and on.
Little is mentioned about the client who is really not that great for your business. The client may be too big, too small, focused on the area of business that is not your core competency. It may even be as simple as being the wrong fit for the team that is handling the client. This article is about that Corrosive Client who isn’t really doing your business any good.
Before we begin, one important note: Yes, this article is about clients who are bad for your business.
This is intended to mean *you* are not ready for the client, not the other way round. In other words, the client is corrosive because of the organisations lack of mettle (pun intended).
The intent of this article is to try and categorise some failures that could be attributed to what we will call the corrosive client, which will hopefully help one identify this early in client-acquisition phase and (even more hopefully) remedy this.
Another thing to keep in mind is that this article is about IT projects, specifically software projects and possibly only relevant to that industry; the author has no experience elsewhere and cannot comment on this being useful to anyone else.
The project is great! You Co. a really fantastic deal. The management is thrilled, the developers are ecstatic and deliver a great project. Then things go rapidly south just after delivery. The client isn’t ready to accept the end project. Ouch.
We bagged a really large and interesting project to revamp and entire CLI (command-line-interface) or a running system. The project was executed and delivered in really good time. Since the system was large and implemented over decades, a complete code revamp produced some really clean libraries that meant very decent reuse of code, a slightly clearer user interface in terms of consistent error messages, good logs, etc.
Long story short, they managed to deliver a much cleaner system that had measurably fewer bugs and worked better. Then the client sat on it. For months. Then, after multiple pushing, prodding, and escalations they agreed to a ‘review’. The tech manager in-charge got her subordinate to review the system end-to-end. After we week, I got called for a review meeting. The meeting was difficult, to say the least. The reviewer was not very knowledgeable about the system and raised issues like: ‘your code is not very good because it has too many function call overheads. You should not call so many library functions that will slow down the system. We tried pointing out that the code is actually really modular and this being a CLI, the user is definitely not going to be bothered by a few nano-second delay.
Again, long story short, that wasn’t a good meeting at all.
A week after that, we were told that the system required a full rewrite and so our delivery was not acceptable. After more than eight months of work, lots of reviews by others, huge automated tests that passed seamlessly, we were being asked to redo the entire system. One that led to another and the project got shelved eventually.
This was more than 15 years ago and it still rankles. What did I do wrong? How could I let down my team that had worked so hard and delivered an impeccable product? Some (possible lessons).
Get a buy-in for the end product deliverables from all stake-holders. No, suite of tests that pass, a 90 percent code coverage is *not* enough. You need to get buy-in from managers, the tech leads and other folks who are close to the manager. Make sure you have the Manager, her close associates who will be involved at the last stage; in short everyone you think *may* be involved?
Have regular mile-stone meetings with client. Make sure all the stakeholders are part of the meeting. If I had taken pains to keep the reviewer in the loop, she wouldn’t have thrown our code away. This is possibly the biggest take-away, meet *every* stake-holder as often as possible.
Make sure your client contact is comfortable with you, or get out of the way!
Make sure someone else is talking to the client contact other than you and will get feedback on how you are functioning, what they feel about the team, etc. Don’t take it for granted that the human element will magically fall in place once great work is done.
I missed many warning signs, but the one very important warning sign was when the client manager wouldn’t look into the sign-off herself and delegated to another, junior person who didn’t know the system at all. This should have stood out as a major roadblock and rather than jump into the review, I should have let the team interact with the reviewer, updated her on the system, had a day-long ‘offsite’ training session with her; something, *anything* to ensure that she was well apprised of the system, understood the project and then and only then handed over the project for review.
This is so common, it almost doesn’t need a case study, but briefly, we did a fairly small component of a large website and just before delivery the complete requirements changed. It was such a small component that I didn’t pay notice and asked the team to spend another week and close it.
This obviously delayed the entire project by over two weeks, got escalated to the big boss who looked at the problem, was told my team messed up and out we went. For want of a horse-shoe-nail, the whole project gets pulled from under your feet.
This is so common and there are so many ways to fail, it is hard to pinpoint all the warning signs, plug all the holes, but some that stand out:
This again happens so often, and barely needs explanation. A project starts with big fanfare and we promise the earth to the client. The client says, no, the MVP (Minimum Viable Product) is actually the earth and the moon, and we agree.
MVP is possibly the most abused word these days of ‘Agile Development’. Even for projects started well, and a great team in place, we simply don’t understand software development well enough to do large projects well.
Even after, what? Four decades of ‘The Mythical Man Month’ nothing has fundamentally changed in the way we understand software. The Indian industry has to take a lot of the blame since we have done millions of hours of software development and there is no tangible record of our failures, statistics, data formats, or *anything*.
We are possibly only second to the medical fraternity in terms of obfuscating data to protect our own interests. Enough rant, some points that may help are:
To all those grey-haired, bleary-eyed folks out there who are by now remembering umpteen other past demons and fervently messaging their buddies to unusually meet mid-week to drown their sorrow, my sympathies.
It’s important that we publicly share, nay, showcase our past follies in the hope that it will be useful to someone. Expecting lots of “been-there-done-that-and-here’s-more” in the comments section!
(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)