Conflicts in software projects
Almost every business gets involved in a conflict about a software project with another party sooner or later.
The differentiating factor is a strategy based on technical facts, combined with agreements and other legal and strategic elements.
The importance of facts and figures
Even in the early stages of a potential conflict it pays off to have a good grip on the concrete risks of the software project. Very often when a project starts to go off the rails, there are some indications of the causes and responsibilities. However, concrete facts and figures, the extent of the problems and their impact are usually not entirely clear.
In order to avoid the downward spiral of speculations, baseless finger-pointing and emotional reactions towards a full conflict, it is important to have insights based on facts about the software, the software project, the processes, as well as the parties and people involved.
Putting together technical, legal and strategic elements
When going into discussions, negotiations or litigation, depending on the stage of the conflict, you want to be fully aware of the faults of the other party and the resulting damages. It is necessary as well to grasp your own strong points in your defence. However, equally important is knowing your own mistakes and weaknesses in order to set up a strategy around them.
With almost 20 years of experience in these types of situations, I work closely together with the available project members, both technical and managerial, your legal department and, if relevant, your external legal counsel. Even better is when I can work with all parties involved towards a transparent and objective assessment of the situation, validated by all, to be used as the basis for negotiations.
Technical, legal and strategic elements have to be brought together in order to come to an agreement and resolve the conflict early and with the least possible damage. Likewise, these elements are required if the dispute enters its later stages and evolves towards a settlement or even litigation.
In my experience the situation has often already too far progressed when the technical and legal elements are first placed side by side. Even in the early stages of a software project, irrespective of an impending conflict, there are certain do's and don'ts for the project staff. Likewise, the legal departement is usually not able to detect relevant technical information when needed in the heap of nitty gritty technical details. An added challenge is effective communication between people with technical and legal backgrounds.
Software project audit
A software audit is conducted together with the relevant and available people. This is a mostly technical exercise with the purpose of analysing facts and figures about the software and the project.
Depending on the situation the following is assessed if available: the source code and its version history (e.g. Git); user stories, issues and bugs (e.g. Jira); infrastructure setup and code; management of (open source) third-party libraries; architecture and documentation; information security and technical and organisational measures; and so on.
These elements are both qualitatively and quantitatively analysed. For example, the source code is assessed with respect to its quality, but statistics are also collected about lines of code, development effort, commits per day, etc. Another example is user stories. These are reviewed with respect to their content, but numbers about lead time and cycle time also provide interesting insights.
Furthermore, the findings can be used to assess processes, people and responsibilities, in combination with a selection of interviews and observations.
Experience and references
In addition to the about section and the testimonials, I'd like to point out that I have assisted companies and other instances with the above for almost 20 years. See also the national registry for experts.
Some of my clients are not in the position to give a testimonial due to confidentiality, but if you'd like more references that are relevant to your situation don't hesitate to contact me.
Don't hesitate to give me a call (or book a call) if you have any questions. We can discuss approach, timing and a cost estimate, without any obligations. And if I cannot help you, I probably know someone who can.