Project complete but does not really satisfy the end users. Business owners unhappy

Question

Some background on the project:

I recently completed a project for a company. The project was a fairly large line of business web site. The customer was a company with no prior experience producing software applications. There was no prior infrastructure, web server, database servers, code repository or formal product owner. I was given a list of requirements and a 6 month completion date. The scope included integrating the web site with their enterprise data ware house, designing the back end database, creating specifically layed out Pdf files on the fly. It also needed to work in english, spanish and mandarin.

I was told their was another developer in-house I would be working with. Once I got a month into the project I found the other developer had no prior web or application development experience. I had to build the infrastructure from scratch. There were issues with the network that cause the application to run slowly. I also completely underestimated the amount of time it takes to create applications for more than one language. I soon realized I was not going to meet the 6th month deadline. I told the I.T. director that there was no way the project would completed on time. I said it would take at least 9 months for a single person to complete the project. She said they couldn't afford to pay over time and just do the best I could.

A smart person would have left the project at this point. I did not do the smart thing. I completed the project within 9 months. I worked 60 hour weeks because I wanted to complete the project and move on.

Many lessons were learned but I still have a dilemma. The company is very small and does not have an in-house developer to support the application. I continue to support the application on nights and weekends. I have asked the company to hire someone to support the application as part of their job but they say they cannot afford it. The application built serves the purpose it was made for but I see absolutely no way it can be maintained.

What are my options?

I feel I really did them a dis-service by creating something for them they cannot maintain and the users don't really want. The project is not getting used as much as it should because I requires a great amount of data entry, the users wanted data to be migrated from an existing file maker application. The data migration was not a part of the scope of the project. Advice needed.

Answer 1

First of all, it is not entirely your fault that the project went over schedule. As they asked, you did the best you could given the resources available. You told them the risks, and they agreed with it. The only points you should have taken more care of is that you took one month (1/6 of the time available) to figure out that the other guy had no prior knowledge of web development, and that the web site, once done, would require someone else to give maintenance.

Second, if the data migration was not part of the scope, you don't have to worry about how they plan to use it. I know it's hard to take pride apart on something that you gave your best efforts to accomplish and it's barely used, but you got paid for that job (I presume), whether they use it or not.

Third, you can start passing the burden of maintenance to the in-house guy. If it was planned that he would be assisting you on the project, he had 9 months to learn something about web, and 9 months is far enough time to learn it. You can expect him to struggle sometimes, but try to assist him solving the problems, instead of you working over nights. If it's still not an option, try having a conversation and make it clear that you won't keep working like this. They will be forced to find another solution, instead of relying on you to maintain the service, because they know you'll fix it every time.

Finally, I strongly recommend you to take a look at Steven McConnel's book Rapid Development, mainly this section #27. It's a nice read and will help you find out these kind of project overrun earlier, and how to solve and avoid them.

Answer 2

This is great example of why there is a difference between product success and project success. Your accountability begins and ends with the delivery of in-scope requirements. It sounds like you were not part of the development of the original business case. Therefore, you cannot be held accountable for its eventual demise. Could you have rendered an opinion of the product in its totality somewhere earlier in the project? That's debatable. Perhaps you could have rendered a rather high level, sort of knee-jerk expert opinion, but to do a cogent analysis and argument, you would have had to take time and money to examine the issues and arrive at a substantiated conclusion. You did not have that time. You were "given" six months and were already over utilized to get it done in nine.

It is not gray; it is a hard black line that separates product success and project success. The only caveat to that is if you were brought in from the very beginning to build a successful product where the initial business case is part of your scope. But in this case, you were not hired until after these decisions were made.

It sounds like they embarked on this with a mission to do it on the cheap.

Answer 3

First things first, do they still owe you money? If they do, everything you do should be based on whether or not you get those debts cleared. Stop servicing, stop EVERYTHING until the balance is settled. Play hard ball if you have to because there is no point getting stuck deeper than you already are.

Assuming they don't owe you money, your options are pretty simple imo.

