This article, the second in a series on avoiding IT project failures, delves into the legal frameworks crucial for IT contract [1] execution, such as specifications, quality assurance plans (QAP), and delay penalties.

Often, operational staff may perceive these legal tools as a means for clients to exert undue pressure on service providers. However, such a perspective can overlook the collaborative essence vital to IT project success. Moreover, the actual contract in play often differs from the original concept [2].

We advocate for the strategic use of legal tools to foresee and adapt to potential disruptions in fulfilling obligations, rather than rigidly binding parties.

Some argue that flexible performance clauses invite chaos and undermine project success. We believe this view is outdated. Transparency and acknowledging project realities should guide such initiatives.

Reframing these tools allows clients to tailor projects to their specific contexts, armed with mechanisms to preempt failure. This approach often transcends the limitations of inflexible contracts.

Here, we present practical tools that balance the client's need for rigidity with the service provider's preference for flexibility, focusing on three fundamental IT project aspects: needs, timelines, and costs [3].

1. Best practices and legal tools for evolving customer needs

Challenges arise when customers believe they have fully articulated their needs, only to find the final product misaligned with their expectations. Conversely, service providers might perceive customer dissatisfaction despite diligent work.

This disconnect can derail IT projects. Often, a few months into the project, it's discovered that customer needs were inadequately expressed. This could be seen as a fault of the service provider[4] or an oversight by the customer[5]. In either case, unclear goals can lead to endless project revisions.

Tools to anticipate these risks include:

• Specifications: Crucial for avoiding surprises at system acceptance. For projects exceeding 1,500 man-days, additional documentation is essential.
• Documentation and Process Documentation: Specific documents, such as existing management rules, are necessary alongside specifications.
• User Involvement: Users should participate in all project phases, from pre-sales to acceptance, ensuring their needs are accurately represented and validated[7].

2. Legal tools for flexible timelines

While project timelines are inherently tied to scope and budget, a rigid timetable can be counterproductive. A transparent yet adaptable schedule, subject to changes in original parameters, is more practical.

For setting realistic timelines, a collaborative discussion between parties is essential. The schedule must account for both parties' corporate cultures and constraints, detailed in appendices like a PERT chart[11].

3. Legal tools for budget flexibility

Project scoping is crucial for accurate cost estimation. We recommend:

• A Scoping Phase: This allows for a budget discussion post-scoping, with an option for parties to withdraw if no agreement is reached.
• Capped Fee Structure: This structure prompts discussion and includes an uncertainty index for justified cost adjustments[13].
• Transparent Cost Determination: Collaboratively determine costs with the customer, detailing the methods used in the contract.

4. Preparing a quality assurance plan (QAP)

The QAP is central to project management, outlining:

• Project committees and their roles.
• Documentation management.
• Change management.
• Roles and responsibilities (RACI).
• Monitoring indicators.
• Project phase definitions and deliverable acceptance.

It's a contract in itself and should be drafted with legal oversight for clear, transparent project management.

Conclusion

Balancing rigidity with flexibility in IT projects is crucial. This balance hinges on collaboration and transparency between the customer and service provider. Both parties must engage actively in the project, sharing fundamental information for informed decision-making.

These tools—requirements documents, change management processes, adaptable schedules, and collaboratively defined equations for deadlines or budgets—are essential for legal certainty.

Upcoming in our series on avoiding IT project failure:

• #3 Contract management strategies.
• #4 Agile methodology for customer collaboration.
• #5 Tools for litigation avoidance.
• #6 Litigation conduct.
• #7 Types of expertise.

For any inquiries, please contact us.

[1] By 'contract', we refer to the comprehensive agreement including its often numerous annexes in IT contracts, encompassing Quality Assurance Plans (QAP), Security Assurance Plans (SAP), and Pricing.

[2] Le Tourneau, Philippe. "Digital Contracts: IT and Electronic." Eleventh Revised and Expanded Edition, updated to June 26, 2020. Dalloz Reference. Paris: Dalloz, 2020, §116.21, p. 144.

[3] Insights derived from A. Durand's work, "Mastering IT Project Management," Dunod, Paris, 2004.

[4] Grenoble, June 4, 2015, Case No. 11/01817.

[5] Paris, July 8, 1981, M. Claude B. vs. SARL Kienzie Informatique.

[6] This refers to a scenario without a service for redefining business processes, which in such cases would require new discussions between the provider and client to modify existing procedures. Existing processes might still be necessary, albeit to a lesser extent.

[7] It is important to consider all interfaces and migration within this framework if it is an integration project.

[8] This also applies to needs, which can be constrained by budget and duration. However, we believe that defining needs in a specification document before the initial contact with a provider means it should originate from the determination of timelines and budgets. Needs might be limited after this initial contact, but overly ambitious specifications are relatively rare.

[9] Refer to A. Durand's book, op. cit, p. 91, for more details.

[10] Costly, yet still a service.

[11] Program Evaluation and Review Technique.

[12] As mentioned above, a specification document alone is insufficient. Subsequent choices must be made by the client based on the specifics of the software or website they desire.

[13] This could be based on the anticipated volume of needs, current workload, etc.