Multiple different development approach are used within the software development industry, the two most common being Agile and Waterfall. In this article, we will breakdown some of the dangers that we’ve experienced during our operation for projects that we’ve performed using the waterfall method so that you can seriously consider the risks.
A brief overview of the waterfall method, the process is generally linear, and once each of the five steps (Planning, Design, Development, Testing, Deployment) has been completed the project moves forward. This makes it critical that each stage of the project is meticulously planned and executed; otherwise, it can spell catastrophe for both the client and the development company. While staying strictly to the AGILE method can resolve some of the following faults that we’ve identified, if the customer becomes disengaged or otherwise disinterested in the project (which is common) then even an AGILE project can either ground to a halt or begin sliding into a waterfall method.
Post-Development Feature Requests – ‘Obvious’ Features
We’re going to start by breaking down the most common issue for us at n-Coders whenever a project is required to go down the waterfall route instead of AGILE.
To be able to get the initial planning step right the first attempt, time has to be allocated to systems analysis. Unfortunately, time costs money. While most customers that are looking for custom software solutions have a reasonable budget of £50K or more, typically customers that prefer the waterfall method are those that have an unrealistic budget of under £10k and wish to push the process through as quickly as possible to get a result.
A simple fact that most people can understand; software developers carry out the tasks that are assigned to them but can’t develop features not assigned to them just in case the customer may wish to have them later on. As proficient as software developers are, mind-reading or future telling isn’t within their skill sets currently. While that seems like it should be common sense, it is often not considered in software development projects by the customer.
Failure in the initial planning process of a piece of software means that when the specification is broken down, and developers are assigned to complete each job, the project ends up following a spec that is extremely lacking in detail. If the customer fails to provide enough information initially or fails to detail exactly what they want, the frequent excuse is that it is “I obviously meant…”, “it is obvious that feature should exist” or “that is a common feature in X software, so I expected it to be in mine”.
Lousy planning will almost always result with the customer will expecting features added for free that were never quoted for or paid for on the basis that they’re “obvious” or “standard”.
Endless Support – Perfective Maintenance, Reality vs Expectation
Constant perfective maintenance strongly links to the previous issue that we highlighted and can also be connected to the failure in project planning.
Customers with lower-end budgets when it comes to software development most frequently have the highest expectations, hoping to get a piece of software as perfected as Microsoft Word without the millions in investments, years of work or hundreds of developers.
If a piece of software is not carefully planned and designed, the customer can and will request continual perfective maintenance to make adjustments to their software for free. As a software development company, the tricky part comes when you have to inform the customer that in fact, the software is how it was designed and that future changes will be billed further. This often faces considerable backlash from the customer that will insist that the software isn’t up to their expectations, not worth their investment or still needs lots of changes (that weren’t included in the initial specification).