Planning, designing and architecture is more straightforward since the customer and the developers agree on what will be delivered early in the life cycle. Since the full scope of work is known, progress is also more easily measured.
Depending on the phase of the project all team members do not need to be locked down in the project. As an example business analysts (BAs) can proceed working on other parts, or other projects entirely, after requirements are written and vice versa, developers do not need to be involved before the BAs actually know what needs to be delivered. Based on requirements from BAs, testers can prepare test scripts while developers are coding along etc.
After the requirements phase there is no strong need for customer presence and thus they can focus on other more pertinent things. The customer basically only needs to be involved for status reviews, approvals etc.
If multiple systems/components/software packages need to be integrated and launched at the same time (internal and/or external) an early design is often required. This is thus suited perfectly to the staged approach of Waterfall.
Architecture, a trade often forgotten or neglected in modern software development, can also be designed better for scalability, overall coherence and completeness since there is a more thorough understanding of all parts of the entire system. Code does not need to be rewritten over and over again, which sometimes can be the case in Scrum and which sometimes results in a piecemeal system.
Project resources are not as critical, since planning and documentation has already been done, thus if a developer drops out, it is easy for a new resource to fill the position and get up to speed quickly and following the plan.
Because the Waterfall method requires upfront planning, software can be launched quickly after development. Estimation of complete timetables and budgets can be done more accurately, which definitely tends to please customers.
Gathering and documenting requirements so the customer understands what they mean is very difficult. Customers are often intimidated by details, and specific details must be provided early in the project before progress can be made. Customers are often not able to visualize an application from a requirements document. Wireframes and mockups will help, but most end users have difficulty understanding these elements in enough detail to clearly visualize the end product.
This problem means that customer might be dissatisfied with their delivered product once it is complete. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until large parts of the project are finished. At that point in time, changes are difficult and costly.
Feedback and testing are deferred until bigger parts of the project is complete. This means that problems or inadequacies can be harder to change without substantial amounts of time and effort.
Some things to consider:
Part 5: Pros and cons of choosing Scrum