Note to the reader: This is a joint blog between GGA and our client, Labyrinth Solutions Ltd, creators of a new product called SilkThread ™. It charts the creation of this new application from a developer’s AND client’s points of view.SilkThread ™ is a compliance-based web application which helps transport operators and hauliers comply with the Undertakings of the Operator’s Licence – this is a requirement for anyone running vehicles over 3.5t (anything bigger than a large van). It enables auditing and visibility across multiple depots of all aspects of transport management, including how depots manage drivers’ hours, vehicle servicing, defect reporting, working time, agency drivers and many other vital aspects of transport compliance. It is the first web app of its kind to be developed in the UK.
It is called SilkThread ™ because, in the Greek myth of Theseus and the Minotaur, the hero was given a ball of silk thread to help him navigate his way back out of the maze after his victorious battle with the Minotaur.
Ruth Waring (Director of Labyrinth)
After the first meeting with GGA, we sat down and wrote the document spec for SilkThread app, which ran to 25 pages. GGA took this away and, after a number of discussions, we agreed to work with them for two half days to develop the spec in more detail, and we would pay them for this initial exercise.
The two half day sessions threw up a number of questions, and was quite exhausting as both sides kept coming up against areas we hadn’t even thought about. GGA MD Paul Rhodes used post-it notes to help us spec the MVP (Minimum Viable Product) – and talked in detail about how we “get the app out of the door”. The GGA team talked a lot of sense and we started to develop a clear plan both for developing the app, but also for carrying out market research and how we could get the product in front of potential clients.
The idea of MVP is that you develop something you can start to sell then, as you get more funds, you add on functionality so that the product has a wider potential reach. We decided to work on MVP as a version we could sell to companies with their own fleet (including multiple depot), whereas Version 1 and 2 would focus on a version which included procurement of haulage services.
The Labyrinth team then had the painful realisation that a Word-based spec was not sufficient, and we would need to do an Excel spreadsheet spec with logic embedded in each question and answer. This threw up lots of other issues and made us realise that the spec we had thought was finalised was in fact some way off. We began to realise why no one else had ever developed an app like this; it is actually really complicated and you needed an unusual combination of in-depth industry knowledge, IT skills, funds and tenacity. We decided to see this as a positive, as we have these elements and it means that we were unlikely to be competing with any similar products in the marketplace.
We then appointed a company to do some research for us; was there a genuine market for the product? Labyrinth used Carol Carpenter Training for this exercise and gave them a very tight brief. We also worked with GGA to develop something called ‘Wireframes’, which are mock-ups of how the screens will look once the system is live. There was palpable excitement in the Labyrinth office when the wire frames came through and we could really begin to see the app working. The feedback from the research was massively positive, with every contact expressing an interest in the product.
Spurred on by the excellent feedback we received we ploughed on with the spec, working a a team with everyone playing to their strengths. Just when we thought we’d almost finished we would uncover a new area to consider.
We have now finished the spec, having spent more time than anticipated dotting the I’s and crossing the t’s on the spreadsheet, to be 100% sure we are happy.
So what happens next?
Paul Tunnicliffe (Project Manager @ GGA)
After Labyrinth had finished their initial specification, they hired us for 2 half-day consultancy sessions to go through what they had written and to really get into the nitty-gritty of the project. As usual on big projects like this, these sessions revealed a serious amount of new issues, ideas, and un-thought of requirements. But this is the beauty of technical consultancy sessions; it allows the developers technical knowledge to combine with the client’s industry know-how to produce outcomes that could never be foreseen otherwise. I’ll write a blog soon about the pros of development agencies offering pre-project kick-off consultancy services but, believe me when I say, they should be an absolute necessity for everyone involved!
These sessions allowed us to learn invaluable inside information about the logistics and transport industries whilst getting Labyrinth 100% behind the idea of MVP delivery as a way to help sell SilkThread without having to do any actual development! We agreed to wireframe out the whole system and fully design key sections, allowing Labyrinth’s Directors Ruth and Jo to go out to companies and use the mock-ups to sell the SilkThread concept. This proved to be a brilliant step for them as it enabled them to quickly achieve the most vital step in product development: VALIDATION.
With the knowledge that SilkThread is actually wanted and needed within their industry, GGA created an in-depth technical specification document that, along with the wireframes, gave us a comprehensive brief on which the system would be built on. SilkThread was to be a user-based web platform with a sophisticated question generator that allowed Labyrinth, as administrators, to create and manage the compliance questions. This in turn would let their customers login and answer the questions, upload supporting documentary evidence, and hey-presto, prove their company is compliant to operate legally. Everyone was happy and production was about to begin.
This is when we hit a pretty big snag…
During the time between receiving the tech spec and kicking-off development, Labyrinth had realised that their original documentation of the compliance questions wasn’t accurate enough and had set upon creating a spreadsheet that showed the full logic of what SilkThread’s question generator needed to do. The problem was, although this flow seemed logical(ish) on paper, it completely upended the logic required from a coding point of view, rendering a large portion of the tech spec redundant!
This was a big issue. The new complexities that the spreadsheet uncovered meant that the question generator simply couldn’t work the way we originally envisaged. So back to the drawing board we went and, after a few weeks of back and forth (and no small amount of remembering what MVP means), we came up with a solution that was expectable to Labyrinth and, fairly importantly for GGA, actually possible to build!
Now, if the advantages of a comprehensive technical consultancy and specification period aren’t obvious at this point, then they may never be! Imagine if we’d have started building based on the original spec? How much time and money would both companies have wasted if we hadn’t all took the time to plan (and re-plan) so thoroughly?
So in answer to Ruth’s question: ‘So what next?’, we’re now in the initial development phase and into the world of agile, Scrum, testing blocks and iterative sign-off. We’ll be covering all that in the next instalment.
Part 3 of ‘the story of SilkThread: Charting the creation of a new tech product from both a developer and client point of view’ will be up soon! Follow @RuthWaring and @ggappsuk to keep up to date.
