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.[1]
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 policy, planning, scheduling, processes, or project management. Assuming noninterference at the project level, you can successfully perform CM on the product in an environment devoid of formal CM constructs. It is possible to produce widget Y on the December 15 target with all requirements satisfied.
In scenario C, I can’t help but point out the fact that widget Y is presented as a standalone effort. Had there been a widget V-W-Z into which widget Y needed to fit, success would be difficult without good project management and interdependent CM like what we find in a configuration control board (CCB). Just imagine if you went forward with widget Y without regard for modifications in the preceding and succeeding builds!
Therefore, I recommend that we straddle the fence between product and project CM. Don’t let poor or absent CM at the project level stifle your ability to perform “the CM way” at the product level. However, realize that product efforts occurring in environments that nurture CM will invariably nurture the product underway, potentially leading to a healthier product. Once the environment is in place, the product CM can begin. [When planning for a CM product, I ensure that I have addressed all tenets of CM through contributions to a project plan, usually drafted by the chief engineer. In fact, because our organization’s program-level policy requires the inclusion of CM content as part of the project plan format, no project gets approval without my planning sections.] With a project plan, the team knows the scope of the project, the timeline, the inputs, the expected product, and where to initiate CM activities in each lifecycle phase.
[1] http://www.guttmacher.org/pubs/journals/3427002.html
About the Author Angela Moore, Certified CM Professional, is a Fortune 500 contractor with 20+ years of experience supporting digital systems engineering through all phases of the lifecycle in the US federal government. She is a subject-matter expert of CM, Business Process Engineering, Information Management, Quality Management, and Knowledge Management. A graduate of Duke University, Ms. Moore lives in southern New Jersey and is the proud wife to Lamott and mother to twins Alex and Jacqui. Her professional motto echoes her passion for the work: “Get it right the first time!”
