It can always be frustrating to which type of engagement you should choose when selecting a vendor for your software development project. On the one hand, you are allocating the budget and want to know how much it would cost to deliver the project. On the other hand, you don't want to lock in the features, so you won't be able to make changes down the road.
In a startup, you can not plan everything ahead. Even if you made quite a thorough project roadmap, something would always change, and you don't want to get your team in a trap of figuring out the change requests every time you need slightly correct the course.
Some customers insist on a fixed bid project, thinking that a vendor can trick them. It's true, and some vendors do this, but aren't you trusting your vendor? Why engage at all? If you trust your vendor, you will entrust them to deliver your project on time and within budget. Now let's get into it.
For some projects, the fix bid engagement is a must-have. For example, established enterprises are all budgeted, and so their projects are. Projects can not get approval at all levels without a defined budget.
For vendors, the fixed budget means they should account for every single line of code and effort it may take to deliver the project. Enterprise projects are far more complicated and could present a challenge during the implementation. The challenge may consist of things like legacy code, migrations, integrations, etc. Sometimes this is a black box, as it might be quite challenging to assess all levels of the project.
This is why there is always the project discovery phase prior to the main stage. The vendor allocates the team of business analysts, data analysts, engineers, designers, project managers, and quality assurance to work out the requirements. This kind of assessment may take a few months to complete, and by the time the vendor makes the estimate, they also account for unforeseen circumstances and add up some risk percentage to allow the team some margin to fight with troubles.
But unlike startups, enterprises have long pockets and can afford a long and expensive process. They don't have a choice. In the case of a smaller MVP project, you'd surely don't try to engage with a large vendor, but a vendor of your caliber will still account for risks and may overestimate the project. If the vendor agrees on the fix bid and you like the price, there are two ways this can go:
And there are tons of stories on the internet about failed outsourcing projects. Try it yourself and see how many proposals you'll get for a fix bid project, and bet that you'll like the price but not the quality and timeline. It's a trap that cheap devs may get you in. That is where the long and brutal story begins.
Still, the fix bid is feasible, and if you feel this is your way forward, you should start the vendor assessment and ensure you complete all the steps before the project starts. This will increase the success rate of your project.
Time and Materials implies a standard phrase for product development or any other piece of work in which you agree to pay the vendor based upon the time spent by the vendor's employees to perform the work during the project, no matter how much work is required to complete the project. Time and Materials is generally used in projects where it is not possible to accurately estimate the size of the project or when it is expected that the project requirements would most likely change.
So far, the T&M had seen as the most advanced type of engagement for agile MVP development. Founders that opt-in to this type are well-informed and prepared to manage the project and lead the team (yes, outsourced) to a successful implementation. It's like an autopilot where you input the initial data, and the computer flies the plan for you. But you should still account for the weather conditions, terrain, and airport equipment to land the airliner successfully.
Of course, as with fix bid, you do your homework quite the same, but there might be no need to get into the full project specification. The beauty of T&M is that you and your team figure out things as you go. It does not necessarily mean that you should not have project estimates and blindly dive straight into the project. The proper vendor assessment, Scope of Work, and Design Sprint should still be in place.
During the vendor assessment and later down the road, ask the team to make all assumptions regarding the budget and timeline. Most of the time, professional software development teams will equip you with tools to plan and track the budget as well as updated timelines and the progress dashboard — like an airliner.
It is always something that happens during development, and the team that trusts you will be transparent about the challenges. But what's more important professional teams will also provide you with options to resolve the issue.
In T&M, you don't know where this road will take you, but you have best friends to help get you there.
We've seen clients come up with ways to protect themselves in multiple ways. Some proposed to pay only for delivered features or pay on a bi-weekly basis. But these all add-up operational expenses and slows down the project. Never do that. Instead, look for a vendor you can trust.
Here are other notes worth reading to ensure you're well-informed and prepared:
MVP Scope of Work [by Jobresponse]
👋 Thanks for reading this. Ever wonder what Jobresponse is? We’re rethinking software outsourcing. Give it a try. Contact us for more information