PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sat Mar 25, 2017 10:34 am

All times are UTC - 5 hours




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 12 posts ] 
Author Message
PostPosted: Fri Nov 09, 2012 1:48 am 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
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


Top
 Profile  
 
PostPosted: Fri Nov 09, 2012 2:06 am 
Offline
Site Administrator
User avatar

Joined: Sun May 19, 2002 10:24 pm
Posts: 6883
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.

_________________
Image


Top
 Profile  
 
PostPosted: Fri Nov 09, 2012 4:27 am 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
Benjamin wrote:
fixed-priced projects.

do you work according to a per hour billing system?

_________________
“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


Top
 Profile  
 
PostPosted: Fri Nov 09, 2012 10:50 am 
Offline
Site Administrator
User avatar

Joined: Sun May 19, 2002 10:24 pm
Posts: 6883
Yes

_________________
Image


Top
 Profile  
 
PostPosted: Fri Nov 09, 2012 4:19 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13385
Location: New York, NY, US
I am the opposite. I always try to do as much Agile design as possible. So I try to do least about of work possible to achieve what the client considers the most important goal. I echo it back to them a small, specific deliverable for a fixed price. Once completed both the client and I are smarter and then we decide what is now the new most important thing to build. You example is good one.
social_experiment wrote:
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.
I would start by clearly specifying exactly what the page will do and what data will be saved in the database, being clear what it will and won't do. And be clear (from this description) that the data can be viewed later, but that nothing will be implemented in this phase to actually view the data. Once built they can decide what their priority is.

So in answer to:
social_experiment wrote:
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” ?
Yes.

I do try to educate the client on issues surrounding what they want to build, but they are professional adults and there is only so much you can describe. Everything else they need to learn by doing (and paying for).

_________________
(#10850)


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 2:48 am 
Offline
Jack of Zircons
User avatar

Joined: Thu Nov 09, 2006 9:30 pm
Posts: 4484
Location: California, USA
I'm retired now, but when I was actively developing for clients, my modus operandi was close to what Christopher described. I would suggest following rules like:
  • Spend enough time with client to extract the best scope definition you can, but if there still are gaping holes, I think it is developer's professional responsibility to explain what your knowledge and experience tells you is missing.
  • If specs aren't complete or don't make sense as a system, propose to deliver a prototype system for a fixed price, with the client's understanding that there will be more to follow, at negotiated additional cost (I think this is what Christopher was saying).
  • I would never accept an assignment where I felt that the specs I was given could not result in a useful system that would benefit client. That's just asking for a bad rep.
  • As for deciding between fixed price and estimated hours billed, there are several schools of thought. I used to prefer fixed price for most projects, if only so that I wouldn't have to keep records of my work and never needed to sweat whether I could justify the number of hours I spent on each piece of the job. Maybe I left money on the table sometimes, but generally it worked for me. It also made clients feel like I knew what my skills were worth, and it allowed them to know what they would be paying. But lots of others prefer punching the clock and getting paid for every minute they work. You can argue this one all night long.


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 7:58 am 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
Thanks Benjamin, califdon and Christopher for your feedback :)

Christopher wrote:
I do try to educate the client on issues surrounding what they want to build

I should probably focus on this aspect a lot more;

It seems we work on a similar method when developing systems, would you care to elaborate a bit more on the process you use to arrive at the point where you tell the client this is what it will cost? I write down what the client wants and break it into sections and based on earlier projects (where i did similar work) i estimate the time that will be required for the project to be completed (this includes time for testing and alterations if required)

califdon wrote:
whether I could justify the number of hours I spent on each piece of the job

This is probably what is keeping me from using the per hour billing system; when working on a project i don't really keep to office hours (8 - 5) so i will work from 8 - 4 and then at night put in another few hours, granted i will finish the system sooner but this will mean more hours i have to bill for, i'm not sure how a client might handle that bit of information.

califdon wrote:
I would never accept an assignment where I felt that the specs I was given could not result in a useful system that would benefit client. That's just asking for a bad rep.

Ditto; I've turned down projects where i felt that i didn't have the particular expertise because it's easy to get caught up in a situation where you offer something but cannot deliver 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


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 12:32 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13385
Location: New York, NY, US
social_experiment wrote:
It seems we work on a similar method when developing systems, would you care to elaborate a bit more on the process you use to arrive at the point where you tell the client this is what it will cost? I write down what the client wants and break it into sections and based on earlier projects (where i did similar work) i estimate the time that will be required for the project to be completed (this includes time for testing and alterations if required)
It may sound strange, but I often just code the thing first -- before quoting it. Not to a polished finished deliverable ... just the basic Model classes with necessary queries and then rough out the Controllers and templates. I may spend an hour on it so I get to see what the actual issues that will come up in the implementation. I would spend an hour thinking about the design and estimating the costs anyway.

Also, I usually set a time/cost expectation for the client initially with a little pad in it. And explain the potential problems that may come up. It most often comes in under that, which makes it ok when it is sometimes over.

_________________
(#10850)


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 4:01 pm 
Offline
Jack of Zircons
User avatar

Joined: Thu Nov 09, 2006 9:30 pm
Posts: 4484
Location: California, USA
There's one more concept that I have always maintained, but may be a novel perspective to some.

There are 2 ways to consider the value of a project:
  1. The value to the client, in terms of his cost savings or ability to expand his operations or whatever.
  2. The value to the contractor, in terms of the opportunity cost of spending his time on this contract or whatever alternatives he may have.
If you lose sight of #1, you are missing the whole point of being an independent developer and probably are selling yourself too cheaply. Yet a whole lot of developers think only in terms of #2, thinking "I want to earn $100 an hour, so I'll estimate my work based on that." Think of a client who needs to automate their customer fulfillment operations, which is now a bottleneck limiting their sales growth. As a developer, you may find that it's a pretty straightforward application that would require maybe 120 hours of your time. You now have to choose whether to:
  1. Bid T&M, estimated 120 hrs @ $100
  2. Bid fixed price $12,000
  3. Ask yourself what a smoothly running customer fulfillment operation would contribute to client's business, before deciding what to bid
You might come up with a very different fixed price bid if you choose C. It's worth thinking about.


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 4:35 pm 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
Christopher wrote:
I may spend an hour on it so I get to see what the actual issues that will come up in the implementation.

Interesting approach; i think i might do something similar on my next project; to me this sounds like a better method than just writing down ideas and putting things on paper.

califdon wrote:
It's worth thinking about.

Point 1 is something i have not considered when quoting for a job; I just focus on getting the value of my time spent. Your post has definitely given me something to think about next time i quote for a project;

_________________
“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


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 5:13 pm 
Offline
Jack of Zircons
User avatar

Joined: Thu Nov 09, 2006 9:30 pm
Posts: 4484
Location: California, USA
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.


Top
 Profile  
 
PostPosted: Tue Jul 29, 2014 7:57 am 
Offline
Forum Newbie

Joined: Tue Jul 22, 2014 4:19 am
Posts: 3
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 12 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group