PHP Developers Network

Recently I was working on a project and after a while things started to bubble up which wasn’t innitialy discussed or covered within the project scope documents. It started me thinking about a developers’ responsibility when developing a system for a client.

• Do I design the system to the client specifications, no deviation from the scope document?
• Do I design according to the specifications but suggest things that I think might be relevant to the project?

A very simple example below:
A client wants a system developed where users can enter their contact information (names, surnames, telephone numbers, email addresses); this information is then stored to a database and can be viewed at a later stage.

That’s the specifications as given by the client in the scope document.

As the developer when you look at the document, you can ask yourself some of the questions below (these are questions I ask myself and the client)

• Who will use this system, will an authentication system be required?
• What formats are needed for the data, formats for names, email addresses,telephone numbers?
• Can information be edited, deleted?

What if the client has no idea about the things above? Do you suggest them, do you avoid them? I’ve found that sometimes suggesting ideas that the client isn’t aware of leads to more and more things that the client wants in the system because one suggestion might spark a whole lot of new ideas.

If you don’t suggest something that the client isn't aware of, it could render the system (or data) pointless at a later stage. This will in my opinion reflect badly on the developer because "the developer never thought of it" will most likely be used as explanation.

I always ask clients to be as detailed as possible about what they want but 90% of the time they still skip things that I think are relevant to the system. Do I just do what they ask and if something is not part of the the system pull up my shoulders and say “Well you didn't ask for it” ?

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

This is precisely why I refuse fixed-priced projects.

Even if you and the client have everything set in stone, as the project evolves, as the code is written, new ideas will arise. Call it feature creep if you will, but I digress it almost always happens.

_________________

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

Yes

_________________

_________________
(#10850)

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

_________________
(#10850)

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

I'm glad if I got you to thinking about it in a different light. The real point is to try to adopt the perspective of your client. Based on your desire to earn a certain level of income, a project has a certain value to you, but that could be much higher or lower than the value based on what it may do for client. This can work both ways: if client stands to increase his profits by a million dollars a year by using your application (don't we all wish!), and you estimate that you will need to spend 100 hours on developing and testing (you DO test your applications, don't you?), you probably should bid more than you would for the same amount of effort on a project that is only going to produce neater looking invoices, even if it takes the same amount of your time to develop. Of course you can't bid so high that client will seek another developer, but it should be a factor in your calculations. On the other hand, if a project is just not likely to produce any increase in profits for client, why should he engage you at all? If client is just too dense to realize that he will be spending money on something that doesn't improve his bottom line, then you have the ethical question of whether you should bring this to his attention. I'll leave that decision up to you.

The real point is that an independent developer negotiates with clients about the value of services that developer offers. How is value determined? It is never truly objective, which is why independent developers are different from employees. Every project offers the opportunity for honest and ethical negotiation to arrive at a valuation that satisfies both parties. The availability of competition, of course, has a decided impact on value. It sounds cynical to say "charge what the traffic will bear," but you don't want to be subsidizing someone else's business either. There's always room for principled negotiation.

Client is always right. That is an axiom. To avoid the misunderstanding the right thing is to clarify as more as possible conditions and put it to the Technical Task. Everything must be discussed - Here is the volume of work which I must do and here is the amount of money which I must get for this job. After doing this, even if your client will have questions that something is not going as he explained you can take the Technical Task and show him the concrete agenda. I `ve met many clients who likes to change the mind while work is almost done. For example - "Listen I wake up today morning and decided that we should change the interface because the first one looks not stylish". In case that Technical Task made in appropriate way you can asnwer - Yes, off course we change you but it will take the additional charges.