Rob Say, Professional Services Consultant, FINEOS
Every customer I’ve worked with has been subtly different both in terms of the business (what the customer does) and their operation (how they do it), but each project has common challenges. The supplier selection process should mean that you’re choosing the best fit for your business but it’s equally important to also consider the ‘how’ in the delivery of your project.
One recurring question which doesn’t have a stock answer is how to get the best out of your supplier. I can install a system for you if that’s what’s needed – or we can help shape and deliver a solution. Between ‘arms-length’ and ‘supplier managed’ projects lie a sliding scale of co-operative and collaborative projects; any of these can succeed, not all will be appropriate to your organisation.
The most successful and fulfilling projects I’ve worked on are those where business change is the key concern and where the IT solution is treated as one delivery mechanism. The customer articulates and takes ownership for the desired change in their organisation; and where our solution is defined and delivered in the context of that change.
This may all seem a little abstract – so here are a few concrete examples of things that have given me a warm feeling recently in customer engagements; any and all of which mean you’re already thinking about collaborating on change:
- One page user stories – which everyone working on the project can understand and contribute to. Whoever your key stakeholders are (claims handlers, team managers, exec …) they’ll be reading these and be able to pick out something to get excited about; something they want or need.
- Requirements that acknowledge criticality & desire and allow for solutions. “Claims handler must complete action before closure” carries vastly more information than “Document button must be pink”. Requirements with a higher density of relevant information make it much easier to define & deliver a solution – it also indicates that not only do you have deep understanding of your own business but that your willing to share and discuss it.
- End-users asking questions and explaining their day to day activities to me. If the end-users are talking to me it usually means that they and other key stakeholders have been involved from the beginning.
- Information on current systems that we do and don’t have to talk to. We don’t know your internal systems and explaining them to us means both that you understand them and demonstrates that you want to get the best out of us.
- Solution Constraints & Exception cases with added ‘why’. Sometimes the simple act of explaining something to a third party can be enough to uncover gaps and restrictions. If you’re also giving us the ‘why’ then solutions options really start to open up.
Do you have these or something equivalent, or a plan to produce them? If you do, I’ll certainly be looking forward to joining the team on that project.