One thing that may not be apparent when transitioning from a programmer / developer to an independent consultant is the importance of business processes. Just because you can program circles around your average developer doesn't mean you can successfully run a successful and profitable business as an independent consultant.
As an independent consultant, you need to focus a lot on your business processes. Just as you profile an application for bottlenecks, you also need to profile your business processes for bottlenecks. You not only want to provide professional development services to your customers, but you also want to provide them in a timely, consistent, and enjoyable manner that allows your customers to feel empowered throughout the entire process.
Agile modeling and iterative development as explained in Craig Larman's Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Interative Development provides a good overview for someone wanting to improve his/her development and business processes. It provides a real practical overview of UML (Agile Modeling) and how to handle evolutionary requirements gathering and the development of the “system” in an iterative development approach that embraces changing requirements and continuous user feedback.
Agile modeling views UML as a sketch, not as a blueprint or documentation. The purpose of modeling (sketching UML, ..) is primarily to understand, not to document. I, personally, prefer to do all my modeling on a white board and then take a snapshot of it with my Canon Powershot G3 and then print it out with my Canon i9100 for reference :) Rarely do I use a UML tool for the initial modeling. For me, I end up getting wrapped up in the tool rather than the process of understanding. Most of my professionally UML modeling diagrams are reversed engineered from my code.
Another key practice emphasized in the Applying UML and Patterns book is iterative and evolutionary development. “In this lifecycle approach, development is organized into a series of short, fixed-length (for example, three-week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable partial system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.“
An important note is that “the output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system.“
It is also important to note that “iterations are timeboxed, or fixed in length - date slippage is illegal. If it seems that it will be difficult to meet the deadline, the recommended response is to de-scope - remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date.“
I will be talking continuously about Craig Larman's Applying UML and Patterns (3rd Edition) in the future as it focuses not only on the agile and iterative development, but also on object-oriented analysis and design. Good stuff for those programmers and developers considering a future as an independent consultant.