8 December 2016

Mission Impossible? How we built and launched a grants application system in just 6 weeks using agile methodology


A couple of months ago, we were approached by Historic Environment Scotland (HES) with an exciting project: building a grant application platform from scratch that would improve the quality of applications across a number of available grants.

HES traditionally offer grants to projects that help or maintain Scotland’s historic environment, such as refurbishments of historical buildings, sites, castles or similar landmarks, ensuring that Scotland’s historical heritage will be preserved for generations to come. In order to facilitate these projects, people can apply for financial support via the central grants system.

Grant application systems are complex platforms; the crux is to design an interface that would make applications as simple and straight forward as possible without missing out on collecting standardised details that would determine whether or not an enquiry is eligible for a grant.

Our team was eager to start working on this project – the only problem was time.

A hard and fast delivery date meant that we had to build the platform in only six weeks – anyone working in website development would agree that completing a project of this complexity in such a short timeframe is more than ambitious.

Fast action was required. We decided to go for a sprint.

Sprinting to success

When I say we sprinted, I mean this more literally than you might think.

We needed an agile methodology to quickly analyse our project objectives, goals and requirements and design a prototype that would be ready for testing. SPRINT enabled us to do this in one week!

This is the point where I should have the full attention of all project managers among you: there is actually a methodology that can help you define requirements and build a prototype quickly and efficiently.

The process we used is literally called SPRINT, a framework for rapid design development.


In their book known under the same name, Jake Knapp, John Zeratsky and Braden Kowitz (all partners at Google Ventures) define a SPRINT as

“a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers”.

The idea is to bring people of various disciplines needed for the project, as well as the clients and decision makers, into one room to intensively work on the project for a whole week.

This process guides you from mapping out your project according to your business objectives, sketching out variations of your product, leading to a final sketch on Wednesday. On Thursday, the prototype is constructed to then be tested on Friday with real customers.
Sprint agenda

Working in agile project teams

The SPRINT methodology has many essential advantages as opposed to traditional approaches.

Rather than working in silos as often done in waterfall-approaches, everyone involved in the project is brought together in one room, including the client.

That means that decisions are made extremely quickly and misinterpretation is easily avoided. As everyone brings a different perspective to the project, the prototypes are of extremely high value; team members from various backgrounds create their individual sketches which then undergo a voting process and are turned into a customer map.

The client (i.e. The Decider) chooses what he or she believes is the best set of sketches to meet the users’ needs.

In a SPRINT environment, most of the product definition is done within that week leading up to the prototype development.

This and the fact that the prototype can be tested already after four days means that teams have a shortcut to learning without building and launching.

This makes alterations much easier, cost effective, and agile.

SPRINT production cycle

From a concept to a functioning product in just six weeks

The SPRINT week was intense – but the effort was worth it. After six weeks, we were able to launch the new system under https://grants.historicenvironment.scot/.

Our client, HES, was extremely open to this new approach and very accommodating. They joined us for the SPRINT, which enabled us to discuss and confirm requirements to quickly define a solution that we all believed in.

SPRINT process

Rather than being trapped in a slow-moving waterfall approach, where the next step often depends on the previous person finishing their tasks, a testable prototype was created within five days! It was then built in a very efficient way as all problems and requirements had been addressed in the first project phase.

SPRINTs work for every project – no matter the complexity

You might have doubts whether or not this agile way of working will be suitable for your project – maybe you’re looking at redesigning a website or even need a grant system yourself? Five days will seem like an incredibly short timeframe for a complex system to be defined, but Knapp et al. stress in their guidebook that SPRINTs work for every type of project. In fact, the more complex the task is, the better it is to work in a collaborative and agile way!

In the case of this project, the team knew from previous experience that grants application systems were notoriously tricky to build. For an applicant to be successful, they have to provide as much detail as possible, whilst meeting specific criteria defined by the body responsible for issuing the grant. This means that the information being requested can be complex and difficult for a user to collate and submit.

During the SPRINT we realised that a grants system, by default, must allow a user to drop in and out of the process at their leisure and must make it very easy for a user to understand where they are in the process at any given time. The challenge, therefore, is developing a system that encourages and supports a user to provide the best possible information whenever it becomes available to them. The system should do the heavy lifting, not the user!

The SPRINT allowed us to focus on exactly what information the HES Grants Team required to determine whether someone should receive a grant. By doing this we were able to map a customer journey that requested this information in a logical way. Once we knew what information we needed to collect we could then focus on:

  • Setting a user’s expectations. I.e. what information they would need before and during the application process
  • Ensuring users always knew where they were in the context of the application at any given time
  • Providing several levels of contextual guidance to help support users of different levels

The process of defining these requirements and designing a platform that would allow a simple and intuitive user journey could have taken weeks alone; thanks to involving everyone in the SPRINT from day one, we were able to generate results very quickly while guaranteeing for a high level of quality.

No project is perfect though and the system was not without its faults. Although it was tested heavily we did suffer an issue with registration emails not making it to new users. This was resolved shortly after launch and now the Storm and HES team are working hard on the next iteration of the system. Go team!

Revolutionising project management with agile methods

As demonstrated with this example, agile working methods hold many advantages over traditional waterfall models.

Mike Cashin, who facilitated this SPRINT and managed the delivery of the HES Grants System, reflects on the positive effect SPRINTs have had at Storm ID:

“The beauty of the SPRINT process is that it accelerates the requirements definition process at the start of the project, allowing you to prototype and test ideas within an incredibly short space of time. The outputs are the same as a traditional web project, the only difference being that they are created collaboratively by a multi-skilled team in a workshop environment and, as the client is in the room with you from start to finish, everything is focussed and transparent.”

In a more and more demanding business environment where being flexible and fast can decide over competitive advantages of a company, teams should focus on becoming nimbler and able to iterate and adjust their products and services to meet an ever changing set of requirements.




Subscribe to Email Updates


We are a digital transformation consultancy. We help our clients succeed.

View Services