As I claim in The Software Engineering Life Cycle for Outsourced Projects, Part 1, a pure Agile methodology may not be appropriate for a company looking to outsource the development of a software project. A "throw-it-over-the-wall" pure Waterfall model may not be appropriate either. I believe the best model to follow for this type of project is to take a two-phased approach.
The first phase is a definition phase, which includes close collaboration with the contract developer. In this phase the developers and business analysts (people who may work for either the company or the contractor that are required to document requirements and design) work closely with business stakeholders to define requirements, use cases, user interface designs, and support workflows. The result of this phase should be a set of models and documents such as wireframes, use case stories, or system requirements specifications.
Only upon the completion of this phase can the contract developer give an accurate quote and timeline for the development, testing, and deployment of the final solution. The cost of this first phase can be variable, as a good contractor will be contributing some of its most valuable consulting services at this time, but if the dedication from management is there to make it happen upfront, then the timeline can be kept short and contained.
If contract negotiations for the development phase are completed and the project is commissioned, then the contract developer can begin the second phase of coding, configuration, testing, and deployment. Developers shouldn’t disappear behind a wall, however. Constant, frequent review and change won’t be required like in an Agile project, but there still should be defined checkpoints and deliverables – perhaps resembling an iterative SDLC model. User Acceptance criteria and test plans (UAT) should be drawn up at the onset of development, and this should be the final gate for delivery of the project and completion of the development contract. Beyond this, the commissioning company should also have a plan for maintenance and support for the software system. If the plan is to cut the contract developer loose after delivery of the finished system, then steps should be built into the project for the proper training of in-house staff and support resources.
A company can have a software system developed for them by an outside company without dedicating their internal resources for a constant Agile process, while at the same time having confidence that their contract developer is building the system that works for them with a known budget and timeline. It simply requires an appreciation for what really is involved in a successful software project.
For further reading:
Software Development on Handshake 2.0