Agile Development: Litigation Risks for Contractors and Practical Precautions (Part 3 — Kickoff)
Jul 04, 2025UP!
1. Agreement on the Development Structure
What becomes crucial is the clear designation of who will take responsibility and how reporting lines are defined. This directly determines the weight of accountability on the contractor. Without clear agreements on these points, the development process will likely lead to an increase in disputes where stakeholders claim, “I was never informed.”
Such claims can be especially problematic when they come from the Product Owner. If a Product Owner says they were not informed, it can quickly escalate into a serious conflict between the user and the contractor.
In many cases, users delegate oversight to other vendors, making it easy for them to say, “Ask them,” later. This is a trap: it gives them an excuse to later claim ignorance. Other vendors may present themselves as cooperative partners to the user but often do not want to exert control over the development contractor — they care only about delivering their own scope of work.
When the Product Owner tells you to route information through another vendor, there is a real risk you will be abandoned later. For example, even if you report issues to that vendor, they may fail to pass the information on to the owner — or worse, they may selectively share only negative updates to manipulate the perception of your performance.
A company responsible for the basic design may coordinate schedules and provide the user with a clear plan, increasing transparency. But in some cases, the same company may exploit information asymmetries and act as the exclusive channel for user communications. This enables them to selectively share information to protect themselves, make good impressions in meetings, and shift difficult tasks onto you — all while avoiding conflicts themselves. If delays occur, they may blame other parties to avoid liability.
In practice, the kickoff meeting often defines the actual balance of power and rights among parties. If the contractual terms do not align with how the work is operationalized, they may lose practical weight. This is why focusing solely on the contract is dangerous — operational realities matter.
One key practical point: the more proactively you present detailed plans, the more responsibility you may be forced to bear later. Therefore, providing detailed plans must be done strategically, not blindly.
Instead, ensure that the balance of power and responsibilities are documented. Meeting minutes and, in some cases, video recordings should clearly show what was discussed and agreed upon. This transparency helps prevent later disputes.
Companies involved in the basic design often have more influence because they are closer to the user. Blindly following their direction or leaving issues vague may result in you taking on responsibility for failures down the line.
If a party with manipulative tendencies is involved — what one might call a “corporate psychopath” — the risk of escalation increases. Preparing protective measures in advance can be invaluable in litigation.
For example, when dealing with stakeholders who frequently fail to follow through, ensure that you get their acknowledgment of your reports and confirm next steps in writing. If the client demands unrealistic deliverables or timelines, politely note in writing that, based on available resources, the scope is not feasible, and request alternatives or additional support. This type of record — including the emotional tone and the context of the exchange — can be highly relevant evidence in court. In litigation, the outcome can hinge on what you prepared beforehand.
2. Scheduling Considerations
Team members who are overly timid or frequently absent should never be assigned as managers or schedulers. If a Product Manager pressures them and they become intimidated, internal staff can become mentally overwhelmed.
One useful analogy is how navigation systems in cars have evolved. Older systems created unrealistic expectations by recalculating arrival times wildly when you made small changes, creating undue stress for drivers. Modern systems adjust expected arrival times incrementally, which helps manage expectations. Similarly, in project management, you should make work volumes and their impact on schedules and costs visible, share this evidence, and negotiate adjustments. Repeating this cycle helps prevent escalation.
It’s inevitable that some issues will be overlooked in the total product lifecycle. The critical question is who will bear responsibility for these oversights. Unfortunately, those in weaker positions tend to take the blame. To mitigate this, meeting minutes should document statements like, “The responsible party stated the following…,” and record if someone explicitly stated that further investigation was needed, specifying the time required for that work. Later, note any omissions found and make it clear there may be others — this helps protect you.
At the kickoff, it is essential to clarify who will handle testing and the related specifications. If testing specifications are finalized only at the last minute, it must be communicated upfront that implementing them may take 30 days or more, and unanticipated problems are likely.
Judges often compare software development to construction work, assuming standard templates like buildings or roads exist. This is a misconception — software requires iterative development and must accommodate rework. There is a significant disconnect between the intuitive understanding of judges and that of engineers. Therefore, do not assume that “a judge will understand if you just explain it verbally.” It is far better to document these points clearly. In fact, generative tools like GPT can often produce clearer, more neutral records than engineers themselves.
It is vital to define scope, hours, and costs transparently and to foster mutual understanding even after the contract is signed. Project managers and developers should ideally be separate roles. Project managers must avoid pushing developers too hard — instead, they should build in buffers and ensure mental well-being. Otherwise, you risk creating unsustainable pressure that will backfire.
Project managers should act as buffer resources, ready to step in as needed. If the user fails to deliver inputs on time, the manager must firmly address this and secure agreement on schedule extensions. Beware: the company responsible for basic design may act like a de facto Product Manager, intentionally delaying tasks to shift blame to you later. Vigilance is essential.
Finally, do not rely solely on internal product logs — provide written notices to stakeholders to ensure a documented record of delays or issues. Some may argue that being overly cautious will damage the client relationship, but if you end up in court, that relationship will be damaged anyway. It is far more cost-effective to address these issues proactively through firm yet balanced negotiation to avoid litigation altogether.
You are welcome to contact us via the Contact Form to discuss and for more information.
