In his guest post for Handshake 2.0, The Software Engineering Life Cycle, Ryan Hagan suggests that the Waterfall model for software development is only appropriate for "ordering software to see a finished project sometime in the future."
To be even able to “order” software assumes that a company must have invested a great deal of time in defining what that software should be. If a company does make an attempt to define a software system on their own without consulting with developers, then likely they have "unicorns" in the requirements spec – features that sound nice on paper and may even be possible, but will raise the complexity (read: cost and risk) to an unbearable level. This might seem on first glance as if a Waterfall approach would lead to wasted effort or uncertainty, but to me, this isn't a problem with the model itself, but with the sponsoring company's management of the initiative.
Likewise, I don't believe that the Agile model is the answer for a project like this either. I assert that an Agile model will have two specific disadvantages for a company whose business may be in some industry other than IT. First, it can place too much demand for the dedication of internal resources for constant review and testing. Secondly, it's too difficult to set an end-to-end budget and timeline for what it will ultimately take to see a finished product.
My company, Vision Point Systems, is a contract software and systems engineering company. Sometimes it’s like we’re mercenaries. We’ll work on software projects for other organizations who either don’t have an in-house IT/developer staff, or who need a temporary boost to support a special project. From my perspective as a contractor, there is no way that I can give a full end-to-end budgetary estimate or timeline unless the contracting company comes to the table with a really solid idea of the scope of the software system they want.
In The Software Engineering Lifecycle for Outsourced Projects, Part 2, I lay out the model that I believe any company looking to outsource a software project should follow.
For further reading:
Software Development on Handshake 2.0