Clients I Have Failed: What Not To Do | Hacker News Reader

Clients I Have Failed: What Not To Do

businessweek.com

33 pointsedw51910 comments

Thanks for sharing these stories. I'm sure we can all relate to at least some of these issues (some more than others -- I've been there/done that on almost all of them! ;).

Some of the product knowledge issues we've been fortunate enough to avoid since we write our own software, but being young (19) and very inexperienced when I started I certainly learned the hard way not to over-promise and under-deliver.

I once had a "Mildred" experience myself where the person in charge on the client's end wasn't unqualified but was constantly changing his mind. Almost daily, he sent us new design plans that had nothing to do with what we were supposed to be making.

After a conversation with his boss about how the project needed to stay on track, no change. After a heavy conversation about how the project was going to fail if they couldn't get a handle on him, no change. His boss actually confided that everyone else was too busy, and that the person we delt with worked from home because if he came into the office everyone else would leave so they wouldn't have to deal with him. Strange...

So the project failed of course, and they decided to not pay us for a chunk of time at the end. I still managed to pay my contract developers out of pocket, but I definitely learned to avoid ever letting such a scenario play out for the amount of time it did.

We actually had another project recently that initially seemed like a fairly simple document manager, but a few meetings in the client had basically explained that they were planning to run their whole business on this thing, all client communications, accounting and everythin. We ended up turning the project down, which was ultimately the best thing to do for everyone.

It would be an excellent tradition for people to post stories about their mistakes -- we live in such success-driven cultures that it's almost like admitting you're a loser if you ... well, lose occasionally. Yet, the more I develop software for other people, the more I see that it's about the people, not the software per se. The map is not the terrain, the plan is not the project.

"the more I see that it's about the people, not the software per se"

Thank you. A fundamental truth we too easily forget.

I'm going through the aftermath of one of my failures at the moment. It's been an interesting, illuminating experience. I've learned that I am (as I suspected) fallible. I've also learned that most "civilians" don't know what they want from software, even though they think they do. And I've learned that you can't please everyone, and it's futile to try. I might write this one up some time, but the fat lady ain't singing just yet.

Sorry to hear about it. For some customers, showing that you care is half the battle. Hope this is one of them.

In fact, you hit the nail on the head. They're discussing canning the project but appreciate I've put heart and soul into it, and are looking at all the options about how to go forward. Fortunately, one of those options includes keeping me on, so they're still paying me. This in itself is one of the lessons I've learned: I don't have to be perfect to be useful. Believe me, that's a real paradigm shift.

In my experience, honesty is your friend here :) I had a contract that we took on which inherited someone else's codebase as a starting point, but it sounded simple enough.

When we realized it was getting not-so-simple we had to decide whether to go back to the client and explain that it's going to be more than we thought, or whether to just push through and go over a bit (false coder heroism...). We decided to push through. Turned out that just made things even worse and we would need even more time to fix it now.

We were also busy with another big project at the same time, so we were focused more on that as well. So things dragged on. Finally, I had to have a meeting with the client where I could make something up or simply tell them the truth. I opted for the truth (that would be my dad's influence :).

I was pretty scared it wouldn't work, but they accepted my apology and the plan to correct it, which did require more time and money to complete. I felt like I had dodged a bullet. We managed to sort everything out in the end, learned our lesson, and they've since recommended us to several other companies because they feel they can trust us. And it feels pretty good to have earned someone's trust that way too.

Anyway, I write way too much on here... (gotta learn to edit! ;) But good luck with your project, hopefully you'll have the same luck I did!

"Anyway, I write way too much on here..."

Not at all. We need more war stories here. Thanks.

"false coder heroism..."

This was me, but now I'm learning the valued art of project management. Like marketing, I used to think it was all baloney, but now I know better.

"I sold cars to unlicensed drivers."

This concisely describes a mistake that a lot of IT consultants have made (myself included), when the product they've installed/built/configured/whatever works perfectly well, but accomplishes (next to) nothing, because the customer doesn't know how to use it.

Pretty much all of the examples the author cites of failing his clients sound familiar (although fortunately, I have avoided most of them).

Reply on news.ycombinator.com