Make up your bloody mind
Contracts are signed by the client and the developer. Often you hear about the client making a developer produce work without signing a contract, and the developer, for the sake of $$, does wat the client requests, and in the end the client refuses to pay, and the sort...
Then there is the case where the client signs the contract. oh now all must be well. no. Apparently many of these clients sign for the sake of making the developer hurry and produce work. Often in web development projects there is a part that states "the developer will produce work to the requirements of the client. any design which the client requires a change after approval of the prototype will be liable to charges".
How often, though, do clients keep changing their minds on a pre-agreed design?? we create the prototype for approval, and the clients say ok. after weeks of development, then the client says: "i think this and that is better. change." And how often does the developer nod and agree without charging the client? sometimes the change on paper is small, like "adding a drop-down list", but they do not realize that these changes require a lot of re-design not only on the interface, but internal components and databases as well. And when the change is done, they will say: "hmm. i think you add something more to that". Why can't these clients make these decisions during the prototype stage? the prototype is meant to be a "toy" for them to play with, but they neva take the word prototype seriously. How often do you hear a web project bust its deadline and clients complain on the competency of the developer? LOL. Make up your mind and do some soul-searching. please.


4 Comments:
U r ONE sad MAn... kekeke...
12:44 AM
Many times. Always. I feel your pain. I try to enforce the additional cost rule to any change. Only really minor changes like words and such which does not affect any design changes will not be charged. That's usually clearly stated in the contract. And usually when they say they want changes, I'll usually tell them we need XXX amount of additional time, and XXX amount of dollars, and XXX amount of more work to be done just to implement that small change, just to discourage them from changing it, or rather make them think twice before actually changing.
Usually what I try to do is to put myself in their shoes, and spec out functionalities that they might want, and imagine myself as the users, and sometimes even interview the potential users (if it's an internal project used by their own people) just to see how they view things, and their habits of doing things. That will reduce the number of changes, because you must remember, the client does not know what they themselves want, rahter you got to know for them.
One of the many trials of being a project manager cum developer.
1:06 PM
We're going to have a discussion on Change Management in our SgDotNet community (www.sgdotnet.org) next month on the 7th July Thursday. Maybe you'll like to drop by and see the pain everyone's facing too.
1:08 PM
thanx triplez, if i have the time i'll do so!
2:28 AM
Post a Comment
<< Home