It’s quite amusing to see many offshore vendors to use LinkedIn Answers for self-promotion but instead of leads generating volumes of offshore-bashing. However amid of self-advertising and political positions you can find browsing this section helpful in many aspects, no cloud without a silver lining I guess… This time LinkedIn Answers offered an interesting discussion topic with a help from Irina Semenova: When outsourcing projects offshore which model is preferable – Time and Materials or Fixed Bid? And my answer is… “It depends.”
What model is going to work for your specific engagement depends on the project goals & objectives, both parties’ org structure and experience, SDLC maturity and style, etc. The selection should be made by careful analysis of all ingredients and with consideration of classic engagement objectives: scope, time, budget, and quality. Below are some tips that you may want consider when making the decision.
If the scope of the engagement is extremely well defined and firmly set Fixed Bid model is very natural way to go. Some of my friends from Agile Camp would probably say that the scope being “extremely well defined and firmly set” is an oxymoron – requirements always change, etc. Well, I do not want to start a philosophical discussion; instead, I’d rather mention a few items that often overlooked in scoping exercises:
- Non-functional Requirements. This is not a very good term but widely used for some reason. By non-functional requirements I mean horizontal requirements that apply to the product not to its functionality. These requirements typically include dimensions such as performance, scalability, maintainability, interoperability, etc. They are extremely important for any project but often overlooked and dealt with in catch up mode exploding the cost of the engagement. For FB projects you not only must specify upfront the requirements but also defined how the compliance would be verified.
- Delivery Requirements. Sometimes considered a subset of non-functional requirements the specifics of engagement delivery affect the cost dramatically. The vendor typically has its own benchmarks in that respect which could be drastically different from your expectations. Do you expect to have 80% unit test code coverage? Do you expect well-document DB design delivered in Erwin format? All these requirements must be spelled out before FB contract is put in place.
- Communications. The volume of communication is a notable aspect in vendor’s overhead and thus affect the cost of the project. You might be expecting daily project updates and rigorous reporting at multiple levels while the vendor thinks just milestone updates and PMO quarterly meetings. It’s much better to bridge the gap up front.
- Quality. It is extremely important to specify Acceptance Criteria in all aspects of Quality of the product as well as process of Acceptance. Metrics and methodology definition should be one of the inputs to the vendor for defining FB price tag.
- Change Management. Any vendor that has meaningful experience in delivering FB engagements has Change Management well under control. What vendor could be not familiar with is your specific change rate and budget change tolerance. It takes tremendous expertise on both side of the relationship to manage Change Management and avoid scope creep wars.
If addressing items above in addition to developing meticulous definition of product requirements falls outside of your capabilities you can hire your vendor to do it for you on a Time and Material basis. That appears like a nice T&M segue into a FB model. There are a few traps associated with that model though. The main being a potential conflict of interest: Will the vendor has your best interest in heart and won’t use this exercise to dramatically increase the scope of the project? That’s not unheard of. You can mitigate that risk by hiring different vendors for FB and T&M portions of your engagement; that approach of course has its own drawbacks.
With all these complexities of FB model why even consider it? Why don’t just go with T&M for all types of engagement? Well, some projects land themselves extremely well in T&M space, for example a classic team augmentation – situations when you just need a team of QA engineers added to your organization during major release, or you need a graphical artist to assist with development website, etc. There are as well a plenty of other situations that make a short or long term T&M arrangement the most meaningful. You should not rule out a FB model for engagements of recurring nature and augmentation tasks though. For example an ongoing legacy s/w maintenance and support task appears as a great candidate for T&M, but it could be extremely well handled as FB SLA arrangement.
A popular concept states that vendors prefer T&M model because it allows them to achieve maximum utilization of resources while being shielded from customer failures to deliver on their obligations. That is a major misconception. Under true T&M model the vendor gets paid only for work being done and is not for waiting for customer to make up their mind. In majority of the situations that would mean that developers would be sitting on their hands for major portion of the project. So typically T&M engagements are sold as “minimum utilization” models, in those the customer pays the maximum of minimum agreed upon amount and T&M amount. That model shields the vendor quite well.
In that light T&M model doesn’t only shield the provider it also reduces dramatically inevitable scope creep wars on fixed bid projects. In many aspects it is good for both sides. The main challenges it presents for the buyer are somewhat hidden and thus create serious traps. Here are just a few to consider:
- Carefully constructed T&M project opens a huge opportunity for add-on sales and could generate enormous amount of unnecessary work. As proverbial car salesmen IT consultants are exceptionally skilled in upselling the customer, keeping themselves occupied, and discovering new opportunities. On the other hand buyers become their own worst enemies as T&M promotes sloppiness in handling scope. As a result T&M projects, unless handled properly, have a high probability of costing more, often much more than expected. The example which comes to mind is ERP implementation which I observed at a large automotive manufacturer; being budgeted initially at $30MM it ended up costing in excess of $300MM.
- T&M projects require meticulous time tracking which could become a considerable overhead. I remember myself spending easily 1 hour a day on keeping track of my time in three systems, of course that hour was billed to the customer as well. For developers that are not used to consulting lifestyle timetracking is true bane of existence, often resulting in malicious compliance producing little to no meaningful results.
- T&M projects are more difficult to budget for and are real pain in GL allocation when services cover multiple cost centers / etc. Appropriate allocation in particular requires detailed time tracking with its respective impact and reliability issues.