Lessons learned

The thinking that underpins the way we work was driven by what we call: The “Bridge to Disruption” and the “Long Hard Look”.

bridge

The bridge to disruption

True disruption has to come from outside the sector, that’s why we looked closely at bridge building.

Like large bespoke software projects, bridges are unique, complex and expensive. Unlike software projects, they tend to look and work how we expected, and come in roughly on time and on budget. This is all in the face of significant risk – people die when bridges go wrong!

It seemed bridge builders knew much better than software companies when key resources were needed to make projects successful. That’s not surprising as we’ve been building bridges for 1,000’s of years rather than the 50 or so we’ve been building software!

We learned three key things from these guys:

  • Break projects down into three key stages: Inception> Design> Build, with those leading the Design and Build stages having a big input into the previous stages.
  • Modelling is critical to all three stages, so use powerful modelling tools and hire people who really know how to use them!
  • Spend more budget earlier to identify problems sooner when they are much cheaper and quicker to fix.
black-bench

The long hard look

We also looked closely at the four big players in the software methodology game:

  • Waterfall’s idea of breaking big problems down into discrete stages is basically sound. So is its drive for a holistic view of the software as soon as possible. Accountants, lawyers and technical architects love the ‘illusion of certainty’ it brings. Of course, Waterfall’s reality rarely matched anyone’s fantasy of the final software, but some of its failures can be traced to it’s historic reliance on abstract modeling devices, like “the requirements document” and esoteric diagrams, rather than the concrete modelling tools now available.
  • Lean’s streamlined methods are particularly good if time and/or money are critical. Importantly, it also recognises the value of formalized ‘design thinking’ and focusing on the customer. Lean can maximize opportunities, but it also involves significant risks due to short cuts, particularly in validating concepts and nailing key details.
  • Agile also recognises the benefits of breaking down software problems into manageable chunks. Its drive to reduce documentation, improve stakeholder collaboration and make coding more efficient are also highly beneficial. But Agile’s call to ‘go on a journey’ with your software supplier, to an unknown destination, taking an unknown amount of time and money, involves significant risks! Agile is also prone to macro level inefficiencies due to code rework and architecture changes as its sprints progress. The lack of up-front holistic vision can also lead to a fragmented and inconsistent design.
  • User Centred Design (UCD) usually gets you what you want in the end. Stakeholders are usually happy. But it’s expensive and time consuming, so few can afford to really do UCD!
 

So after looking inside and outside the software industry, with our decades of experience on 100s of software projects, and our degrees and doctoral research, we had four big thoughts:

  • Waterfall the project into three stages: Inception>Design>Build.
  • Left Shift to reduce risk by increasing spend on Inception & Design. Do this by focusing Lean and/or UCD methods on the key requirements, USPs and challenging problems. Adapt Agile’s and UCD’s idea of wide stakeholder involvement so that: leads from the Design and Build stages are more involved in earlier stages. Validate design decisions using only representatives of those (proto) personas who have the biggest stake in the decision. This traps out key problems early and efficiently, maximises opportunities, promotes teamwork and enables a shared vision of what’s being built.
  • Communication: Many inefficiencies and disasters in software projects are due to communication problems. Address this by using multiskilled professionals to lead the three stages so they all speak each other’s language. Minimize the number of software engineering and project management tools to reduce translation and integrity errors.
  • Modelling: Use a powerful modelling tool, in our case Axure RP Pro, that can be used seamlessly across all three stages. This generates, communicates and validates a common vision of the software product.
 

Overall, our REEAX method minimises the weak parts of the current software methodology thinking and integrates the best parts to deliver maximum efficiency with minimal risk.

Find out more about the: reeax method

A few of our customers

tripadvisor
VISA
IBM
KPMG
Roche
E.ON

Contact Us