Imagine that you are the captain of a commercial airliner that has crashed on a desert island, and 200 people have survived. Food is scarce, there’s nothing but sand and people are going to start dying if you don’t get them off the island.

In the distance, you see a lush tropical island with tons of vegetation, banana trees and shelter. You know the only way to save everyone is to get everyone to that island. So, you come up with two possible solutions:
1. Build one big boat that can fit everyone in one trip.
2. Build many smaller boats that can bring everyone over in multiple trips.

The Big Boat

You decide to build one Big Boat to get everyone off the island and you estimate that it will take six months to build it. After eight months (instead of six) 50 people die of starvation before the Big Boat is finally ready.

Finally, you get the remaining 150 survivors on the Big Boat and you cast off. Halfway to the tropical island, the Big Boat sinks and 100 people drown.

The remaining 50 survivors make it safely to the tropical island and, shortly after they arrive, they find a small airplane in good flying condition—except there’s no jet fuel.

Eventually everyone dies anyway.

Many Small Boats

Instead of deciding to build one Big Boat, you immediately start building many small boats. As soon as the first boat is done, you send three people in it to the tropical island. The first small boat sinks but it’s small so the boat sinks before they make it very far and the people are able to swim back to the desert island. The people on the first boat tell everyone why the boat sank so they can learn how to make a better boat. So a second small boat sets off (while a third boat is being built) and three people make it to the tropical island. When they arrive, they find the small airplane in good condition and they tell the people in the third boat to return to the desert island to get fuel from the crashed commercial airliner.

All 200 people survive.

How Does This Compare to Building Software?

The Big Software Build
If your first build is packed with every possible feature, it will:

• Inevitably take far longer to build than you had originally planned (read: “Your Estimates Suck” from the book, REWORK)
• Provide no insight into real-world usage and ways you can learn how to make it better (floating Vs sinking)
• Limit your ability to learn and change the features you really need and eliminate the ones you don’t (can’t return for jet fuel)
• Force you to over-invest in building a product before you can prove there’s even a business for it (6 months building and still no boat)
• Carry more risk and potential to fail (sunken boat)

Many Small Software Builds
The first small boat can be viewed as your prototype. You can let a few people use your prototype so you can learn how to make it better. It will be quick and easy to improve upon because it’s, well, small. As you roll out each small build you are constantly learning:

• How to make the software more usable
• What features should and should not be included in each build
• How to make the infrastructure perform better
• How to make your business even more successful

Of the many reasons why conducting visioning sessions are a critical step in any software development project, none are more important than the way they get all members involved on the same page before any development is started.

On any project team, you may have some team members thinking blue sky possibilities while others are thinking time-to-market and budget constraints. You may also have some members thinking of a robust product that must perform every imaginable piece of functionality while others may be thinking a much more basic solution.

Beyond the obvious cost-savings involved with defining what you want to build before you build it, often times Visioning Session reveal a more cost-effective use of a budget than was previously thought about. An effective Vision Session is not focused on how big of a product can be built in 6-8 months, it’s focused on what kind of minimum viable product can be built in 4-6 weeks. As a result, the conversation during a Vision Session begins to get much more focused.

Here are some real-world examples of what a client first came to us for and what we ended up defining as a result of our Visioning Sessions:
Real Estate Company

• Pre-Visioning Session: “The first thing we need is a points management system.”
• Post-Visioning Sessions: “The first thing we need is a simple marketing website that we can add a points management system to later.”

Medical Equipment Company

• Pre-Visioning Session: “The first thing we need is a marketing website to let people know about our products.”
• Post-Visioning Sessions: “What we really need is web-based software that lets our customers purchase tests and access their test results so we can start generating revenue.”

Public Relations Company

• Pre-Visioning Session: “Our client needs an elaborate Farmville-type of Facebook game that will encourage their customers to fill out a form for a quote.”
• Post-Visioning Sessions: “Our client needs a simple mobile game app that encourages their customers to fill out a form for a quote and share their experiences with friends on social websites.”

Promontory Interfinancial Network’s innovative financial deposit products require fully automated solutions due to complex calculations and high volume. Their financial solutions business was built on a technology infrastructure that supplied 100% of the functionality to provide service to their customers. Which worked great … until it didn’t.

Defining the Vision
“We were looking for a diligent and careful vendor that understood the role of technology. Ultimately, because Promontory’s business is software-based, we were looking for a partner to support our business initiatives. It was very important to me that our technology partner used business decisions to drive the technology, not the other way around. We needed a partner to enable us, not shape us,” explained Promontory Interfinancial Network Vice President for Business Operations, Robert Hyland.

Promontory contacted Fusionapps, initially, for help building a portal for an existing transaction system built by a third party. Once completed, the majority of the project work became nothing more than creating work around solutions for the third party built faltering application. The existing system was struggling under the strain of immense growth in use. It couldn’t keep up when demand quickly grew to over $25 billion worth of managed funds. Promontory’s own and clients’ needs were not being met. They had to have a better solution.

