In any infrastructure project1, there almost inevitably comes a point where we find a gap between the desired functionality and the available budget. Often that leaves us with a stark choice; remove the requirements or attempt to increase the budget.
So how do we avoid this?
The trick is to find the gap early on, in fact the earlier the better, because it’s much easier to deal with the gap before choosing a solution. To identify the gap you need to do two things:
- Really, really clearly define your requirements.
- Rigorously test potential solutions against those requirements.
Simple? Well, it should be but rarely is.
Defining requirements does not mean writing a list of functionality that a system should have. It means listing exactly what that system will enable you to do within the organisation. That may sound obvious, but I’ve seen plenty of requirements documents that are a shopping list of features when they should be a shopping list of benefits.
The worst cases is when the project ends up being led by the functionality. If a vendors offers features outside of the requirements, ask yourself how they will help you achieve any the business goals you have identified. If they don’t, they are superfluous to your needs and should be disregarded.
Once you are clear about your requirements, the only way to be sure that any solution will address them is to test the one against the other. Again, a list of functionality or vendor assurances is not enough. Testing means using the system in a simulated environment that is as close as possible to how it will really be used.
Proper testing takes time. You should be arranging at least a 30 day evaluation, and then making as much use of that time as possible. A couple of hours is not enough. Remember that you are the worst person to do any testing, because you know what you expect it to do. Instead you should test with people who are typical of real end users.
So what do you do once the gap has been identified? I generally follow a simple set of rules:
- Find a solution that meets at least 80% of your requirements out of the box
- Look to solve 10% of your requirements through configuration2 changes
- For the last 10% ask yourself if you can change your business processes to fit the chosen system; if not, you may have to commit to customisation.
- I’m deliberately not limiting this to any particular type of system, but what I’m talking about here is relevant to any learning related systems; e.g. LMS, virtual classrooms tools, social learning platforms. ↩
- Configuration is different to customisation, in that it involves making changes through the interface, not in the code. It’s usually easier to do than customisation, and causes less problems when upgrading. ↩