* In-house team won't have the experience necessary to deploy this project effectively. Robust customer/audience and business process automation understanding are not typically part of the in-house team's repertoire.

* To mitigate risk, design each phase so it can stand on its own and future phases can be killed without completely negating the value of the previous phases.

* Build ROI assumptions around each phase. In a perfect world, each phase should be able to stand on its own from a profit contribution and/or expense reduction standpoint. If not, then phase combinations must be able to deliver the target ROI. Although your scenario doesn't specifically mention it, ROI doesn't ONLY have to consist of incr. revenue and/or decr. expenses. There are other types of risk that could be quantified in the ROI.

* Perhaps this prospect is simply the wrong business for this proposal (e.g. too small; unable to fund it)?

Food for thought…

Mark Hill – you kind of had the grand finale I think. Your comments seem to a. summarize a lot of the said, and perhaps more importantly, unspoken thoughts; b. add some unique perspective from your eclectic experience; and c. tangibly illustrate what I've been suggesting for you for about 2 years now – the industry needs to hear more of your voice. Start blogging!

Great comment on the 'bet'. Good characterization. So if they add the 'throw away' project, which will probably take 6-12 months to finish internally, and perhaps $30-50k in payroll, overhead, etc., the 'bet' now is even higher than the $160 I proposed.

"…a BAD or marginal web experience could sink a good one." That is my concern exactly. And that's the HUGE risk they would be taking. This is also where SO Many other good ideas around the industry have crashed and burned. Poor execution gives a very false set of project assessment metrics.

Great idea about "'the man behind the curtain.'”

First Impressions

- Question on Internal Capacity = Do they have capacity for the job?

- Confidence = While they have "market tested", we don't know what that means or how many agents they have included.

Assumptions

- As a professional web development shop, IdeaStar has a more advanced skill set in both design and implementation.

- Internal development (soft labor cost) is about 1/3 the hard dollar cost of external development, assuming similar skills/experience. (taken from personal experience)

- They will not likely build out the full end-to-end process you proposed and, if the product is successful, the end result of the internal project will not be as robust as they may need (i.e., the internal site will be a throw away)

Conclusions

What is seems to come down to is this … It's a $160,000 bet on the project. If an internal site shows promise, are they willing to make a total investment that is greater than the $160,000 you proposed.

If they have the development capacity and are unsure about the results, I don't think they made a bad decision. Even if your ROI analysis says your project is a great idea, you still have the absolute hard-dollars (that other, higher priority projects may be competing for) and potential internal excess capacity issues that you won't be able to overcome with the current project.

You need a way to answer the confidence question – faster and at a lower cost. Then, as they have some confidence in the project, show them how your solution will be faster to market, more robust and a lower total cost when the results are positive. This is a win form them regardless of the result.

Suggestions

In asset management, most of your investment results are driven by the asset class you select – stocks, bonds, cash, etc. With diligence on selection within an asset class, managers can't ALWAYS outperform the market, but they CAN minimize the variance of returns, i.e. help avoid disasters.

Likewise, while the BEST web experience (selection) will not save a poor product (asset class), a BAD or marginal web experience could sink a good one. The user experience is important to adoption rates – and, further, is part of the experience that will form the Agents' long-term opinion of the company.

They should recognize here that the FRONT-END user experience is pretty important – and further reaching than this project alone.

Next, remember the Wizard of Oz … "Pay no attention to the man behind the curtain." The Agents see the from end, not the back end. So, how something gets done behind the scenes after they hit submit is of little consequence … so long as it gets done. Your project proposal appears pretty end-to-end and the project time and budget reflects a lot of back-end work. Focus on submission and accepting the quote. Rate and Bind offline – they can probably gin this up in Excel in a week or so – and email the result. Forget about the renewal process, it's a year away, they may never need it and, worst case, do it offline.

Then, remember the 80/20 rule. No matter how much effort you put into it, Agents will always have suggestions and you won't get it 100% right the first time. Offer to do a joint design project with their IT team and time-box the design time to something really aggressive. The focus here is getting it 80% + "right" in short order. Offer to assist development where their skills aren't 100% or they dont' have capacity to meet an aggressive launch.

Finally, in the initial phase, make sure the architecture is not throw-away when (if) they decide to build-out the whole process.

In the end, they should be able to get a pilot site up faster and less expensively with you than doing it themselves AND be able to leverage a substantial portion of the initial investment if they decide to move forward.

All too typical.

The desire to 'test' is understandable.

The bigger issue seems to be with the management at distributors. Great sales guys don't always make great management teams. It's great when you're in the sales process and they're excited about their new idea. I find it's always valuable to find the COO or CFO as early as possible too to see if the spend is budgeted. Dragging the nay sayers out early, and if all you have are those sales types, pin them to evaluation criteria that release the budget so they unearth their own objections sooner than later.

See you soon Mike.

Simon

I agree with Miguel's suggestion #2 above. If they don't bite at that, they really don't have any faith in the product and there is essentially no hope from the start. This is not a new phenomenon – lots of great ideas, few of them profitable. Unfortunately for you, you are the one who brings reality to the table (we are in that boat when we get involved in disability product development deals). By the way, I suspect that the option to build a cheap solution in-house will serve to ensure the agents do not adopt the concept and will 'sour the well' for the foreseeable future. On a brighter note, sounds like a great solution you developed!

Terry, yep. That's my thought, too. So they'll get started to great excitement and fanfare, and within a couple months either get burned out and begin to slow, or turnover, or a 'shift in priorities'. Isn't it easier to manage a vendor relationship than employees?

Here is my commentary on your story:

1) A worse outcome would be a decision to outsource, the business fails to execute on their end, and everyone looks bad.

2) To reduce the risk to the business, if this business product/approach was something YOU truly believed in, seek to just cover your cost for development, and then charge by transaction, or some performance based amount that would have signaled a partnership between you and the client. The key here is that you need a seat at the table from a business perspective to make sure their business plan makes sense and they're executing on that plan.

3) Having spent most of my insurance career on the broker/MGA side, I can't tell you how many half baked ideas we came up with where the "only barrier to entry was a technology solution." We would spin our wheels and those of our technology partners, only to find that our gun shy executive team didn't have the appetite for the risk or their capital priorities were focused elsewhere.

Here’s a quick story that explains the gun shy comment:

We come up with an insurance product for an affinity group: Professional Liability for Financial Advisors that are members of this particular organization. We can electronically underwrite the entire submission and take payment all from the website. We decide we need a web platform, but that platform must interface with our systems, and yadda yadda ya. The platform is estimated to cost nearly $1m, but this single program will only bring in $350k per year. But wait, we can create more programs like this based on the platform and make a killing. Sounds good, pull the trigger. Platform is developed and deployed (not without its share of bumps and $$$ overruns). Four years later, guess how many programs are on the platform? Just the one, and they are still probably waiting to break even. Hence, gun shy execs who are afraid to pull the trigger on every half baked business idea.

4) Finally, build it in-house is just plain stupid. If I got nothing else from "Good to Great" it was the Hedgehog Principle: Do only what you can make money at, what you can be the best at, and what you are passionate about. For an insurance broker, software development does not fall into either of those categories. I worked for the world's third largest insurance broker, with a pretty significant IT staff, and it was only have several internal development disasters that they finally moved to a “buy vs. build” strategy and/or started outsourcing to technology partners.

Not sure if this helps, but wanted to share my perspective nonetheless. Thanks for your article as well.