Issue 2: Selecting a PAS

selectingsoftware

Welcome to the Orpheus Inversion series.  In the second of our series we explain how to select PAS software . . .

We didn’t realise anything was wrong, but after we had that impressive sales pitch by “Newco PAS Systems” we thought it would be good to modernise those clunky old platforms.  We liked the ability to be more agile, have open standards and have a modern platform (that will keep the IT guys happy). 

Speed is everything, so to make the process faster lets get a business person (one only), maybe someone we’re trying to move out, or works on ‘special projects’.  They can do all the heavy lifting and manage it from our end.  IT are busy people so we don’t need to drag them in yet. 

So, that’s us ready, now time to create a project and find some software.

We could spend time figuring out which vendors we should approach in a Vendor Selection process but hey, lets cut down time and just use the ones we’ve seen in the press recently.  We’ll invite Newco because they’ve already bought us dinner and that Newco stuff looked pretty good. . . 

How can we find some others. . . Feeling Lucky. . .?

good_pas_software

We’re going to be busy with lots of internal meetings, so here are the things we can fast track:

 

  • Functionality – Don’t waste time conducting a high-level, functional assessment that focuses on areas such as product management, underwriting, rules and rating, administration, channel distribution  . . . All PAS systems will do this.  The vendor is an expert in their field so they can tell us what we need – they’ll know because they told us they sold their system to lots of companies, “just like us!”

 

  • Business Scenarios with Real-Life Data – Preparing real-life scenarios that can drive vendor’s proof of concept demonstrations won’t allow them to show us what we want to see.  Our old platforms probably mean that our processes are out of date anyway.  Most of the vendors will ignore our requirements – so covering them quickly should save us some time and get to the demo’s quicker (they’re the fun bit anyway).

 

  • Architecture and Flexibility – IT will take care of anything we select; but keep them out of it for now as they will just complicate matters.  And make sure we only consider one deployment model.  Don’t look at any cloud-based solution for PAS – it just won’t work for our complex business and there could be all kind of security issues (my friends mother had their Hotmail account hacked).

 

  • Delivery Model and Third-party Integrator Market – now let’s hire a generic Project Manager, they can work out the project methodology we should use and the best delivery model.  ‘Seek’ is a good place to start – a project is project after all!  And if we use a load of contractors then it’ll allow IT to keep “the lights on” while we complete the project. 

 

  • Staff and Planning  – if we can get cheap rates then we’ll be able to hire more people and finish the project even sooner.   We reckon the project will take 18 months but that might not sit well with the board so let’s tell them 12.  With all those contractors I’m sure we’ll accelerate against timeframes as the project goes on.  And in terms of project budgets let’s keep all the contractors on 6-month contracts; that way we can get rid of them easily if we’re going over budget. If we really, really get stuck then we can always go to a big Tier-1 consultancy to tell us what to do, when to do it and how much we should pay.

 

  • Cost – Don’t worry about total cost of ownership – that becomes a BAU cost once we’re live. And by selecting a short-list of one we can avoid any of that complex and sometimes nasty competitive tension in the negotiation.  And we don’t really need any vendor management expertise, as we all know that the vendor will always give us their most preferential terms.  And discount heavily . . .

 

Now we know what we want and we’ve got a team we can move onto the Formal Evaluation & Scoring: 

project_team_2

 

  • RFQ/I/P.  If we had done it earlier we could use our functionality and architecture assessment as part of the criteria in this request, but vendors often find this misleading and unhelpful, so it’s a good job we didn’t.  Their solutions will become the backbone of our organisation so there is no need to include any helpful blueprints on our architecture to provide vendors context – IT can sort this later.  RFPs tend to be more detailed and longer than RFIs or RFQs. Anything less than a 1000 questions and we’re not trying.  We should send the RFI out as a PDF so vendors have to re-type the questions.  If we’re stuck – we can bulk out the RFP with generic questions – like can your PAS pay the milk bill?  Try to make the questions as generic as possible, scattered with phrases that only our organisation uses and as far away from our business scenarios as possible.  Lets make a mental note to never bind the RFx responses into the contract.

 

  • Vendor Background. Make sure our RFx does not include questions about the vendor’s background, how many insurers in our space they’ve signed in the last two years and last 12 months, who owns them (or what happens if they’re acquired), the number of failed projects they’ve had (it will be zero), the typical implementation times and sizes.  We can find this all out on Google later if needed (is there anything it can’t tell us?).

 

  • Site Visits. Who wants to visit any of their current installations?  If we’re forced to do it then lets just pick one that is nothing like us or somewhere “nice”.  We’re a direct insurer but a visit to a broker based install should be valuable shouldn’t it?  We’ll ask the vendor for a list of current installs and if we pick an exotic location we might be able to tack a family holiday onto the end of the business trip.  And while we’re visiting customers’ lets make sure that the vendor hosts us all the time so we can’t ask any tough questions. 

 

  • Client References. We will only speak to the Clients the vendor has pre-vetted.  We’ve not got time to hear hard luck stories.

 

  • Proof-of-Concept . Everyone knows that an on-site proof of concept over the course of a week or so, using data and scenarios we have prepared with the business, is pointless.  What are we going to see in 3 days that we’ve not already seen from a 2-hour demo?  We’ll call the sales team if we need to full in any gaps. 

 

In conclusion, it’s obvious that we can waste a lot of time figuring out what we really need and which vendors might be able to fulfil those needs.  Instead, we could get the PAS selection team to begin selecting a vendor before business needs are well defined.  That way the business will feel engaged and once we select the vendors they can return to their day jobs.  This way we can focus on what matters most to the business and should enable us to make sure the PAS selection process is just perfect.  Time to engineer a business case for the board and we’re done.

 

Or invert everything in the inversion above!   Want to do it properly and need help?  Contact us.