4

We are working on a project that has already been a month delay (due to change requests from client.) After we complete our work include these change requests, we found a performance degrade issue (it takes 1.5 more seconds to book a car.) This issue might prevent us from releasing this new system to our client.

I found out this issue early in the morning and sent out an email to everyone involve (internal) right after explaining that it is a complex issue and will take a month to fix it; an estimate from engineers is 2 weeks so I put one month.

I will have a meeting with our client next week but I wanted to have a meeting with them tomorrow (Friday) to let them know about this issue. Should I schedule this meeting ASAP? How can I handle this situation with our client?

Improve this question
4
  • 1
    Really tends to depend on the client. Is the product usable without the fix? Can you give the client options whether to roll out with this version in the meantime?
    – Gamora
    Feb 20, 2020 at 15:39
  • 2
    @Bee the product is usable and 100% functional. The issue is that it is 1.5 seconds slower than the current system. Giving an options to client is a good idea. Thank you for your suggestion
    – Hamed
    Feb 20, 2020 at 15:43
  • 2
    Its sounds like your management isn't very good. Whoever decided to honor change requests that weren't in the original contract agreement and allowed the project to be so delayed that you cant resolve last minute issues probably isn't ready for the role they are in.
    – TheBatman
    Feb 20, 2020 at 18:39
  • 1
    The client can surely live with a 1.5 second delay in the interim (as a customer, I am quiet used to "@~£$! computer is slow today"), as long as you promise a fix. Break out valgrind, or whatever profiling too is available to you and get to it (note that you might get away with only profiling the recent changes, but , if you have the rime, profile everything, including database accesses)
    – Mawg says reinstate Monica
    Feb 21, 2020 at 6:28

3 Answers 3

Reset to default
12

From the comments, you've clarified that the product is 100% usable. Therefore you have delivered it onetime.

I would frame it, not as a bug but the potential to add value. I don't think there is any need to move the meeting forward, but it really depends on the relationship you have with the client and whether you think it will be really important.

They have two choices:

  • Go live with the product as is whilst you work on v2.0 which will be 1.5 seconds faster;
  • Wait 2-4 weeks for the improvement before going live

Notice my wording - improvement. Don't mention that its an error there isn't a need and it will give them ammunition to blame you for all the delays to upper management.

Improve this answer
3
  • 3
    (+1) "Why does this run slower?" - "because it does x,y,z better things the old system couldn't do"
    – user81330
    Feb 20, 2020 at 15:50
  • 2
    @bilkokuya I was just wondering if I should add something along those lines to the end of my answer when you posted!
    – Gamora
    Feb 20, 2020 at 15:51
  • 2
    There might have been requirements on the new systems performance and that requirement has to be met. If so, it is not not delivered on time, even though it is functional.
    – Just another Java programmer
    Feb 20, 2020 at 19:46
3

Should you tell people right away about a significant schedule change? Yes.

Why? There's a principle of business and engineering excellence. The Principle of Least Surprise. Communicate to avoid surprising people. Always.

If you make it known that you're facing a problem, it stops being just your problem. The people depending on you can plan ahead for the delay. That's always better than being having them be surprised on the day when you were scheduled to deliver.

And, in your specific case they can help you make a decision whether another month of work is worth 1.5 seconds of latency.

(Oh, and by the way a one month slip on a software project is not very bad. Don't beat yourself up about it.)

Improve this answer
0

The product is usable and a delay can be explained by adding the new features. Go live and promise an upgrade.

The client can surely live with a 1.5 second delay in the interim , as long as you promise a fix. As a customer, I am quiet used to hearing "the @~£$! computer is slow today", and getting my car 1.5 seconds sooner is not really going to cause me to boycott that particular hire company.

Break out valgrind, or whatever profiling tool is available to you and get to it (note that you might get away with only profiling the recent changes, but , if you have the time, profile everything, including database accesses).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .