Mixing
Do I need to be honest with a client even if it would show my incompetence?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
17
down vote
favorite
I am a new software Project Manager and facing an ethical dilemma. I have to deliver my software to my clients, who will use it to diagnose ill patients in a hospital. I have to deliver it on time, but recently have found that there are some bugs in software that need to be fixed immediately, which will take some time.
One of my project engineer advised me that, instead of divulging the bug to customer, we told them that this is demo version of the software and not to use it right now. Also to ensure them that we will release the full version quite soon.
I don't want to lie to my customer, but I also don't want to lose customer confidence. How can I solve this problem?
ethics project-management
edited May 17 '14 at 11:35
O. Jones
13.6k24070
asked May 17 '14 at 6:24
Alok Hazra
8913
add a comment |Â
up vote
17
down vote
favorite
I am a new software Project Manager and facing an ethical dilemma. I have to deliver my software to my clients, who will use it to diagnose ill patients in a hospital. I have to deliver it on time, but recently have found that there are some bugs in software that need to be fixed immediately, which will take some time.
One of my project engineer advised me that, instead of divulging the bug to customer, we told them that this is demo version of the software and not to use it right now. Also to ensure them that we will release the full version quite soon.
I don't want to lie to my customer, but I also don't want to lose customer confidence. How can I solve this problem?
ethics project-management
edited May 17 '14 at 11:35
O. Jones
13.6k24070
asked May 17 '14 at 6:24
Alok Hazra
8913
17
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
4
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
1
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54
add a comment |Â
up vote
17
down vote
favorite
up vote
17
down vote
favorite
I am a new software Project Manager and facing an ethical dilemma. I have to deliver my software to my clients, who will use it to diagnose ill patients in a hospital. I have to deliver it on time, but recently have found that there are some bugs in software that need to be fixed immediately, which will take some time.
One of my project engineer advised me that, instead of divulging the bug to customer, we told them that this is demo version of the software and not to use it right now. Also to ensure them that we will release the full version quite soon.
I don't want to lie to my customer, but I also don't want to lose customer confidence. How can I solve this problem?
ethics project-management
edited May 17 '14 at 11:35
O. Jones
13.6k24070
asked May 17 '14 at 6:24
Alok Hazra
8913
I am a new software Project Manager and facing an ethical dilemma. I have to deliver my software to my clients, who will use it to diagnose ill patients in a hospital. I have to deliver it on time, but recently have found that there are some bugs in software that need to be fixed immediately, which will take some time.
One of my project engineer advised me that, instead of divulging the bug to customer, we told them that this is demo version of the software and not to use it right now. Also to ensure them that we will release the full version quite soon.
I don't want to lie to my customer, but I also don't want to lose customer confidence. How can I solve this problem?
ethics project-management
edited May 17 '14 at 11:35
O. Jones
13.6k24070
asked May 17 '14 at 6:24
Alok Hazra
8913
edited May 17 '14 at 11:35
O. Jones
13.6k24070
edited May 17 '14 at 11:35
O. Jones
13.6k24070
edited May 17 '14 at 11:35
O. Jones
13.6k24070
13.6k24070
asked May 17 '14 at 6:24
Alok Hazra
8913
asked May 17 '14 at 6:24
Alok Hazra
8913
asked May 17 '14 at 6:24
Alok Hazra
8913
8913
17
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
4
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
1
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54
add a comment |Â
17
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
4
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
1
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54
17
17
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
4
4
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
1
1
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
37
down vote
To refuse to release software until you believe it works is a sign of competence, not incompetence. This is especially true for mission-critical software used for patient care. Does it pass the "what if it were my mother?" criterion, or not?
Almost all software contains defects, even long-lived and widely deployed stuff. An obvious example is the recent Heartbleed defect in OpenSSL. The measure of your engineering organization is not the absence of defects. It's how you handle them.
This is your first big "go / no-go" decision point as a new PM, and you're advocating "no-go." That stinks. My heart bleeds for you (pun intended). I've done software since 1974, and I still remember each time I had to advocate "no-go." It's one of the most difficult tasks in the business. But it's necessary. Almost every notorious disaster in software can be traced to such a decision being made poorly.
They don't teach this in school.
I have some concrete suggestions for your conversations with your customer on this matter.
Use the formal word defect rather than bug.
Explain that your pre-release software testing process has revealed certain critical defects. Tell the customer how many. If she asks, disclose what they are.
Say that you believe the software isn't fit for production use until those defects are corrected. Explain the consequences of using the software without correcting the defects. For example, "the software will sometimes crash," "under certain circumstances the software will indicate an incorrect drug dosage," or "the software may incorrectly assign input to the wrong patient's record," or even "Some error messages aren't correct, and users will be confused" Be clear and detailed about the defects and their consequences. Transparency is everything.
Disclose your plan and schedule for correcting the defects and retesting.
Conclude by saying, "I think we should correct these defects before we go live, and you are the customer. What do you think?"
Invite your colleague who suggested the lame "demo version" excuse to witness these conversations, and to participate in them if that's appropriate.
Finally, be very happy that you, and not your customer, found these defects. Finding problems before your customer is another measure of competence.
answered May 17 '14 at 11:27
O. Jones
13.6k24070
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
add a comment |Â
up vote
27
down vote
Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
 |Â
