I took over a rather complicated project as the sole developer/project manager and tester sometime last year.

In November last year there was a deadline for some new functionality to be delivered.

The system I took over which was supposedly ready to be used was far from being ready.

Sitting with one of the our customers users he came up with new features and requirements which was required. Even though the features they asked for was implemented he argued it was nothing like what they specified in the requirements.

So I had to get back to the drawing board and do extensive changes to the system.

Promise after promise, this is my own fault, I missed subsequent deadline due to different reasons: over-optimistic planning on my behalf, sick kids and various other personal issues.

And there have been failings on the customer side too: only testing when I watch over their shoulder and so on.

Yesterday we agreed that we go live if their users approve the application.

Of course some issues showed up and now today, when I tried to call our customer he hung up and hasn't replied to any of my emails.

This is really wearing me out, the hours and time spent on this far exceeds normal working hours and has taken its toll on my family as well

Obviously there are things in this situation that are specific to this project, but I don't think the overall pattern (multiple small problems, leading to project breakdown) is uncommon.

If they already paid then I would do nothing.
–
PemdasFeb 23 '11 at 16:17

1

I've made a few edits to make it a little more generic. There are specifics in here which apply to this project but I think the overall pattern (multiple small issues leading to an overall failure) is remarkably common and a good question.
–
Jon HopkinsFeb 23 '11 at 16:49

10 Answers
10

EDIT: On re-reading this sounds a little bit harsh, it's not meant that way. The things you describe are common and are usually caused by entirely understandable factors (and then exacerbated by your trying to be helpful). Anyway, if it comes across as harsh, sorry, it's not finger pointing, it's just trying to say "this is what seems to have gone wrong, and this is how to deal with it".

What seems to have happened from what you're saying is:

You were delivered code to work with which wasn't in the state you were led to believe

The users then claimed that the application didn't meet the requirements as stated

Assorted plans (largely unrealistic) were made and missed

Testing wasn't properly carried out

He's now throwing his toys out of the pram in a passive aggressive way.

And, as a result, the project is failing.

My first point would be that you need to stop doing what you've been doing so far (which appears to be optimistically carrying on, assuming that if you just keep going it will all work out). That's not worked for the past 3 months, why do you think it's going to work now?

Essentially each of these issues should have been addressed as they came up, dealing with both the symptom (e.g. a missed deadline) and the root cause (e.g. the plan was over optimistic). As this didn't happen (not uncommon), you're now in a position where there are multiple issues to deal with.

In my experience when a project runs significantly off track in this way, the best thing to do is to get everyone involved back together and re-establish the requirements and responsibilities and re-agree a (realistic) plan based on these and so on.

Your client needs to:

Confirm the requirements clearly and unambiguously. This may be as a specification, it may be as a list of deviations from what is currently implemented, however it must be complete and unambiguous and communicated in writing.

Accept a test phase that is theirs to manage at the end of which they will report all defects. This will then be what you will work against. They probably also need to accept that there will be at least one subsequent test phase for retesting the bugs that WILL come out of the first one.

You need to:

Realistically assess the requirements, accurately estimate the work (including reasonable contingency) and put together a plan to deliver this. The key thing is accurate. If you think it's going to go down badly then tough, plans put together to make people happy which don't reflect reality don't deliver software.

Deliver against this plan.

In terms of contacting the client again, I'd recommend you put together a proposed approach along these lines, stating why and send it to him. Right now he wants to know how things are going to get better and that's what you need to be delivering to him if you're going to rebuild the relationship.

I disagree with almost all of this, the OP obviously can't accurately estimate deliver, how is doing more of the same waterfall process that has failed them so miserably going to do anything but lead to a repeated cycle of failure in this case, they need to offer some new approach that is going to represent change!
–
Jarrod RobersonFeb 23 '11 at 18:40

@fuzzy, Shortening the timeline here, and doing tight iterations, brings it much closer to a scrum style. This answer doesn't really look like it says all of this has to be done as one long "waterfall".
–
anonymous cowardFeb 23 '11 at 20:09

In any case, see the part about "getting everyone together" and coming to a "new" agreement - whatever methods you decide to use. I do agree with fuzzy that doing things in short iterations, and making the client the "owner" (and a responsible, priority-setter) is probably the best way up... but you may never get "out" without firing the client.
–
anonymous cowardFeb 23 '11 at 20:11

