OK, it's been a while of watching the ongoing self-rebuilding of the software industry.  None of us are ever sure how long a software project will take.  None of us knows the expense or the manpower - mythical or otherwise.

A typical attitude of the past decade plus is that the project management approach called "waterfall" is too obsolete to even think about, and that everyone knows what waterfall is and hence why it's lousy.  Not completely convinced of either. Much of the waterfall software development process was driven by military projects in the 1980's, and much of it was codified in Mil-Std/DOD-Std/2167 documents.  Not all of this seems to have survived into the new millennium.

The Interface Control Document is one of the main losses.  For all of the blather about this functional, object oriented, top-down, service-oriented, this piece of the puzzle remains blithely ignored - the glue that was intended to connect systems together.

Whatever you think about a design philosophy, its interfaces are a place to hold its feet to the fire and make it work.  But as I continue to see software project management and design approaches evolve, interface definitions seem almost to have disappeared.  You can't just say a WSDL or other document embodies it.  That's a dodge.  WSDLs help web services slurp lots of data between web applications, but they don't provide any handle on the semantics of the exchange.

Worse, by being effectively typeless, a WSDL can actually make an interface definition less precise and reliable, not more so.

I like Java interfaces a lot, but they may have inadequate documentation to be 'tight.'

Maybe internet RFCs or IEEE protocol standards are a better inspiration.

Whatever the format, I would suggest making an effort to identify the key interfaces in your system and make them a formal part of your project design.  Don't just leave it in the 20th century.