Now is the time to innovate - and no, that does not mean spending money. The term 'innovation' has been hijacked by the software industry during the Web2.0 craze, and we have lost sight of the true meaning of the term from a business perspective. Some of the most valuable innovations are actually related to people, processes, structure and strategy - and have very little (if anything) to do with technology.
Take your development methodology as an example, or your project management methodologies (if you have them). Can these be reviewed during the downturn and transformed? Does this classify as innovation?
The following is a simple summary of the rapid development methodology which has successfully been employed by a number of successful KM and IT projects. Firms such as Blake Dawson have been utlising the approach for a number of months now with great success. Asked if they considered the approach an innovation, we're confident that the team would say 'yes'.
Freehills is another firm that has adopted the approach on a number of their KM system projects in the past six months with great success. We're currently working with an international firm to transform their internal and external development approach to a very similar model.
The concept of a rapid methodology involves undertaking small “bursts” of development which results in incremental deliverables being released, rather than a traditional approach of trying to fully specify and develop a complete “product” to be delivered at a single go-live point. At the core of rapid development is the concept that “requirements evolve, but that timescales are fixed”.
During more traditional application development projects it was seen as critical to gather all requirements prior to development, freeze the functional scope of the application during the development phase, take the process of development out of sight (or outsource to technical resources), and then undertake testing and implementation. After this, it was then common to re-develop the application based on future or changing requirements, or redevelop based on incorrectly analysed requirements.
Because of the historical high costs associated with software development, and the fear that changing scope during a project will cause timescales and budgets to blow out, it is not uncommon that functional specifications and design briefs for developers included everything that a project team or user community could think of. This in hindsight is not necessary the most cost effective or efficient way to proceed.
Unfortunately, usage and behavior statistics across the software industry (including Microsoft’s own analysis of their product suite’s feature lists) indicate that only 20-40% of the total functionality available to a user within a software application is ever used.
Another way of stating this is that anywhere between 80-60% of software which is included within detailed functional specifications, and then subsequently developed (and paid for) is never used. The cost wastage is not just restricted to the initial development. It also leaves the organisation with ongoing direct and indirect maintenance costs for unwanted and/or un-used software.
Even when a significant requirements gathering exercise has been completed, and a large number of features are included for development (“just in case” they may be used in the future), the requirements gathering process itself and the interpretation of requirements into design can often be problematic and inaccurate while also rarely being truly representative of user behaviours.
Rapid and agile development methodologies encourage building less, and in doing so, delivering more value to the user by only developing those pieces which are proven to be true requirements and ensuring that they are developed well.
From a project and cost management perspective, this process of incremental feature development allows for clearer and more transparent oversight of project costs. It also assists with cost planning and development prioritisation for each individual “burst” or feature rather than having a single quoted price for an entire “product”.
In true rapid or agile development projects, it is always scope which is the variable – timescales and costs are always fixed. It is important to note however that scope variation does not equate to development or delivery quality variation. During the project, where an original high priority feature cannot be delivered in the fixed timescale or cost restriction, it is re-prioritised against other features which may not necessarily be as essential.
The benefit of a truly rapid approach is that the daily and weekly collaboration of resources and regular status “pokes” during the project day allow for these issues to be immediately identified and dealt with.
From a return on investment perspective, developing and incrementally delivering small sections of valuable functionality (rather than developing a full, complete application in the traditional sense) means shorter development periods and faster deliverables to users.
The faster a deliverable is released, the shorter the period for a potential return on investment to be realised. For a rapid approach to be successful, it is critical that developers, users, and analysts are working together during the “burst” – ideally in a co-located environment where progress is monitored daily and weekly.
From our experience, a successful rapid development project requires teamwork, commitment and extremely close and visible collaboration within the project team. Teamwork is even more important than the quality of the platform, skill of developers and designers, or the quality/amount of project documentation.
