Why are the costs and timelines for the software development contracts I’ve received so different?

To begin with, be wary of inflexible contracts. They are not Agile-friendly or conducive to a true Agile process which benefits both parties. Agile has been around long enough for organizations to adapt themselves to Agile workflows and get a hang of penning Agile contracts. Even so, when it comes time to enter into a contract that must embrace Agile work deliverables and processes, we still see the stamp of Waterfall language. Waterfall methodology and contracts that favor it, like the fixed-bid have been around long enough for us to see some patterns in the pricing and contracts. Even so, you’ll see a whole range of quotes for the same project. Barring geographical and economical differences that sway the budget, from the contracting side there is definitely more work to be done, to get a clearer break down of pricing and where the differences creep in. If we want to see contracts which are truly aligned with the interests of all parties involved, there are a few steps we need to take.

Every project comes with three variables: Money, Scope and Time.

To write an Agile contract, you must first determine which of the three variables you want to constrain. For truly practicing the Agile methodology, only a single variable must be fixed. The other two should be kept flexible. Otherwise, the contract won’t align with an iterative process. Sure, the development team on the ground can work in sprints, pair, practice test-driven development and do continuous deployment. But if the contract fixes more than one variable, the contract will not be able to align with Agile development.

If your biggest worry is “How much it cost me?” Then frame the same question in a different way, viewing cost as an investment. This will make the conversation and the work about value, not just about money. At other times, there might be a deadline approaching, like the end of the fiscal year or the holidays. Here, it makes more sense to fix the time variable. And in other cases, your scope might be quite defined, but keep both money and time flexible.

• If you choose to constrain money, the contract should read like a fixed budget contract. Here, you’re given an estimate close to the budget, with a commitment to not exceed that budget. When a project comes with a limited budget, one has to prioritize the features continuously. This helps maximize the return on investment by ensuring that the most important features are being given priority. Assisting your developers in figuring out the must-haves vs. the frills is integral since a fixed budget demands your team to stop building the moment they hit the budget, or choose to raise the budget together. It’s very important to keep an open dialogue here. Now keep in mind that “fixed budget” is not the same as “fixed price.” Often, the term fixed price is used to imply that both money and scope are fixed, which isn’t recommended. “Fixed-budget” doesn’t fix the scope, only the money.
• If you choose to constrain time, write the contract to have a fixed length. In this case, you still want to give a cost estimate and make it clear that the project will end on a certain date.
• If you choose to constrain scope, the contract should read to have a fixed scope. This kind of contract is the most difficult since it has to clearly specify the essential features and outcomes of the project that has to be delivered. In a project with fixed-scope, you must understand that both cost and time could increase to make sure the features agreed upon are delivered.
• If all parties involved cannot agree on fixing just one variable, you have to make a business decision. Basically, if you’re looking to fix both money and scope, you are asking for a fixed bid. Working on an Agile project within the constraints of a contract written for another type of methodology and trying to complete the project on time will make work for the development team hard and could lead to some compromises you are not comfortable with towards the end. So make sure you’re all on the same page about workflow and expectations, and that the contract reflects what you are actually doing.

Conclusion:

The differences in costs and timelines you see across various software development contracts for the same project is because they factor in these three variables, money, time and scope differently. Additionally, geographical and economical conditions and the kind of service vendor you choose, will all affect the contract. So don’t compare contracts rather work on framing a contract that works for all parties involved. It is essential to consider the implications of a contract on behavioral motivation too. Working as a team is the right way to build a beautiful product.

Follow us on Product Insights Blog from CognitiveClouds: Top Ruby on Rails Development Company