Software Development evolves but timelines and cost should be fixed. Distinguish between “I Need”, and “I Wish”. This is in stark contrast to traditional software development projects, where one of the earliest goals is to capture all known requirements and baseline the scope of work so that any other changes are subject to change control.
Traditionally, users are educated that it’s much more expensive to change or add requirements during or after the software is built. Some organisations quote impressive statistics designed to frighten users into freezing the scope of work. The result: It becomes imperative to include everything they can think of – in fact everything they ever dreamed of! Further users are required to determine a priority and what is all important for the first release. We all know phase 2’s implementations are invariably harder to get approved once 80% of the benefits have been realized from Phase 1.
Ironically, users may actually use only a tiny proportion of any software product, perhaps as low as 20% or less, yet many projects start with a bloated scope. In part, this is because no-one is really sure at the outset which 20% of the product their users will actually use. Equally, even if the requirements are carefully analysed and prioritised, it is impossible to think of everything, things change, and things are understood differently by different people.
We work on a completely different premise. A development project should work on the premise that requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. In the time you would have spent analysing and reviewing requirements and designing a solution, external conditions could also have changed.
Therefore, if you believe that no-one can really know what the right solution is at the outset, that it’s inherently difficult, or perhaps even practically impossible, don’t start a development using a traditional approach to software development.
Traditional development projects fight change, with change control processes designed to minimize and resist change wherever possible. By contrast, our development projects accept change; in fact they expect it. The only thing that’s certain in life is change.
There are different mechanisms in our software development process to handle this reality. In a Development project, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.
This ensures the team can remain focused on the agreed timescale, and allows the product to evolve into the right solution. It does, however, also pre-suppose that there’s enough non-mandatory features included in the original time frames to allow these trade-off decisions to occur without fundamentally compromising the end product.
So what does the business expect from its development teams? Deliver the agreed business requirements, on time and within budget, and of course to an acceptable quality. All software development professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. Something must be variable in order for the project to succeed. In a Development, it should always be the scope of work (or features of the product) that are variable, not the cost and timescale.
Although the scope of a project is variable, it is acknowledged that only a fraction of any product is really used by its users and therefore that not all features of a product are really essential. For this philosophy to work, it’s imperative to start development (dependencies permitting) with the core, highest priority features, making sure they are delivered in the earliest iterations.
Unlike most traditional software development projects, the result is that the business has a fixed budget, based on the resources it can afford to invest in the project, and can make plans based on a launch date that is certain.