Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am creating a Mobile application (CRM) for another software company. They told me they need these these stuff from here and there, within 15-30 minutes. But they never provided a detailed client requirement document in writing. I have been asking this for number of times, but still no. As soon as I started working I realized what they told by mouth is not even 10% of the work. They first asked me to come up with my own design which is similar to another app they mentioned. I did, 100% similar design to the app they mentioned. Then they said they don't like it so they gave me their design. I completed there design and submitted it. Now they again say they don't like their own design and asking me to do another design! Apart from that, they are asking for some "Activity Sliding Animations", "Windows Like UI" etc now. In order to do this, I need to remove the entire work I did and start from the scrach, because it can be done by Fragments and mine contains Activities. I even have no idea how the backend will be. Even after one month, we are still designing and changing the designing (Because you have to send at least 3-4 mails, contact at least 2 of their team via phone to get an answer. Very slow communication).

And will they pay for the trashed designs? I don't think so. So what about the other customers of mine which I said 'no' due to the lack of time I am going to have because of this project? I feel almost crazy.

They always say come up with your own idea, but that is very risky in this situation. If my idea is not accepted, waste of time and money.

I am so tired of this, I wasted lot of time designing two 100% different designing, and about to proceed to 3. Since I don't know how the software will be, I haven't done a cost estimation as well. So my question is, client is not supposed to give you any documented requirement? May be an SRS? (What I meant by SRS is, complete detailed document about functionality they need. Including these 'animation' stuff, because I have no super power to guess) The requirement doc they provided is useless, it only says "update", "delete", "edit". All my other clients did provide complete data, some even provided drafts of the design process, except this one. They should at lease ptovide me their requirements in details, in writing, I need some advice here.

share|improve this question

marked as duplicate by gnat, GlenH7, Robert Harvey, Dan Pichelman, ChrisF Nov 25 '13 at 23:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
@gnat: In the question you have mentioned, they all have client req. documentation. That is what I don't have here –  Dongle Nov 25 '13 at 17:54
3  
What does your contract say? If you don't have a contract then chalk this project up to a learning experience of why a contract is a must. –  Mike Nov 25 '13 at 18:43
    
@Mike - put that up as an answer I will up vote it 1000 times. –  mattnz Nov 25 '13 at 19:15

2 Answers 2

This is essentially a contract dispute, and should be covered in the contract.

Would a builder start building a house without knowing how many bedrooms and what the budget was? What would a builder do - he would help the customer by drawing up some plans, agree to the plans, then start building. Would he charge for those plans - that depends, but he would tell the customer.

Every professional software developer knows not to start a project that does not have requirements (Even Agile - the anti-Requirements evangelists, has User stories and backlogs).

Given where you are today, you have several options, not all palatable, an most will depend on your contract. If there contract is as loose as there requirements, (quite common), you have a leg to stand on insisting on payment. One option always is walk away- always be prepared to do this, or you will dig a deeper hole. Learn the meaning of "Sunk costs" if you do not know it.

You could invoice the client for you time, depending on the contract he may or may not pay. If they refuse to pay, what are you prepared to do about it?

My preference in your situation would be meet with your client, with accurate records of what you have spent, and discuss with them a way forward, basted on "fair and reasonable". The contract will define where you stand, however I have had clients pay more than contracted on a project that blew out, they wanted to maintain an ongoing business relationship. If the relationship is not fair and reasonable on both sides, walk away.

share|improve this answer

First, I completely agree with the answer from mattnz. If you are worried about the cost of having to propose multiple designs before the client has something they like, you should definitely formally decide the terms of providing designs, in a contract, before design work begins.

Having said that, it only solves half your problem. The main issue is that you are having a hard time designing something the client finds acceptable. It really stood out to me where you describe the process of submitting new design ideas, and what you get back from those submissions. I have been in that situation before.

I think maybe the problem is that you are dealing with someone other than the person or persons that OK the design. I think you should see if you can have a meeting with the person that is actually making design approval decisions, so you can have a conversation with them about what they want. Chances are, their requests, that come back as obscure "Should be more (insert vague term here)", will make a lot more sense to you if related in person. It will also give you a chance to defend design decisions you made that the client doesn't like, but have been made for good reasons they might not know about.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.