Configuration Management and PRINCE2
Configuration management, as it is used within a PRINCE2 project, is little more than version control and is vital for the success of your project.
Configuration management needs to be a permanent part of your organization, as the products created within a particular product will need to continue for the rest of their operational life, where changes, upgrades, servicing and maintenance may continue to occur.
To the many individuals who need to study PRINCE2, the term configuration management strikes fear in their hearts – as a minimum may consider it mundane and boring! I say it is ‘business critical’, so listen up while I make my case…
In a typical PRINCE2 project, it is project support that is responsible for providing configuration management.
However, some organizations may have a project management office (PMO) offering standard services across all projects.
Using configuration management on your project
Software configuration management is intended to control the configuration of a software product or system throughout the life cycle of the product, and that includes the project that builds it.
Software development organizations will have a robust software configuration management process in place; all you need to do is to determine the activities, tasks, milestones, and deliverables your project must plan to be compliant.
Project managers who don’t have the advantage of an established software configuration management process will have to implement one as part of their project.
The advantage of doing so is twofold: you maintain control of the applications, networks, and manuals that are compiled for the system and you establish a re-usable process that can maintain control of the system throughout its lifecycle.
The process you leave behind can also be used by other projects. Not implementing some sort of configuration management process will lead to problems when you try to produce builds and patch the software.
Typical of this type of problem is the software bug that was fixed by an earlier build recurring in a subsequent build, or the 1 hour build that takes days.
Configuration management approaches
There are two ways to approach the issue of configuration management where there is no existing process.
You can either make the definition and implementation of a process part of the scope of the project, or you can implement just enough to satisfy the needs of the project and leave the implementation of a proper process for another project.
Your first step should be to evaluate the software environment your project is inheriting. I’m assuming here that your project isn’t the first software development project your organization has ever undertaken.
If it is, you’ll need to make the establishment of a software configuration management process a part of the implementation of the software development environment.
Configuration management tools
The backbone of a software development shop is the source library.
The source library is also the tool that must support any configuration management processes you wish to implement. The source library should support baselining with the ability to store and track different branches (for example, development branch), and to merge a fix across multiple branches.
It should also support running scripts such as the build script used to compile a configuration of your software application. Analyze the source library tool in your organization to determine its fitness for use to support your project.
Unless your project has unique requirements these tools should satisfy your requirements. Your release management process will identify any special needs your project has in this area; more about the release management process later.
Configuration management librarian
Your next requirement will be a librarian who is responsible for controlling the checking in of code, software builds, and releases. Checking the code out is never the issue; code that is in the source library is controlled by the library tool. It is only after the code is checked out that the fun begins.
The librarian should maintain the standards set for checking code back into the library and have your support for their enforcement. There are lots of tools out there called “librarian software”. Don’t confuse the two.
Librarian software may be a great asset to your software librarian but will not perform the functions you will call on your librarian for. Let me give you an example.
Let’s say you’ve chosen an iterative methodology for your project. You’ll need to perform at least one build per iteration (more if you perform any “emergency” builds) and each of these builds is an opportunity to introduce new bugs into the release.
Satisfying the need to perform builds by assigning build duties to one of the development team who doesn’t have experience as a librarian is going to lead to delays and frustrations as builds fail, deadlines are missed, and the team searches for someone to blame for this mess.
The person who will be held responsible by your project sponsors is you and you could have avoided this by identifying an experienced software librarian to control the source, perform the builds, and be responsible for the releases.
Establish, a set of criteria that code, must meet before it can be checked into the library at a minimum code must compile error free before being checked in.
Compiler warnings should be analyzed to determine which notifications are acceptable and which must be eliminated to avoid problems with the release. Other criteria that you may wish to establish can include: design reviews, code walkthroughs, and system testing.
You may also want to establish standards for commenting on the code and identifying bug fixes or approved changes in the header as part of the criteria for check-in. Such standards can be enforced during a code walk-through.
Don’t forget to include documentation as part of the configurable product. Business requirements documents, functional specifications, and especially user manuals are all part of the product you are building and should all be under the same control as the source code.
A change to the design of a software feature should trigger a change in the functional specification, detail design document, test cases, database data dictionary, and user manual and each artifact should be identified with the unique identifier of the change.
Here’s a tip to help the librarian with build issues. Choosing a good continuous integration tool such as hudson can eliminate an awful lot of anxiety at release time. Continuous integration packages can be configured to perform builds at scheduled intervals, whenever someone checks code into the library, manually, or any combination of these.
The theory behind these tools is that the librarian won’t be wrestling with code that can’t be integrated with the application at release time, the developer responsible for new code will have to trouble shoot integration issues in order to check their code in.
The criteria for checking code into the source library should be part of a documented release management process.
The release management process should be the roadmap that takes the team from an empty library to a working software system. Include the steps to take to ready the library for the build, steps to prepare the various environments for deployment of the release, steps to take for emergency releases, criteria for emergency releases, and roles and responsibilities.
Gate reviews
Gate review meetings which precede releases should include the criteria specified in the release process as gating criteria. One process may or may not cover cutover activities when the system is released to the production environment.
If it does, special criteria for release to production should be noted and the rollback strategy defined. The release process should identify all the tasks necessary for building the software system, preparation of the environments the system will be installed in, and the installation of any data required for testing.
Establish code freezes as a part of your release process. The code freeze will require developers to complete coding, compiling and testing in advance of the final build and release of the software. The freeze means that code which misses the deadline for check-in must wait until the next build for inclusion, or the build must be delayed.
Enforcement of the freeze will be up to the librarian but any corrective actions will be your responsibility.
Penalties for missing a build/release will be an added incentive to programmers not to miss deadlines. A decision to proceed with a build and release without part of the software will require a re-cast of the project plan to include the missing software.
Set the criteria for an emergency release in your release process. Emergency releases may be required even when you use the waterfall method of software development.
An emergency release will require the librarian to perform unplanned work to include the emergency fix into the library, perform the necessary merges, perform the emergency build, and release the emergency build to the various environments.
This unplanned work may impact on other librarian work especially if the librarian performs programmer duties in addition to their librarian duties. Emergency builds should always be negotiated with you and you should determine whether the build under consideration would put the project behind schedule.
Check out your organization’s knowledge base for any artifacts that can be re-used such as release processes, cutover plans, etc. and then make the necessary modifications to meet your project’s requirements.
Adapting an existing release process may be as simple as changing a few names or dates, or it may be so extensive that it makes sense to ignore it and start from scratch. The idea here is to eliminate as much work as possible while still meeting the project’s needs.
Making all these plans doesn’t mean that you’ll have a rock solid software configuration management (SCM) process. Still, it will mean that you have provided your project with all the pieces critical for a successful build and implementation of the software system.
If the project manager has no such support, it will have to ensure configuration management services themselves, although this is likely to happen in some cases.
An organization will typically have configuration management because its business will have already determined its need as a central management control.
To give you a few examples of why configuration management is mandatory, consider the following invented questions being asked (and the negative impact that they could have on your organization):
- I’ve found a draft bill of materials for a test rig – is it the rig our project will use?
- We need help finding the widget specification; we know it was created, but where?
- Sue says she has just seen one of the team modifying a test document that management had already signed off on – who gave them the authority to change it?
- We’ve got three design documents with no version information – which one is the latest?
- Dave says he remembers giving the widget specification to somebody – but who was it?
- Who was the person or people who produced these designs so that we could check them with them?
Let us now look at particular activity points within PRINCE2 where configuration management will be used:
Prepare the change management approach.
The configuration management plan is created here. The project manager is to liaise with project support to discuss how the project will use the configuration management system.
Set up the project controls.
This takes information from the project plan and adds the project filing structure to the configuration management plan. Your configuration management system may already have these facilities.
Authorize work packages
update the configuration item record to “under development” – project support will typically do this. Ensure the work package contains information regarding how version control will work for the developer, obtaining copies of products or product descriptions, submission of the product to project support, and passing product status information.
Review work package status.
Capturing “actuals” and updating the status of products in the configuration item records (CIR). Project support can provide a product status account if needed.
Capture and examine issues and risks.
The project manager will do this, but project support could receive and document all issues and maintain the issue register.
Review the stage status.
Project manager and project support to check configuration item record to ensure that all products have the status of completed/authorized.
Take corrective action.
Project support to make any products or their copies available, add new copies to the configuration item records and update configuration item records for any status changes.
Escalate issues or risks.
Project support to update configuration item record status and add links for the related issue.
Receive the completed work package.
Project support to update the configuration item record to a status of ‘completed’. The product is now baselined if this has yet to occur.
Execute a work package.
Specialist team to advise project support to update each product’s configuration item record status (this may have been done via checkpoints via the project manager).
Deliver a work package.
Project support to handle the return of completed products (if appropriate) and to assist project assurance in confirming customer and/or user acceptance of products.
Report stage end.
Project support with the assistance of project assurance to confirm the configuration item record is the same as the actual status of products by carrying out a configuration audit. Also, check that version numbers are correct and updated.
Produce an exception plan.
Project support will provide a product status account of products to be replaced or incomplete. New configuration item records will be created if needed.
Prepare planned closure and hand over products.
Configuration item records are checked for completeness and used as input to the product status account – confirmation from the customer’s configuration management records that all products are approved.
Refer to the change management approach for how the products will be handed over to those with support and operational responsibilities. Carry out a configuration audit to check that all products are approved and that each complies with the status shown on their configuration item records.
Product-based planning technique.
This technique is used when creating the project, stage, and team plans. PRINCE2 states that a product description and the configuration item record should be made once the need for a product is recognized.
This will generally occur for the first time when creating the relevant plan where such a product has been identified.
As each stage plan is created, new or modified product descriptions and their new/updated configuration item records will be made.
The configuration item record is created regarding the method and process in the change management approach.
Configuration management
The PRINCE2 manual needs to clarify how and when configuration management is used.
In particular, the manual does not list in one place the many activities and how configuration management is used and applied. The PRINCE2 configuration management is covered in the change theme and is an excellent introduction to the main aspects that must be considered.
Configuration management is business-critical. If you think it’s just “admin”, stop reading now… this blog is intended to give you a flavour of the dynamics of configuration management within a PRINCE2 project.
Remember to scale the following information steps, including how formally each step is done.
The change management approach.
The PRINCE2 change management approach is created in the initiating a project process. The project manager liaises with the configuration librarian to discuss how the project will use and apply the PRINCE2 configuration management system.
The change management approach is drawn up. Remember, it is a strategy – it describes how to use and apply configuration management for this project.
Let’s now deal with crucial points within a project where PRINCE2 configuration management will be used. Oh yes, and remember that project support generally supplies it.
Authorize a work package. Update the configuration item record to “under development” – the configuration librarian will do this. Ensure that the work package contains information regarding:
- how version control will work for the developer
how to obtain copies of products or product descriptions
how the submission of the product to the configuration librarian will occur
how will passing product status information back to the configuration librarian occur?
Assessing progress. Capturing “actuals” and updating the status of products within the configuration management records (CIR).
If needed, the configuration librarian can provide a product status account (PSA). As the name suggests, this is a report of the status of products in the PRINCE2 configuration management record system so that these can be checked against the real world.
If correct, then this confirms the actual status.
Capturing and examining project issues and risks. Project Support/configuration librarian (they usually provide PRINCE2 configuration management) could receive/document all issues and maintain the issue log.
Reviewing stage status. Requesting a product status account. This is typically done at the end of a PRINCE2 stage but may be requested at any time. The project manager and configuration management (usually provided by project support) check the configuration item record to ensure all products have status = completed as anticipated.
Take corrective action. This is the PRINCE2 project manager taking any steps needed – providing the project/stage is forecast to be within tolerance. As a result of this, there may be changes to work already underway or future planned work.
Remember, without the project board’s agreement, the project manager can’t make any changes to “baselined” products, including their PRINCE2 product descriptions.
The configuration librarian creates any products or their copies available, adds new documents to the configuration item record, and updates the configuration item record for any status changes.
Escalating project issues. The project manager is now forecasting that tolerance is to be exceeded. This may result from an issue or advice of a new risk. The configuration librarian will update the configuration item record status and add links for any related issue.
Receiving completed work package. The specialist team or team manager must agree that a particular work package will be started. Configuration librarian to update the configuration item record to a status of ‘completed’.
Configuration management ensures that all the work package products have passed their quality check and have been approved. The product is now baselined if it still needs to be done in assessing progress.
Execute a work package. Specialist team to advise the Configuration Librarian to update each product’s configuration item record status (this may have been done via checkpoint reports given to the project manager).
As each product is approved and provided its physical state allows, it may be returned to their configuration librarian at this time. Alternatively, if its physical state allows, the actual product may be returned once the work package is returned and confirmed as complete – coming up next.
Delivering a work package (back to the project manager). Configuration management via the librarian to handle the return of completed products (if appropriate) and to assist project assurance in confirming customer/user acceptance of products.
Reporting the stage end. With the assistance of project assurance, the configuration management librarian confirms that the configuration item record is the same as the actual status of products by carrying out a configuration management audit.
Also, check that version numbers are correct/updated.
Producing an exception plan. Configuration librarian will provide a product status account of products to be replaced/incomplete. New configuration item records are created if needed. Remember, all future products product descriptions are at “draft” status until the project board approves the plan containing them.
Closing a project. Configuration item record checked for completeness and used as an input to product status account – confirmation from customers’ configuration management records that all products are approved.
Refer to the change management approach for how the products are to be handed over to those with support/operational responsibilities. This is likely an item in follow-on action recommendations.
Conduct a configuration management audit to ensure all products are approved and comply with their configuration item record(s).
Define and analyze the products. This occurs in the product-based planning technique. The configuration item record is created regarding the change management approach.
In PRINCE2, all plans are documents, and the product-based planning technique (contained within the plans theme), is used to create those documents. It is here that configuration management will need to be involved in the initial (or updating/refinement) of each configuration item record.
Configuration management summary.
Please don’t forget these key facts:
configuration management is a tool and a service
configuration management is mandatory
configuration management will be used for all specialist products
configuration management will be used for all management products – except the registers and logs.
Within PRINCE2, configuration management is basically “version control”, – but consider how configuration management will need to do the following “in practice”:
Configuration management is a service – so it must be a permanent part of your organization – before and after the project even exists – forever, in fact – even beyond the product life – (consider, just because you run an old system or a car, imagine how you’d feel to be told: “we don’t support that anymore”!
Manage, track and keep control of all the products
Have a library with a structure so that each product’s status can be recorded, control access to each product, and how it will be stored in a secure way (when appropriate).
A suitable system for logging, tracking, and filling product issues (which includes changes).
On a practical basis, how configuration management will ensure that products are identified, booked in and booked out, and how copies will be dealt with (mostly with documents). Scale the whole thing. If a locked filing cabinet in the corner of an office is appropriate – with a proper human interface – then this is acceptable.
The use of configuration management.
Prepare the change management approach
The change management approach is created. The project manager to liaise with the configuration librarian to discuss how the project will use the configuration management system.
Setting up project controls
This takes information from the project plan and adds the project filing structure to the configuration management plan. Configuration management systems may already have these facilities.
Authorize a work package
Update the configuration item record to “under development” configuration librarian will do this.
Ensure the work package contains information regarding how version control will work for the developer, obtaining copies of products or product descriptions, submitting the configuration librarian, and passing product status information.
Review work package status
Capturing “actuals” and updating the status of products via their configuration item record. Configuration librarian can provide a product status account if needed.
The configuration librarian could receive/document all issues and maintain the Issue Log.
The project manager and/or the configuration librarian will check configuration item records to ensure all products are completed.
Configuration librarian to make any products or their copies available, add new copies to the configuration item records and update relevant configuration item records for any status changes.
Escalate issues and risks.
Configuration librarian to update configuration item record status and add links for related issues.
Receive completed work packages from the configuration librarian to update the configuration item record to a status of ‘completed’. The product is now baselined if it still needs to be done.
Specialist team to advise the configuration librarian to update each product’s configuration item record status (this may have been done via checkpoint reports and sent to the project manager).
The configuration librarian handles the return of completed products (if appropriate) and assists project assurance in confirming the customer/user acceptance of products.
Configuration librarian, with the assistance of project assurance, to confirm the configuration item record is the same as the actual status of products by carrying out a configuration audit. Also, check that version numbers are correct or have been updated.
Configuration librarian will provide a product status account of products to be replaced/incomplete.
New configuration item records are created if needed.
Hand over products
Configuration item records checked for completeness and used as input to product status account – confirmation from customers’ configuration management records that all products are approved.
Refer to the change management approach for how the products will be handed over to those with support/operational responsibilities. Conduct a configuration audit to ensure all products are approved and comply with their configuration item records.
PRINCE2 product-based planning technique
The configuration item record is created concerning the change management approach:
– cm procedure
– cm system/tools links
– issue and change control procedure
– tools and techniques
– records
– reporting
– the timing of configuration management and issue and change control activities
– roles and responsibilities
– scales for priority and severity
– project identifier
– type of product
– product title
– latest version number
– product description
– life cycle steps for product
– ‘owner’ of the product
– product creator
– date allocated
– library/location where kept
– product source
– links to related products
– status
– copyholders and potential users
– references to issues (if any) that caused a change to this product
– any relevant correspondence
– product status account
– project name
– product type
– product identifier
– version number
– product description – baseline date
– product – baseline date
– list of related products
– date copy of the product was issued for a change
– the planned date for the following baseline
– the planned date for the next release
– relevant notes (change pending/under review)
Authorize a work package.
Update the configuration item record to “under development” – the configuration librarian will do this. Ensure that the work package contains information regarding:
How version control will work for the developer
How do we obtain copies of products or product descriptions?
How submission of the product to the configuration librarian will occur
How will passing product status information back to the configuration librarian occur?
Assessing progress. Capturing “actuals” and updating the status of products within the configuration management records (CIR).
If needed, the configuration librarian can provide a product status account (PSA). As the name suggests, this is a report of the status of products in the PRINCE2 configuration management record system so that these can be checked against the real world.
If correct, then this confirms the actual status.
Capturing and examining project issues and risks.
The project support/configuration librarian (they usually provide PRINCE2 configuration management) could receive/document all issues and maintain the issue log.
Reviewing stage status.
Requesting a product status account. This is typically done at the end of a PRINCE2 stage but may be requested at any time. The project manager and configuration management (usually provided by project support) check the configuration item record to ensure all products have status = completed as anticipated.
Take corrective action.
This is the PRINCE2 project manager taking any steps needed – providing the project/stage is forecast to be within tolerance. As a result, there may be changes to work already underway or future planned work.
Remember, without the project board’s agreement, the project manager can’t make any changes to “baselined” products, including their PRINCE2 product descriptions. The configuration librarian creates any products or their copies available, adds new documents to the configuration item record, and updates CIR for any status changes.
Escalating project issues.
The project manager is now forecasting that tolerance is to be exceeded. This may result from an issue or advice of a new risk. The configuration librarian will update the configuration item record status and add links for any related issue.
Receiving completed work package.
The specialist team or team manager must agree that a particular work package will be started. Configuration librarian to update the configuration item record to a status of ‘completed’.
Configuration management ensures that all the work package products have passed their quality check and have been approved. The product is now baselined if it still needs to be done in assessing progress.
Execute a work package.
Specialist team to advise the configuration librarian to update each product’s configuration item record status (this may have been done via checkpoint reports given to the project manager). As each product is approved and provided its physical state allows, it may be returned to their configuration librarian at this time.
Alternatively, if its physical state allows, the actual product may be returned once the work package is returned and confirmed as complete – coming up next.
Delivering a work package (back to the pm).
Configuration management via the librarian to handle the return of completed products (if appropriate) and to assist project assurance in confirming customer/user acceptance of products.
Reporting the stage end.
With the assistance of project assurance, the configuration management librarian confirms that the car is the same as the actual status of the products by carrying out a configuration management audit. Also, check that version numbers are correct/updated.
Producing an exception plan. Configuration librarian will provide a product status account of products to be replaced/incomplete. New configuration item records are created if needed. Remember, all future products product descriptions are at “draft” status until the project board approves the plan containing them.
Closing a project.
Configuration Item Record checked for completeness and used as input to product status account – confirmation from customers’ configuration management records that all products are approved. Refer to the change management approach for how the products will be handed over to those with support/operational responsibilities.
This is likely an item in follow-on action recommendations.
Conduct a configuration management audit to ensure all products are approved and comply with their configuration item record.
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
