Contingency explained to our customers
This post was initially published during April 2018 on medium.com and i-logs blog.
Introduction
At i-Logs, we help companies building digital applications, mostly consumer facing, APIs or B2B software and websites. That means we assist our clients with product architecture, product development, project management, technical sourcing and strategic planning. We have a small, agile team dedicated to custom Web application development (Hi Team!). We are not a communication agency, we don’t build presentational website, we don’t hire Photoshop pro, we don’t define marketing funnels. Our team is made of software engineers, systems engineers and UX/UI specialists. Our daily job includes working with wireframes, databases (SQL and NoSQL), PHP (Yii Framework, Drupal, Symphony, …), Javascript (Pure Javascript, JQuery, Angular and AJAX mainly), CSS/HTML (Bootstrap, Material Design, …), APIs, XML, JSON and other technologies more backend oriented.
When a customer wants to hire our services, once the specs are known and once the strategic planning is done we usually provide a quote for the development of the project. These quotes are mainly elaborated on workload estimate. What we do is quite simple: breakdown the tasks, estimate the workload in terms of weeks, days and hours for each task and then apply a specific pricing related to the kind of task. By the end of the quote, we usually charge for what looks like to be an arbitrary duration which can range between 10% to 20% of the total estimated time and that we call the contingency period.
This period is undoubtedly the least understood and the most disputed part of our quotes. By writing this post, we wish:
- to bring some explanations about why we charge for it and why this is a real competitive advantage that we offer to our customers in a win-win situation.
- to inspire others which may have the same workflow than ours (be it in Software development or any other domain).
Workload estimates
First of all, we know selling custom software solution based on estimates is far from being optimal and presents many risks. Unfortunately, in the context that brings us together, there is no better way to work than on the basis of these estimates. It is therefore advisable to proceed like this.
The good news is that the customer knows exactly what they are paying for. Indeed, all our offers have a fixed price, no hidden fees. By sticking to the specifications, the client is guaranteed to know perfectly his budget at the beginning of the project. In addition, we offer at no additional cost support for acceptance tests and a one-month operation guarantee after the application has gone into production. What does this mean concretely? This means that we continue to be mobilized for approximately 60 days after delivery to the validation server.
In this context, what are the meaning and the purpose of charging contingency to our customers?
Contingency acts like an insurance. Contingency appears in our offers to cover the various risks related to the procedure described above. In detailing the list of these risks, we hope to convince you that in reality you wish to benefit from this insurance.
There are 3 major risks that are related to 3 key stages of the project: when writing the software specifications, when estimating the workload during the preparation of a offer and, finally, when developing the solution. Let’s review the risks associated with these 3 phases.
Risks in specifications
The risk lies in the fact that, as precise as the specifications and the business requirements are, there is always something that has not been thought about or thought poorly.
We have agreed on wireframes and functional specification to make an offer that best meets your needs. Nevertheless, when you have the application in hand, you will realize that you want such a picture a little larger, or that it would be better to replace the red ribbon with a blue one, … Our (almost) 10 years of business experience have shown us that this situation is inevitable.
Without contingency, we would have to either refuse these small requests, or to issue further bills to cover them. In these conditions, it is almost impossible for you to know accurately either what your application will look like or how much it will cost you.
On the other hand, thanks to contingency we can afford some form of flexibility. Of course, there is no question that the contingency covers features that are not described in the specifications but it allows to accommodate the features that are included to your advantage. As such, this insurance is the guarantee of a certain flexibility during the development period so that you get the solution you really need without being held by a too small budget.
Risks in estimates
The risk lies in the fact that estimates are not an exact science. Even if we are professionals and we know our job. sometimes we overestimate a load, sometimes we underestimate it. Unfortunately, this can not be known in advance. In practice, both occur.
The contingency in this context acts as an additional motivation of our team: the better we work, the faster we deliver for the benefit of both parties. Contingency therefore represents for you the guarantee of our efficiency and our professionalism.
Risks during the development period
The risk lies in the fact that software development is not an exact science either.
Let’s imagine in an ideal world in which we would deliver a bug-free software that would meet 100% of our client’s expectations, as soon as the sources are delivered to validation server. You can find this perspective quite shocking: here we are taking 20% of the price for nothing!
In fact, this means that we have worked perfectly and in this situation, everyone is a winner: acceptance tests can be carried out without delay and without interruption, the time between the start of the project and the delivery to production. is reduced and, once in production, users are not impacted by malfunctions, the customer does not wait for additional deliveries that eventually allow the application to work as expected …
Created by GraphiqaStock — Freepik.com
The reality is of course different. As meticulous as the team that prepares the software is, acceptance tests carried out seriously will highlight existing bugs and they will have to be fixed. The corrections are done at our expense during the validation period and during the warranty period.
As you can see, the work is far from stopping when the solution is delivered to the validation instance. From this perspective, contingency is for us a constraint on the quality of the code we provide. And this is again a big advantage for our customer.
Conclusion
Contingency is a way to balance the risks related to a software development project between the project owner (us) and the business owner (the client). A serious contingency provides several guarantees which are essentials in the development and the exploitation of a custom software and participate undeniably to the project’s success.
How do you deal with this kind of question or situation with your customers? Do you charge for contingency? How do you justify it? Please share your own experience in the comments below. We would be delighted to here from you.