Configuration Item Register 1.0.0

Scope

This document describes the logic of the process of storing any project’s product.

The process of storing is mainly focused on the availability of the correct item. Therefore, this information is apt to understand both its readiness and the organizational aspects that produced it.

Quality

These are listed the essential rules for creating and running the system as described in the Configuration Management Strategy:

  1. The chosen system (e.g. SVN ) hall comply with all company’s requirements about safety and security.
  2. The map of directories shall reflect the logic of the project as stated in the referring document (see bottom).
  3. Accesses to the specific areas shall be granted on the personal basis, previous specific authorization of the person accountable for the service (e.g. users, testers, developers etc.).
  4. The concept of assigning (automatically) a unique identifier to each stored items has to be approved. This includes its ability to respond to the challenges created by the product (e.g. maximum number allocable); therefore,  the tools that will be used during the whole project life cycle.
  5. The access and distribution of logs (version history) has to be disciplined as required by company’s policies and then by project’s project’s need. It is important to balance the quest for security with a reasonable grade of freedom, in particular within the developers’ team.

RACI (who does what)[1]

Operation desc./Roles[2] Spr PM BA SME TL Prd Stkhd
Approving the plan for setting the Configuration  Item Register up

I

A

C

C

R

C

C
Planning the audit procedures and timing

C

A

C

C

R

C

C
Appointing the person responsible for the standard maintenance

I

A

C

I

I

I

C

Document structure

Registrar Section

Unique Identifier It could refer to the project, the item (see section 9.2.2 of the Prince2 -2009 edition)

Item version.

 The current version as suggested by standards . his value has to be strongly linked with the status. It is possible that within a single status (draft) there are different versions.

Item Title / code

 The production elements should be titled with the WBS code. (This code could be created in a different time from the initial WBS – see various posts about it)

An important reminder: this system manages also the documents (e.g. plans), so that any reference should consider a code/title that makes easier to spot the nature of the treated item
Date of last Status Change This value is supplied by the versioning system’s logs
Producer Person or team responsible for building (updating or creating) the item.
Customer Stakeholder who ordered the function that needs this item. This reference is necessary for supplying information including marking its priority.
(Sub) System name Just in case there is more than one system with specific address / access policies.
Item Status The condition of the item in the process of production. These values are to be fixed in the Configuration Management Strategy.
Item state It could be useful if the project is focused on legacy code. In this case, the items to be coded are those that will be dismissed (see section 7.3.3.2 of the Prince2 -2009 edition)
Owner / Organization, Organization which possesses the item either for production, leasing or any other form or reason. This entity gets all legal rights on the item.

Technical domains

Product Status Account

Quality Strategy Management

[1] RACI http://en.wikipedia.org/wiki/Responsibility_assignment_matrix.

[2] Spr Sponsor, PM Project manager, BA Business Analyst, TL Technical Leader, Prd Producer, Stkhd Stakeholder