Reading Stephen’s editorial a about the viability of the SLA process, I began thinking about the RFP process as well. Both processes have something in common. The worst case scenario is that the contracts result in a pre-determined scape goat to blame when things go badly. The best case scenario provides guidelines for how both parties will behave and perform.
It may be that the energy spent to write and implement an SLA would be better spent building a fault tolerant application on all tiers. Using the same thought process, I’m wondering if we could replace the RFP process with a solid understanding and agreement for implementing an Agile development process.
In an RFP you have to have a fairly clear scope of work in order to get useful proposals. Agile doesn’t replace the establishing of the scope of work; it calls it stories, with story points assigned to individual features.
What changes is what happens after the scope is established. Now you are simply trying to lock down cost and mange change. An RFP requires you to build everything. Since it is fairly high level, anyone responding is going to have a lot of hedging. Both parties are going to be resistant to change because of cost. EDS was great at dealing with RFPs back in the day. They low bid everything knowing they could tack on lots of upgrades after the project was underway. The point is, the RFP focuses on how to protect cost and profit.
Using an agile process an agreement would be made for a number of resources at a fixed cost and period of time. Now that you have your team, you start building your application from the same scope. You start with the most important or difficult deliverables. Change is still managed, but not from the perspective of money as much as the perspective of importance.
There’s some food for thought. Do you think the idea is crazy? Share you comments, or drop me an Email at btaylor@sswug.org.
Cheers,
Ben