Posted by: SJC
Agile, Application RFP, custom application development, estimating application cost, RFP Process, Waterfall
My posts last month generally consisted of comments, suggestions and difficulties with preparing cost estimating of legacy applications. Recently I had the opportunity to come accross an interesting blog post which relates to “the other side” of the coin, that of preparing the RFP. While the post doesn’t directly relate to an RFP to replace an existing legacy application, certainly there are points of comparison.
Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall is the posting to which I am referring. Early in the article it is stated that “The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI.” There are many pitfalls to this way of thinking, not the least of which is that it doesn’t really hold up in fact, in a large part due to inadequate requirements.
Then there is the “feature set” to be considered, an area which I commonly dig into with my clients — always using the “…delivery of valuable software” idea of the Agile Manifesto. As for features, the post makes the statement that “…studies show that 45% of features built under waterfall are never used.” WOW! The common cry of “If its not broken, why fix it!” should be replaced with “If it isn’t used, then why have it?” Many is the time that I have been with a client and seen that there are always areas which just don’t get used. Unused fields in a database always seem to be asking the question – what am I doing here? Sometimes it is a change in process that has made it obsolete, but more often than not I find it is a matter of some program area which “seemed like a good idea at the time”, but which just never fit what was envisioned, therefore didn’t provide the “value”.
As for preparing an RFP — I wonder about the effectiveness of most RFP’s, and the referenced article helps me identify why, it seems to demand a waterfall approach, and I’m clearly into an Agile approach to development.