Subcontracting an innovative project is no easy task. For a start, any piece of innovation brings its share of uncertainties. So when you also have to ensure that the budget and the deadline are respected but also find the right
Subcontracting an innovative project is no easy task. For a start, any piece of innovation brings its share of uncertainties. So when you also have to ensure that the budget and the deadline are respected but also find the right
Subcontracting an innovative project is no easy task. For a start, any piece of innovation brings its share of uncertainties. So when you also have to ensure that the budget and the deadline are respected but also find the right service provider, the one who will be able to carry out the project successfully and whom you can trust, the equation becomes complex.
How can we be sure that our deadlines and budget will be protected? Are there methods that allow us to secure these two elements? Should we choose between innovation and security (budget, deadlines and specifications respected)? Can a contract provide for everything?
Some contracts contain the keys to these sensitive issues. Yes, it is quite possible to innovate while controlling the budget and the deadline. No, fixed-price and time-and-material contracts are not the right answer in 100% of cases.
So, what are the key points for making the best choice of contract with your partner? In this article, you will discover the keys to help you succeed in outsourcing your project!
The first of the essential elements to be found in your contract with the engineering company is the dynamics of your collaboration. How can you be sure that your service provider will listen?
The classic fixed-price contract give you a say right up until the signing of the contract. You define your expectations in the most detailed specifications possible, and the engineering company develops what is written there, as planned, on the scheduled date. This is a reassuring contract for the client.
With a fixed-price contract, when everything goes well… Well, everything goes well. Congratulations! But what if something goes wrong?
With this type of contract, there is no room to change our mind. If the practical turns out to be different from the theory, your new needs will have to wait until another contractual agreement is signed (amendment, renegotiations, delays and additional costs). Here the supplier is legally obliged to fulfil the contract as signed.
The penalties for deviating from the specifications could be heavy for them. So, once the commitment has been signed, there is little room for real exchange, co-construction, collaboration between you and the technical experts, or a possible change of direction; this could impact your innovation ambitions since we are sticking to the content of the contract here.
The service provider will not really be motivated to innovate or to go further than what is written in the contract. They wants to guarantee the client’s margin. Instead, they will put himself in a position to secure the budget and the deadline as much as possible by meeting the specifications. This scenario is not conducive to innovation.
Another type of traditional contract that puts the client in the cockpit. Piloting your project is a nice idea to make sure you don’t stray off the road. This type of contract makes sense in the following situations:
However, when you use an expert workforce, it is usually to benefit from their technical advice. In fact, while the management contract offers you the guarantee that the engineering company will do what you want, you will benefit from their expertise but not, once again, from their ability to innovate. Indeed, the team will theoretically only have to carry out your orders. It will not be there to make suggestions and think outside the box.
This is not a collaboration in the strict sense of the word, but rather the occasional hiring of a competent workforce or the occasional expansion of a team, when there are no plans to hire in the long term. This is known as capacity supplementation. This type of contract may be perfectly suitable for a client who is an expert themselves, who knows exactly where they is going and who wishes to expand their team from time to time. On the other hand, this type of commitment is not suitable for a multi-trade context.
The Agile contract is designed to be flexible. With this model, it is you, as the client, giving the instructions on what your product is to achieve, with a defined cost and timeframe (more details in the video below).
While securing time and budget, this contract gives the project the possibility to move, if needed. The primary purpose of the product remains the project objective. It is together that you determine the objectives of your project, by prioritising each functionality. It is this prioritisation work that will maximise the added value of your product. It’s also useful for teams to know what to focus on.
This contract puts the collaboration between you and your engineering company at the centre of the project.
How can the scope of the project change?
It can change according to progress, according to certain difficulties encountered. It is this flexibility that will allow the engineering company, with all its expertise, to offer you the appropriate technical solutions for the realisation of your product. The choice not to be constrained by specifications gives the project a better chance of success. You remain present throughout the development of the project, you approve them and thus the project is built hand in hand.
This is the method that best combines innovation and collaboration.
Of course, the question of budget is key. When you sign your contract, you should feel comfortable knowing how much it will cost. But what if something unexpected happens? What if my budget is exceeded? Who is responsible, me or the engineering company?
On paper, the fixed-price commitment is very safe.
After consulting several service providers, you find the right one. It is the one who, for the fixed sum of – say – €200,000, will deliver to you, in 10 months’ time, the connected object that you and your team have described in the specifications. It’s written in black and white. Nothing could be simpler. No possible financial deviations, otherwise the service provider will be responsible for it.
Phew. Now you are reassured.
That’s why many clients choose this type of contract. Guaranteed results, within budget and on time, responsibilities transferred to the service provider… That’s all we want! Moreover, it is a model that everyone knows. So most service companies will offer it directly to you. This makes it even more convenient because it will allow you to compare a large number of offers on the same basis. You can find your way around. Very good!
The project starts and suddenly the service company is at a dead end. The key component of your connected product is out of stock at all distributors and resellers. Ouch! Because not only the design of your object but also some of its functionalities depended on this component.
You say to yourself: I signed a fixed-price contract. This unforeseen event is therefore the problem of the service provider. We’re not going to change the contract to revisit the specifications (with new negotiations, price changes and deadlines). So, see you on 25 September with my deliverables all in order, thank you.
Is this likely?
No, you are right. The truth is that your service provider will try to keep to the budget. More concessions will be made. To do this, they will find a solution, probably less advantageous, but which will not make them lose money. You will then end up with a product with potentially compromised functionality. In the end, if you want to be satisfied with your product, you will have to put money back into your project to get your product back on track and to do that you will have to exceed your initial budget (the €200,000 already invested in the contract).
A fixed-price contract can work well. This may be the case when developing a new version of an existing product, for example. When there is little innovation, there is little room for error. On the other hand, for innovative projects, there is too much uncertainty and it is difficult to assess. It is an illusion to believe that one can know all the tasks to be carried out when trying to innovate and therefore be able to put a fixed figure on them. People always underestimate the complexity of a project, whether in terms of time or resources. This is what Hofstadter’s law says: “It always takes longer than expected, even taking Hofstadter’s law into account.” In this case, this type of contract can quickly take you out of budget.
The fixed-price is quite suitable for predictable projects but is not really conducive to innovation, therefore.
In a technical assistance contract, the customer rents the skills of an expert workforce to create their connected object. This labour is valued per day. This is called the ADR (average daily rate).
You still have your €200,000. You contact different engineering companies, who tell you that they can complete your project with a TA contract, in 10 months, and that their Average Daily Rate is “so many” euros per day.
You calculate :
(The number of days the company needs to create your product) X (Their ADR) = your budget)
It’s easy to compare, just look at the ADR.
Not bad, you think. In the least amount of time possible, you hope to create the best possible product with this expert workforce. A good plan!
However, it can sometimes be difficult to compare offers because an ADR does not expose the performance of the provider. Also, there can be big differences between two engineers.
In TA, there is no guarantee of results and you have to pay for delays
However, if the reality on the ground differs from the theory, your wallet could suffer heavy losses. And this time, the costs are borne directly by you, unlike the fixed-price. Your service provider must provide you with the means to create your object, but here there is no guarantee of results. So, if something goes wrong, you have to go above you budget until your problem is solved. Otherwise, no functional product.
Another inconvenience is that at such times, stress tends to affect everyone: the client who is managing the project and who will tend to enter into a micro-management phase will have a counter-productive effect on the teams, and will also ultimately impact the development of the project.
So, in the event of a setback, there is a double negative impact with this type of contract: you are going to spend more for a project that is unsound.
This type of contract can also work well. However, it is more suitable when the project does not particularly call for innovation. On the other hand, it is useful when you need technical reinforcement in a field that you master. It is therefore for connoisseurs and well-trained project managers, who will be able to deal with all the unexpected events (technical, planning, administrative). It is also suitable for discovery purposes on a specific subject, which you do not master, but on which you need reinforcement for a given period.
So what is the best type of contract to guarantee innovation and maintain the productivity of the service provider?
The Agile method has been designed to try to overcome the limitations of traditional models. In fact, to remedy the unexpected, there are different types of contracts that offer several budgetary solutions, such as “50%-50%” or “Stop or else”. Unlike the TA or fixed-price, the client and the service company always remain in a “win-win” dynamic. This mode of engagement makes it possible to break away from the subordinate relationship and aligns the interests of both parties. This encourages productivity. And that’s good for your product and your budget.
Wondering what an Agile contract looks like in detail?
Here are some free templates made with the help of Bold.
Instead of starting with something fixed which, as we saw earlier, is not well suited to IoT projects, Agile contracts create flexibility. As the budget is linked to deadlines, let’s talk about deadlines.
Operational focusAn Agile contract works by iterations. What does this mean? The client and the engineering company will collaborate over several short periods of 2 to 4 weeks, called sprints, at the end of which the client will systematically obtain a deliverable. Each sprint serves to advance the development of the product’s functionalities, according to the priorities defined beforehand. At the end of the sprint, the service provider reviews the product with the client to validate it and move on to the next phase. The deadlines are short and therefore easy to meet. |
When you manage the budget over short cycles, it is also easier to arbitrate on which features to develop more or less. In general, the engineering company estimates a fixed amount per sprint in advance. Therefore, you avoid unpleasant surprises and know what to expect for each sprint. As a result, you are able to stop: when you have reached your budget – even if there is no guarantee that it will be completed. Overruns are thus limited, or they are binding on both parties.
The risks of this happening are reduced compared to a fixed-price or TA contract (but of course not zero). This is because you are present during the development of the project and your interests and those of your provider are aligned. It is this balance that will enable the right choices to be made in a co-construction dynamic. Even if there are unforeseen circumstances, these are managed with your agreement.
Remember that there is no budget overrun since you can stop the collaboration at the end of each sprint. And the aim is always to deliver a deliverable with which you can leave. If there is dissatisfaction, there are easier ways out. This limits the risk of drifting off course, unlike with other types of contracts.
For all clients who are looking to venture into innovation while maintaining guarantees on time and budget, and for whom the scope may change.
But let’s talk about it in more detail…
Another essential point of the contract is the definition of your expectations. What is the difference between executing a specification and innovating? Can you get a functional product with a controlled budget and deadline and innovate at the same time?
Is there a format that can combine innovation and the management of deadlines and budget?
In traditional contracts, we talk about “scope” to define what the client wants. This scope describes, in a specification, the functionalities that will enable the creation of the connected object you have imagined.
There are two types of specifications: the extremely detailed version, which contains a list of technical details and specifications, precise in their operation and implementation, which should theoretically serve you.
The second, a somewhat more vague version, because the client is less certain of their needs, especially in technical terms. This is what happens when you move from theory to practical:
So what can be done?
One can play with the constraints of the scope in the contractual agreement, but again, the legal value of what has been laid down on paper can be a brake on the creation of an innovative product. This is why Agile types of contracts change the game and make it possible to secure innovation by protecting deadlines and the budget.
Sure, you have a specific product idea in mind.So why can’t your service company just make
it happen?
Often the reality turns out to be different from what was expected. So from the very beginning of the crea
tion of connected projects, the question was raised as to why a fixed-price model with fixed specifications, budget and deadlines should be
applied, which are perfectly suited to construction projects (such as bridges and buildings), but less so to IT. Numerous studies have shown that these traditional contracts rarely result in a viable product, and at the cost of significant time and budget overruns, but with less functionality ordered by the client. Very few were considered successful
Subsequently, Agile contracts emerged.
To remedy the situation, these contracts put usage back at the heart of the commitment. Together, by mutual agreement, you will decide on the development of this product. This means that you no longer have to implement a specification, but instead focus on developing features that are useful to the end user and therefore to you. This means that the service provider does not promise to create a product with 1001 specifications, but rather to make a functional product. At the start of each sprint, you receive a deliverable and debrief the past sprint. It is thanks to this intermediate validation that the product will have the best chance of success.
The final product, born of an Agile contract, must be able to be used as is by the client at the end of the period indicated in the contract, without having to refurbish it, or reinvest. The budget is defined at the outset. It is a fixed amount for each sprint. However, it is important to be clear that not everything will be done in this development. From the beginning, the choice will be madeon the key functionalities of the product in correspondence to the allocated budget.
This type of contract is therefore not at all suitable for a structure that wants to see every single feature completed.
This type of contract is designed for an organisation that wants to control the time and budget for the development of this product.
Agile contracts have arrived on the market more recently than fixed-price or TA engagements. Do you have any fears? Some preconceptions? That’s normal! They are less well known, so how can you tell the real from the fake?
FALSE – The contract must detail the development and acceptance process of the project. In order to move forward quickly, a defined and fairly short time frame will allow the client to accept the deliverable. It will also limit the duration in time to allow for modifications. The shorter the time frame, the better the teams can move forward for the next development sprints.
A kick-off meeting is held to define the objectives to be achieved by mutual agreement. It is this meeting that will make it possible to define in each sprint how to achieve the objective.
These parameters are different from traditional contracts but are nonetheless written in black and white. This also makes it possible to check that the service provider, who calls himself “Agile”, really knows what he is talking about. Run away if THEY cannot explain their methods precisely.
TRUE & FALSE – There is never an obligation to draw up a contract in the context of a collaboration. On the other hand, if nothing is done to lay the foundations of the relationship (the successes as well as the disappointments), it can become dangerous for both parties. This will also avoid misunderstandings about each other’s expectations.
STRONGLY TRUE – Agile practitioners say it themselves, if you try to compare (although the basis is different) a fixed-price or a managed contract to an Agile one, the prices will often be higher. You can try to reduce your sprint to an ADR to do this. However, as said before, the chances of success are greater in an Agile contract that aims for better collaboration. It secures innovation and leaves a lot of autonomy to the provider team while co-developing with the client and guaranteeing the delivery of a functional product. In order to make a fair comparison between all types of contracts, it would be ideal to calculate the contingency, the overruns in fixed-price and technical assistance and also the result obtained.
You are now familiar with the different types of commitments and contracts. You now understand that fixed-price or time and materials are not the answer in 100% of cases. And above all, you know that it is possible to innovate while securing your budget and your deadline. In short, you have all the keys to maximise your project’s chances of success!
Un peu de lecture
Des articles, des podcasts, des webinars… et surtout des conseils pratiques ! En bref, une collection de ressources pour mener à bien votre projet.
