Looking for advice - Being rushed by a client to finish the project asap

[MikeH]

So, as per title, my client (very valuable) is extremely keen to get the project ready to use. I had said a matter of months, but they need it now.

I've just got off the phone with them pleading with me to help and I've said where I'm up to but there is still stuff to do and that takes time.

I'm thinking:

1, Stick to my schedule.
Pros = Eases stress on me.
Cons = The person with that job is threatening to quit, their software is that bad. They want me to step in and use their existing software but it is terrible.

2, Get a limited version useable and go with that.
Pros = Their person will be happy stay (at least for now) and be trained in my software and that can be done gradually as it is completed.
Cons = I won't be able to get every feature they want finished in time

3, Some compromise of those two
Pros = Keeping a good, open relationship with them. Sharing the stress between myself and them
Cons = I will still be more stressed than option 1. Such is (self employed) life!

What would you do?

 

[JohnC]

What do you mean by "They want me to step in and use their existing software but it is terrible"?

The bottom line is that if they are a good client, they know that "their" problem is not your fault, so they shouldn't expect you to do extra work to fix their problem for free.

So, do whatever it takes to make them happy because when they are happy, they will be happy to pay you extra because you fixed "their" stress, and by getting more money, it will reduce your stress

 

[MikeH]

What do you mean by "They want me to step in and use their existing software but it is terrible"?

The bottom line is that if they are a good client, they know that "their" problem is not your fault, so they shouldn't expect you to do extra work to fix their problem for free.

So, do whatever it takes to make them happy because when they are happy, they will be happy to pay you extra because you fixed "their" stress, and by getting more money, it will reduce your stress

The person doing the job wants to quit so they've asked me to replace them. I will be reimbursed. Ultimately, I will do this job but probably shared with others.

I like your further words, thanks

 

[JohnC]

The one thing I have learned is that the main goal is to keep the customer happy, and they will be happy to pay you because you made their life happier. Customers who expect you to do things for free, are not customers I want because they will almost always cause me too much stress.