Our Thought Leaders conducted an intensive Visioning Session with Promontory’s leadership. What we saw was a problem larger than a series of bugs.

“Our business needs to be efficient, reliable, and of a consistently high quality, just like any other business. A small mistake can mean millions in lost revenue. There’s a huge amount of risk in not doing things correctly,” said Hyland.

Promontory faced a common problem. Their software solutions weren’t meeting present expectations and couldn’t scale fast enough. The unique value of a Fusionapps custom product is that it can stem the bleed while simultaneously building a new solution that will work better, faster, and more efficiently.

The vision we created was twofold. It entailed keeping a failing system running — to ensure no service disruption — while completely scoping a new system to handle the existing business needs and scale for the future, a future that was growing as fast as technology itself.

A custom solution is much more about the needs of the business, their customers, and their employees than it is about using the latest technology. Those needs heavily inform the development trajectory of the final product. The Fusionapps team saw a number of workarounds being employed to make up for the existing platform’s shortcomings.

Workarounds are a telltale sign that the system isn’t working properly and is running inefficiently. They’re also a common problem with commercial off-the-shelf (COTS) systems.

A true solution would necessitate a close relationship with the Promontory team to ensure that the new system would have none of the failings of the existing system.

Building the Solution
We set to working with Promontory to build the new system we envisioned.

The implementation process involved key Promontory staff working on-site at Fusionapps with their dedicated team to deconstruct their existing programs and map out feature enhancements.

“It came to the point that Fusionapps developers were indistinguishable from our own employees. Their style of collaboration has been very effective for Promontory,” said Hyland.

“The financial space is particularly complicated, and our technology and infrastructure needs are total. It’s scary to outsource this integral part of our business to a vendor who wants to essentially control, manage, and direct the core component of our business, offsite. Instead, the relationship that Fusionapps offered was very much that of a partner. Our solutions have to work, all the time, otherwise there is no business. And that’s why the Fusionapps relationship worked so well for us. Fusionapps is part of our family.”

Lessons and Iteration
“[Fusionapps] was able to keep our systems running while being a true partner in developing a new solution that ensured that our business could continue to provide the same high-level of service for our clients now and into the future. The solution they delivered was on time, on budget, and exceeded every expectation,” said Hyland.

We continue to maintain and monitor the performance of the Promontory custom solution. In particular, this includes having the dedicated Promontory team measuring performance daily against benchmarks that were established throughout the development and production processes. The Fusionapps process enables us to tweak system processes as needed to meet changing or emerging needs, which are made evident by performance against these benchmarks.

The Fusionapps Vision > Build > Learn methodology put us in a unique position to identify Promontory’s system pain points and see what exactly was needed to maximize their business potential.

Of the many things that get overlooked when companies have a business-critical software product (website, web app, mobile app, etc…), coordinating efforts between your marketing teams and IT/development teams is one we at Fusionapps always seem to run into. The root cause of this issue is that departments within an organization often work in silos – where one department is never aware of what the other is doing. This can not happen when the business as a whole is relying on the software product to generate revenue and build its brand. Even the most seemingly mundane effort of one team can have a dramatic impact on the software product.

Here are just two examples that Fusionapps has run into:

Large toy company launches huge marketing campaign – but neglects to tell the IT team.

It was approaching the company’s busiest time of the year, Christmas season, when the marketing team decided to run a huge campaign that would drive a ton of traffic to the website during a specific time period where customers could get a special deal off of their purchases. Unfortunately, the campaign was a huge success.  The marketing team never informed the IT team (mainly Fusionapps consultants) about the campaign and what kind of potential impact it may have on the website’s servers – and the servers began to fail. Unable to handle the huge volume of simultaneous users flooding the website, the IT team had to scramble and send extra teams of consultants to the data center to start start building and adding new servers to the infrastructure as fast as they could but there was no way to get the work done fast enough. The data center resemble a triage in the middle of a war zone. Throughout the night, the IT team was split between teams that were trying to keep the website live – rebooting boxes, restarting services, configuring load balancers, etc… – and teams that were building and slapping servers into the racks as fast as they could make them.

This night would be a devastating lesson for the business. Customers began issuing complaints and demanding refunds. The press got wind of the issues and had a field day – blasting the company for being so ill-prepared.

Staffing company gets featured on a primetime network TV show and works with IT team to prepare for traffic spikes.

It was an exciting time for this customer, they were about to be featured on a primetime TV show. The exposure for the business promised to drive a lot of users to their website. Knowing the potential impact this could have on the performance and load of the website, the customer informed Fusionapps and a coordinated effort ensued. The customer provided an estimated maximum spike of simultaneous users and the Fusionapps team prepped the application and server infrastructure to handle it. The TV showed aired, the website traffic rose and the infrastructure performed perfectly.