1. Try to determine if they are REALLY broke and don't take their word for it. Some customers will take advantage off you just because they can. It's not nice, but it's not rare either.

2. If they are really broke, you need to decide if you want to continue doing this. We are all different creatures but if I were you, there would be zero guilt with stopping. However, the fact that you haven't cut your losses and are posting here probably means you are feeling some guilt. As the others have mentioned, this guilt is not justified so get over it imho. Helping them get over the hump won't result in anything beneficial. In the long run, you would have just taught them that they can expect help for free and they will have taught you that free help is worth exactly zero bucks in the bank account.

Answer 4

It is a testament to your character that you want to keep the customer happy beyond the scope of the project. However, it is not your responsibility.

The best way to help the company at this point (granted, we're only seeing one side of the story) is to let them develop the vision, infrastructure and management capacity necessary for I.T. to meet the company's goals. You aren't helping the company by providing a band-aid.

They need to take responsibility and decide whether and how to move ahead with this line of technology. Step out of the way.

Answer 5

There are many issues here. I will just dwell on a few.

1) It is clear there is a disconnect between IT and the business. Not the first time this happened in the world. It is your job force conflict if avoiding it harms the project. This is necessary but not easy.

2) You have to balance who is paying you (your immediate loyalty) to the overall harm to your reputation if the project flops.

3) There is a rate where supporting the system is worth your time. 50 an hour? 500 an hour? Somewhere in between? Don't be affraid to ask for it. If support wasn't in your original agreement, put a price on your time.

Answer 6

Two thoughts come immediately to my mind.

First, the project must have had a justification up front, otherwise it would never have been commissioned. Has the company looked back at this to see whether the anticipated benefits have been met? - I suspect not. It sounds as though you were taken on to deliver the system, and not to deliver the benefits. You have done your part. It is now the responsibility of the business to make the system work, and if that requires data, then that's what they have to provide. It is not your job, unless you want it to be, and if it is your job, then you should be paid for it.

Second, you need a way out of this difficult situation. However this is to be achieved, it is not going to be easy, so don't expect an easy, cosy chat with your client. I think you need to put down in writing the issues that need to be addressed. Steer away from emotive or emotional statements, and stick to facts...

• The system requires maintenance. Option 1: they give the maintenance to the in-house person. Option 2: they hire someone. Option 3: they pay you to do it.
• Data migration is required. Option 1: You develop the capability in return for money. Option 2: they hire someone to do this. Option 3: they handle this manually.
• ... and so on. You will know the list of key factors.

Present the list to them and ask for a meeting to discuss it after they have had time to review it and digest it.

At the end of the day, you need to protect yourself, and you need income. Working crazy hours for no money achieves neither. My advice is that if they won't pay you, give them a week or two of advance warning, then walk away and don't look back. It may sound harsh, but it might just be the wake-up call that they need. And actually, they probably know this, but have simply been taking advantage of your better nature and desire to do a good job.

Answer 7

I agree with most of the opinions expressed by our peers on the other answers, so I'd try to offer another view of this very same scenario.

• First, don't blame yourself (too much). Problems happens all the time, unfortunately. On the other hand, as more problems we get in a project, as more lessons we learn. So, take this case as an exercise for your next projects. You already mentioned several lessons you learned, so is time to take them and move on.

• Second, stick to what has been agreed. As David mentioned, there's a huge gap between project success and product success, and you cannot take all the blame if things got wrong. But you need to know what was agreed and follow it. Was there any clause talking about the maintenance phase of the project? We know you want to do your best and your client wants to pay as less as possible... that's normal. So, if there wasn't any clause talking about the maintenance, both sides may need to reach an agreement IN ALL LAYERS, i.e. payments, worked hours, scope of the maintenance and so on. I'm not sure about the contract aspect of it, but I believe that in case something is not clear, lawyers may be required to clarify things up. Either way, be formal and be candid.

• Third, formally agree with the client the next steps. This way, there will be sound boundaries both sides will need to respect, avoiding that 'cloudy' area where lies what each part needs to do.

Success!