Sunday, October 20, 2013
The need for The Solution Owner role when implementing CRM systems
The key thing for such a role is that it should be someone who understands (or can learn to understand) not only the charity's requirements and strategies but fundraising/charity requirements more generally, as well as CRM, software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. Something I discuss constantly.
This means that when someone on the project, or a user or manager in the charity, has a question as to how the solution will work or how something fits in, or queries what will happen if we change something or what it will mean if something is left out and so on, then that person can be in a position where they can provide an answer - or know who they should ask in order to get an answer. It's a key need.
Ultimately, the role provides the charity with a central point of contact for design understanding and fundamental decision making and would usually also help provide requirements information.
Clearly this is not just Project Management. Historically, when I have done all this, I have called myself a 'Project Manager Plus'. But the more I have worked on implementing larger fundraising databases and with the new 'CRM' systems, the more I have realised just what a critical role this 'Plus' bit is in any such implementation (whoever does it!).
Recently, whilst working on one project, this specific role - the 'plus' bit - was described to me as The Solution Owner, and this struck a cord with me - it is indeed what I think such projects need. (On top of the project manager, business analysts, trainers etc, as appropriate, depending on project size and complexity).
One thing I should emphasise is that this is not a technical role, not a Solution Architect, nor a post-implementation Solution Owner (a role you do sometimes see advertised for), where it is more likely that it will need someone who is closer to the technical aspects of the system.
And as I stated above, the principle thing is that such a role should ideally be someone who understands the business - fundraising - and technology too. That way, they can help the charity and advise them on specific options as the project progresses.
I've also come to the conclusion that this is an especially indispensable role when implementing the (new) CRM systems where you can do so much with such systems and where it is not just a matter of configuring an existing vertical sector solution (such as a fundraising or membership package) - although it is by no means exclusively a requirement for CRM. Without such input, there is a real danger that you could go off down one route without understanding the implications, that you could over-customise a system too much when a simpler, alternative option could have been better, or you could lose track of just what is dependent on what and what interacts with what, which a central resource should be able to resolve. And the project team, client-side and supplier-side, will not have a single point of reference to help co-ordinate central requirements.
The Solution Owner is, IMHO, becoming a pivotal role for CRM and database implementations and is only likely to become more so.