3

@fuzzy - I believe the OP could do a better job of estimating if he changed one thing - his desire to make up for his mistakes by telling the client what they want to hear rather than the truth. In my experience the single biggest error programmers make is in massaging what they believe to be true to closer represent what they hope will be true which I'm fairly certain is in large part what's happened here.
–
Jon HopkinsFeb 23 '11 at 20:20

I don't think the proposed, "plan" to make a plan is realistic given the failure to do that so far. I think, the "plan" should be to change the process, and make the plan, we are going to deliver the most important things to you this week, then the next most important things next week and make the customer responsible for the delivery. Making a monolithic, this is "the plan" plan is just setting up for the same failure again. You say "the key thing is accurate" I don't think the OP can live up to that key thing, they haven't so been able to in the past, that is what got them here to begin with
–
Jarrod RobersonFeb 23 '11 at 21:02

I really like your answer and would've done this if it wasn't for the fact that I'm the only dev at our office.
–
user17971Feb 23 '11 at 16:30

2

I assumed that you had made the original commitment to the customer. Are you an employee or are you self employed? If you're an employee your company may have contractual obligations that you'll need to wade through.
–
John WeldonFeb 23 '11 at 16:33

I'm an employee. I didn't make the original commitment to the customer. Just trying to follow up on already made promises.
–
user17971Feb 23 '11 at 21:42

Promise after promise, this is my own fault, I missed subsequent deadline due to different reasons: over-optimistic planning on my behalf, sick kids and various other personal issues.

Their business needs this done, and you've broken promise after promise. You need to stop making overly optimistic promises. When I've been in these situations, it is extremely hard for me to regain credibility with the customer. When you work in business, your reputation is extremely important. If you're going to make estimates, you need to hit them. If your kids/family are sick in the future, is there someone to help take care of them like spouse or other family? Look to move towards a "no excuses" future.

Of course some issues showed up and now today, when I tried to call our customer he hung up and hasn't replied to any of my emails.

He wants results, not excuses. He hung up because he didn't want to hear yet another excuse. What can you do to get the project back on track? What can you do to finish this project? How did you get involved in this project in the first place?

If I were you, I'd spend time today getting documentation ready to hand this project over to the next guy.

The system I took over which was supposedly ready to be used was far from being ready.

I've been in situations like this also. In the future, never spend significant energy describing this to the customer because it sounds like you're goldbricking. Why did the previous guy leave it in the unfinished state it is in?

And there have been failings on the customer side too: only testing when I watch over their shoulder and so on.

This was one of the most painful parts of the latest project I was stuck on like yours. The subject matter expert (who is retiring this summer) doesn't document anything, so most of the bugs result from my imperfect memory of conversations with this guy. Plus, he was used to keeping all the stuff secret to make himself indispensable, and that habit has been extremely hard for him to shake in his last 2 years on the job.

The other critical failure was that there was no test environment. For the past year, all code to be tested was promoted directly to production where it would be QAed by the end users.

The final situation was that this federal agency didn't have any budget to hire anyone, and I was finishing this project to save my friend from getting sued. In the end, they let me go (yippie!) and used someone working on a different (yet funded) project. It was more than a year late before I got involved, and even though they doubled their budget for the project, that budget was shot by the time I got involved.

Going forwards, you need to learn to do better estimates. Something like the diary recommended in PSP (book). This project is a failure. Also, you may wish to discuss things with your personal friends, do any of them have the skill and bandwidth to assist you in future screw-ups like this? Next time you get in over your head, will you repeat this failure or is there something you can do to mitigate the failure next time?

Upvoted for giving the customer business viewpoint so well.
–
David ThornleyFeb 23 '11 at 18:09

this is the first time I'm in this kind of trouble. I have other projects that I manage fine and I've managed different projects OK in the past, never had any of these problems. the key difference to me is that this project thats running wild now is a really big project with much code and many dependencies and probably the most over-complicated project I've ever seen in my life.
–
user17971Feb 23 '11 at 21:59

If you've written software that will be used/implement by the customer, the customer has a responsibility to pay for that software and respond to requests. It sounds very much like the client has washed his hands of the matter, so unless you're prepared to head to court over this issue, you may just end up taking this one in the seat.

