Deadlines set by the customer
-
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
-
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
Exactly!
Christopher Duncan Author of The Career Programmer and Unite the Tribes www.PracticalUSA.com
-
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:
What do you do in such a situation?
work overtime. Not the best solution, and I tell the customer that. Plus working overtime is not efficient, productivity drops, so although doubling the time may "look" like you should get half the schedule time, it usually means only 2/3rds or 3/4ths. You pay a lot more for less time.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)