Risk management in software projects, part 3: Collaboration and trust

Posted by Sami Tikka on December 26, 2016

This is a third post in my series on risk management in software projects.

In first post of this series I wrote how failure in software project risk management leads to unrealistic estimates for project duration and costs. In second post I sketched a simple system for mapping out biggest sources for cost and time overruns in software projects. This post is looking at aspects of project management outside the hard engineering work: trust and co-operation.

Evolution in construction industry contract models

Engineers at construction industry have been also struggling with risk management. Lots of high profile cases are often perceived as having exceeded their time and cost estimates. Traditional contracts in construction industry place significant emphasis on the consequences of failure and tend to focus primarily on risk allocation. This results in project being perceived as zero sum game, where one party’s gain is another party’s loss. Parties do not seem equally incentivized and ultimately do not build the trust needed for successful co-operation.

People in construction industry have therefore developed a new contracting model called an alliance contract, in which the parties agree to work together as one integrated team. In alliance contract all contractual parties, the owner, the constructor and designers, agree to work on one “virtual organization” and share the risks. The contractor is incentivized by earning a greater or lesser profit margin depending on performance and having a share in the overall cost performance. Alliance contracting is gaining popularity in many countries, including in Finland.

Lots of common characteristics for construction and software engineering disciplines

Projects in construction industry obviously differ a bit from those in the software industry. Software projects rarely have lots of subcontractors, which is the norm in construction projects. Also software projects might be more suitable for dividing them in sub-projects, where each individual system can function on it’s own. The individual sub-systems can be put to production use on their own.

Common issues for both engineering disciplines are risks arising from creating novel systems with unknown technology, and natural tension between owner and contractor perceived to have non-aligning business goals.

Software industry has developed a number of agile contract models, where the lack of trust is worked around by a) doing work in short durations, b) keeping the feedback loop short between client and contractor and c) making sure the client appoints a single dedicated product owner for the project to prioritize the work according to business needs. Ultimately, agile methodologies do not guarantee success, and things can still go wrong. Software project contracts are often written in significant detail to guarantee the client some visibility into the final delivery date and project costs.

In ideal case contracting parties are able to trust each other, so that the client can trust the contractor to deliver what the client needs in relatively specific time frame and costs. The contractor can also trust the client as having sufficient motivation to co-operate with contractor and convey the actual business needs. When both parties trust each other, even setbacks can be handled together without blaming anyone. This is at the core of alliance contracting.

Trust is earned

Building trust obviously takes some time and often it helps to have a common history working together. Software projects might benefit from starting small, so that client and contractor agree on smallish, tightly scoped subsystem, ideally with no unknowns when it comes to technical solutions. When this first system has been finished, both parties can better evaluate whether they are able to extend their trust to each other and fully commit to building the project and share the risks. The client can also at this point walk away, if co-operation does not arise naturally and trust does not manifest itself.

Success in software project is defined by success in risk management, trust and constructive co-operation between parties. Risk management is one part of contractor’s technical expertise and another part of psychological insight into managing client expectations. Trust can be built by achieving mutually agreed milestones. Achieving goals in co-operation gives both parties extra energy to work towards next goal and thus producing a positive loop.