You need to have documentation, contracts, written requirements, deadlines, deliveries and shortfalls. If you can show that you did your due diligence in meeting the contract and the customer did not, then you have something. If you can't then it's just "He said he'd pay me to do this, so I did it, and now he won't return my calls."

My recommendation to you is to contact this customer's secretary/assistant/whatever you can to schedule a face-to-face meeting with him. Don't waste his time, don't beat around the bush. Tell him that you appreciate the opportunity he's provided you to work on this project, and that you recognize there have been some shortfalls in expectations. Don't cloud the issue with excuses or quid-pro-quos arguments. They'll just make you both angry in the long run and get you nothing.

Ask the customer what action is necessary to get this rolling the way he would like it rolling. Consider your capabilities, status, availability, everything. Be honest with yourself. Whatever you come up with as far as cost/time/etc, DOUBLE IT. If that doesn't fall within the compromise area, then you need to cut bait and part ways.

This is probably a foregone conclusion as it sounds like the customer is pretty honked off, but it can be turned into a learning experience. It sounds like you need a lot of extra preparation in various matters regarding contracts of this nature:

Get it in writing. Get it signed. Find out what the customer actually wants, and get it in writing.

If there are changes along the way, write them up as changes in a document, get the client to read it and sign it. Include any changes in deliverables, time-tables, costs.

Learn to estimate your time better. You really need to know how quickly you can develop certain types of projects, how to recognize the needy customer who will drain your time, the inattentive customer who will waste it.

Budget your time and resources better. When you're estimating a project, be as honest as possible with the time it will take to do something. If you don't know, take a swag. Whatever the result, double it (or at least increase it by half). This will give you wiggle room when the feces hits the oscillating air modulator.

Get yourself a quiet, undisturbed work area with fewer distractions. It sounds as if you were working at home for a lot of this. You need to treat this time as if you were at a corporate office. When you're "at work", you're at work. Your wife is not in the other room, your kids are not sitting on the floor next to you screaming for attention. If you can't meet this basic working need, you are not prepared to meet anyone's expectations.

Learn to pick your customers more wisely. Meet with them, observe their behavior. Provide them small tidbits to respond to and gauge their reactions. Clients who are impossible to please are the easiest to spot. You can spot this over lunch because nothing will be right at the table. Clients who are too demanding will be on your phone way more than they should be. Clients who do not respond are clearly not interested in your services or improving that area of their business. These clients should be dumped ceremoniously. Do not do it childishly, simply be straight forward. Honor all existing contracts, and simply deny any future contracts. Indicate your reason bluntly, "I do not have the resources to meet your continuing needs."

If this is a recurring problem on the customer's end (unresponsive, non-payment, etc) that can't be avoided, build a relationship with a nearby collections agency (they are everywhere). Open an account, make a friend. Having a third party capable of leaning on deadbeats is a very handy resource to have.

If you're going to engage in a profession, be professional. There are no sick kids or personal issues in the business world. That's a cold statement, but it's a fact. We don't work for gummy bears and candy bars, we work for money.

The last thing I can recommend for the future is to be honest with yourself. If you can't meet a client's requirements in a professional manner then don't attempt to. When I call a plumber to come fix my leaky sink, I don't want to hear about his sick kids or how he wasn't aware that fixing it was going to take 7 hours. I want it fixed. I'll pay for the extra time if he can show me that it was necessary and not just him clutzing around in my pipes. Your customers have expectations. If you promise May 1, have it done on May 1. If something from the client gets in the way, get it in writing that the date will be pushed back because of the client's request. Get it in writing. If it's something on your end, fix it. If you know it's going to to cause a problem and the deadline simply will not be met, be honest and admit it. Then be prepared to offer a discount of some kind.

I think this is pretty harsh. Although I agree with you in theory it is never as clear cut as this, a specially not when you are the sole developer/project manager/tester/account manager on the project and when things happens there will be a direct effect. even though the harsh words I think it is what I need to read/hear. +1
–
user17971Feb 23 '11 at 22:08

