A Time Sensitive Request: How Soon Can You Get That Done?

By Luke Hoezee

Over the years, I’ve noticed the most common conversation between a software development company and their customers goes something like this:

Customer: Last week we spoke about the urgent fix we need done which is being pushed by our compliance department. You mentioned you needed a few days to determine how soon this can be done...

Company: We had an internal discussion, this fix will not be in place until our next release cycle.

Customer: Okay, when is that?

Company: In about 6 months.

So, the rest of the conversation, could go two ways. The customer could be completely understanding and just go with it. However, in most cases when someone hears 6 months, their heart skips a beat. Especially if it's something with compliance or some kind of regulatory issue.

In some cases, the six months turn around time might be required because the change has a major impact on how the entire system was originally coded. In other cases, and honestly in most cases in my experience this one task will not take 6 months.

So why would something take so long?

Here are a few things that may take, what seems like a small task, six months to see production. It may be a combination of these or just one:

• There are 10 other medium size priority items that have been in the works for the few months. These items might be 90% done. So the company has decided it would be best to finish these off and release it with the new urgent item.
• The company simply has a very strict policy when they release new software, no matter the urgency.
• The developers are still working on the past 3 urgent items that were brought up last week. The company is a small team and can only handle so many urgent tasks in their workload.
• The company will not release anything to production until all automated tests are setup and the QA team is overloaded with work right now.
• Not all details were given to the development team. During the QA testing many items were not coded correctly. So the company spends the next month or two discussing all use cases with the customer.
• The company does not have a hot-fix process in place.. Yikes! I've seen it before.

I'm sure there are many more crazy reasons why it would take so long. Feel free to comment on your situations :)

When the customer realizes it should not take that long.

This article is not meant to offend anyone on how their processes are, but I'd like to point out my personal experience on the items that should take less than 2 weeks to complete. Going back to the example conversation in the beginning of the article. The rest of the conversation went like this:

Customer: But last week one of your developers said it was a quick fix.

Company: I'm not sure why they said that. We have our ways on how we release features

Customer: Okay, but this is not a feature, it's a bug and has a major impact on our business

Company: Bug or feature, we have to stick with our policies and procedures.

So there it is, the annoying developer speaking his mind on a conference call. Yes I'm allowed to say that because I am a software developer! I'm guilty of doing this all the time. Why do you ask? After 15+ years coding different software you learn really fast what a two week task is and what would really take six months to do. To a developer, it's very obvious.

Why six months for something the developer thought would be "quick"? Just read the bullet points above, I'm sure the reason is there somewhere.

Sometimes, to make your customers happy, just let your development team do their thing to get things done. Remove the processes that hold them back, remove the lengthy conversations, and in some cases (not all) just let the developer speak directly to the customer.

Most of us want to provide a quick solution for our customers, but there are a few companies that really stick to their "old corporate ways". In the long run, these companies will lose out to the fast pace software companies. What about the short term though? Most of these customers are stuck in a 3 - 5 year contract with the company. Unfortunately, there's not a whole lot you can do. Perhaps you can share your experience and help others not make the same mistake... Pass-it-on ;)

How would someone know? What are the signs?

Ask yourself this question. Are you working with a company or considering working with a company that thinks they are too large to fail? If so, I would recommend for you to do your homework on them. I recommend the following action items to help determine this:

• Talk to their existing customers. Find out what their support system is like.
• Get a sense on their company culture. Are they too corporate structured with too many "cooks in the kitchen"
• If possible, see if you can get on a call with their development team. If they say no, this is a big red flag. Why hide your development team? There are situations where your developers do not want to be bothered, but if a new customer wants to ask some technical questions, just do it.
• Ask them what their "Hot Fix" process is? How do they define a "Hot Fix"?
• What is their process for accepting new feature requests? If there is no process... Should you even consider using them as a provider? I sure hope not!

To be fair, there are big advantages to taking things slow with longer release cycles. The major benefit is less bugs. We all want less bugs! However, if you've been in this business as long as I have (or longer), you'll realize the customer doesn't want to hear about the bugs, they want solutions FAST! Actually, they want both... Fast and no bugs! This is very hard to accomplish, but it really depends on what you're doing. Even longer release cycles can introduce bugs.

At Bankjoy, we are always tweaking our process. We try to find that fine line of fast pace development cycles at the same time, maintaining our high standard of quality. No matter what our normal development cycle is, we will ALWAYS release Hot Fixes as soon as possible. We have turned around hot fixes in less than 1 hour and as long as a few days. We will work nights and weekends to fix any major items that directly impacts your business.

Which this goes back to a previous bullet point. There needs to be a clear understanding what a "Hot Fix" is and how is it identified.

Conclusion

No process is perfect. No software is perfect. You can however, strive for perfection. In order to strive for perfection, you need the right culture and team members. If your small bank or credit union is looking for a change and want to compete with the big banks, you can schedule a demo. We move fast and will provide top quality support and a quality product that nobody can compete with.