Gap Analysis Questionaire


	Unified Configuration Management
Home \| CM Survival \| The CM Portal \| CM About Us \| Email

CM GAP Analysis Questionnaire

GAP Analysis Configuration Management

The following questionnaire form is a generic GAP analysis form to review "Unified" Configuration Management practices across an organisation. The primary focus of this review is to review maturity of change control practices e.g. Change Requests, Defect Tracking, Deployment Management and Version Control.

To support cross-referencing with the IEEE the questions have been grouped into one of four categories i.e. Identification, Management, Status Accounting or Audit.

The recommended scoring strategy is to use a simple score card with rating being highlighted as High Risk (Level Red), Medium Risk (Level Yellow) or Low Risk (Level Green). For example:

Summary GAP Report – Configuration Management
No	GAP Section	Requirement Headline (See Appendix)	Rating

1.1	Identification	Existence of Comprehensive CMP	(No) High Risk
1.2	Identification	Are all Artifacts fully documented (identified)	(Yes) Low Risk
:	:	:

Note: GAP analysis ratings are specific to organisations particular needs. It is recommended that as part of any GAP analysis deliverable, a complete clarification of expectations and reasons for conformance rating should be highlighted in an attached sub-section.

Questionnaire Follows

Section 1 - Identification

(ID) Does the organisation/division have a documented process for identifying their Configuration Management Process e.g. Configuration Management Plan?

Note: CMP should aim to address key areas of CM i.e. Identification, Management, Status Accounting & Audit. This should cover CM process and tools.

(ID) Does the program have in place ongoing mechanisms to identify configuration of all system and CI's (Configuration Items?). Consider source code, components, scripts, property files, technical documentation, testware, cots, patches, hardware etc)?

Note: Identification could be done through documentation or through more automated methods e.g. snapshots, baselines etc.

(ID) Are CI's relationships managed i.e. has the program got the ability to relate the various associated project/system artifacts at a particular point in time and space? For example using a baseline to relate application and property files on a particular system?

(ID) Does the framework have the ability to relate CI's beyond basic system components i.e. does program gave collective baselines? Example: A collective baseline may relate 100's of components residing on distributed systems at a single point in time.

Section 2 - Management

(MG) Is CM Process & Controls integrated into organisations culture.

Note: Typically done through education and training.

(MG) Does organisation use Version Control for CI's (Configuration Items).

(MG) Is Version Control Process Consistent across organisation?

Note: Standardisation is seen as key factor in simplicity and removal of chaos.

(MG) Does Version Control Process utilise formal branching/parallel-engineering strategies to support streamlining and avoid delivery contention.

(MG) Does organisation have formal change request process i.e. approval process.

Note: Include Change Requests, Defect Tracking & Release Requests in this evaluation.

(MG) Is Change Process Consistent across organisation?

Note: Standardisation is seen as key factor in simplicity and removal of chaos.

(MG) Does Program support clear tracking of change status.

Note: Include Change Requests, Defect Tracking & Release Requests in this evaluation.

(MG) Is there a formal request review process i.e. does program have a formal approval/review procedures before accepting request?

Note: Include Change Requests, Defect Tracking & Release Requests in this evaluation.

(MG) Does process use quality gates to ensure best practices followed. Quality gates can be manual sign-off or automated mechanisms to ensure products follow correct (e.g. promotional) life cycle.

(MG) Where practical, does process utilise automation as part of deployment management i.e. builds & releases. Note: Automation is seen as a key mechanism to streamlining delivery and reducing manual error.

(MG) Are all Releases supported with concise version documents (Bill-of-materials)?

(MG) Does organisation use tools for managing workflow to support the CM process?

Note: Workflow tools support activities like assignment, electronic authorisation and process flow.

(MG) Does program have adequate resource and organizational support to support Change Management?

(MG) Is Configuration Management control process independent of divisional self-interest?

Note: An example of divisional self-interest might be an engineering team influencing process to circumvent activity or artefact tracking etc i.e. in the mistaken belief they are saving time.

(MG) Are the various forms of change (for example change requests, defect tracking, version control and deployment management) integrated to support full visibility of change and cause of change (cause and effect).

Note: Consider Change Sets.

(MG) Is process 100% repeatable or traceable? Hence supporting accurate re-engineering, streamlining and enhancing recovery.

(MG) Does organisation employ a Change Control Board to evaluate risk and acceptability of change? Do all changes go through this group.

Section 3 - Status Accounting

(SA) Are status reports being generated regularly to identify status of requests?

Consider Change Requests, Release Requests and Defect Tracking.

(SA) What reports/metrics are being generated?

(SA) Are reports being used proactively as well as reactively?

(SA) What groups use CM reports to support there Job e.g. Security, PM, Resource Planning.

(SA) Does Status Accounting show granularity of state i.e. % complete or position in life cycle? Consider Change Requests, Release Requests and Defect Tracking.

(SA) Does Status Accounting support Management Decision-Making?

Note: Project Managers should be able to use these tools to fully identify progress or slippage.

Note: Senior Managers should be able to review these reports to identify whether groups are meeting required SLA's.

(SA) Do Status Accounting mechanisms support real time needs (opposed to just management)?

Note: Real time information is required to support decision-making during a current change. The kind of facilitating information that we would typically be interested in would include similar changes, similar defect, recent changes etc. Example: Engineers may want to query system to determine when a particular system was last modified, hence supporting maintenance.

(SA) Does Version Control tool provide status accounting capability e.g. Recent changes to CI's, difference to components, baselines, contents of packages etc?

(SA) Does status accounting support unified reporting across both activity and artifacts (items) i.e. do reports show relationship between Activity Requests (e.g. a Change Request) and items delivered or changed (e.g. under version control)?

Section 4 - Audit

(AU) Does organisation have a formal group (e.g. CCB) that is responsible for CM audits?

(AU) Are audits scheduled at regular intervals or at project milestones?

(AU) Does organisation perform CM Process Audits?

Note: Process Audits are intended to analyse effectiveness of the CM process and ultimately lead to better optimisation.

(AU) Does organisation perform Physical Audits?

Note: Physical Audits are intended to check that the identified composition of a system (identified under Change Control) matches the actual physical composition. Example: Checking whether a component in production matches its version-control bill-of-materials.

(AU) Does organisation perform Functional Audits?

Note: Functional Audits are intended to check that the identified functionality (identified in change control) reflect the actual requirements (functional expectations). Note: This form of Audit is actually part of System and Acceptance Testing.