Obviously, I can't give a complete treatment of Sponsored Project Management here... whole volumes have been written on the subject, and I don't have the room. However, I can give a summary treatment, covering the important points that all too many small contractors and VARs know little about. Here goes:
This is a rough outline of the steps required to plan and implement a sponsored development project. It's optimized for the independent contractor, and pretty much follows the guidelines that I've used myself for consulting and in numerous companies with structured IS departments. Generally speaking, as you contract for different companies they may have different methodologies, which they may call the "framework", "life cycle", or "methodology", but you can just about go down the list here and translate terminology to get the same results. For example, you can replace "Contractor" with "IS Department" and "Client" with "Business Unit" and this works pretty well for a large business. It also works pretty well for internal development, so long as you understand that you must take on all of the roles.
If you'd like to see what happens to programmers who don't practice sound methodology, take a look at this. Also, I encourage you to read this article on Linuxmanship by Don Marti... although it deals with selling a particular operating system, it's got valuable information for anyone doing any kind of consulting. Another nice link I've found contains Commandments for IT Job Changers.
Note: I've been using this methodology for a number of years now (it's been documented on this website since October 1999, but it was developed in its original form in 1996. I'm gratified to learn that it actually has a name. The December 2001 issue (Vol.34 No.12) of Computer magazine (published by the IEEE Computer Society) describes something amazingly similar in an research feature entitled Function-Class Decomposition: A Hybrid Software Engineering Method. Except for differences in terminology and diagramming (the authors use a new diagramming method, whereas I stick with UML iconography that replaces my earlier use of Data Flow Diagrams and Entity Relationship Diagrams) the technique is the same.
In the simplest possible terms the technique is this: when engineering any system, object-oriented or not, design from the top down, Refine and implement from the bottom up.
Before We Begin