Feasibility Study Prevents Six Figures in Bad Investment

Just imagine the moment when you had a stroke of genius. Out of nowhere, you envisioned a game-changing custom software application that could become a significant revenue generator for your business. You already have market share through your core service offering and can tap into existing relationships to socialize the concept and begin pre-sales activity.

This is the profile of the CEO we had the pleasure of serving. He was so excited and ready to begin that he invested a significant amount of time and resources in generating an RFP before we even met. The RFP included a description of an algorithm and a third party IoT device that would be used to measure humidity. He was intentional when defining response criteria, requiring vendors to prioritize user interface design so that his sales team could use the materials in pre-sales activity while the product was in development.

Sounds great, right? If all went according to plan, he’d have multiple customers ready to purchase just in time for the initial release. Now that his playbook was defined and the RFP was ready to go, they simply needed to search for the right vendor. One that would execute the plan to perfection. What could possibly go wrong?

The RFP Process

They submitted their RFP to three highly recommended software development companies. Two of the three responded in short order with very few clarifying questions and provided various options to begin work immediately. They were more than happy to provide all the resources needed to bring his vision to life. The third, as you’ve already guessed, was Red Hawk Technologies.

We were thrilled to be included in the RFP process and knew we were up against stiff competition. All we had to do was respond in a manner that fit the RFP requirements, provide references and a reasonable budget. However, when reviewing the RFP, we identified a few potential risks. Not for us, but for the Client. We asked several questions, but none more important than the following:

• How did you define and test your algorithm?
• How are you determining what’s “normal” humidity in any given environment?
• Are you confident the tolerances indicated are reasonable for detecting abnormal levels of humidity?
• How is the performance of the IoT device impacted when its battery life fades?

We learned the Client made several assumptions when creating the algorithm and expected the IoT device to behave in a consistent manner, simply failing to report data when the battery died.

The Alternative

We were asked to expedite delivery of our proposal if we were to be considered for the opportunity. The other vendors had no concerns and already provided their budgets and project plans. Unfortunately, simply responding to the RFP would have required us to bypass our core values — Empathy, Integrity, Creativity, Transparency and Collaboration. We declined, offering a Feasibility Study as an alternative.

“Incorrect assumptions lie at the root of every failure. Have the courage to test your assumptions.”

Brian Tracy

Fortunately, after a brief call to explain our concerns, the Client was receptive to the Feasibility Study. Soon after, we provided the following services, knowing that if the results were positive, the source code could be repurposed as part of the larger scope and we could respond to the RFP.

The Feasibility Study

• Develop a web application to collect data from a dozen of the Client’s IoT devices.
• Program an interface to display the data, using the Client’s algorithm to indicate if humidity levels fell within the normal tolerance or not.
• Change humidity levels, testing the IoT devices responsiveness, consistency and overall performance.
• Allow for continuous operation and monitor performance as the IoT devices batteries faded.

The Results

We discovered the IoT devices became more and more unreliable, behaving erratically as battery life faded. There were also issues with the algorithm, and calibration onsite would be required to define “normal” humidity levels.

Ultimately, the larger vision proved unfeasible. The CEO pulled the plug, spending less than 5% of what he budgeted for product development.

Recommendations

If you’re speaking with vendors about custom software development, systems integration, web or mobile application projects, pay close attention to the types of questions they’re asking. If they’re not looking for potential risks to your business, they’re probably not the best choice.