How to make a software project exciting and engaging

How to make a software project exciting and engaging

Great products go along with great people, diversity of talents and mutual engagement of the customer and the supplier. Here is an excellent example, the EPEX project in Making Waves.

In a galaxy far, far away, the planet EPEX could be found. One of its kingdoms, Azuria, was ruled by a fair and brave lord. Due to the kingdom’s bountiful natural resources, the people did not have to work. They lived in peace. But one day, everything changed… This could be the beginning to your average IT fairy tale. This tale, however, is not fantasy; instead, it describes an exciting product we built for our customer. In fact, this is one of the best products we have ever created. EPEX is an innovative new leadership programme that offers an opportunity to gain real-life insight into the complex workings of the global oil and gas industry. At the heart of EPEX lies a software system that provides the tools necessary to identify, analyse and implement the key strategic decisions faced by oil and gas companies around the world. EPEX is a simulation software that combines a game and a complex business application. The resulting program takes participants on a multi-year journey, during which they have to make decisions on a variety of issues. This project involved our minds and our hearts. Not only did we enjoy the project work itself, but we were also deeply involved in the overall success of this start-up. What was so special that it engaged us so much?

Collaboration over contract negotiation

Instead of providing a standard offer and negotiating a contract, we decided to invite the EPEX team to a workshop. We knew that one of the key factors to success was understanding the business problem and the users’ needs, neither of which we could do by simply reading the long spec. Instead, we needed to get to know  the customer. Therefore, we organized ourselves in a multidisciplinary team consisting of creative and technical consultants and conducted a two-day workshop in Krakow. During these very productive days, we were able to come to understand not only the vision and main usage scenarios of the software, but also to the complicated business domain. Moreover, we developed a common language. Ultimately, we were able to demonstrate first concepts of the product.


The level of trust is a one of the most significant elements influencing the way organizations run their projects and customer-vendor relationships. The lower the level of trust, the more non-value-added activities must be performed. More artefacts (paper trails, documentation, etc.) must be maintained throughout the course of the project. A higher the level of trust means that more focus can be placed on work completed. In this EPEX project, we worked with a very high level of trust from day one. We were transparent with the customer regarding all aspects of the project. We not only shared with EPEX our successes, but we also were clear about our problems and mistakes, the good and bad decisions we made, as well as our strengths and weaknesses. This created a foundation for our day-to-day work and streamlined the way we operated and communicated with the customer. We were able to focus more on actual development of the product rather than administration and contractual elements.

Working in multidisciplinary teams is fun and a source of innovation

We worked on a truly multidisciplinary team. The interaction and collaboration between different people, different backgrounds and different skills was fun but at the same time was a source of innovative ideas. Developers were able to influence designs by their structured thinking. At the same time, they learned a lot about how humans behave  and how users interacted with the software. This, accompanied by the customer’s excellent business knowledge of oil and gas industry, ensured that all three domains – Business, Technology, and Users – had their voice in the project. Our lack of domain knowledge was actually an advantage for the customer rather than a hassle. Because we came to the project open-minded and fresh, we challenged (in the positive way) the customer based on our fields of expertise. epex1

Agility by heart

There is no doubt that we were agile in the way we ran this project. We managed to build an interdisciplinary team of excellent consultants with complementary skills. The project team was autonomous and was able to make their own decisions within contractual boundaries. The development methodology we used evolved along the way, yet we followed key principles that had been agreed upon at the project’s start:

  • focus on collaboration with the customer (the customer came to our office once a month);
  • interaction rather than exhaustive documentation (only necessary artefacts were created, such as UX design or various algorithms);
  • focus on working software at any time (so that it is available for testing); And, last but not least,
  • we were prepared for changes in terms of both code and scope (short iterations and continuous prioritization).

Sounds familiar?

Contract that empowers

A critical factor that influenced the way in which we realized the project was the contract’s formulation. On one hand, it defined the scope and budget for the main part of the project. On the other hand, it allowed space for change. It also provided incentive for both parties to finish the project within boundaries. These combined factors provided a solid legal framework. This led to a focus on innovation, end-user orientation and collaboration based on trust rather than the legal matters. The project was successful. Yet more importantly, the product and the whole concept were successful as well. Today, EPEX runs their courses all over the world. The courses use the simulation software we developed. As a result, the software provides end users the best class experience, confirmed by excellent feedback we received.