I’ve been involved in a few conversations recently about business systems with a number of education customers. And there’s a recurring question through these conversations, which is:

Should a university/TAFE/school buy a system for its technical capabilities, or for the business problem it solves?

Take Business Intelligence as an example. Should you look for the all-singing, all-dancing answer to everything (ie the one that solves the 300 pages of use-case produced in a typical tender), or should you buy a solution to solve a specific business problem (eg something that reduces your budget cycle by 50%; or reduces your cost of producing your annual report by 30%).

What I’ve noticed with the first approach is that the procurement cycle takes a very long time – because writing the specifications takes a while (and lots of meetings right across the university) – and then implementation can take even longer – often because you are trying to solve lots of problems all in one go. In fact, in some cases the procurement and implementation can take so long that the original requirement has completely changed by the time that something is built. Or the delay has a real financial cost to the institution bigger than the investment (I once was involved in a project where all sides agreed savings in implementation meant the payback period for the investment was seven days – and yet it took 9 months to do the procurement)

I’ve seen this happen for lots of different business systems* – business intelligence systems; Customer Relationship Management systems; learning management systems – across lots of different education organisations.

So what can you do about it?

  • Stay focused on solving the business problem, rather than switching to buying a solution for it’s technical capabilities alone
    And I say that in the full knowledge that will make life difficult for us, as we often default to talking about technical capabilities too!
  • Don’t get carried away with solving everything in one go – because scope creep can really delay projects badly
  • Find a partner that shares a mindset about agile development, rather than the historical waterfall method
    ie rather than spending a year writing a specification, spend that year delivering the system, because these days it can be just as quick (or quicker) to configure a system and write the code, as writing a specification document on paper

This is only my personal opinion, but it’s based on decades of watching educational ICT systems and procurement, and realising that projects that seem to grow in size during procurement, and then promise to solve all the existing and potential business problems at the end, never actually seem to deliver what people want or expect.

 

* Let’s hope it’s just a coincidence that there’s a correlation between the existence of an acronym (BI, CRM, LMS) and the length of implementation.