Just propose the two different solutions (provide a scaled down first version, or work for them using the existing software in the mean time) to the customer and let them choose because their choice is the one that will make them the happiest, and thats the goal (so you shouldn't make that choice, and the bonus of letting them make the decision is that if their choice doesn't work out the way they expected, they know that they are the ones who made that choice

 

[mcqueccu]

If they are not ready to wait for the full software to be ready, perhaps the software is what they use for their day-to-day running of the business, then I will go for option #2.

Get the very basic feature that they need to continue running their business whiles you work to get the other parts working.

 

[aeric]

I will prefer option #2 too. Build the trust and it will be easy next.

 

[epiCode]

It is human tendency to pick the easy way out. If you were not around, they sure would have a plan B or they will have to make one.
Your stepping in should not make things difficult for you and easy for them, and yet does not compensate you someway.

 

[epiCode]

one more tip... after you get a lot of suggestions, make the client read this thread.

 

[MikeH]

It is human tendency to pick the easy way out. If you were not around, they sure would have a plan B or they will have to make one.
Your stepping in should not make things difficult for you and easy for them, and yet does not compensate you someway.

Their plan B I think would be to find someone internally to use their software. This is how I get my chance, no-one wants to do it. Not only am I a new person to help, I'm supplying better, easier to use software so that others will be more keen to do the job. All the same, I'd be happy to do it. My bigger plan is to sell this software online (MSoft/Apple/Linux(?) market).

Compensation isn't an issue at all, thats all good. I'm using this place for testing and they're fine with that, in exchange they get a discount.

 

[emexes]

2, Get a limited version useable and go with that.
Pros = Their person will be happy stay (at least for now) and be trained in my software and that can be done gradually as it is completed.
Cons = I won't be able to get every feature they want finished in time

Piecewise step-by-step development is not entirely a bad thing. ?

Yes, you'll look back and think it would have been quicker to code the whole lot all at once, without the intermediate working versions.

On the other hand, seeing the intermediate versions in actual day-to-day use also helps keep the project focussed on core functionality, and lowers the likelihood of implementing features that never get used or turn out to be on the wrong side of the cost-vs-benefit tradeoff.

What do you mean by "They want me to step in and use their existing software but it is terrible"?

The person doing the job wants to quit so they've asked me to replace them. I will be reimbursed. Ultimately, I will do this job but probably shared with others.

Lol sounds like you're bound by confidentiality, but I am curious as to how software could be so bad that it causes somebody to want to quit their job. Or maybe I've misunderstood completely. ?

 

[MikeH]

Piecewise step-by-step development is not entirely a bad thing. ?

Yes, you'll look back and think it would have been quicker to code the whole lot all at once, without the intermediate working versions.

On the other hand, seeing the intermediate versions in actual day-to-day use also helps keep the project focussed on core functionality, and lowers the likelihood of implementing features that never get used or turn out to be on the wrong side of the cost-vs-benefit tradeoff.




Lol sounds like you're bound by confidentiality, but I am curious as to how software could be so bad that it causes somebody to want to quit their job. Or maybe I've misunderstood completely. ?

Yes, I agree. It keeps me "in the loop" with how they operate, what they need and what they dont need. Ive been sitting in to observe how they're using it and what obstacles they have. I've arranged an in person meeting on Saturday afternoon to demonstrate what I've got so far. With a few more tweaks, I think it could be useable already.

Lol right back at ya Ive had a good look at this software, it was written in 2005 and doesnt look like its had an update since. It has a very unintuitive interface, with everything crammed into the one window. Text is a maximum 12 pts high... need I go on? They've been paying a decent price to renew 5 licences for it over the last 5 years too. It does eventually do what they want but its such an incredibly arduous task.

 

[Peter Simpson]

So, as per title, my client (very valuable) is extremely keen to get the project ready to use. I had said a matter of months, but they need it now.

I've just got off the phone with them pleading with me to help and I've said where I'm up to but there is still stuff to do and that takes time.

Did you not get your client to sign a client/developer software agreement document, I always do that not unless the project is extremely short and simple to create (short is one month).

Apart from short simple projects, I always get an agreement signed by both parties (the client and myself) for the maximum time that I have to develop their bespoke solution, then the first, second and and third (final) payments are due, when the client will receive the first beta copy of the software etc etc etc.

Why do I have clients sign the software agreement, well that's simple really, so that I do not end up in a situation like you are currently in.

If I ever ended up in the situation that you're currently in (which I never have) I would simply have a meeting with the client referring them back to the signed agreement with time lines. But saying that I would let the client know that I would try to speed up the development process a bit, but only if doing so doesn't interfere with other projects that I may or may not be busy doing.

Basically, if you can't speed things up then they will just have to wait and get their bespoke software by the original delivery period.

If your client originally wanted the software sooner, they should have told you that from the very beginning before you gave them a price for the work to be carried out.

This response probably doesn't help you at all, but I hope that you manage to get everything sorted out without too much stress...

 

[MikeH]

Did you not get your client to sign a client/developer software agreement document, I always do that not unless the project is extremely short and simple to create (short is one month).
...

You're correct - I didn't. I don't see any harm in them asking for it sooner, its just down to me to be realistic and tell them straight whats possible and whats not. Thats going to happen in the meeting tomorrow. I'm shattered with the long hours I've already put in but I do have a limited, working version now. I think they'd probably accept that it takes time and its actually me thats wanting it done sooner - having my heart strings pulled yesterday with the phone call partly to blame. I aint Superman though, as much as I try to kid myself. My bed has forgotten who I am. Its end of the financial year too when I normally take a break...

 

[Peter Simpson]

My bed has forgotten who I am. Its end of the financial year too when I normally take a break...

Oops

I don't see any harm in them asking for it sooner

Neither do I.

Don't get me wrong, I if I had a client ask me if I could deliver their project sooner rather than later I would try my best to accommodate them. But I would also know that I got them to sign a software agreement document with their original project completion date that they signed beforehand.

To tell you the truth, basically all my project have be completed early, larger project are usually completd a few months before the completion date. On the odd occasion I've had larger project completed just a couple of weeks before the completion date, but usually that's because I'm doing a second project at the same time, shh

I always try to finish projects early as long as the client gave a realistic project completion date in the first date. I have actually turned down work when potentially new clients gave totally unrealistic dates with an unrealistic budgets. I basically just say I can't do it for what they want and I say goodbye to them. Sometime those same potentially new clients contact me afterwards requesting that I send them a quote with what I believe the timeline and price should in fact be. On the odd occasion I have been given the go ahead and I've gotten the new client to sign a software agreement document.

Good luck with your meeting tomorrow.
Just stick to your guns and your price, they should fall into line as they are the ones that have changed their mind and move the goalposts on the timeline, not you.

 

[johnc_nz]

The old adage, their choices on time, to budget, and to spec, pick any two. I agree with the thoughts above, be open to what you can deliver given the time constraint they want to impose. Having an incremental release of features is okay, and maybe even advantageous in that once the first version is in, you may see a different set of features for the next version that will make it even better.

 

[Computersmith64]

If you were using a Scrum methodology (which I'm not necessarily a supporter of) you'd be trying to get to a MVP (Minimum Viable Product) asap anyway, so that's what I'd propose. Get them to tell you what the minimum requirements are for a system they can use & start there. Once you have that, you can build on it. It might take several iterations of defining the minimum requirements - because the user will always want everything on the first pass - but if you sit down with them & thrash it out you should be able to get somewhere. Once you have the MVP defined, then they have to accept that it will take however long you tell them it will take.

- Colin.

 

[Bruce Axtens]

I strongly recommend reading Never Split the Difference. The negotiation techniques are pratical and true-to-life. The fact that the author was an FBI hostage negotiator helps. As an Australian who finds Yankee hype off-putting, there's a matter-of-factness to the book that's quite refreshing: he's as open about the failures as he is about the successes.

 

[emexes]

I strongly recommend reading Never Split the Difference. The negotiation techniques are practical and true-to-life. The fact that the author was an FBI hostage negotiator helps.

I haven't read the book, but I've watched the author's videos on YouTube and they are excellent.

Lol excellent enough that, combined with the above recommendation, I'm now going to hunt down the book too.

 

[Peter Simpson]

Thats going to happen in the meeting tomorrow.

Good morning Mike,
How did your meeting go?

I hope that your meeting went to plan and that you managed to come to some sort of viable solution. I presume that you bashed out a solution with your client that allows for a incremental staged releases in beta form to your client until the software has been completed.

Enjoy

 

[ilan]

4. hire a freelancer that will help you finish the project in time.