If your project started with a business case, you should have had a list of benefits you were looking to achieve, these may be something like:

  • The data in the CRM is reliable and free of duplicates, allowing the business to make informed decisions.
  • Communications, resources and events are relevant to audiences’ interests and in line with a content engagement strategy.
  • Operational tasks are automated where appropriate, meaning that the risk of human error is reduced, and staff are able to focus more time on strategic initiatives.

Moving on from the business case stage, the language tends to shift away from benefits and towards functional requirements, and thus the talk of benefits can get lost. Although a functional requirement does not always explicitly include the reasoning or justification behind it, you should always ultimately be able to link requirements back to the positive outcome that they intended to deliver.

For example:

  • Functional requirement: Ability to assign areas of interest to a contact.
    • Benefit: Communications, resources and events are relevant to audiences’ interests and in line with a content engagement strategy.

Through training and testing, the focus continues to be on the functional requirements, with system acceptance occurring when all functionality passes the tests. Hence, the temptation following a successful testing period is to say that that an outcome has been achieved simply because the tech is working as it should (I can successfully assign an area of interest to a contact), consequently forgetting to ensure all other processes are in place to achieve the benefits.

In seeing a successful piece of functionality as evidence of outcome achieved, it’s possible that you’re losing the opportunity to identify and exploit room for improvement, or worse still, you are declaring the project a success, when in fact the benefits are not being met at all.

For this reason, we recommend a benefits realisation exercise taking place after system go-live. This allows time for users to settle into the system, user adoption to pick up and the project team to have some headspace for reflection, before conducting an exercise to ensure that the benefits outlined in the original business case are in fact being met.

The diagram below shows the steps between a functional requirement and the positive outcome, and the actions required for the benefit to be realised.

Steps between a functional requirement and the positive outcomeIn order to track a benefit, it is not enough just to test and sign off the technical requirement. You must have an understanding of what the tech is doing to achieve the benefit, but more importantly what processes are in place to support this, and who owns these. It is only when the other steps are in place, and owners are responsible for ensuring that these are completed, that you can be confident that the benefit can be achieved.

From there, the next step is to identify a tangible measure for each benefit, but I’ll leave that for the next blog post…