“Will you be able to bid by the 20th, so we can accurately plan the project timeline, budget and compare all bids?”
“Please include SDLC phases, a project timeline in months, your roles for this project, total hours to complete the project and grand total price.”
I had imagined that the dysfunctional days of the RFP (Request For Proposal) in software development were gone. Man, was I surprised to see an Executive-level IT Manager still committing the irresponsible mistakes that have driven software development projects to failure over the last 40 years.
So who uses the RFP model? Where did it come from?
1) Construction industries – who have known, repeatable processes with supposed predictability but who still have a 90% failure rate on estimates.
2) Sleazy sales people – who are not interested in software value – only their commission.
3) Government – whose addiction to waste should never be used as a business model.
And we all know this negligent game – toss out the lowest bid, toss out the highest bid, haggle on rate, fabricate timelines, pad estimates, rush to an arbitrary deadline, work 80 hour weeks and then celebrate project survival.
But what are we really bidding on? A contractual guarantee that change won’t occur or that punishment should ensue? And what if change does occur during the project?
An RFP will guarantee you fixed time and cost, but here’s what else it will guarantee you:
Waste. 68% of IT projects are NOT completed on time and budget. (Only 32% of IT projects are completed on time/budget, 44% are completed late and over budget and 24% are abandoned. Source: Standish “Chaos Report” 2009.) You are not exempt! Your RFP will ensure your inclusion in this statistical failure – despite your belief that it’s the remedy. The RFP is part of the continuing cause of these wasteful company practices. Can you really afford to be a statistic in this economy?
Disgruntled Developers. The inability to move a timeline or cost means employee overtime to meet what was well intended guesswork on software that hasn’t been created before. Good developers in the .Net space are a rare commodity. Treat them well. They are almost as recession proof as beer and can work almost anywhere they like. Managers/owners who view them as replaceable commodities will deservedly incur the cost of knowledge loss and replacement learning curves.
Disgruntled Employees. Change is inevitable and it’s a naïve manager who believes that employees won’t go directly to developers to secretly request changes to their original scripting in that almighty RFP. It just means the developers will have to sneak it in and work longer hours to help out the users. They both know they’re on the same team… Why don’t YOU?
Disgruntled Accountants. Sure, you’ve made the accountants happy up front with the RFP temptation of “set-it-and-forget-it” budgetary “predictability”, but experience should tell you that you have created an inherently wasteful, poor quality product that will have ill-effects beyond delivery….perhaps even before delivery. The accountants will ultimately be disgruntled because what they thought was a finished product is not. In fact, many more maintenance projects will amount to many times more than the original RFP. The cost of that original RFP will also spill into other projects in the form of Technical Debt.
Disgruntled Customers. Fixing project cost creates measureable business cost in the form of customers who prefer to use your competitors’ products. It doesn’t matter if your customers are internal (employees) or external paying customers. Your “internal customers” will pass on a poor software experience to your paying customers. (How many times have you had that experience passed on to you over the phone? “I’m sorry, the system isn’t able to …”) You will pay for it either way. RFP’s ensure that customer-driven requirements will take a back seat to the time/cost commitment of the almighty RFP. A company’s inability to adapt “the plan” and pivot/respond to real business customer feedback cycles guarantees poor quality software and a poor client experience.
Disgruntled Ownership. Antagonistic relationships between developers, employees, accountants and customers make for disgruntled Ownership. Creating a company quagmire from an RFP seems at odds with good entrepreneurship. If you are a business owner, and your IT manager is proposing a model like an RFP – understand that it is at odds with the very nature of software.
Fired Managers. Managers playing the RFP game are not interested in value…only cost. They are interested in following the plan – not the ability to respond to change. They are more interested in comprehensive documentation – not iterative working software. They are more interested in contract negotiation – not customer collaboration. These are all things that the Agile Manifesto addresses. Do yourself and your career a favor. Learn better software philosophies. It will save your job.
RFP is NOT the right model for software development.
And it never was! IT professionals have always known the irreconcilable disconnect between guesstimates and the reality of coding. Listen to them!
Let’s stop this awful, wasteful practice. We’ve learned so much from the failures of this system to be perpetuating this harmful, wasteful approach to software development in this economy.
I have an idea. I’d like to redefine what RFP really means to companies. Here’s a handful of options – feel free to add your own.
· Requesting Failure Please?
· Recreate Former Problems
· Ready For Pain?
· Request For Panic?
· Request Flawed Performance
· Request Flatulent Product
· Run For Parachute
· Randomly Formulated Plan
· Really Faked Projections
· Reassess Failed Philosophy
· Restart Failed Project
· Random Firing Permitted
· Repress Future Profitability
· Rewrite Forced Programs
· Rework Fanatical Projections
· Remember Former Pain?
· Recently Failed Project
· Refund Financial Profit
· Regret Faked Promises
· Richly Formed Prank
· Relic From (the) Past