When applying configuration management (CM), do you take a short-term, make-the-deadline approach, or do you think about your project from a more long-term perspective?
SCENARIO A – The obstetrician provides prenatal care, treating the pregnant woman in order to support the development of her fetus. The project perspective in this case is the health of the mother as host. In tandem, the product (if you will) is the fetus, which relies on the systemic health and nutrition provided by its mother for its own health, development, and nurturing environment. Yes, there are many babies born to the world without excellent prenatal care, but are they the healthiest “products”? Lack of prenatal care is associated with a 40 percent increase in the risk of neonatal death overall and a doubling of the risk among women delivering at or after 36 weeks’ gestation. 
SCENARIO B – You are considering buying a first-floor apartment of a multiplex for rental. The upstairs neighbor vacuums right in the middle of your afternoon nap time. The north-side neighbor is undergoing construction, and the noise and debris it creates prevents you from enjoying your space without a face mask and ear plugs. The south-side neighbor has a pet that loves to mark its territory. You can smell it every time you step into the common hallway. Considering this set of neighbors, would you choose to invest your money for this rental apartment?
In both scenarios, the surroundings and environment of the product matter. Risk is introduced in both scenarios – the first realizes risk to project and product, the second poses risk to investment. Most business persons can relate to the terminology of risk. Whenever possible, risk to success must be mitigated.
For such reasons, I believe that an organization should ensure that project-level CM fosters a culture and environment of healthy product CM. I would not attempt to focus solely on a product’s CM without ensuring that the local environment is suitable, vis-à-vis the project. While development of a product may not rely on the happenings at the project level, I have seen very few product successes that are completely unaffected by project conditions. Typically, the disciplined thinking that is expected to be encountered in a CM-educated environment assists development’s progress at the product level. The CM practitioner does not have to convince the project team about CM’s goodness and benefit. CM resources are planned and allocated. The project staff already knows and has relative buy-in to support the performance of CM. CM at the product level is healthiest when CM at the project level is in place. Project CM hosts the product CM environment.
In contrast, it is possible (and sometimes necessary) to seek short-term wins in order to meet customer expectations, milestones, and deliveries.
SCENARIO C – You have to get widget Y out the door on December 15, regardless of what the organization is doing with its CM. To contrast arguments above, we will assume that CM is weak or nonexistent. CM is “the systematic way” to do any process with an output. As the CM practitioner, you know the way to plan CM for widget Y, identify the configuration items (CIs), control system changes, audit and verify configurations, and status account . You know what documentation must be used as inputs and may even be asked to validate them prior to use. You verify configurations prior to testing and monitor results, ensuring that the verification requirements traceability matrix (VRTM) or the requirements tracking tool gets updated. All the steps to manage widget Y’s configuration depend on your expertise irrespective of absent