I build guitars.

I'm also a software engineer and project manager for a large manufacturing firm and often find myself consumed with implementing large, multi-stage IT projects (macro projects). I also spend a fair amount of time handling requests for enhancements or upgrades. Often these are short duration projects that can be completed quickly and only involve a handful of stakeholders (micro projects). As I reflect on the nature of my work (in and out of the office) I realize that many of my activities and hobbies could be classified as micro projects.

Some clarification: most people can conceptually understand a large project – many stakeholders and participants, a long duration, often highly complex with a substantial budget. A small project, by accepted definition, is typically a one to six month project with a limited scope, budget and only a few stakeholders. A micro project, on the other hand, could be defined as even smaller – less than a month of effort and often executed by a single person. The budget, scope and risk tend to be much more intrinsically manageable than the large, multi-year project.

So why manage the micro project? The answer is in proportionality. The number of micro projects a person is faced with can be much higher than the large scale projects that usually get the formal attention. The impact of schedule delays or budget over-runs, while not having the same scale of impact that would affect a larger project, can, when taken in the aggregate, add up to a significant factor in determining success over time.

Which brings me back to guitars. I have build about a dozen over the years averaging one per year. I've found that the estimate of effort is somewhere between 40 and 80 hours of labor, plus an additional 10% in planning and design. This fits the category of micro project and the activity lends itself well to some disciplined project management.

Managing Scope

My first guitar building projects involved making new electric guitar body for an existing guitar. Seems simple enough, but I failed to define the project scope at the onset and found that scope creep took a significant toll on the deadline. My original intention was simply to find a nice piece of maple and carve/route the body to accept the current neck and hardware. During the execution phase of the project I determined that replacing some of the hardware (the pickups and some electronics) would greatly improve the final product. Unfortunately, my carving had already progressed to the point where I now needed to fill in some areas and develop alternative designs in order to accommodate my scope change. The whole project took three times as long as I anticipated and the cost was way out of line with my expectations.

The Sequence Diagram

Most of my guitar projects today involve the design and development of three distinct components: the neck, the body and the electronics. There are numerous subcomponents to each of these, but the main point is that, in most cases, these top level categories can be developed independently with an integration phase occurring near the end of the project lifecycle. I have found though experience that either the neck or the body development will fall on the critical path, depending on the complexity of the original specification. Performing the analysis up front saves a considerable amount of time in completing the project. The activity sequences that fall outside of the critical path usually have enough float to allow for flexibility in response to conditions on the ground (or in this case, in my garage/workshop). If it's too hot (or cold) for woodwork, I can shift to developing the electronics. If conditions are good, I can concentrate on critical path activities and shift to non-critical activities while I'm waiting for paint or lacquer to dry, etc. I've found that thinking in these terms and developing a plan allows me to complete the final project earlier and more efficiently.

The Project Plan

Each micro project becomes a learning experience. The lessons I've taken away from my guitar building projects are translatable to my everyday professional responsibilities. It boils down to this: have a plan; get agreement on the plan; stick to the plan if possible, if not, then redo the plan and start again; breakdown the activities and sequence them; map the execution of the project to the plan and activities; and finally, capture what you've learned from the project.

Effectively managing the micro project will promote efficiency improvements for any enterprise, personal or otherwise. Perhaps the improvement is only incremental and the argument can be (and will be) made that the increased effort is not worth the incremental gain. But the value is in the aggregated improvement over time and, I would argue, in the lessons learned from managing each project no matter how small.