It is not controversial to say that we live in a world where technology moves at a rapid pace. This is even more so with software. Even when we think of stable apps and infrastructure updates are constantly being pushed to our devices. Rarely has the promise of “done and dusted” been so qualified. The same general principle applies when developing bespoke software. Because of this there is a need, even in a project where there is a set parameter, to have some flexibility. If this is not provided for contractually, time and money can be wasted in unnecessary amending of contracts and may lead to commercial uncertainty. In this article, we will briefly set out how Full Stack deals with this issue through the use of development framework agreements.

What's in a name?

In traditional contracting there can often be a set scope and price, and unless provisions have been made for such changes, it will require an amendment of the commercial terms between the parties. This can make for a messy contract due to multiple pieces of paper and a need to cross-reference what has changed and what remains. It may also lead to a situation of uncertainty, especially if the amendments were not executed in the same manner as the original contract and there is a dispute about what was supposed to happen.

A good software development framework agreement is essentially what it says it is, namely an agreement that acts as a framework for software development. It recognises that there are unknowns when developing a software solution, or that the demands of the client may change as the project progresses. In a framework agreement the commercial aspects of the relationships are settled and a parameter for service delivery and pricing is provided. This would include provisions relating to the following:

• A method for dealing with minor changes to an existing project.

This is important because even in a so-called ‘fixed scope’ project there will be things that change.

• A method for dealing with ad hoc work that isn’t formally contracted for.

Whereas we don’t recommend doing anything without certainty, sometimes people just like to wing it, and in such cases everyone should know what the implications of this would be so nobody ends up surprised.

• How and when payments are made.
• How software is tested and deliverables are accepted, and what occurs when they are not acceptable.
• How we deal with your information.

POPIA is a thing, after all, and so we must be mindful of data, how it is processed and how best to protect it – but more on that in a future article, maybe! Our contracts cover these aspects, and would also have provisions relating to how we maintain your confidentiality in general.

• What warranty we give on our services, what it covers, and for how long.
• How we manage the creation and ownership of Intellectual Property Rights

The ownership or rights related to software can be quite complex. For more on this topic, feel free to read an article about this here[PK1] .

• What do to in the event where things go wrong

A sad reality about relationships (including commercial ones) is that they sometimes end. This doesn’t always have to be painful, and so having rules governing these aspects also makes things somewhat easier.

The above provisions are nothing revolutionary, and any good service agreement relating to software development will cover them and more. Where the framework agreement differs from a singular development agreement is that the specifics of a particular project is set out in a separate scope of work that serves as an annexure to the contract. Within this Annexure, the following aspects will then be covered:

• A high-level description of the work to be done.

This is important in order to frame the expectation and succinctly set out what the parties have agreed to.

• How long the project is expected to take.

It’s important to manage expectation around how long things take, and this can be set out in a scope of work. However, one must bear in mind that it might not always be that easy to make such a determination. A duration could be set for a specific date or event, so it can be either fixed or flexible.

• In what manner the services will be rendered.

At Full Stack, we generally have three main methods of rendering services to a client.

The first, and most traditional, is agreeing to a fixed project scope at a fixed price. Whereas this creates some certainty from a scope and budgetary point of view, it can be quite inflexible and does not take into account that changes can and likely will occur. By having this as an option within a more flexible framework, one can create certainty while still allowing for changes or additional aspects (which may be separate or related) to be added.

The second method is where a client buys a development pipeline with a fixed amount of resources at a set monthly rate. Whereas Full Stack helps to ensure these resources and ensure are fit for purpose, the client is able to dictate how they are used. We have found that this model of service delivery has become increasingly popular as it provides certainly for the client to spend a set monthly amount while allowing for the most flexibility in terms of what is ultimately done.

The final method is our agile development option. This option is best used for complex large-scale projects which will be developed over a long-term or ongoing basis. In such instances, parties agree to a broad description of a project before engaging in further detailed analysis to develop the relevant specifications and a roadmap for the project. This detailed analysis will then be broken down into specific tasks and assigned to self-contained development phase lasting a few weeks (commonly referred to as a ‘sprint’). At the end of each sprint, what has been done and what needs to still be completed is assessed and if need be changes are made to the project plan.

Something separate yet related to all the above is the need to have maintenance and support of software to ensure it continues to optimally function over time. This is also something which can easily be provided for as an additional annexure within a development framework agreement.

Naturally, it can be possible for us to have a variety of projects with a single client, or for the nature of the commercial relationship to change over the years. An added benefit to this means of contracting is that one single agreement effectively tells the entire story of the commercial relationship between Full Stack and a client, making it easier to see how things have evolved over time.

At Full Stack, we have developed templates for both the framework agreement and the various scopes of work based on how we do traditionally operate. However, we wouldn’t be practicing what we preach if we weren’t flexible, so if you have a particular method or idea of how you would like to do things, we are always willing to negotiate if it makes sense to do so, so please don’t hesitate to reach out so we can discuss this.

Pieter Koornhof is the Company Secretary and Legal Officer of Full Stack. He holds a variety of qualifications in law, economics and education, including a doctorate on the regulation of internet monopolies. He is also a World Intellectual Property Organisation recognised expert on matters of software, IP and competition, and digital entertainment.