If you’re planning your software project, you need an organisational strategy that produces the right outcome. There are numerous ways to approach complex coding projects, but not all are created equal for every development team or software type. Is your coding job geared towards a final product that should be locked in place and set in stone, or does it need a great deal of flexibility in planning for future changes? These can be determining factors in the right project management approach. Watch our video to learn about one of the processes known to work well in many instances.
First let’s look at waterfall. Waterfall methodology is a sequential and non iterative process. Sequential means there is a series of steps and those steps will all occur in a specific order. Generally speaking for the waterfall projects, you document everything upfront. You might then hand that off to designers who will put front end pictures on all of that. Then it will go to developers who build the interfaces, testing and then release.
Importantly it is non iterative. You are never going to repeat any of those phases. You do all of your documentation upfront. That is it, the documentation phase has ended. If you’re going to do any more documentation, that goes through as a change request. Then you do all of your design. If you make a mistake in design, too bad, it’s done. It’s all finished.
Whilst it may sound as if that is quite restricting, waterfall does have some awesome parts to it. It is very clear on outcomes. Waterfall methodology generally comes with a really clear declaration of what it is this system is supposed to do in its fullness, not looking at what it’s going to do tomorrow, but what it’s going to do when the system is complete.
It’s good for sign off between a large number of stakeholders. If you’re trying to work with a large number of people, you need to maximise the communication between them and get them all on the same page and all in agreement that they’re going to spend the money or that they’re happy to go down this path. Waterfall, because it does all its documentation and such upfront, is really good for that. It is a benefit.
It forces decisions early. This has pros and cons but if you have a limited budget and you’re working in a waterfall manner, this can make you think can we afford all of this? Do we have to narrow our scope? It makes you think about how you’re going to roll out the whole project rather than thinking of it iteratively. There are pros and cons to that of course.
It allows for estimation or better estimation in quoting upfront. Bringing all of the documentation together,(some of these are controversial) there is an argument that says then, you have a better idea of all the pieces that are in the project and you can produce a more accurate estimate or quote based on that.
It remains stable which is really good for large teams. If you’re working say in the IBM space, you’ve got hundreds of people involved in a project. You need a process that remains stable and that people aren’t going to find changing on them day to day. Then you need to change manager just to get your processes updated. You couldn’t do agile in a massive team because just the overhead of keeping the processes updated would be too high.
The down sides to waterfall though, humans can be pretty bad at thinking of the full picture. It’s a fact, we’re not able to hold a complex system of certain size, so thinking through edge cases can be a bit of a pipe dream.
The larger the project, the more scope there is for change. The larger the number of change requests that are likely to go through, unless you leave enough buffer in your budget, if your initial spec is all up to your budget, you’re going to find change very difficult.
There is no ability to change the product to meet a changing market. You’re a year into your development cycle, someone releases a product that is exactly what you were going to do. You don’t have an ability to pivot, you don’t have an ability to change what you’re doing because your process is sequential.
It doesn’t allow you to change the process itself if you spot areas for improvement. Even if you have found an area for improvement, the process has already moved on beyond the point you found that change. You can make the change but you’re never going to revisit it.
No matter what method ends up working best for you, it is going to take structure and determination to complete your software development goals. Different teams create a range of dynamics between responsibilities and talents. The end goal is the same each time, but the road to a finished product can determine how expensive the project ends up being. Learning methods that are used for success will help empower you to decide for yourself which one is right for your project.
If you need help putting together the right team for your software project, get in contact with us today.