How to Successfully Shop for Software Solutions

You may be unaware of something that you need to know.

Spending ten years in chemical manufacturing is not the typical path to preparing for a career in software development; but that’s what I did. It came with some perks as the operations & manufacturing expertise I developed couples very nicely with writing software for the industry.

I worked at four different sites across three different companies. Each of these companies had the same habit. Seeing as it was a 3 out of 3, I must assume that this habit exists in all of manufacturing.

Each company that I worked for had a lot of high tech software. In fact, they had different high tech software for each division within the company. Safety had incident management software, Operations had Management of Change software and version control software amongst others. Accounting had an ERP like SAP or Oracle, and may have even had other software they worked with on top of that to meet the needs that the ERP did not.

None of these systems worked together, and so in order to build reports and tools using common data, each company would call upon their engineers to build those in MS Excel or MS Access.

If I had to estimate, I would say that I spent half of my time in manufacturing building these types of reports and tools. That’s five man-years! I built production & yields reports for the business, round sheets for the operators which then fed into the former report, and so many other forms.

As I write this now, I can’t help but wonder: Who is maintaining those tools now?

My guess is no one. Afterall, once I left the companies, all it would take to make the tool obsolete and unusable is a single input writing over a single formula in a single cell. Or in the instances where I intended to prevent just that, maybe I included a password – maybe the password was even blank. But when a new tag gets added in the field that needs to be added to the report, no one will know the password. If they call me, I’ll give it to them – if I remember it.

Having seen it so many times, my guess is that many of you have reports & tools that your business heavily relies on, and if the person who built them leaves, your business could be in trouble.

Wouldn’t it be nice to have a trusted software partner who could help you maintain your business continuity. Wouldn’t it be nice to have a partner who could manage all that data and those reports you currently track in excel, so that you don’t have to worry about your engineers leaving? Wouldn’t that be nice?

But how do you find this trusted software partner? Where do you even begin?

Last year I attended the Supply Chain Conference of Baton Rouge. It was my third time attending as I find this conference not only completely fascinating, but also fully engaging.

After the event, they host an after party. At the after party last year, I met Cody.

Cody was both excited and a little apprehensive about the fact that his company had just signed a contract with a development team to build their production and inventory reports.

I love production reports! So, I couldn’t help but to ask all about it. Here’s how this conversation went:

Gina: This is so exciting! When are you going to be able to use it and try it out?

Cody: The company said it would take them 18 months to build it.

Gina: Ok, but when are you going to be able to test it out and make sure that it’s on track?

Cody: …18 months?

Gina: 18 months?!

Cody, this is a huge red flag!

You should be able to use your software along the process, and typically within one week of kicking off the project.

When are you paying for it?

Cody: We had to pay most of it up front and will pay the final invoice before they turn it over to us.

Gina: So you have already paid for this software even though you will not be able to use it for 18 months?

And when it is “complete”, do you expect it to work?

Oh Cody… You are headed full speed toward a brick wall.

Then you, as the client, have all the decision power to prioritize the features you would like to have implemented.

Up front, you describe the features that are important to you (we like to call these descriptions stories). Your software partner is allowed to help guide you in this process, especially up front as you are learning how to write the stories.

Each story will have thorough acceptance criteria outlining exactly what you expect the feature to do and how you expect it to behave.

For each iteration, you select the stories to be implemented. Your software partners then spend that iteration implementing those stories. At the end of the iteration they demonstrate them to you; and if they meet your acceptance criteria, you approve, and only then do you pay for the iteration.

I continued with Cody (who had lost all color in his face).

Gina: What’s your exit plan?

Cody: What do you mean?

Gina: I mean, when things go wrong how do you get out from working with this company?

You are going to own the software that they build for you right?

Cody: …

Gina: Cody, you need to go back and reread your contract and make sure that you own your code!

You! You own your software! You own not only your software, but you also own your data. And you should have a clause in the contract for how you will get your data in the case you need a bulk export.

I had a friend at one of the plants that I worked at who got into just this kind of pickle. The company had a Software as a Service (SaaS) that they stored all of their ultrasonic thickness readings in. They wanted to divest from this service and so requested all of their data. The SaaS said, “Sure. It’s yours. You can download it all from the app.”

There was no bulk export though, so they had to download tens of thousands of PDFs, which my friend had sole responsibility for inputting into Excel. He was pretty savvy though, and used this opportunity to learn VBA to automate the inputs–Excel & VBA do have their place for sure. Very impressively, he did just this, and he did it well. So, I married him.

Make sure you have a clause for a bulk export of your data in a format that you can easily consume!

OK. So now you’ve been iteratively working with your trusted software partner, and all of a sudden your application is “DONE”! The quotes are to emphasize that software is an evolving medium that may never be fully done.

Now what?

Oh no! A short time after, you discover a bug. If you have a trusted software partner, then all you need to do is call them up and say, “Hi Gina, so I was using the app, and I discovered this bug…”, and I would say, “That shouldn’t be happening! I will get on this as soon as reasonably possible!”

As soon as reasonably possible means (typically) within 1 iteration/week. And I’m going to fix it for you – at no cost to you.

For instance, if you were to order Kung Pao Chicken at a restaurant, and discovered that one of the thai chilis was actually a camouflaged cricket, would you expect to have to pay to have the restaurant remake it cricketless? (true story…)

Same thing. If there is a bug that shouldn’t be there, as expected by the acceptance criteria, then why should you have to pay for it? At Clean Coders Studio, we have a bug free guarantee!

What about post-development maintenance?

Well, hopefully by now, you’ve developed a solid relationship with your trusted software partner. Even still, before signing, there would have been a clause or section in the contract regarding post-development maintenance.

For instance: Will they continue to host your server? What if there are library updates; will they take care of this? And the answer to all is: yes; simply because your trusted software partner is not going to want you to ever have to worry about your software meeting your business needs–even years after development.

Finally, and I’m not going to go into depth on these items, but please feel free to get in touch if you want to know more about them. When interviewing a potential software partner, keep these questions in your back pocket and be sure to ask them.

Now, and as promised, the money pit!

So here are a bunch of lines.

The green one represents your engineers building excel or access reports & tools.

Of course, right off the bat, you’re going to notice that it’s nearly half that of the other lines.

Sure. But let’s factor in the lost opportunity cost associated with dedicating an engineer to building & maintaining these reports.

Don’t forget that this also represents only one engineer–if your company is anything like the ones that I’ve worked at, then you can probably multiply this upwards by 5 or 10.

Let that sink in… On top of the risk this habit already threatens your business continuity.

Sunk?

Ok. The orange line represents custom waterfall or turn-key software. This is where you are promised a working application in 18 months, like Cody was. It typically starts out with a proposal promising a cost that looks less expensive than an agile custom project might look, but upon the first trial of the software (at 18 months), more is needed to make it fit your needs. Not only will these adjustments cost you double, this is often where companies backtrack, seek out a new team, and follow the blue line of Agile Custom Software.

Lastly is SaaS, which is unbounded. If you were to expand this chart out, that pink line would continue upwards forever.

Now, I’m not saying don’t buy or implement SaaS. It is a necessary part of your business, and a lot of it is needed. All I’m saying is that the next time you are considering implementing a new SaaS, I encourage you and I implore you, that before you add yet another software to your stack, that you talk to your trusted software partner to see if you could add a valuable asset to your balance sheet instead.

Thank you!