Towards agility
Procurement and management models have been developed for as long as information systems and software have existed. For a long time, the traditional, or ‘waterfall’ model was relied upon, where a project was carefully planned and defined before tendering and implementation began. In complex areas such as construction, this type of approach is possible or even necessary.
In contrast, the development of information systems is a complex process, and it isn’t known in advance what the best final solution will be. Implementing them in a waterfall fashion rarely leads to a good outcome for users. In software projects, a more adaptive and empirical approach is needed.
The Agile model doesn’t pre-design the world before implementation but recognises the need to deepen understanding and specifications as the complex project progresses.
This allows the project to be steered as the understanding of user needs and business opportunities grows as the project progresses. In practice, the client typically puts the skills out to tender and gets a team to implement a system that meets its vision.
However, a contractor-supplier agile project can be challenging as the size of the project and the number of suppliers increases. The predictability of the project and the uneven risk transfer have also created a need to further develop the collaborative model.
From buildings to bits
The alliance model, which is gaining ground in the building and infrastructure world, has also attracted interest in software systems procurement. In an alliance, the contractor and suppliers work closely together, sharing the risks and benefits of the project. The project model aims to engage the different parties to achieve a successful outcome. In the project model, both the client and the suppliers win and lose together. The alliance has a common organisation in which the client is also actively involved. This means a common way of working for the parties involved in addition to which there is often a shared space (big room) to facilitate communication.
In 2016 the Finnish Transport Agency was the first to apply the tried and tested alliance model to an IT project. The VELHO project is building a system package for road information management. The IHKU project, which started in 2018, is also applying the alliance model. The IHKU project between the Finnish Transport Agency and six major cities will modernise cost accounting for infrastructure projects in Finland. We are involved in both alliances.
What kind of IT projects does the alliance model work for?
The starting point is that the project requires several different actors, competencies and skills that cannot be provided by individual actors alone. The model aims to bring these capabilities together in an alliance.
The alliance model requires a special effort from both the client and the suppliers at the procurement stage. From the client’s point of view, identifying the required capabilities is crucial for the right kind of tendering process. Similarly, for the supplier partners, building the right consortia is key to enabling a successful bidding process and project.
Smooth collaboration is at the heart of the alliance. The contracting authority should pay particular attention to the smooth cooperation of the candidate consortia. Skills and cooperation are crucial to the success of the alliance.
Due to the high initial investment, the model isn’t suitable for small projects. System projects of close to ten million euros can achieve the benefits that the alliance model is aiming for.
The resources and time required for the procurement process and project start-up should be taken into account in the project design. The alliance model is therefore suitable for projects with a minimum duration of several years.
Let’s stay agile
The alliance model commonly used in the construction world is divided into three phases:
- Development phase
- Implementation phase and
- Maintenance phase
This division has also been brought into the IT world as a framework for project phasing. At this point, agile advocates are likely to raise their hands in alarm! Phasing sounds very much like a waterfall model from the past.
Contractually, it should be ensured that the phasing of a project doesn’t lead to overly extensive and detailed planning at the start of the project.
“We never know as little about a future system or service as we do at the start of a project” remains excellent wisdom.
Definition and conceptualisation during the project will be done in close collaboration with implementation. In an alliance, this should be reflected in the collaboration and working methods, integrating the different parties and actors in the day-to-day work. This is all very familiar to those who work on agile projects. Let’s not forget these lessons in alliances either.
Even if you don’t “design the world” at the beginning of a project, you need a vision and a roadmap. In large and complex projects, it is important to maintain a vision of where the project is going: what are the key objectives, functionalities and processes that will be fulfilled in the name of the project?
The roadmap and vision are tools for communicating direction and meaning, both internally and externally. They also provide the basis for the work of product management on a day-to-day basis.
One example of the differences between construction projects and the development of information systems is the relationship with the budget. In agile projects, instead of a precise pre-determined plan and content, the goal is envisioned (achievable customer value) and the solution is built piece by piece (incrementally), refining it based on user feedback and lessons learned (iteratively). In this case, the reward system linked to the project target budget used in construction projects doesn’t fit well with the agile development model.
Alliance contracting models should support the approaches that an agile software development project needs. The current contracts still need a comprehensive review from an information systems development perspective. This would create the conditions for a wider use of the model in the IT sector.
The alliance model has its place
With two projects and more than six years of experience in alliances, the model works for IT system projects. It is a good option for the implementation of large, complex projects requiring multiple skills. Of course, the laborious procurement process has to be taken into account, but the trade-off is committed contractor(s) and suppliers.
Most importantly, the alliance provides, at its best, an excellent framework and guidance for genuine collaboration between the different parties. The adaptation of the project and contract model to the IT world is still a work in progress. The work can be completed in cooperation between contracting organisations, consultancies and suppliers. The valuable experience that has already been gained will be exploited.