Our Philosophy of a Product Life Cycle

Not very many people like to be told what to do. From a management perspective, we don't think it's a very good idea either. For one thing, it gives rise to the Not-Invented-Here (NIH) syndrome, which is a natural and fairly invincible source of resistance. Good managers empower their people; help to define what needs to be done (focus vision), provide the necessary resources, then let their people go to it, and hold them accountable. You were hired for your abilities; you should be able to use them freely. That doesn't mean you shouldn't have to think about what's really needed. This PLC is a set of things somebody a some point found they really needed.

While this PLC was being constructed there was a long, hard debate about what should be included and what should be left out. We decided it should be up to the users to decide what was valuable for their specific circumstances. We replaced a three-inch binder full of advice with a simple set of tools: checklists, templates for deliverables, forms. Early in a project, the manager would examine the PLC to decide what was needed.

This model was designed to be used on any development project. Nowhere does it suggest a specific development methodology. It is not object oriented, structured, spiral, evolutionary, incremental, iterative, or waterfall. It can be used with any of those methods. We don't tell you how to do anything, but we do suggest that there's an overall framework of fundamental events. In every project or product, you must:

Convince management that what you want to work on is worth pursuing (Investigation Approval).
Gain approval for staffing and funding (Project Approval).
Have a plan (Schedule Approval).
Build and test your product (Alpha, Beta).
Deliver it to your customers (Release Milestones).

This PLC can help you do all those things well.