Developing software as an ongoing, collaborative process Software projects are never one-off developments. Well none that we’ve ever worked on. It’s the nature of software that either the system requirements or the technology on which the system runs, or both, change over time. If it’s not requirements that were originally missed, then it’s changes to working practices, scale, operating systems or browser specifications. It could be the addition of new features made possible through technological advances, or new security legislation that demands changes to the software.
Developing software as an ongoing, collaborative process
Software projects are never one-off developments. Well none that we’ve ever worked on. It’s the nature of software that either the system requirements or the technology on which the system runs, or both, change over time. If it’s not requirements that were originally missed, then it’s changes to working practices, scale, operating systems or browser specifications. It could be the addition of new features made possible through technological advances, or new security legislation that demands changes to the software.
In most projects, the requirements change continually during the development process too. As with any complex situation involving human activities, it’s impossible to accurately predict beforehand exactly how things will work or, more often, there isn’t the time, resources or will to sufficiently analyse the situation.
The software development industry has learned to work with this inevitability by adopting techniques that embrace change. Agile development is based on the premise that software evolves over time and the core principles of modern programming are designed to facilitate change. Indeed, a whole industry has blossomed to provide tools that support this objective.
THE AGILE-COST CONUNDRUM
But there’s a catch: businesses need to fund projects.
Companies require plans to secure investment or management must provide fixed costings to their finance departments. As a result, we as software developers are expected to produce an estimate of cost and delivery timescales for the entire project before it starts and before the full detailed requirements are known.
With fixed costs, it’s the software developer that takes on the risk of underestimating. To mitigate the risk they add arbitrary padding to allow for changes, and they demand that the project specification be signed off by the client who seldom has the time, experience or inclination to study it in sufficient detail. This means that the inevitable oncoming train of changes becomes chargeable and there’s no funding available to pay for them. The result? A strained relationship of mistrust between client and supplier, and software that fails to meet the requirements of the business and its users.
To us this is a lose-lose situation. We want to build successful, usable software at a fair price. To do this, you need trust.
ADAPTING TO THE REALITY
Like software, trust is something you build. We can’t change the fact that there will be changes to the project scope, but we can build a solid foundation for dealing with those changes. That’s why we work hard on fostering collaborative relationships with our clients.
By structuring requirements in prioritised stages, with detail concentrated on the core features, you can be more precise with estimates of the initial costs and timescales.
We encourage project sponsors to involve those controlling the funding in the process, and to backload the cost by mixing lower initial funding with an ongoing operational budget to fund the later functionality. This functionality will in turn be costed more effectively, since ongoing developments emerge from actual use of the system and be tailored to the true needs of the business. Delivery targets are more likely to be met with the end result what’s actually wanted.
Real-world projects change. If you accept this and plan for it both technically and financially, you will get better software at a lower cost.
IN SUMMARY
- Requirements, and therefore the scope of a project, will change and software development projects should be seen more as an ongoing process rather than one-off.
- Development practices have evolved to embrace this. However, the financing side of projects is lagging behind, forcing the process to be less than optimal.
- This can result in a lower quality product at a higher than necessary final cost.
- The small company or middle management project owner can improve the chances of success by mixing lower initial funding with an ongoing operational budget to allow for the fact that requirements will change and evolve and new ideas emerge once the software is in use.
- Trust is a by-product that feeds back into the process over time.
