Outsourcing work approaches: Fixed contract per project

The fixed contract approach is arguably the most secure, predictable option for outsourcing your IT project. Alas, it’s probably the most fastidious and rigid too. What are the reasons for this strange dichotomy?

First off, a brief history lesson. The "fixed" approach to project outsourcing originated from the “waterfall” model for software development, which was first mentioned in 1956 and formally described in 1970. This was ages ago, when transistors first replaced vacuum tubes in computers, followed by integrated circuits replacing transistors. Amazingly, the waterfall approach lasted into the 90s because software development cycles were gigantic — programs were distributed on floppy disks (for example, Microsoft Office 95 was distributed on two 3½-inch floppy disks requiring only 55 MB of hard disk space, whereas Microsoft Office 2010 is 708 MB in size and requires 3 GB — a 55x increase!), and user feedback took months to deliver. Consequently, each new release needed to be perfectly tested. It's a good thing there were only three operating systems in widespread use at the time, and that they were updated once every two to three years, so compatibility was rarely a problem. Also, back then it was understood that users would access your website via a PC + browser, and not with one of the hundreds of unknown, unnamed mobile devices we see today.

Nowadays the tempo of software development and release has increased exponentially, and today’s entrepreneurs aren’t keen on investing in "big design upfront" without confidence of success among users. Today’s developers prefer to act more accurately and iteratively, sounding out users’ impressions and flexibly changing the development direction according to user feedback and analytics data, all the while monitoring the business’s essential metrics. Since user feedback is now instantaneous, one cannot restart the full "fixed-fee" model’s cycle after each round of feedback. There’s zero interest in creating a detailed specification document, inviting tenders, requesting a fixed proposal from a pool of providers, and getting lost in months (or years) of "black box" development as was done in the Dark Ages, when nothing could be changed on the go.

Well, we’ve certainly made the fixed approach sound obsolete and sluggish — but is it really that bad? Actually, it’s not. To be honest, there are two scenarios where projects can benefit from the fixed (“flat fee”) approach.

1. The first scenario concerns a project that is extremely well-documented, contains no integration with third-party APIs, and doesn’t use third-party code (code created by another development team). All functionality (both end-user and administrator) is described, and no scope-changing will happen. Projects of this type are often small, or can be divided into small independent, integral parts that are comprehensively documented in their turn. This scenario occurs when it's absolutely crucial for the customer to define each and every requirement upfront, and when the development team has the opportunity to foresee all risks and tricky spots.

   If the opposite scenario occurs, and a customer gets a flat-fee proposal for a project with undefined or unclear requirements, and where there is no comprehensive description of functionality for every interface, and the software being planned is supposed to use third-party APIs and/or be integrated with third-party services, then one of two things will happen: either the customer will pay more than they initially wanted to because the provider will provide a blanket estimate that covers all possible risks, or the provider will ask for more money during development because the risks haven’t been included in the budget.

   A common question is, "I’ve found a provider who quoted a flat fee for my complex and undefined project. Why shouldn’t I agree to their proposal? They’re agreeing to complete my project for a fixed budget within the defined timeframe. Even if something goes wrong, I won’t pay more than agreed." This situation frequently arises in small to medium-sized projects. So what happens next? Most likely, the provider will ask a lot of clarifying questions and the customer will have to give extensive feedback to every version released. This feedback will trigger what’s known as "scope changes", "scope extension" or "new feature requests", which are always followed by an increased amount of development work. The provider will either ask for more money due to the "scope extension", or assume the risk on its side. In the first case, the customer has the legal right to refuse to pay anything more than the "flat fee" contract stipulates. But do you think the project will still be successful if relations cool and one of the two involved parties suddenly loses interest in the project?

   The lesson is this: you should only consider a fixed-fee approach if you know precisely what you want to develop and if you can put it into words for specification documentation.

2. The second scenario is less troublesome, and occurs when the development team is already acquainted with the software being improved or updated, or with the customer’s business itself (in case of new software creation). Also, the development team created the initial code (relevant if the software is being improved/updated) and/or knows the peculiarities of the customer’s business, i.e. software solutions and hardware already in use, and the personnel’s education level and working habits. One more indispensable condition for success in this case is the use of a “fixed price and scope for iteration” approach. This means that the project will succeed if the development team is acquainted with the system and the customer’s business, and if both parties agree to proceed on fixed tangible iterations.

   The possible variation for this case is to consider the “fixed contract” approach only after the development team creates a working prototype of the system on unfixed terms. This allows the development team to “feel” the system, find the incompletely described tasks in the specification documentation, request scope clarification from the customer, programmatically realize some of the third-party integration, and thus foresee and calculate risks.

   The term “risk” has a broad meaning here. It’s not only about undefined scope and third-party involvement. The customer and provider should also consider “risks” such as:

   • The ability to establish efficient communication between parties
   • The presence of relevant technical and industry experience
   • Schedule changes during the holidays or when a team member is sick
   • Changes in industry-specific standards and/or best practices
   • The presence of implied (and therefore unspoken) features and functionality
   • The failure to correctly prioritize tasks

In a nutshell, a suitable project for a fixed-fee approach is one in which all possible risks have been considered and visualized. At Sibers, we’re open to this kind of work approach and we can quickly recognize whether a project is suitable or unsuitable for a flat-fee arrangement. The Sibers team has successfully realized many fixed-contract projects, adeptly meeting the customer’s objectives while anticipating any risks that may appear.