show 1 more comment
up vote
4
down vote
I don't see how the "demo version" story makes you look any better. Either way, they're expecting certain functionality delivered at a certain time, and they won't be getting it.
Put yourself in the client's position: how would you feel if you were expecting a finished product, and instead you got "Oh, yeah, it's totally finished, right on time! It's just the demo version, though, so you can't actually use it. But it's finished!" You wouldn't just be disappointed, you'd be bewildered and angry. You'd feel like the developer either didn't understand the requirements, or was trying to give you the runaround.
They'll respect you more if you're honest and straightforward. Focus on what needs to be done to finish the project and how the client can help.
answered May 17 '14 at 21:28
Robert
511
add a comment |Â
up vote
3
down vote
Engage with your costumer. Tell them the true state of your software, and work to fix the bugs. The Therac-25 Accidents is a great lesson to learn from.
Such actions would make you standout and more importantly built a trustful relationship with your client.
answered May 17 '14 at 20:53
KhaledMohamedP
1412
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
add a comment |Â
up vote
1
down vote
I would be far less confident in a software product that was given to me as a demo on the deadline than a project manager who told me up front that they found some last minute bugs and must fix them before shipping. Lives depend on this software, you cannot afford to get it wrong.
As a project manager it is your duty to tell the client the problem and the proposed fix and the revised schedule. You need to tell them now, as soon as possible, not wait until the deadline to tell them you are not delivering on time.
Being a project manager is all about the ability to manage client expectations and the only way to do that is to tell them the truth even when it is not happy news. You must have the ability to face up to telling bad news if you want to continue as a project manager.
Every time I have seen a PM try to manage by never telling the bad news and hoping it will go away (Management by wishful thinking) he has been fired because the truth eventually comes out and clients don't like being lied to.
I remember one time when the devs told the PM that the deadline was not achieveable (and we were already working overtime) and we would misss the deadline by at least a month. He waited to tell the client until the day of the deadline and we lost a multi-million dollar client because " How could you not have known it would take 4 more weeks before today?" Truth was we did know weeks ahead of time, but the PM was a coward and didn't tell them, so he lost the client and his job. That is what is likely to happen to you if you go with the "Demo" story.
answered May 19 '14 at 14:15
HLGEM
133k25226489
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
37
down vote
To refuse to release software until you believe it works is a sign of competence, not incompetence. This is especially true for mission-critical software used for patient care. Does it pass the "what if it were my mother?" criterion, or not?
Almost all software contains defects, even long-lived and widely deployed stuff. An obvious example is the recent Heartbleed defect in OpenSSL. The measure of your engineering organization is not the absence of defects. It's how you handle them.
This is your first big "go / no-go" decision point as a new PM, and you're advocating "no-go." That stinks. My heart bleeds for you (pun intended). I've done software since 1974, and I still remember each time I had to advocate "no-go." It's one of the most difficult tasks in the business. But it's necessary. Almost every notorious disaster in software can be traced to such a decision being made poorly.
They don't teach this in school.
I have some concrete suggestions for your conversations with your customer on this matter.
Use the formal word defect rather than bug.
Explain that your pre-release software testing process has revealed certain critical defects. Tell the customer how many. If she asks, disclose what they are.
Say that you believe the software isn't fit for production use until those defects are corrected. Explain the consequences of using the software without correcting the defects. For example, "the software will sometimes crash," "under certain circumstances the software will indicate an incorrect drug dosage," or "the software may incorrectly assign input to the wrong patient's record," or even "Some error messages aren't correct, and users will be confused" Be clear and detailed about the defects and their consequences. Transparency is everything.
Disclose your plan and schedule for correcting the defects and retesting.
Conclude by saying, "I think we should correct these defects before we go live, and you are the customer. What do you think?"
Invite your colleague who suggested the lame "demo version" excuse to witness these conversations, and to participate in them if that's appropriate.
Finally, be very happy that you, and not your customer, found these defects. Finding problems before your customer is another measure of competence.
answered May 17 '14 at 11:27
O. Jones
13.6k24070
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
add a comment |Â
up vote
37
down vote
To refuse to release software until you believe it works is a sign of competence, not incompetence. This is especially true for mission-critical software used for patient care. Does it pass the "what if it were my mother?" criterion, or not?
Almost all software contains defects, even long-lived and widely deployed stuff. An obvious example is the recent Heartbleed defect in OpenSSL. The measure of your engineering organization is not the absence of defects. It's how you handle them.
This is your first big "go / no-go" decision point as a new PM, and you're advocating "no-go." That stinks. My heart bleeds for you (pun intended). I've done software since 1974, and I still remember each time I had to advocate "no-go." It's one of the most difficult tasks in the business. But it's necessary. Almost every notorious disaster in software can be traced to such a decision being made poorly.
They don't teach this in school.
I have some concrete suggestions for your conversations with your customer on this matter.
Use the formal word defect rather than bug.
Explain that your pre-release software testing process has revealed certain critical defects. Tell the customer how many. If she asks, disclose what they are.
Say that you believe the software isn't fit for production use until those defects are corrected. Explain the consequences of using the software without correcting the defects. For example, "the software will sometimes crash," "under certain circumstances the software will indicate an incorrect drug dosage," or "the software may incorrectly assign input to the wrong patient's record," or even "Some error messages aren't correct, and users will be confused" Be clear and detailed about the defects and their consequences. Transparency is everything.
Disclose your plan and schedule for correcting the defects and retesting.
Conclude by saying, "I think we should correct these defects before we go live, and you are the customer. What do you think?"
Invite your colleague who suggested the lame "demo version" excuse to witness these conversations, and to participate in them if that's appropriate.
Finally, be very happy that you, and not your customer, found these defects. Finding problems before your customer is another measure of competence.
answered May 17 '14 at 11:27
O. Jones
13.6k24070
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
add a comment |Â
up vote
37
down vote
up vote
37
down vote
To refuse to release software until you believe it works is a sign of competence, not incompetence. This is especially true for mission-critical software used for patient care. Does it pass the "what if it were my mother?" criterion, or not?
Almost all software contains defects, even long-lived and widely deployed stuff. An obvious example is the recent Heartbleed defect in OpenSSL. The measure of your engineering organization is not the absence of defects. It's how you handle them.
This is your first big "go / no-go" decision point as a new PM, and you're advocating "no-go." That stinks. My heart bleeds for you (pun intended). I've done software since 1974, and I still remember each time I had to advocate "no-go." It's one of the most difficult tasks in the business. But it's necessary. Almost every notorious disaster in software can be traced to such a decision being made poorly.
They don't teach this in school.
I have some concrete suggestions for your conversations with your customer on this matter.
Use the formal word defect rather than bug.
Explain that your pre-release software testing process has revealed certain critical defects. Tell the customer how many. If she asks, disclose what they are.
Say that you believe the software isn't fit for production use until those defects are corrected. Explain the consequences of using the software without correcting the defects. For example, "the software will sometimes crash," "under certain circumstances the software will indicate an incorrect drug dosage," or "the software may incorrectly assign input to the wrong patient's record," or even "Some error messages aren't correct, and users will be confused" Be clear and detailed about the defects and their consequences. Transparency is everything.
Disclose your plan and schedule for correcting the defects and retesting.
Conclude by saying, "I think we should correct these defects before we go live, and you are the customer. What do you think?"
Invite your colleague who suggested the lame "demo version" excuse to witness these conversations, and to participate in them if that's appropriate.
Finally, be very happy that you, and not your customer, found these defects. Finding problems before your customer is another measure of competence.
answered May 17 '14 at 11:27
O. Jones
13.6k24070
To refuse to release software until you believe it works is a sign of competence, not incompetence. This is especially true for mission-critical software used for patient care. Does it pass the "what if it were my mother?" criterion, or not?
Almost all software contains defects, even long-lived and widely deployed stuff. An obvious example is the recent Heartbleed defect in OpenSSL. The measure of your engineering organization is not the absence of defects. It's how you handle them.
This is your first big "go / no-go" decision point as a new PM, and you're advocating "no-go." That stinks. My heart bleeds for you (pun intended). I've done software since 1974, and I still remember each time I had to advocate "no-go." It's one of the most difficult tasks in the business. But it's necessary. Almost every notorious disaster in software can be traced to such a decision being made poorly.
They don't teach this in school.
I have some concrete suggestions for your conversations with your customer on this matter.
Use the formal word defect rather than bug.
Explain that your pre-release software testing process has revealed certain critical defects. Tell the customer how many. If she asks, disclose what they are.
Say that you believe the software isn't fit for production use until those defects are corrected. Explain the consequences of using the software without correcting the defects. For example, "the software will sometimes crash," "under certain circumstances the software will indicate an incorrect drug dosage," or "the software may incorrectly assign input to the wrong patient's record," or even "Some error messages aren't correct, and users will be confused" Be clear and detailed about the defects and their consequences. Transparency is everything.
Disclose your plan and schedule for correcting the defects and retesting.
Conclude by saying, "I think we should correct these defects before we go live, and you are the customer. What do you think?"
Invite your colleague who suggested the lame "demo version" excuse to witness these conversations, and to participate in them if that's appropriate.
Finally, be very happy that you, and not your customer, found these defects. Finding problems before your customer is another measure of competence.
answered May 17 '14 at 11:27
O. Jones
13.6k24070
answered May 17 '14 at 11:27
O. Jones
13.6k24070
answered May 17 '14 at 11:27
O. Jones
13.6k24070
answered May 17 '14 at 11:27
O. Jones
13.6k24070
13.6k24070
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
add a comment |Â
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
1
1
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
"you are the customer. What do you think?" -- I've never written safety-critical medical software, but I suspect that ethically one must be firmer than this about functional defects. That is to say, if you believe the defect takes the diagnostic accuracy outside the formal requirements, you probably can't offer the customer the opportunity to relax the requirements at the last minute...
– Steve Jessop
May 18 '14 at 1:59
1
1
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
+1 for oferring concrete steps towards a solution. And yes, they don't teach this in school...
– Radu Murzea
May 18 '14 at 8:19
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
@SteveJessop, asking rather than telling the customer isn't intended as an ethical loophole. Rather it's to ask for conversation about exactly what they need and when.
– O. Jones
May 18 '14 at 10:50
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
About the "colleague who suggested the lame "demo version" excuse": That sounds to me like an experienced developer trying to figure out how his new and out-of-his-depth project manager reacts to a suggestion that can be only taken as a joke. And guess what, the project manager swallowed it and took it as a serious suggestion. If I suggested that to my manager, he'd say "good joke" and we'd both laugh about it.
– gnasher729
May 18 '14 at 11:39
2
2
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
@SteveJessop engaging the customer as part of the process by asking what they think does not mean you relinquish the decision to them, it means you already believe they would make the same decision but rather than force it upon them, you want them to feel they are part of the process; this builds a better relationship with your customer. If you thought they might disagree, you would not give them the option -- which would not build a better relationship but would not harm it either.
– mah
May 18 '14 at 13:50
add a comment |Â
up vote
27
down vote
Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
 |Â
