I would like some input on how to handle clients and third party vendors that ask me about the deficiencies in my design.

For example. It turns out I need a data field in a webservices response. This response has been signed off on weeks ago and I get questions like "Why haven't you identified this field X weeks ago?". Of course the answer is that all software development is iterative and this requirement wasn't on my radar at that point in time. I'm not prescient.

I would like a business-y way of deflecting these questions. Any advice?

Update: To clarify, this shortcoming is completely on me. How do I then own up to this mistake cleanly, without sounding too apologetic?

  • 3
    If X wasn't in the requirements, there's no need to deflect the question. The business-y way of handling it would be to get straight to the point: "X wasn't in the requirements, and I've done the implementation you approved." – Blrfl Mar 26 '13 at 18:22
  • @birfl I updated my original question. It's my mistake, I need a good way of wording it while still appearing professional. – EightyEight Mar 26 '13 at 18:29

I almost always just accept the blame for everything:

I'm sorry, I missed it. Perhaps we can get into the details why in a future retrospective. In the meantime, field X has now been identified and needs to be implemented now in order to come close to meeting our deadlines.

It takes the issue of blame off the table, and lets people focus on being constructive.

If you think they'll fire you over it, well, you've got other issues in your relationship with your customers.

|improve this answer|||||
  • The thing with accepting blame has the danger of projecting incompetence. Usually saying "i missed it" will work the 1st time.. but the 2nd or 3rd time, they're going to start looking for another vendor / reviewing your code.. – hanzolo Mar 26 '13 at 20:06
  • He did say the shortcoming is entirely on him, if it happens several times then that might be the problem at hand. – Jeroen Vannevel Mar 26 '13 at 20:28
  • I understand.. but if it was signed off, the defect is not ENTIRELY on the OP. The actual mistake is, but coding mistakes happen, it should've been caught in QA / Acceptance. I think taking the blame here opens the door for unneeded scrutiny in the future, when it's the process which is actually to blame. – hanzolo Mar 26 '13 at 21:09
  • 1
    @hanzolo: the phrase "we all missed it" is a good one when dealing with things that were missed, and then the design which missed them was signed off by the client. – Carson63000 Mar 26 '13 at 22:11
  • 1
    @hanzolo - I would say the key is to follow up with a successful delivery. If everyone is happy with the product in the end, rarely will they come back and say how incompetent you are. – Matthew Flynn Mar 27 '13 at 15:12

Add the new field in (do the work), and tell them that you're "looking forward to improving the development process" so that these shortcomings are prevented in the future.

Basically, by adding the field in, you've acknowledged that additional development was needed to satisfy the requirements.

This is not YOUR fault necessarily (it could be if the spec was overlooked, but it happens), and if it was signed off, then everyone missed it.

and then acknowledge the the communication and acceptance process "has room for improvement" so that this situation doesn't arise again. This gives them reassurance that this is not acceptable and they can expect improvements in the future.

The last thing they want is an apology, they want you to acknowledge the mistake, and to hear that it was in fact, a mistake and that efforts will be made to correct and prevent more mistakes in the future.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.