@user17971 - It is pretty harsh. But 2 things I read in your question that indicated it might be necessary. The client was hanging up on you and you appeared to be delivering excuses. I've been there. I've lost clients for similar reasons, and it was an experienced contractor that cured me with some similar frankness. I've inherited a ton of horrible situations from previous developers (both independently and while working for companies), and these concepts have give me the empowerment to recharge them all.
–
Joel EthertonFeb 24 '11 at 0:27

I have been in the exact same situation. I had a customer that wanted way more than I could provide and was changing expectations every week. At the start it was a simple job but so many things got tacked on... I lost a lot of sleep and it heavily affected other aspects of my life.

The best thing you can do is just shut it down and move on. Failing projects just happen sometimes and it is best for both parties to recognize the signs and catch it early. Once it starts getting into your personal life it has gone too far.

Ask the customer what they want. If it falls within the present contract do that, otherwise renegotiate the contract. Either way make sure you have a clear understanding of what the customer actually wants in a document that they sign off on so that they can't later say that you missed something that wanted.

The key factor here, as I see it, is that the requirements were not agreed on.

I don't know how you were billing. If it was a fixed price contract, with flexible requirements, you may have no recourse. Never get into a contract where you get paid X amount without solid written agreement on what you're supposed to supply. If you have to do something like this, get the project broken into phases, and don't do phase N+1 until phase N is signed off on (if not actually paid for). Always specify customer responsibilities as well as yours.

In this case, your predecessor apparently accepted additional requirements without a contract renegotiation. That's bad. If a project meets agreed-on requirements, additions to that should be negotiated as part of changes to the contract. You don't necessarily have to charge more, but obviously in this case the deadline needed to be reset.

You can have flexible requirements, as long as you don't have a fixed price or completion date.

Your estimation problems are typical in the industry, but try to learn from them. Unexpected issues will come up fairly frequently, so never give anybody figures on a best-case estimate.

I tried to get them to agree to an contract when I took over the project but they refused to accept this based on that they already had created this list. Weeks later I found this list in a excel sheet. Very very vague/unspecified requirements. I regret it every day that I didn't stand up to many of my convictions and ways of doing project management to this customer in particular.
–
user17971Feb 23 '11 at 22:10

Learn from it. The best advice I got about giving time estimates was to: calculate what you think it will take, then double it and add 10%. :)

Congratulations, you've learned a valuable lesson in software project management. Try to avoid being so obsessed about satisfying your customer that you end up making them ticked off. This isn't unique to the software industry. What would you expect if you went to a restaraunt, and the server took an hour to bring your food, and when you got it, it wasn't what you had expected? You'd want a discount or appology, right? Offer what you can to the client, and just move on.

You need a better process, Agile Methodologies, SCRUM in particular, offer better transparency, forced customer interaction by making the customer a stake holder and a team member as well as the testers as team members, everyone becomes responsible for deliveries not just the developer.

It enables shorter delivery cycles, that way when you are going to miss and deadline it is only 1 or 2 week Sprint and you and the customer both know you are going to miss it way before the end of the Sprint.

If you are going to fail, since you only plan out a single Sprint of 1 to 2 weeks, you fail quickly, small instead of late and large.

SCRUM also makes the final acceptance of delivery the responsibility of the Product Owner ( customer ) which means if they keep changing requirements and what not it is transparent to everyone who is causing the delays and very well documented.

More things get to 100% complete and tested and accepted before new features are worked on. Imagine you have a list of 100 features. What would the customer be more happy with?

80% of the most important features 100% complete, tested and accepted as bug free?

or

100% of all the features 80% complete, untested and buggy?

Processes like SCRUM force the customer ( Product Owner ) to prioritize features for you, so you only deliver what they are asking for the current Sprint. The most important work to the Product Owner gets done first, other things that are less important may never get done, but at the customers decision that is isn't valuable.

I'm the only resource at all on this project. Doing SCRUM is difficult with that in mind. I do use some agile methods, trying to get customer to accept some responsibility but it is challenging..
–
user17971Feb 23 '11 at 22:15

1

being the only developer on the project makes process even more important and gives you a position to negotiate from
–
Jarrod RobersonFeb 23 '11 at 22:23

yes. I am very process oriented but for some reason this project is just deciding to have a life of its own. Thanks for your insights, you're telling me exactly what I need to hear.
–
user17971Feb 24 '11 at 11:23