show 1 more comment
up vote
27
down vote
Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
 |Â
show 1 more comment
up vote
27
down vote
up vote
27
down vote
Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
edited May 18 '14 at 2:23
Aaron Hall
4,16312033
4,16312033
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
answered May 17 '14 at 7:13
Vietnhi Phuvan
68.9k7118254
68.9k7118254
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
 |Â
show 1 more comment
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
+1 for explaining why deciding fór the customer when a product is considered "available".
– Luceos
May 17 '14 at 8:05
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
"probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier" - do you have any sources for that effect? Both seem quite bad for a business, though they may indeed work as an improvement if the previous state was "shipping out defective products late".
– O. R. Mapper
May 18 '14 at 8:19
3
3
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@ORMapper I am probably partially giving away my age, but there was a time when customers held back from buying version x.0 e.g. 3.0, 4.0, etc. of anything from Microsoft. They would wait until x.1 or x.2 would come out and Microsoft had worked out the wrinkles.
– Vietnhi Phuvan
May 18 '14 at 11:17
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
– SSumner
May 18 '14 at 15:09
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
@SSummer I haven't been an almost exclusively Linux/OSX guy for several years now, and I have been none took diligent about keeping up with what's happening in the Microsoft world, except for Microsoft's all-out support for Javascript. From the few conversations I've had with those of my entourage who bought Window 8 laptops, I am stating away from Windows 8. I used to do third level support for Windows Server 7, and it wasn't an unpleasant experience :)
– Vietnhi Phuvan
May 18 '14 at 21:34
 |Â
