January, 2018

The Top Questions Executives Should Ask Their Organization

In our last CMsights post we presented the case that Product Configuration Governance (PCG) deserves more attention from the executive office suite beyond what it receives from configuration management (CM) practitioners. But how does a product line executive know when issues of PCG and CM are receiving the managerial oversight they deserve to avoid change orders, service advisories, warranty recalls, or even product performance failures?

CMstat has developed a set of governance-level questions from our 20-plus years of supporting the implementation of CM best practices and software tools across the A&D industry. We often recommend that our customers start with the following questions to evaluate if CM is receiving the attention needed to mitigate risks from failure to deliver products that meet customer requirements.

  1. Which organization and executive office ultimately owns corporate oversight, governance, and accountability for the performance of the product configuration management function? Which manager(s) in these groups have responsibility for the reliability and integrity of product configuration data that other groups consume, enrich, or repurpose?
  2. Does our organization have a clearly stated definition of vision, strategy, and goals for what we seek out of CM? Is the practice of configuration management and change control used for our products, processes and services truly helping us to achieve these goals, or is it simply costing us money?
  3. Do we have a CM plan and when was it written? Does it address the five tenets of CM which include planning, identification, status accounting, change control, and traceability and audit? Who has responsibility for the plan’s maintenance and implementation? How often is it reviewed and updated?
  4. Do we understand the technical benefits and financial value derived from executing the CM plan, as well as our vulnerability and risk for failing to do so? Can we quantify a monetary return on investment (ROI) or financial risk-avoided quotient (RAQ), and what are the appropriate metrics being collected to support this analysis?
  5. How do we measure our maturity level of CM along several axes including core competency, capacity, best practices, industry standards, software tools, training, and implementation? What KPIs do we use and do we have a continuous improvement process in place for tracking them?
  6. For our line of business, what configuration items are or should be under management from an exhaustive list that can include hardware parts, software components, drawings, assemblies, baseline specifications, design requirements, product structure, EBOMs/MBOMs/SBOMs, change requests, change orders, inspections, warranty notifications, test procedures, training materials, service advisories, compliance records, and site-dependent configuration items? Can we justify each item’s designation as a CI?
  7. What software tool(s) do we use for CM? Who owns them and how are they supported, maintained, and integrated with other applications? Do these tools provide us a complete view of product configuration at any point in time in the development cycle or by serial number for as-deployed assets in the field?
  8. Who has access to product configuration data and documents managed by these software tools? Who is authorized to author, view, approve, update, annotate, revise and version the data and documents? What other processes, applications, and suppliers consume or depend on this data and what authority do they each have?
  9. How current is the data and complete is the documentation managed by these tools for all of the information needed outside of product engineering, such as in shop floor tooling, test lab benches, quality assurance, maintenance and repair depots, facility infrastructure, and aftermarket service manuals? Is there a feed-back loop from the data consumers back to the engineering authors?
  10. Who in our organization has live on-demand access to a tree structure representation of the complete product throughout its history? How difficult is it to retrieve or recreate the configuration by serial number of deployed product equipment at each lifecycle stage from as-required, as-designed, as-built, as-tested, as-shipped, as-installed, as-certified, as-provisioned, as-maintained, as-repaired, as-refurbished, and as-retired or as-disposed?
  11. How reliable and robust are our processes for change requests, proposals, orders, notifications, disposition, reporting, tracking, and archiving? How difficult and accurate is it to foresee ahead of time the complete impact and cost of a change before it is made? Is there adequate visibility and control of all the one-to-many, many-to-one, and many-to-many data and object relationships that can be effected by a change?
  12. Do we have a documented, agreed-upon process for dealing with product components as they approach end-of-life or end-of-support? Where is legacy product configuration data held and for how long? Do we have a LOTAR policy for accessing legacy data? How dependent are we on the configuration of IT hardware and software to access this legacy data?

In future CMsights posts throughout 2018 we will unpack a few of the more important questions from the above list, and share real-world example answers from our work within the A&D industry. We expect this will help managers to answer one very important last question: do their organizations need more objective, external help in prioritizing and answering these questions, or can they do this by themselves without undue bias, groupthink, or defensiveness.

If you’re not sure, give CMstat a call at (877) 537-1959 or send an email to information@cmstat.com to request an on-site CM capabilities maturity assessment.

To follow this series subscribe to CMsights by filling out the Subscribe form at the top of the right channel of this page.