Deadlines set by the customer
-
Well... What do you think about it? Sometimes a customer demands to have something in a set time, but the problem is that time has nothing to do with developer's estimation. What do you do in such a situation? I usually don't take such projects where the customer doesn't understand that he just can't make up a deadline out of nowhere. I will usually say "no, thank you" and direct him to look somewhere else. Yes, I may loose business that way, but I save on nerves ;) and usually find other customers who are better to work with. My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree. It is true when you have enough manpower to build a bigger team that can do things faster, but not when you're working alone. I want to have a life outside of work, money is important, because that's how the world is built, but not the most important thing to me. The colleague is a workaholic, actually. ;) It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run). This just happened to me a few days ago, so I thought it was time to discuss this with other developers. How do you manage such situations? Regards, Pawel
Pawel Krakowiak wrote:
It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run).
This is why I make people sign a contract stating when the deliverables will be ready.
Pawel Krakowiak wrote:
My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree.
Sure it can. Suppose they are willing to throw at you a whole year's salary in something that can be done in a few months.
"Try asking what you want to know, rather than asking a question whose answer you know." - Christian Graus
-
I point out that there are three things that can be achieved in a software project: speed reliability features You can only have two of the three. If someone were to tell me I had to focus on speed, I'd ask which of the other two I was to drop.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Do you ever get anyone who chooses speed and features? :rolleyes:
"Try asking what you want to know, rather than asking a question whose answer you know." - Christian Graus
-
Mind if I coin this as Graus's Uncertainty Principle?
-- Kein Mitleid Für Die Mehrheit
-
The secret to managing such situations has nothing to do with technical considerations, and everything to do with understanding people. The overwhelming majority of techies forcibly ignore this reality by sitting in a corner and chanting to themselves, "I'm not paid to do anything but write code." And of course in their spare time, they complain about how unfair things are. The world is run by humans, and humans have a tendency to be complex, emotional, illogical, self serving creatures who often suffer from tunnel vision and delusional thinking. If things aren't going well with one of your pet humans, then you should put down that compiler tutorial for a moment and pick up the "Care and Feeding of Your Pet Human" manual. Seriously, if you want to succeed in this or any other endeavor, whether you're running your own company or just managing an individual career, you need to learn how to interact effectively with people. Failure to do so will ensure that you spend more time complaining about how unfair things are than you do on the technical activities that you enjoy. Welcome to Earth. I don't make the rules. I just work here. :)
Christopher Duncan Author of The Career Programmer and Unite the Tribes www.PracticalUSA.com
Exactly right and something I've brought up here many times before only to receive bitchy replies along the lines of "I live in a bubble and people must cater to me" followed a few months later with "It's so unfair that the company I used to work for decided to outsource". :)
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
Well... What do you think about it? Sometimes a customer demands to have something in a set time, but the problem is that time has nothing to do with developer's estimation. What do you do in such a situation? I usually don't take such projects where the customer doesn't understand that he just can't make up a deadline out of nowhere. I will usually say "no, thank you" and direct him to look somewhere else. Yes, I may loose business that way, but I save on nerves ;) and usually find other customers who are better to work with. My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree. It is true when you have enough manpower to build a bigger team that can do things faster, but not when you're working alone. I want to have a life outside of work, money is important, because that's how the world is built, but not the most important thing to me. The colleague is a workaholic, actually. ;) It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run). This just happened to me a few days ago, so I thought it was time to discuss this with other developers. How do you manage such situations? Regards, Pawel
Usually I talk with the customer to get the unreasonable deadline out of his head. This doesn't always work, in those cases I end up discussing wich features to drop or simply tell him to rethink his decision. However customers that give me a deadline are a rare ocasion. Sometimes they need something because the law requires them to provide a certain service, but they usually start early enough for me to come up with a reasonable plan.
WM. What about weapons of mass-construction? "What? Its an Apple MacBook Pro. They are sexy!" - Paul Watson My blog
-
Well b'cos customers do not understand, they will often choose speed and features. Then how do we be good professionals then? Mr Q
You get them to sign off on it so when the crash complaints start to come in you can show them what they paid for. :) I had a customer sign a statement once that showed that they insisted that I pull my schedule in by a month. It included a listing of tests and processes that had to be skipped due to this. It ended up covering my butt a few times when they trued pulling a fast one on me. I pulled out the document and showed them a direct correlation between what their problem was and the areas skipped. I didn't like doing it but the customer is the customer :)
-
I don't mind if the customer sets a deadline, it's just like anyone else--manager, client, heck, even myself. If the deadline is unreasonable, then I say so and explain why and that usually results in a more realistic deadline. I actually like it when the customer sets a deadline. Because then, when they say "oh, can we add the moonbase widget", well, there's that deadline that they set, hahaha. What I don't like is the crisis customer. "You have two weeks to get this software done because that's when the peak shipping period for my goods begins, and I need an automated solution by then." (true story, I left out the details). Those customers are trouble, because they clearly can't manage their OWN deadlines! I have no qualms saying "your crisis is not my crisis" directly to them. The reaction is always entertaining, and sometimes positive. Marc
To this I would respond... "then we need to reset the scheduled to a longer deadline to hit the exact season next year and you should keep doing what you have been doing for years this time." If what they have been doing for years has gotten them this far they can do it one more time before having to shoehorn in a new system. The heck with just getting it built and tested, what about getting the users trained? People always seem to forget about user training in their schedules.
-
To this I would respond... "then we need to reset the scheduled to a longer deadline to hit the exact season next year and you should keep doing what you have been doing for years this time." If what they have been doing for years has gotten them this far they can do it one more time before having to shoehorn in a new system. The heck with just getting it built and tested, what about getting the users trained? People always seem to forget about user training in their schedules.
Ray Cassick wrote:
If what they have been doing for years has gotten them this far they can do it one more time before having to shoehorn in a new system.
Exactly. I was a bit surprised by the request. Marc
-
Well... What do you think about it? Sometimes a customer demands to have something in a set time, but the problem is that time has nothing to do with developer's estimation. What do you do in such a situation? I usually don't take such projects where the customer doesn't understand that he just can't make up a deadline out of nowhere. I will usually say "no, thank you" and direct him to look somewhere else. Yes, I may loose business that way, but I save on nerves ;) and usually find other customers who are better to work with. My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree. It is true when you have enough manpower to build a bigger team that can do things faster, but not when you're working alone. I want to have a life outside of work, money is important, because that's how the world is built, but not the most important thing to me. The colleague is a workaholic, actually. ;) It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run). This just happened to me a few days ago, so I thought it was time to discuss this with other developers. How do you manage such situations? Regards, Pawel
The last time I was in a similar situation, we worked our asses off to meet the demand, and later found out that the customer actually started using the system some 6 months after we delivered it :)
-
The last time I was in a similar situation, we worked our asses off to meet the demand, and later found out that the customer actually started using the system some 6 months after we delivered it :)
Nemanja Trifunovic wrote:
The last time I was in a similar situation, we worked our asses off to meet the demand, and later found out that the customer actually started using the system some 6 months after we delivered it
You know, I think this is quite common... At first it's BURNING and when you deliver the customer actually "doesn't have time to look at it now".
-
Well... What do you think about it? Sometimes a customer demands to have something in a set time, but the problem is that time has nothing to do with developer's estimation. What do you do in such a situation? I usually don't take such projects where the customer doesn't understand that he just can't make up a deadline out of nowhere. I will usually say "no, thank you" and direct him to look somewhere else. Yes, I may loose business that way, but I save on nerves ;) and usually find other customers who are better to work with. My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree. It is true when you have enough manpower to build a bigger team that can do things faster, but not when you're working alone. I want to have a life outside of work, money is important, because that's how the world is built, but not the most important thing to me. The colleague is a workaholic, actually. ;) It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run). This just happened to me a few days ago, so I thought it was time to discuss this with other developers. How do you manage such situations? Regards, Pawel
Most people think programmers just make up estimates (Often, they're right ;) ), However, when we make them up, they're based on experience. When they make them up, they're based on.. well, whatever goes on in their heads. ;) The problem you're having is that you should have a signed contract with your client up-front for the project, describing how long things will take, and the consequences of alteration of that schedule (either to add more features, or move timetable). A lot of programmers don't like to do this, because it then makes them liable if they mess up.. but it really covers your ass. There's an old saying. "Lack of planning on your part does not constitute an emergency on my part". You work your X hours a week, you do your work on your timetable. If they need it faster, then you have them sign a document that reflects the things you will have to do (or not do) in order to give tht to them, and what that will mean to the end product. In any case, if your ass is covered, you don't have to worry about raising your blood pressure or restricting your life. If they want you to work overtime to get it done, tell them you won't. They can find someone else if that's not ok with them. The customer is always right, but only as far you are willing to let them be.
-- Where are we going? And why am I in this handbasket?
-
Pawel Krakowiak wrote:
It is true when you have enough manpower to build a bigger team that can do things faster
Not in every situation. I usually ask a person proposing this a question. "If it takes an hour to drive to Warsaw will having 2 drivers in the car get us there in 30 minutes?" time compression corollary "If it takes an hour to drive to Warsaw will we get there in 30 minutes if we set out in 2 cars?" As you can see just having resources doesn't unnecessarily mean that you can utilize the resources available. There are situations where having more resources available will speed up the outcome but don't fall into the trap of expecting linear returns. I once had a discussion with a manager who wanted to cut my coding time estimates by half. My response was why not say the modules and will be ready tomorrow since they will not be functioning anyway. He decided to go with my estimate. :doh:
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote:
"If it takes an hour to drive to Warsaw will we get there in 30 minutes if we set out in 2 cars?"
No, but if you're driving to Warsaw to pick up some paperwork, then you can do it in 30 minutes if another driver drives from Warsaw and meets you halfway with them ;)
-- Where are we going? And why am I in this handbasket?
-
Well... What do you think about it? Sometimes a customer demands to have something in a set time, but the problem is that time has nothing to do with developer's estimation. What do you do in such a situation? I usually don't take such projects where the customer doesn't understand that he just can't make up a deadline out of nowhere. I will usually say "no, thank you" and direct him to look somewhere else. Yes, I may loose business that way, but I save on nerves ;) and usually find other customers who are better to work with. My colleague says that money can twist time, i.e. if the customer pays well enough his deadline becomes reasonable. I don't agree. It is true when you have enough manpower to build a bigger team that can do things faster, but not when you're working alone. I want to have a life outside of work, money is important, because that's how the world is built, but not the most important thing to me. The colleague is a workaholic, actually. ;) It's worse when you already are in the middle of a project and the customer suddenly tells you it must be done in two weeks (which means one week, because that's not the only project you run). This just happened to me a few days ago, so I thought it was time to discuss this with other developers. How do you manage such situations? Regards, Pawel
You might want to read http://www.ddj.com/architect/201202925[^] and definitely the last page http://www.ddj.com/architect/201202925?pgno=4[^]
-
Well b'cos customers do not understand, they will often choose speed and features. Then how do we be good professionals then? Mr Q
It's your job to make them understand, and if they refuse, then, as someone else said, get them to sign off on it. A document that says 'I accept that I have requested software to be written with no guarentee or warranty of quality or lack of bugs', will scare most people into reconsidering their position.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Mind if I coin this as Graus's Uncertainty Principle?
-- Kein Mitleid Für Die Mehrheit
It's not mine, it came from a book called 'Rapid Development'
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Do you ever get anyone who chooses speed and features? :rolleyes:
"Try asking what you want to know, rather than asking a question whose answer you know." - Christian Graus
No, what generally happens is that it brings things down to earth, and if speed really is a fundamental, then it leads into a discussion of what features become v2 features.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
No, what generally happens is that it brings things down to earth, and if speed really is a fundamental, then it leads into a discussion of what features become v2 features.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
then it leads into a discussion of what features become v2 features.
Sounds similar to the one aspect of Extreme Programming in which you put together story cards of the features you want to implement, and prioritize based on the time constraints what needs to be done now, and what can wait until later.
"Try asking what you want to know, rather than asking a question whose answer you know." - Christian Graus
-
The secret to managing such situations has nothing to do with technical considerations, and everything to do with understanding people. The overwhelming majority of techies forcibly ignore this reality by sitting in a corner and chanting to themselves, "I'm not paid to do anything but write code." And of course in their spare time, they complain about how unfair things are. The world is run by humans, and humans have a tendency to be complex, emotional, illogical, self serving creatures who often suffer from tunnel vision and delusional thinking. If things aren't going well with one of your pet humans, then you should put down that compiler tutorial for a moment and pick up the "Care and Feeding of Your Pet Human" manual. Seriously, if you want to succeed in this or any other endeavor, whether you're running your own company or just managing an individual career, you need to learn how to interact effectively with people. Failure to do so will ensure that you spend more time complaining about how unfair things are than you do on the technical activities that you enjoy. Welcome to Earth. I don't make the rules. I just work here. :)
Christopher Duncan Author of The Career Programmer and Unite the Tribes www.PracticalUSA.com
Christopher Duncan wrote:
The secret to managing such situations has nothing to do with technical considerations, and everything to do with understanding people.
There's a good book on that subject called "The Career Programmer: Guerilla Tactics for an Imperfect World[^]" but I guess you heard about it :-D
-
JimmyRopes wrote:
"If it takes an hour to drive to Warsaw will we get there in 30 minutes if we set out in 2 cars?"
No, but if you're driving to Warsaw to pick up some paperwork, then you can do it in 30 minutes if another driver drives from Warsaw and meets you halfway with them ;)
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
JimmyRopes wrote: "If it takes an hour to drive to Warsaw will we get there in 30 minutes if we set out in 2 cars?" No, but if you're driving to Warsaw to pick up some paperwork, then you can do it in 30 minutes if another driver drives from Warsaw and meets you halfway with them
The question was can you get to Warsaw in half the time if you had 2 cars driving there. You are answering a completely different question. :confused: I never mentioned paperwork and you would still be 1/2 way to Warsaw at the point the other driver meets you. :doh:
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Christopher Duncan wrote:
The secret to managing such situations has nothing to do with technical considerations, and everything to do with understanding people.
There's a good book on that subject called "The Career Programmer: Guerilla Tactics for an Imperfect World[^]" but I guess you heard about it :-D
:-D
Christopher Duncan Author of The Career Programmer and Unite the Tribes www.PracticalUSA.com