So Agile I Was Tied in Knots: Lessons from a Year in Tech Development

Published On: March 25, 2024Categories: SaaS
Dr Elizabeth Stephens, Managing Director of Geopolitical Risk Advisory

RiskPal COO, Tom Bacon, reflects on what he has learned from the past 12 months working on a major RiskPal upgrade.

Last week, we released a major upgrade to our RiskPal platform, culminating more than one year’s work. After countless delays, setbacks, and many a late-night testing some very obscure logic, this is my release. My colleague said this project would be on my gravestone – little did I know it was going to kill me. Well, nearly.  

In late 2022, we began scoping improvements to some of RiskPal’s administrative features and performance. Described by one (lovely) client as an iPhone for the user but in less flattering terms for administrators, we had to rebuild the indexing logic behind our library to improve content management and ease-of-use.  

A supposed tech sprint became a marathon, a marathon became an ultra, and now, more than one year in, this apparent lunar mission has exhausted both mind and body. With the end in sight (I say this reluctantly, having been fooled to believe it so many times over), I outline a few learnings that might be useful for anyone else embarking on such a journey.

RiskPal Library Development Journey

Setting the Scene for RiskPal’s Digital Transformation

The setting spans the four seasons, with countless hours glued to a computer screen at my home in London, but that’s not the point. Please allow a little detail on the project itself…

RiskPal has a library of safety information, grouped into approximately 20 categories (labels) and 200 activities and risks. This forms a repository of searchable content crucial for risk assessments – your risks, hazards, controls and mitigations in common industry speak.

Now, why the complexity when there are knowledge libraries and off-the-shelf CMS (content management system) tools readily available? Well, RiskPal stands out due to its unparalleled configurability. Users can edit our guidance and create brand new content, reflecting their unique business needs and protocols. Moreover, the platform ensures seamless updates across all risk assessment templates, giving you standardised templates and tackling the perennial challenge of version control. Plus, we’ve revamped the user interface and introduced other new features along the way.

Ok, cool, but still not getting the big deal?

Honestly, even after a year in the weeds of tech development, effectively articulating the scope of our mission remains a challenge. In essence, we had to unpick the system logic underpinning RiskPal and rebuild it from the ground up; a bit like rebuilding the foundations of a house with lots of unwelcome surprises along the way. All the while, we had to make sure our work didn’t affect the thousands of client risk assessments already in our system or compromise their own extensive content.

Painful Lessons Learned: Key Insights for Tech Development Projects

A couple of disclaimers: First, this is not at attempt to teach developers or project managers how to do their jobs – there are millions of courses, experts and books who can help on that. Had I studied some of these more, I might not be recounting my ordeal. Secondly, I know we didn’t build the Taj Mahal, but this was a massive technical undertaking for a small team – I hope some of the below provides insights to others embarking on a development journey.

Another day, another bug sheet.
Another day, another bug sheet.

Scoping and specification.

You don’t need to write Don Quixote before work begins but it is vital to get everyone onboard early, for the team to understand the goals of your project and collectively map some of the scenarios you will need to overcome. Don’t get talked into building a quick minimal viable product based on some loose requirements and adjusting along the way, especially if modifying a live system. Faced by an abundance of constant questions and with enthusiasm eroded by the monotony of endless product testing, at times we delayed on some complex issues, let ambiguity creep in and paid the consequences through lost time at a later date.

Avoid scope creep and don’t confuse agile with a lack of direction.

Break up deliverables into individual components with mini-milestones – it’s project management 101 but can easily get lost in the cloud of a much larger deliverable. Your specification doesn’t need to be water-tight, and some requirements will evolve through a big project like this but don’t let things creep without recognising that your deadlines will move with them.

Get people together.

Whether digitally or not, communication is fundamental. Disjointed responsibilities, in our case between a design agency and development team, left me in the middle, translating messages between the two. Multiple iterations of the same page designs because of ill-considered user journeys and disjointed technical understandings saw us lose considerable time. Whether working with third parties, internal teams, or a combination of both, be sure that responsibilities are clear and communications clearer still.  

Invest time in testing schedules.

Structured testing plans and documentation are not sexy but if working with logic and complex data scenarios, it’s essential to map out what to test under variable conditions. When faced with testing the same functionality for the tenth iteration in a week, it’s easy to jump straight in, make assumptions and cut corners. Ease the workload further with automated testing tools, something we still haven’t adequately adopted and is a core goal for the year ahead. 

Plan your time and add a lot of fat.

If you are managing a large digital transformation project and don’t have the luxury or a big team or endless capital, be ready for a significant time commitment. I’m the COO of a company, with countless responsibilities beyond development; other jobs – and, frankly, the businessall suffered as a result of how much time I have had to spend on this project. At its peak, more than 50% of my working time (not even counting the evenings) went into this work per week. Plan your time, then add a 30% buffer. If you are going to be hands-on in the project, make sure that there is resilience in other parts of the business and delegate some of your wider responsibilities. 

Small investments and smart tools can help a lot.

Investing under $100 in a screen and audio recording tool was one of the best investments I have made. It saved me hours every week by not having to screenshot and type down system bugs and resulted in much better descriptions of the issues at hand. 

Teamwork and fresh perspectives.

Having a good team is key. Development projects can be lonely, especially in a world of remote working. Two hours of system logic testing can test your sanity at the best of times. I was lucky, having a great co-worker to share the testing burden with and a development team that persevered throughout some very testing periods and setbacks. In isolation, without a team connection, it would be much easier to give up. And when close to chucking it in, struggling to see the wood from the trees, get fresh perspectives. On two occasions, facing seemingly insurmountable challenges and the daunting prospect of more project setbacks, input from others detached from the day-to-day work helped us identify solutions.  

Be realistic (I’m still working on this one) and don’t expect perfection.

Keep focus, smile and nod approvingly when someone asks if your team of two people can create a product like Google in just a few weeks. Or calmly tell them to f**k off. Whatever gets you through.  

I’ve Seen the Light: Achieving Milestones in RiskPal’s Software Development Journey

Nervously revisiting our original 18-page specification document, I read the three core objectives of the project as: 

  1. Improve content management in the RiskPal library for all system administrators, providing an easy interface to search, navigate and manage large content repositories.  
  2. Overcome the need to run separate libraries per industry sector by creating multi-sector scalability with new data tagging and content. 
  3. Improve system performance and speed across the platform by reindexing content. 

I’m relieved to have achieved these and a lot more; we’ve now got a system built for growth, ready to scale and deliver risk assessment across multiple markets. We’ve delivered a library of expert advice that is accessible in a few clicks and super easy to configure. And we’ve dramatically improved the overall risk assessment process and user interface along the way.  

It’s been a bloody struggle and there are still a few final pieces of the puzzle to complete. Beyond the tech, we also rewrote and relaunched all the library content, just to make things fun. Remember what I said above about being realistic? Hindsight… 

Would I do it again? No chance. Will mistakes creep into future work? Without doubt. But at the end of this slog, the outcome is an unrivalled product development that has transformed our platform and could help you transform how you do risk assessment.  

The gravestone will have to wait.  

If you’ve read this far, thank you. I’d love to hear about your development lessons if you have embarked on a similar journey. And, of course, if you are interested to learn more about RiskPal and see what we’ve done then please do get in touch. 

Our newsletter focuses on how to drive better safety engagement.

Why not subscribe?

Share this article:

Related Articles