ArgonDigital - enterprise automation experts

Share This Post

Let’s say you take your car in to have it worked on and you get a $1000 estimate and are told you have to leave it for 2 days to get the repairs. It turns out that once the repair shop opens up the engine, they find out the cost is an extra $500 and it will take another day. Here are two possible responses:

  • Repair Shop A. The repair shop calls as soon as they find this out and lets the customer make an informed decision about how to proceed or abandon the work.
  • Repair Shop B. The customer shows up at the end of day 2 to pick up his car, and he’s told his car is not ready, sorry, and, by the way, you’ll owe an extra $500 when we are done. Or, you can take it today, but it won’t work right. Regardless, you owe use $1000.

As a customer, I’d readily consider going back to Repair Shop A. They made a mistake in the estimate, but they kept me informed and gave me options. I’d feel they acted in good faith.

On the other hand, Repair Shop B would never see me (or my friends) again. I’d feel they were unprofessional and acted in bad faith.

Yet, I see this happen in development all of the time. There are situations where the development team has control of the schedule: their estimates are accepted and scope is controlled to allow development to complete in their estimated time frame. The development team does not report any problems or schedule issues during development. However, when the software reaches code complete and is turned over to the quality assurance team for testing, it is a frightening mixture of buggy and undeveloped features.

Why don’t developers understand they are acting like Repair Shop B? That they are acting in bad faith when they do this, and that their credibility is damaged? Again, the problem is not that they made a mistake in the estimate; it is how they handled it.

I wish I had a solution to this. I realize situations like this are usually complex and perhaps loaded with baggage. Right now, I’m hoping that my analogy will help developers understand the consequences of such actions are not only to the product they are producing, but also to how others view their credibility. Act in good faith.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage