Risky Business
Building software is a risky business. In modern day software development, most things change most of the time. Changes cost money. Because of this, there is always a significant risk that a software project could:
- Fail to deliver an acceptable set of features
- Suffer from quality issues
- Significantly exceed budget
This building to spec approach has never dealt well with adapting to changes. In some cases the spec is well understood and does not change very often, but in lots of situations there is significant change. If the spec doesn't change a lot, the phased approach discussed is the best approach to building software, otherwise you need to take a iterative approach.
The problem is that an iterative approach is one of discovery and therefore neither a spec or a price can be agreed upon at the outset. Instead the process follows more of a 'Time and Materials' approach to cost where the buyer compensates the vendor for its time and costs as they go along. The result is that the buyer owns the risk of what is getting delivered and when.
A proposed solution - Agile Prototyping
It is possible that there are projects where an Agile Prototyping approach is an appropriate way for the buyer and the vendor to share the risk.
In this approach, the project would be split into two phases, a discovery phase that would be iterative and therefore the buyer would own the risk, and a delivery phase that would be fixed scope/price and the vendor would own the risk.
The discovery phase would consist of the vendor and the buyer working together very closely. Resources from the vendor side would be exceptional at crossing the technology business divide as well as excellent programmers, capable doing magic things with software in very little time. The deliverable of the discovery phase is a working prototype that delves into each functional aspect of the system without fully fleshing it out. It would pay no attention to IT issues such as scalability or performance. In essence, at the end of the discovery phase, a executable spec is delivered that is of sufficient detail so that 'fleshing it out' and delivering it is something that can be estimated and sold at a fix cost.
In the delivery stage, the vendor assumes the risk, but also is freed from the constraints of working with the customer. The vendor is free to deliver the software in the most economic way it can safely do it at the price quoted.
The key assumption that is being made with this proposed project structure is that the majority of change in some software projects, is not really change at all, it is discovery.
For projects where the primary change component is discovery, the benefits of this structure are as follows.
- It enables the buyer and the vendor to share the risk and therefore makes it much more attractive to both parties.
- By separating the clients involvement into the discovery phase, we focus them on the decisions that they need to make and avoid asking them to make decisions that generally they don't want to make (such has mundane UI details).
- Free the vendor to deliver the project in the best way that they can.
- Concentrate skills of workers into the phases where they can have the best impact
- How much of the cost of the project can be moved into the discovery phase?
- The risk is shared, but does the overall cost of the project go up or down?
- How much of the prototype is reusable?
- Do modern technologies such as rails enable fast prototyping?
- How easy is it to find people who can 'cross the technology business divide' and be excellent programmers?
3 comments:
As a user (and yes, sometimes l'user) I love this idea. It could address the main cause of dysfunction in Vendor-User relationships. Much of what has developed that is so destructive to the relationship from the vendor's point of view (ie. a user wanting to dictate platform, language, micro-managing) has developed for good reason. Software development is expensive and the seeming lack of understanding of the user's point of view on the part of the vendor leads to distrust and can infuse the relationship with unwarranted hostility.
Sitting down to negotiate a contract, even with in-house vendors, is often seen as a battle. Careful preparations are made. Special resources are called in. The walk away point is known.
Much of your argument for this prototype approach is aimed at the vendor - getting the user out of the way so she or he can do the job of programming. To sell this to a user the argument must be more about creating trust and reducing uncertainty that everyone is speaking the same language. "crossing the technology business divide" is absolutely key!
The concept is aimed at the buyer. The guy that currently owns all the risk. Its sort of saying, 'There is risk and uncertainty, we can't get rid of it, but lets find a way to share it.'
Thanks for the comment.
I have an approach similar to yours with a couple of differences.
1. In the first iteration, I build a skeleton (core features), not a prototype. Key to success is great analysis that comes very close to identifying most of the core features. Like in your approach, a lot of detail is left out in this iteration. I believe that typically the skeleton represents about 30% of the total effort (not total code -- may be much more than that. This is time boxing so amount of effort is key, not amount of code).
2. I work with the users/customers in the following phases as well - just not nearly as much.
Post a Comment