show 1 more comment
up vote
4
down vote
I don't see how the "demo version" story makes you look any better. Either way, they're expecting certain functionality delivered at a certain time, and they won't be getting it.
Put yourself in the client's position: how would you feel if you were expecting a finished product, and instead you got "Oh, yeah, it's totally finished, right on time! It's just the demo version, though, so you can't actually use it. But it's finished!" You wouldn't just be disappointed, you'd be bewildered and angry. You'd feel like the developer either didn't understand the requirements, or was trying to give you the runaround.
They'll respect you more if you're honest and straightforward. Focus on what needs to be done to finish the project and how the client can help.
answered May 17 '14 at 21:28
Robert
511
add a comment |Â
up vote
4
down vote
I don't see how the "demo version" story makes you look any better. Either way, they're expecting certain functionality delivered at a certain time, and they won't be getting it.
Put yourself in the client's position: how would you feel if you were expecting a finished product, and instead you got "Oh, yeah, it's totally finished, right on time! It's just the demo version, though, so you can't actually use it. But it's finished!" You wouldn't just be disappointed, you'd be bewildered and angry. You'd feel like the developer either didn't understand the requirements, or was trying to give you the runaround.
They'll respect you more if you're honest and straightforward. Focus on what needs to be done to finish the project and how the client can help.
answered May 17 '14 at 21:28
Robert
511
add a comment |Â
up vote
4
down vote
up vote
4
down vote
I don't see how the "demo version" story makes you look any better. Either way, they're expecting certain functionality delivered at a certain time, and they won't be getting it.
Put yourself in the client's position: how would you feel if you were expecting a finished product, and instead you got "Oh, yeah, it's totally finished, right on time! It's just the demo version, though, so you can't actually use it. But it's finished!" You wouldn't just be disappointed, you'd be bewildered and angry. You'd feel like the developer either didn't understand the requirements, or was trying to give you the runaround.
They'll respect you more if you're honest and straightforward. Focus on what needs to be done to finish the project and how the client can help.
answered May 17 '14 at 21:28
Robert
511
I don't see how the "demo version" story makes you look any better. Either way, they're expecting certain functionality delivered at a certain time, and they won't be getting it.
Put yourself in the client's position: how would you feel if you were expecting a finished product, and instead you got "Oh, yeah, it's totally finished, right on time! It's just the demo version, though, so you can't actually use it. But it's finished!" You wouldn't just be disappointed, you'd be bewildered and angry. You'd feel like the developer either didn't understand the requirements, or was trying to give you the runaround.
They'll respect you more if you're honest and straightforward. Focus on what needs to be done to finish the project and how the client can help.
answered May 17 '14 at 21:28
Robert
511
answered May 17 '14 at 21:28
Robert
511
answered May 17 '14 at 21:28
Robert
511
answered May 17 '14 at 21:28
Robert
511
511
add a comment |Â
add a comment |Â
up vote
3
down vote
Engage with your costumer. Tell them the true state of your software, and work to fix the bugs. The Therac-25 Accidents is a great lesson to learn from.
Such actions would make you standout and more importantly built a trustful relationship with your client.
answered May 17 '14 at 20:53
KhaledMohamedP
1412
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
add a comment |Â
up vote
3
down vote
Engage with your costumer. Tell them the true state of your software, and work to fix the bugs. The Therac-25 Accidents is a great lesson to learn from.
Such actions would make you standout and more importantly built a trustful relationship with your client.
answered May 17 '14 at 20:53
KhaledMohamedP
1412
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Engage with your costumer. Tell them the true state of your software, and work to fix the bugs. The Therac-25 Accidents is a great lesson to learn from.
Such actions would make you standout and more importantly built a trustful relationship with your client.
answered May 17 '14 at 20:53
KhaledMohamedP
1412
Engage with your costumer. Tell them the true state of your software, and work to fix the bugs. The Therac-25 Accidents is a great lesson to learn from.
Such actions would make you standout and more importantly built a trustful relationship with your client.
answered May 17 '14 at 20:53
KhaledMohamedP
1412
edited May 17 '14 at 21:53
answered May 17 '14 at 20:53
KhaledMohamedP
1412
answered May 17 '14 at 20:53
KhaledMohamedP
1412
answered May 17 '14 at 20:53
KhaledMohamedP
1412
1412
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
add a comment |Â
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
1
1
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
You don't get to practice medicine without a license. On the other hand, some pimple faced kid could be working on your life-critical medical software :)
– Vietnhi Phuvan
May 18 '14 at 3:03
add a comment |Â
up vote
1
down vote
I would be far less confident in a software product that was given to me as a demo on the deadline than a project manager who told me up front that they found some last minute bugs and must fix them before shipping. Lives depend on this software, you cannot afford to get it wrong.
As a project manager it is your duty to tell the client the problem and the proposed fix and the revised schedule. You need to tell them now, as soon as possible, not wait until the deadline to tell them you are not delivering on time.
Being a project manager is all about the ability to manage client expectations and the only way to do that is to tell them the truth even when it is not happy news. You must have the ability to face up to telling bad news if you want to continue as a project manager.
Every time I have seen a PM try to manage by never telling the bad news and hoping it will go away (Management by wishful thinking) he has been fired because the truth eventually comes out and clients don't like being lied to.
I remember one time when the devs told the PM that the deadline was not achieveable (and we were already working overtime) and we would misss the deadline by at least a month. He waited to tell the client until the day of the deadline and we lost a multi-million dollar client because " How could you not have known it would take 4 more weeks before today?" Truth was we did know weeks ahead of time, but the PM was a coward and didn't tell them, so he lost the client and his job. That is what is likely to happen to you if you go with the "Demo" story.
answered May 19 '14 at 14:15
HLGEM
133k25226489
add a comment |Â
up vote
1
down vote
I would be far less confident in a software product that was given to me as a demo on the deadline than a project manager who told me up front that they found some last minute bugs and must fix them before shipping. Lives depend on this software, you cannot afford to get it wrong.
As a project manager it is your duty to tell the client the problem and the proposed fix and the revised schedule. You need to tell them now, as soon as possible, not wait until the deadline to tell them you are not delivering on time.
Being a project manager is all about the ability to manage client expectations and the only way to do that is to tell them the truth even when it is not happy news. You must have the ability to face up to telling bad news if you want to continue as a project manager.
Every time I have seen a PM try to manage by never telling the bad news and hoping it will go away (Management by wishful thinking) he has been fired because the truth eventually comes out and clients don't like being lied to.
I remember one time when the devs told the PM that the deadline was not achieveable (and we were already working overtime) and we would misss the deadline by at least a month. He waited to tell the client until the day of the deadline and we lost a multi-million dollar client because " How could you not have known it would take 4 more weeks before today?" Truth was we did know weeks ahead of time, but the PM was a coward and didn't tell them, so he lost the client and his job. That is what is likely to happen to you if you go with the "Demo" story.
answered May 19 '14 at 14:15
HLGEM
133k25226489
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I would be far less confident in a software product that was given to me as a demo on the deadline than a project manager who told me up front that they found some last minute bugs and must fix them before shipping. Lives depend on this software, you cannot afford to get it wrong.
As a project manager it is your duty to tell the client the problem and the proposed fix and the revised schedule. You need to tell them now, as soon as possible, not wait until the deadline to tell them you are not delivering on time.
Being a project manager is all about the ability to manage client expectations and the only way to do that is to tell them the truth even when it is not happy news. You must have the ability to face up to telling bad news if you want to continue as a project manager.
Every time I have seen a PM try to manage by never telling the bad news and hoping it will go away (Management by wishful thinking) he has been fired because the truth eventually comes out and clients don't like being lied to.
I remember one time when the devs told the PM that the deadline was not achieveable (and we were already working overtime) and we would misss the deadline by at least a month. He waited to tell the client until the day of the deadline and we lost a multi-million dollar client because " How could you not have known it would take 4 more weeks before today?" Truth was we did know weeks ahead of time, but the PM was a coward and didn't tell them, so he lost the client and his job. That is what is likely to happen to you if you go with the "Demo" story.
answered May 19 '14 at 14:15
HLGEM
133k25226489
I would be far less confident in a software product that was given to me as a demo on the deadline than a project manager who told me up front that they found some last minute bugs and must fix them before shipping. Lives depend on this software, you cannot afford to get it wrong.
As a project manager it is your duty to tell the client the problem and the proposed fix and the revised schedule. You need to tell them now, as soon as possible, not wait until the deadline to tell them you are not delivering on time.
Being a project manager is all about the ability to manage client expectations and the only way to do that is to tell them the truth even when it is not happy news. You must have the ability to face up to telling bad news if you want to continue as a project manager.
Every time I have seen a PM try to manage by never telling the bad news and hoping it will go away (Management by wishful thinking) he has been fired because the truth eventually comes out and clients don't like being lied to.
I remember one time when the devs told the PM that the deadline was not achieveable (and we were already working overtime) and we would misss the deadline by at least a month. He waited to tell the client until the day of the deadline and we lost a multi-million dollar client because " How could you not have known it would take 4 more weeks before today?" Truth was we did know weeks ahead of time, but the PM was a coward and didn't tell them, so he lost the client and his job. That is what is likely to happen to you if you go with the "Demo" story.
answered May 19 '14 at 14:15
HLGEM
133k25226489
answered May 19 '14 at 14:15
HLGEM
133k25226489
answered May 19 '14 at 14:15
HLGEM
133k25226489
answered May 19 '14 at 14:15
HLGEM
133k25226489
133k25226489
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f24192%2fdo-i-need-to-be-honest-with-a-client-even-if-it-would-show-my-incompetence%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
17
This sounds like homework question from an ethics class :-
– Good Person
May 17 '14 at 19:15
4
@GoodPerson Indeed, and a bad one at that. Seeing as the OP is in charge of delivering a safety-critical product, delivery must be delayed. There's no ethical conundrum here, how to handle the client is purely marketing, in my (rather inexperienced) opinion. Plus giving out a demo version when it's time to ship the complete product is a dead give-away that the code still needs work, so I don't see how the OP can escape the situation either way.
– rath
May 18 '14 at 8:03
1
This question reminds me of the Therac 25: youtube.com/watch?v=6Z8OmqY3zJI#t=43m47s. Just be honest: tell your client it's a work in progress.
– jubobs
May 18 '14 at 19:08
What does deliver "on time" mean? Isn't there a customer testing and approval period established before going live?
– user8365
May 19 '14 at 18:54