Greg Wdowiak’s post on application integration and agility (as in agile development) includes a great comparison of plan-driven versus adaptive development. He rightly points out that both approaches are valid, but for different types of projects:
Adaptive approach provides for an early customer’s feedback on the product. This is critical for new product development where the customer and designers ideas may significantly differ, be very vague, or the kind of product that is being design has not been ever tried before; therefore, having the ability for the customers to ‘touch’ an approximation is very important if we want to build something useful.
That pretty much describes most development projects that I’m involved in…
The plan-driven approach allows for optimization of the project trajectory. The trajectory of adaptive approach is always suboptimal, but this is only apparent once the project is complete.
As this last quote from his post makes clear, the plan-driven approach works well for well-understood implementations, but not so well for the introduction of new technology/functionality into an organization. The plan-driven approach reduces logistical risks, whereas the adaptive approach reduces the risks of uncertain requirements and unknown technology.
One of the key advantages of adaptive development in introducing new technology is the delivery methodology: instead of a “big bang” delivery at the end, which often surprises the end-user by not delivering what they expected (even though it may have been what was agreed upon in the specifications), it offers incremental approximations of the final result which are refined at each stage based on end-user feedback.
So why isn’t the adaptive approach used for every new technology project? Alas, the realities of budgets and project offices often intervene: many corporate IT departments require rigid scheduling and costing that don’t allow for the fluidity required for adaptive development, for example, by requiring complete signed-off requirements before any development begins. Although it’s certainly possible to put a project plan in place for an adaptive development project, it doesn’t look the same as a “classical” IT project plan, so may not gain the acceptance required to acquire the budget. Also, if part of the development is outsourced, this type of rigid project planning is almost always used to provide an illusion of control over the project.
When a company just isn’t ready for the adaptive approach yet, but can be convinced that the plan-drive approach isn’t quite flexible enough, I propose a hybrid approach through some project staging: my mantra is “get something simpler in production sooner”. If I’m working with a BPM product, for example, my usual recommendation is to deploy out-of-the-box functionality (or nearly so) to allow the users to get their hands on the system and give us some real feedback on what they need, even if it means that they have to work around some missing functionality. In many cases, there’s a lot of the OOTB functionality that’s completely acceptable to them, although the users may never have specified it in exactly the same manner. Once they’ve had a chance to see what’s available with a minimal amount of custom development, they can participate in informed discussions about where the development dollars are best spent.
This approach often puts me at odds with an outsourced development group: they want to maximize their development revenue from the client, whereas I want to keep the design simple and get something into production as soon as possible. I’ve had many cases in the past where I’ve worked as a subcontractor to a large systems integrator, and I almost always end up in that same conflict of interest, which explains why I usually try to work as a freelance designer/architect directly for the end customer, rather than as a subcontractor.