Using the waterfall methodology saved us precious time by implementing it but at the same time we discovered some disadvantages when we applied it to the real life scenario. The advantages as mentioned earlier was that it is linear (straight forward) – the resources to use this methodology are very minimal – after finalizing each stage we were able to verify and check for code and data consistency so that everything is correct. Ironically however we noticed that the biggest advantage of waterfall can turn easily as the biggest disadvantage. If you discover afterwards that something has gone wrong in the design process things can get ugly in the implementation phase. That is mainly because occasionally the client is not very clear or descriptive on what he wants and any changes that he/she mentions afterwards can cause some confusion. That makes us realize the importance of reoccurring meetings and take nothing for granted. However the biggest disadvantage of waterfall was that you cannot present the project until you reach the final stage of the waterfall process – and the client does not know until the end if what we developed is what he asked for. Thankfully the changes were minor and we didn’t had to destroy any previous process in order to create a new one. So in our scenario the waterfall worked excellent if you ignore mistakes that were mainly caused by us initially.