Analyze This!

I was considering changes for a website for a side project and almost missed a crucial part: business analysis.

My entrepreneurial experience goes way back. Though most side projects have been in some sort of job + hobby capacity (a "jobbie" according to Carol Roth's book), a recurring lesson for "gigs," corporate life, and  school projects or independent research (I read leadership, technical, and technical leadership books for fun) is to clarify expectations up front. This early analysis helps avoid huge issues later on.

Project managers use a project charter and scope statement. Clients or internal business units have business requirements,  business analysts (BAs) write functional requirements, and systems analysts (and BAs) or system architects may create system requirements or technical specifications. Scrum masters and other agile practitioners (is that a small "a" or big "A?") rely on user stories. Recipes, blueprints, directions, user guides, and instructions all fall into the bucket of analysis and/or up front communication. Pause. Evaluate. Understand. Then execute.

Now with all this being said, why is it did I practically skip all this and attempt to start hacking away at some chunks of HTML? Code monkeys, techies, or uber geeks love to either play with the code or want to solve things as fast as possible (read about "Rand's incrementalists"). Perhaps the dark side of the power to manipulate  markup, code, or systems will continue to tempt knowledge workers, programmers, and other implementers.

I'll stay in the light and do some proper analysis and documentation up front. The balance between analysis and coding could make a whole other post or even book!