Turning a Successful Pilot into a Project, Part 1

Skip Navigation

Turning a Successful Pilot into a Project, Part 1

/ August 11, 2014

SavanToday’s guest post comes from Savan Vyas, Scrum Master and Mendix Business Engineer at LV= Insurance. In this two-part series, Savan shares advice on how to turn a successful pilot into a full-blown app delivery project. The first post outlines pre-requisites for delivering a production-ready app in one sprint, while the second part will focus on important elements to keep in mind during the sprint.

In early May, an opportunity arose at LV= to do a one-week pilot assessing whether we could improve the broker department’s manual processes. The pilot was initiated to prove the viability of the project and whether using the Mendix App Platform would be the best approach.

For this particular pilot, the goal was to create a workflow management app for the broker department that converted their standard email/phone box enquiries into a streamlined workflow, replacing several spreadsheets/database files with a single system. We combined three processes on three systems into one application with an automated tracking capability and reporting feature. The system can be used to measure productivity, get work state analysis and improve company SLAs. In just one week, we were able to deliver a production ready application which achieved all of the above mentioned benefits.

This was achieved due to great IT-business collaboration and using agile development techniques. The pilot was a great success as the department started using the app immediately, with users filling in over 1,000 work logs by the end of the first week of use. It has quickly turned into a project where the business wants to expand the capabilities in breadth and depth. Best of all, the basic system functionality was achieved in just one week by only two Mendix engineers!

So how did we do it? Here at LV=, we have been working in an agile environment using Mendix for almost two years now. With each project, we have improved our process by getting it more and more aligned with the ‘pure agile’ approach. As a result of refining our agile development approach using Mendix, we are now able to launch new insurance products and services in less than six weeks.

I attended Mendix World 2014 and took part in the 24-hour hackathon, working day and night with my team to deliver a fully functional app for charity Terre des Hommes. This was a great learning experience, and gave me a lot of confidence on just how much you can accomplish in 24 hours using Mendix.

When this pilot came up in May, it was the perfect opportunity to combine all the lessons learned from previous experiences and the thrill and speed of the hackathon in order to deliver something production ready in a very short timeframe.

Pre-Requisites for Delivering a Production-Ready App in One Sprint

When starting a project, it’s important to consider a few pre-requisites to make sure you are equipped to deliver something the customer can use by the end. The following items are some of the elements we believe setup for success.

  • Agile/Scrum and Mendix Project Management training: Initially for some of the projects, we used external trainers to give half-day training on agile/scrum, so that the team had a common understanding of language, roles and responsibilities. As this was a small pilot project and there was no budget for external training, we decided to execute the agile/scrum training ourselves to give the business a high-level understanding of the process we were going to follow and also to get them to use the Mendix project management capabilities. This ensures the team has a common understanding and a common language to communicate, while enabling users to take ownership of the users stories and work towards a common goal. Big project or small, this is worth the investment in time.
  • Workshop: It is not essential but definitely recommended that you have a half-day workshop before starting the pilot sprint to understand the whole project and business objectives you are trying to achieve. The project sponsor and product owner should be in this meeting and by the end, you want to come to an agreement on what you plan to deliver (and also not deliver) for the pilot sprint. Essentially, this is to get an idea of what they expect at the end of the pilot and the success criteria for turning it into a full-scale project.
  • Co-Locate: For the LV= pilot project, Simon Black and I went to the office where the business was based. We got some high-level information of the project, decided on the sprint goal for the pilot and who would be the product owner, and made sure we delivered the right things by asking ‘Why’ questions. We began reviewing their processes and questioning, “Why are we doing this? Do we need to do this? What could we be doing better?”  The goal wasn’t simply to replicate the existing process but to make it better. Because Mendix is a rapid app development platform, we were able to build some forms which gave them a visual feel for the product.
  • Pre-built Development components – If you want to cook something up quickly, you need all the ingredients in place beforehand. We did precisely that by baking in the core components needed for any new project in one ‘starter-kit’ module that we published in our private company app store. (This module saves crucial time on building all the pre-requisite components of the project and allows us to focus on the business requirements.


  • Operational readiness – This is one of the most important questions the team needs to ask before starting any work and one which is often overlooked. Mendix development is frequently even faster than we anticipate, allowing development cycles to be shorter than planned, which sometimes means the software is ready before the business is. Where this has happened in the past, when the operational side wasn’t ready, we had to pause the project.

The one question you should always ask the business before starting the project is, “If we are able to deliver the sprint goal at the end of this sprint, what is going to stop you from using it?” The answer could be anything from no testing resources or time for training to lack of senior management backing. Usually, we would come out with a solution within the team. For example, for the broker workflow app, the business took ownership of testing and training during the sprint cycle and we took ownership of creating documentation. The business adapted really well to the agile/scrum methodology, and told us about things that might stop us from going live which ranged from not having Chrome on their work desktops (needed for a specific drag & drop feature) to daily reports they needed to track their work. This feedback helped us prioritize our user stories and to make sure that, at any cost, we delivered those things first so that we could go live by the end of the sprint.

In the second part of this series, I will outline the key considerations to keep in mind during the pilot sprint—again, with the goal of making the pilot successful and turning it into a full-blown app delivery project. Stay tuned and in the meantime, feel free to share your experiences in the comments below.

Copy link