How we developed a course booking system for the Education and Training Foundation

The new course booking system that SkillsLogic developed for the Education and Training Foundation is a great example of how we work with a client to turn an initial set of broad requirements into a mission critical web application that delivers real value from the day it goes live.

Our approach is essentially 'agile development' but within an overall fixed-price framework. We have to meet a set of requirements that are agreed up front but we still manage to build in the flexibility and responsiveness that comes with 'agile'.

The course booking system development for the Education and Training Foundation went something like this:

1. There was a fairly broad list of requirements at the start (part of the tendering process). Not a huge amount of detail but sufficient to give us a feel for the scope. The domain is familiar - we've developed course booking web applications before - so we're fairly confident (even with gaps in the detail) that we can come up with a sensible estimate for the overall cost of the software development. We also have a good sense of how big the missing detail is (if that makes sense).


2. You get a further feel for the potential cost when you do the interview/presentation that's part of the procurement. Again, understanding the domain means you can ask more meaningful questions and if the worst comes to the worst and you think you've badly underestimated the cost of the development then you know you can always back out before contract signing (not happened yet).


3. We always start with 2 or 3 weeks of requirements analysis and software design. It's actually a lot more of the former (requirements analysis) - that is the real high value work. Requirements analysis upfront sounds more like traditional waterfall development than agile but it's absolutely necessary - you simply can't develop reasonably complex business software on a fixed-price project without really getting to grips with the business requirements at the start.


4. We write software quickly and most systems have some fairly standard areas of functionality that allow us to use a lot of pre-existing boilerplate code. The foundations go in and the walls go up during the first 3 week 'sprint'. Users can login, see a menu system, some basic functionality (managing user accounts, email alerts etc.) and some of the core functionality - adding and editing a basic course for example.


5. You want the client to see the software every three weeks. The Foundation were great at giving us feedback and they'd always go away armed with plenty of questions for their wider team. Customers get confidence when the see the software beginning to emerge. They also get a feel for the amount of training (minimal we hope), wider stakeholder engagement and other things required before launch. The Foundation are London based but I think they'd agree the trips up to Sheffield from St Pancras every three weeks were really worthwhile.
   
   New requirements definitely emerge during the development, but they tend to be tweaks, refinements and clarifications rather than whole new functional areas. Again experience means that we can anticipate the likely impact on cost and budget accordingly.


6. We do a couple of weeks of testing at the end and then the client does their acceptance testing. We provide access to the system on a test server and we agree a process for raising and fixing issues. There are never any surprises at this point - the 'sprint'' reviews every three weeks took care of that - then we're pretty much ready for launch. I don't think I can ever remember a project where the launch was delayed by issues that came up during acceptance testing.

Experience - both technical and domain - is the thing that we bring to clients like The Education and Training Foundation. The real challenge isn't writing code - those tools and techniques are well understood - instead it's around getting to the bottom of the business requirements quickly and then working with the client to prioritise those requirements within the overall budget.