Decoding the corrosive client

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.

Corrosion by ‘delegation’

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.

Corrosion by escalation

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:

1. Get your specifications down pat for all the sub-systems. Nothing is too small, or too big. When there is a delay, screwup, anything, be the first to highlight to client always with a mitigation plan.
2. Have an escalation matrix in place for every project and make sure you escalate to the right person as early as possible. One caveat here is that you need to judge the client a bit and make sure that client manager takes issue escalation well. My preference is to make sure the client knows I’m going the escalate bad news faster than good, but that has back-fired quite badly in the past. That hasn’t changed how I do things, but YMMV; just stay honest and consistent to your style.
3. Have regular integration and integration meetings, especially in large projects with multiple components and teams. Have a QA lead in place who understands the entire system and also has a team of QA all in sync. She will be the key person delivering the project. Again, I’m a huge believer in QA driven, QA lead projects, YMMV
4. Have someone batting for you on the client’s side. For large projects having a Sales, CRM in place and regularly updated is a huge help. In my experience, Sales folks really appreciate being made part of regular team updates, especially if it is after work-hours on Friday, over “dinner”.

Corrosion by cost-escalation

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:

• This is one occasion when getting into loggerheads with sales early in the life-cycle is a good thing. Don’t allow the project to start with vague promises of functionality to be delivered.
• A manager once told us: ‘Schedule slippage of a year starts one day at a time’. Think this is a mantra well worth following: Keep your requirements tight, don’t allow anything new to spoil the schedule and make *very* sure there is no slippage week-on-week.
• Start schedule and delivery check-points from day one of development. Start development after a very detailed analysis phase. This requires more elaboration.
• We already know we don’t have a great template equivalent of an engineering drawing to demonstrate exactly what is to be delivered. So, spend lots of time initially trying to pin down everything.
• Small, functional POC (Proof of Concept): Build quick, small versions of the software, similar to the scaled down version of buildings that architects make. In fact, every project must have at least 20 percent of the resources building *ahead*, making sure the other 80 percent is developing upon well-understood and well-defined models.
• Borrow heavily from the hardware, chip manufacturers in terms of building a prototype. And testing, testing, testing. The reason, why hardware failure is much smaller than software, is that there is a real cost involved in rebuilding a chip and so a tremendous amount of time is spent in QA and testing the chip out.

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.)