The history of the development of computer based systems is littered with spectacular and costly failures. In many cases, the reason so many projects are doomed to fail can be traced back to inappropriate methodologies. Often the methodology employed is designed to make money for the developers, not to deliver value to the client.
IDE's approach is built on modern agile methodologies for delivering solutions. As the Agile Manifesto says, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." At IDE, we value customer collaboration over contract negotiation.
We tailor our methodology to meet the needs of the project, but we approach problems as follows.
Objectives First
Your journey never ends unless you know where you are going. Our first step is to listen, understand and prioritize the business objectives. This means starting by clearly defining why the system or service is being developed. This is a good time to layout the business case for the project.
Rapid Prototyping
It is faster and much more effective to develop a prototype system based on the business objectives than it is to write a detailed specification. The prototype is put into operation with real users at the earliest possible time. This is by far the most efficient approach to discovering the real functional requirements. Using this approach, real users are providing invaluable feedback long before a detailed written specification (which is almost invariably wrong) is completed. In addition, operational value is derived from the service from early on in its life cycle. This allows a very early assessment as to whether the approach will deliver the value hoped for against the business objectives set for it.
Continual and Rapid Enhancement
The prototype is 'evolved' in rapid small steps without the expensive overhead of a slow and usually highly bureaucratic 'change request procedure'. The fact is that the requirements change at a faster rate than the 'change request procedure' can respond so that the longer a development project runs the farther behind it becomes. The usual result of this is that the project collapses in a bureaucratic morass of paper and disputes about escalating costs.
Document the Prototype
A prototype system that has been tempered in the fire of real usage is almost always more robust and reliable than a 'production' system that has only been artificially tested to detect code bugs. When the prototype stops evolving because it has successfully achieved the business objectives and it is favoured by users, it is much better to document the prototype rather than redesigning it from scratch. Many very successful systems have been lost by throwing away the prototype and allowing an expensive 'redesign' to get a supposedly more 'robust' implementation.
So, what about risk? The most common objection to the 'Evolutionary Methodology' is that it is risky because it does not have a 'fixed price'. This objection is not founded in reality.
The facts are that this methodology produces a useful result in the form of the 'operational prototype' at a very early stage. Often this prototype is delivering significant value while other methodologies are still at the 'arguing over specs' stage. Moreover, 'fixed price' is largely a myth. This fact is witnessed by the preponderance of fixed price projects that dramatically overrun their original cost estimates.
Historical experience has conclusively shown that the real risk of an expensive failure lies in using the traditional and highly structured methodologies. A key reason for this is that in these traditional methodologies, real measurable results are not expected to be achieved until the end of the project. Real mitigation of risk is much more a function of looking for useful results early when the cost and resources have not already been exhausted.