Project Management vs. Configuration Management
February 2, 2009 | Author: PM Hut | Filed under: Miscellaneous
Project Management vs. Configuration Management
By Oakleigh Consulting Ltd
Project Management has a basic requirement to deliver products ‘on-time’ and ‘within budget’. IT development projects, on the other hand, take place against a background of changes to: original specification, additional functionality, user requirements and so on. This can present real conflict where change is not managed effectively.
Configuration Management (CM) provides an effective management tool by considering the impact of change across the wider project environment and assessing this against:
- Project’s business case
- Organisation’s business strategy
- Whole programme timescales / costs
Configuration Management is valuable therefore on projects where IS/IT systems are being introduced to deliver against an organisation’s business goals and objectives. The bigger and more complex the system being delivered then the greater the need to exercise such control.
Configuration Management consists of four basic components:
- Identification of Configuration Items
- A Change Control mechanism
- Audit procedures
- Configuration status reporting
As Configuration Management has matured as a concept its usage has been extended to cover more than just IT system development:
“Configuration Management embodies a set of techniques used to help define, communicate and control the evolution of a product or system through its concept, development, implementation and maintenance phases” (Kerzner, H., Project Management.)
Configuration Management Provides Traceability of Change
We can use Configuration Management to identify the current details about any part of a system and record any changes that take place over time. We can also hold details of any changes or enhancements that are proposed or are in course of being implemented. Configuration Management therefore provides traceability of changes through a system’s life-cycle.
This is enshrined in the British Standard Code of Practice for Configuration Management:
[Configuration Management is] the totality and inter-relationship of the hardware, software, firmware, services and supplies required for the successful operation of a computer-based system at a given reference point in time…
…It therefore permits the retrospective reconstruction of a system whenever necessary.
Why is Configuration Management Needed?
Two fundamental developments are affecting IS/IT development projects, especially in the public sector:
- Adoption of PRINCE II means that most planning is now ‘product based’: These products are subject to change and amended requirements and are therefore ‘configuration items’, which must be managed through Configuration Management.
- IS/IT projects linked to the business objectives of the organisation: IT developments are no longer isolated and run totally within the IT department. They must fulfil cost / benefit justification and have viable business goals based on those of the organisation. Any change request to the project must therefore have its impact considered across a wider perspective.
Adoption of Configuration Management can assist by:
- Identifying the project’s deliverables;
- Setting the project’s business objectives
- Ensuring that each configuration item meets its quality criteria;
- Encouraging user involvement by:
- Introducing Change Control
- Informing users of changes
- Impact analysis of changes across organisation.
Additionally, Software development is increasingly being outsourced and the processes for managing change will become increasingly complex. The boundaries between user, supplier, manufacturer and service provider become more blurred. This will require the formal adoption of improved change control through the use of Configuration Management.
Sadly, many projects apply a watered down form of Configuration Management to only their internal documentation assets and assume that management of the deliverables will be handled by the Supplier. Such an approach is short-sighted, Configuration Management should cover the whole product life-cycle and any impact analysis should take account of the organisation’s business objectives and the wider programme environment. If this is offloaded onto the supplier then it is unlikely that any impact analysis will take account of anything other than the narrow considerations of the immediate product and its delivery.
Conclusion
Projects must take Configuration Management seriously and manage assets on a life-cycle basis not just for the duration of the delivery phase. Outsourced IS / IT development projects should look at extending the scope of Configuration Management to include all configuration items and to work closely with the supplier to ensure that any impact analysis includes wider organisation considerations.
Oakleigh Consulting Ltd has wide experience of configuration management and has assisted its clients in the practicalities of applying change controls and managements as part of the development process.
If you have any questions about the subjects covered in this white paper or you would like to find out more about how Oakleigh Consulting could help your organisation, please contact us on 0161 835 4100 or email us.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.










