Many IT managers resist the temptation of going agile (which implies working under a time and materials model) because they believe their managers, or their purchasing department, or whoever approves a budgetary expenditure, will not easily approve a T & M project.
It is easy to see that for someone who has not been directly involved with the complexities of software engineering, purchasing a "fixed amount of work, for a fixed price" makes plain sense, as it can be compared to purchasing, say, a computer or an office chair (i.e. you know what you are getting and you know how much you are paying for it). The problem lies in that, when partnering with software engineering firms, buying under a fixed bid model is not optimal (we explored this matter in greater detail in previous posts here and here). Why so? In short: it creates incentives for vendors to low-ball an estimate to then inflate it once they are awarded the project --a sort of "bait and switch"; it often reduces the vendor selection process to pricing decisions (and not quality, or ease of communication, or other factors that are more critical to project success); because the final price is often so off from the "committed estimate" of the vendor, price turns out, in retrospect, to be a weak variable for choosing a vendor; fixed bid projects create a tense and adversarial relationship between the vendor and the client, which is not conducive to long-term productivity, or to leveraging the experience a vendor gains with one's company in future "repeat" projects.
Assuming you are an IT manager that wants to try going agile with a vendor --which, again, implies working under a time and materials model--how to go about convincing the purchasing department that you are not signing a "blank check" to the vendor?
The ease of convincing a purchasing manager to purchase agile services depends on the nature of the organization. Fundamentally, organizations, where purchasing departments see their functions as providing sanity checks, are more successful in implementing agile. On the other hand, organizations where the purchasing department wields the power of the final decision as well as the philosophy that drives the decision (rather than letting the de-facto department that is utilizing the services, such as IT, determine the philosophy behind the decision) are less successful in purchasing agile services.
In this regard, our clients share with us the following tips to convince purchasing departments about "going agile" with their IT services vendors:
1) Letting the purchasing department know about past projects that, despite being run under fixed bid, were unsuccessful. An organization with some track record usually have little difficulty coming up with those ;)
2) When possible, speaking to a purchasing manager about the advantages that the IT department sees in going agile (i.e. adaptability, a better chance of achieving functional relevance, not trying to "guess" a correct application up-front, etc.)
3) Letting the purchasing manager speak to purchasing managers or IT departments at other companies that have tried both models (i.e. agile and fixed bid) and have found agile to be significantly more successful;
4) Convincing the purchasing department of starting with a small pilot with the chosen agile software development vendor, that will demonstrate the quality of the service, to then proceed, after proof of concept, to grow the team.
5) Letting the purchasing manager know that virtually all leaders in the IT field use agile themselves to run their internal operations (Google, Amazon, Apple, Microsoft, Sony, etc.)
6) Agile software development companies/vendors are often very good at exposing the advantages of agile (if they weren't, they wouldn't be in business :)... Hence, sometimes it is worthwhile to try to have a vendor or several, speak to the purchasing manager as to the advantages and cost savings that are implicit to agile methodologies.
Would you like us to have a conversation with your purchasing department? Drop us a line and we´ll get in touch.
Regarding PSL: With more than 30 years of experience, PSL specializes in outsourcing and nearshoring software development projects as well as Team Augmentation. Based in Colombia, Mexico, and the US, PSL is an agile SCRUM development shop focused on high-quality services.