What they need to contract with is a project manager and designer. Effectively, the "Architect" for the project. (Architect is a overloaded word, especially in data processing.)
While the goal may be to come up with a set of work items and a schedule that you can then throw labor at to execute, the real task is for this person to take whatever scheme this client has and "talk them down" so to speak. Project their idea on to the hard surface of modern computing. As anyone who has dealt with "end users" and "requirements", what they want, what they need, and what they expect can all be VASTLY different.
This Architects job is to get those three things on the same page to the satisfaction of the client, AND to the satisfaction of the Architect in that the end result implementation has a good chance at success.
This is time of a lot of interaction, ideally some mock ups, perhaps some prototypes, etc. Zillions of use cases, etc. It doesn't have to be an implementation plan, but it has to be done to focus the user on the problem within the constraints of developing software.
Once this part is done, THEN the task of implementation can be approached.
Also, it doesn't have to be complete, as a good Architect should be able to know what can be deferred for later, more detailed specification as long as the major concepts and interactions are laid out as a well described foundation upon which new "features" can later be added.
The primary "failure" of many computer projects is not necessarily the implementation, but rather the expectations of the client. These all need to be well managed and defined up front for the client to feel that the implementation is a success.
The Architects job is to both build and quell the clients enthusiasm as the project takes shape.