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?

  • 17
    This sounds like homework question from an ethics class :-\ May 17, 2014 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, 2014 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.
    – jub0bs
    May 18, 2014 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, 2014 at 18:54

5 Answers 5


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.

  1. Use the formal word defect rather than bug.

  2. 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.

  3. 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.

  4. Disclose your plan and schedule for correcting the defects and retesting.

  5. 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.

  • 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... May 18, 2014 at 1:59
  • @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, 2014 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, 2014 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, 2014 at 13:50

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."

  • +1 for explaining why deciding fór the customer when a product is considered "available".
    – Luceos
    May 17, 2014 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". May 18, 2014 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. May 18, 2014 at 11:17
  • @VietnhiPhuvan - you mean like when Windows 8 and 8.1 were released?
    – SSumner
    May 18, 2014 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 :) May 18, 2014 at 21:34

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.


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.

  • 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 :) May 18, 2014 at 3:03

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.

You must log in to answer this question.

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