1. Change,Configuration and Release Management
Ed McMahon
Chair, CMSG
October 2001
The only Constant is Change
Name
Thank you for Allowing me to present to you this evening.
Sadly it is only my voice as my colleague cannot be here
I shall try to make this as interesting as I can for you.
It has been some time since I have been in front of the camera as I am not classed as very photogenic. I shall try to ignore it as I have to admit that it does make me nervous.
I have no problem with questions being asked during the presentation however I shall be around for a time afterwards for the question and answer session.
If you believe, agree or even understand the statement on the screen you will begin to understand the need to manage Change and this is one of the major reasons for the CMSG’s existence.

2. CMSG: Aims and Objectives
To be the voice of CM in the UK
To promote the disciplines of Change, Configuration and Release Management
To actively pursue the establishment of standards
To introduce ISEB approved education and examinations…..
WHY?
Talk through.
CM in this context is synonymous with both Change and Configuration.
There is an esoteric argument about which comes first. Is Configuration part of Change or is Change part of Configuration.
Personally I do not think that it matters as one cannot be accomplished properly without the other.
However we exist to promote these disciplines within the industry.
WHY

3. BSI PD0005 Service Management framework
Service Design & Management Processes
Security
Service Level Management
Capacity
Management
Management
Service Reporting
Availability
& Service
Control Processes
Financial
Continuity
Management
Configuration Management
Change Management
Release
Relationship
Processes
Processes
Because they are seen as necessary, critical, central and a key building block in the overall Service Management Framework.
I would argue that without mature Change, Configuration and Release Management processes there will be a potential severe lack of quality in any development programme or project as there will not exist the details with which to audit the system(s).
As we see the Service Management Framework gain greater acceptance in the industry we must therefore better define what is meant by these discplines and where they fit.
It is not only Service Management.
Resolution Processes
Business
Relationship
Management
Release
Incident Management
Management
Problem Management
Supplier
Management
Automation

4. Projects & PRINCE Organisation Change Control Plans Configuration
Controls
Stages
Management
of Risk
Quality in a
project
environment
Configuration
Change
Control
Effective Project and Programme Management is also dependent upon Change and Configuration and, with the increased demand of faster products to market, Release Management should also probably be a segment of this diagram
as, of course, should Testing.
Source: OGC’s PRINCE ®
methodology
PRINCE is a registered
trademark of OGC

5. Why? Related processes with a direct impact on Quality
Essential disciplines that must be planned for and
Implemented early in the Lifecycle
Provides key information and input to
Project Management
Testing
Quality Management
Audit and Verification.
So the reasons why the group exists is because these disciplines have…
Talk through.
The group is a voluntary group like most other SIGS and the work is done by volunteers in their spare time.
To fulfil our objectives we

6. Accomplishing these Objectives?
Day events and seminars
Running introductory sessions on the disciplines
Presentations at other SIGS
Introduction of an education syllabus
Linking with ITIL and the ISM Levels.
Try to do the following:
AFTER TALKING THROUGH
Of Course we have the usual problems and issues that all other SIGS have.

7. Problems and Issues Time. Committee work is voluntary
Money. Group is self financing.
Position. Not seen by industry OR
Seen but not recognised as effective.
Talk through.
Position. It is hoped that the new relaunched BCS will bring about improvements or advancements in the way the industry relates to the SIGs.
However, we also need to help ourselves and promote ourselves.
But, as a potential discussion point the BCS could help by perhaps.

8. What is required? - Discussion point.
Higher Profile
Semi-dedicated resource from BCS to support volunteers
Financial support from BCS
A higher profile from BCS itself.
BCS promotion of the SIGS
Gaining a higher profile within the industry. This is something that they are working on.
TALK THROUGH REST
We have also started to help ourselves.

9. What can we do ourselves?
Make the group more attractive.
Appeal to a wider audience.
Appeal to a Management audience.
Present solutions as well as awareness
Promote ISEB qualifications in recognised disciplines - Train practitioners
Promote appropriate ISM Level within organisations.
We have tried to make the events more attractive and interesting. The recent events on Content Management Versus Configuration Management were very well received and attended.
Appealing to a wider audience rather than just the Configuration Management disciple has also been an objective that has been partly hit.
Sadly we have not, as yet, been able to crack the Management nut who still seem to be enthralled and impressed with still more open standard computer languages and development tools whilst paying little attention to the underlying processes and people.
As well as awareness we are also trying to present solutions. After each supposed IT Paradym shift the amount of work required to maintain systems rises. First mainframes, then downsizing client server and then the internet brought new languages and new developments. Some time afterwards the amount of time and money being spent on Maintenance rather than new developments increases towards the 75% mark. We do not appear to learn any lessons. This time, with faster delivery, we have just got there faster.
Perhaps the answer lies in education but before education comes visibility

10. Easier to Sell? Name Change From Configuration Management to
Change, Release and Configuration Management.
Long and heated arguments: against and for
Esoteric arguments - not commercial.
The name change took years to get through.
It was done to give a more specific home to related disciplines.
It was done to make the group more marketable
The purists argued that Change and Release belonged within Configuration and that we did not need to change. Whilst they are right it is not a marketable statement.
We need to market ourselves more both within and without the BCS if we are to be successful.
Education plays a major role.

11. Education Proposed Courses and syllabus for two levels
Essential: Target BCS ISM Level 3 for Change, Configuration & Release Management
2 days, 14 hours, 1 hour exam
ISEB Business Systems Development: Certificate in Change, Configuration & Release Management Essentials
Intermediate/Practitioners: Target BCS ISM Level 4-5 for Asset & Configuration Management
3-4 days, 20 hours, 2 Assignments, 1 hour exam
ISEB Certificate in Change, Configuration & Release Management Intermediate/Practitioners
Talk through slide.
By making the industry aware that these courses and professional qualifications are there we will hopefully raise the acceptance of the disciplines.

12. Management Awareness Assessments : BS 15000 Achieve this Standard
Conformance
Manager’s Overview
PD0005
Capability & Maturity
Process Definition
This is the target. The top three layers already exist and provide a mark against which the bottom layer can be implemented/measured.
By creating PD0005 it is hoped that Managers will be able to quickly read, understand and assess the implications for their organisations.
By achieving the standard they can increase the quality of their deliverable without making any unnecessary concessions to cost or time to market.
This then is the key message of Change, Configuration and Release Management.
Enabling organisations to get measurable quality products to market at the right cost and at the right time using as many releases as is necessary whilst still retaining management control and flexibility of change.
ITIL
Solutions
In-house procedures
ITIL Best Practice & Standards Links

13. Structure, Relationships and Content
Change, Configuration and Release Management
And so to what we actually mean by these disciplines.

14. ITIL Version 2 Service Support
Configuration Mgt.
-identifies impact &
updates records
The Service Desk
Release Mgt.
-controls release of
software & hardware to
implement the change
Incident Mgt.
-logs & resolves incidents
The quick and easy definitions are given by the IT Infrastructure Library.
These are quite simple and do not require much explanation.
As there is no need for improvement or process without change lets use that as a start point.
Problem Mgt.
-identifies root cause
& minimises effect
Change Mgt.
- assesses &
authorises change

15. Change Management - Activities
Requests For Change
Approve & schedule
changes
Change
Management
Most of the functions within Change Management involve either research or decision making. Requests for Change (RfCs) must be researched for impact, cost, need, and dependencies. Following this analysis the Change Management process must decide whether the change is approved or denied.
This simplifies an extensive and human process of decision making. The research part is accomplished through a link with Configuration management.
Oversee change
building, testing
and
implementation
Review all
implemented changes

16. RFCs & Configuration Management
Initial
Change Request
Configuration Management
Assess Impact & Proposal C M D B
Software CI
to be changed
Related
Training CI
Related
Operating CI
Related
Hardware CI
The information held in the Configuration Management Database is based on a unit called a Configurable Item.
We shall cover this later.
Once analysis is done and related CI’s have been identified then another level of change analysis can be undertaken to link associated Request For Changes that require common CI’s.
Linking related RFCs not only assists in making impact assessment more realistic but also reduces the bureaucratic overhead of change management.
Combined
Change Request

17. Change Procedure Raise RFC CMDB Assess Manage, Impact monitor, report,
chase,
RFCs
Assess
Impact
Identify CIs
Approve
Release CIs
CMDB
Implement
The Change Procedure therefore, in its simplest form looks something like this.
Talk through major points.
This then defines a relationship with Configuration Management where Change Management is the deicion making on which action should be taken whilst Configuration Management holds and provides the base information for those decisions as well as the control mechanisms that carry out those changes.
Update CIs
Post Impl.
Review
Audit CIs
Close RFC

18. Configuration Management Objectives
Enabling control by monitoring and maintaining information on:
Resources and configurations needed to deliver projects, systems and services
Configuration Item (CI) status and history
CI relationships
Providing information on the infrastructure for all other processes & Programme/IT/IS Management
Data about Configuration Items (CIs) are held in the Configuration Management Database (CMDB). These are key terms in ITIL.
Configuration Management is considered to be fundamental to the success of the other processes.
It is however very difficult to create a working Configuration Database without knowing which questions will be asked of it and information that is needed by those using it.
This also makes it difficult to cost justify the considerable investment in resources required to establish Configuration Management from scratch. A view has recently been put forward that it should be considered as an emergent process - gaining resources and process definitions from the other key processes.
This does not however detract from the fact that tools are necessary regardless of the amount of data held and that defined process is required before tools are selected and implemented.

19. Configuration Management - activities
information
Identification &
Naming
Verification &
Audit
Configuration
Management
Configuration Management looks like this.
All components (and their relationships) of an IT infrastructure have to be identified, categorised and named. CMDB design and population are non trivial activities which often pass through several iterations.
Identification should begin as soon as it is possible to predict a CIs entry into the infrastructure.
Control is concerned with ensuring that CIs are not changed, removed or added without authorisation and that all actual and planned changes to CIs are recorded in the CMDB. The overall Control activity clearly has strong links to the Change Management process.
Status Accounting records the state of CIs in time (e.g... in development, test, scheduled to go live, live or archived). It includes recording the historic, current and expected present state of CIs.
Verification ensures that the CMDB is accurate and helps to identify unauthorised changes.
Management Information is fed in to all the other processes and to IT Management.
Control
Status
Accounting
Need to be planned!

20. Configuration Control
Configuration Control is responsible for the way in which we put our projects and systems together. It allows us to assign and associate a series of selected elements to form a Release Unit or Release Package (i.e. Set)
Pre-grouped elements formed into identifiable packages are what we move through the life cycle.
These types of control have to be thought out before projects start.
It should be a key part of the Configuration Management plan for a project or programme and the control should be generic as possible and created by the Configuration Management strategy of an organisation.
The controls are identified as

21. Configuration Control Procedures
Depend on Configuration Item Type:
Check-out/Check-in
Impact Analysis
Versioning
Move/Copy/Build
Baselining - packages, systems & environments
Environment Restore
System/Package/Change Backout/restore
Security
Talk through each one leaving build till last.
Build is one that deserves more detail.

22. Build IN OUT Inputs must be from controlled library or repository
Identify environment, inputs, outputs and build tools
Identify dependencies to permit rebuilding later on & order!
The way a system is built and the parameters used can have an enormous impact on the state of the system and therefore its reliability and quality in whatever stage of the lifecycle that it is in.
It is no longer acceptable or necessary to have developers build software with whatever options they want or without doing the proper impact analysis for pre-requisite or co-requisite code, I.e. version of code that should be included in the build.
This has a direct result on the quality of the system.
And so onto Configurable Items. IN
OUT
Build Tools &
Clean Environment
Built
Environment

23. Configuration Management
Categories include
Programmes/Projects
Services
Systems
Hardware
Software
Documentation
Environment
People
Data
Any item that you want to control is called a configurable item.
Additionally, one configurable item may consist of many other smaller configurable items.
You will note here the similarity between Configuration Identification and Product Breakdown Structures in Prince. One technique compliments the other.
Items you want to control are called Configuration Items (CIs)
Data about all the CIs are held in the Configuration Management System or Database (CMDB)

24. Configuration Item (CI)
A Configuration Item
Is needed to deliver a system/product/service
Is uniquely identifiable
Is subject to change
Can be managed
Belongs to a CI category
Has relationships
Has descriptive attributes
Changes status over time
There are categories suggested by ITIL and we would normally include Services and Datafiles as categories. In fact since the only reason we hold information on CIs is to help manage services it follows that the service category is the most fundamental of all to hold information on. Software includes system software as well as applications .
ITIL is not prescriptive in terms of the relationships used. They should represent real world relationships. These relationships are used in the Impact Analysis
Typical relationships used are: is a part of, makes use of, is a copy of, is being used by, etc
The CI relationships are used to assess the impact of events/incidents/problems and changes.
States might be: ordered, received, in repair, stored, operational, under development, etc.
Each individual CI also has attributes

25. Configuration Item (CI) Attributes
number
Name
Category
Description
Security
Own
attributes
Version
Euro
Size/Capacity
Supplier
These are only a few examples. The specific attributes recorded will depend upon the CI involved and the information required to manage the service. Some attributes will, however be common across all CIs (such as owner)
In addition to these relationships a CI record will also be linked by relationships to other forms of records, including changes, incidents, problems and known errors.
Status
Support
Group
Location
Owner

26. CIs - scope and detail D E T A I L SCOPE Service Environ- ment
Hardware
Software
Documen-
tation
People
resources D E T A I L
Network
printer PC
Local
printer
Bundled
s/w
The relationships shown here are for illustrative purposes only. In reality the relationships are multi dimensional and can become very complex with different logical models being required.
Since the only reason we are maintaining data on CIs is to deliver a service it is important that all CIs are directly or indirectly linked to the Services that they support.
From a management perspective the over riding factor in deciding both scope and detail is the information needed to manage the service, irrespective of the cost or difficulty of obtaining and maintaining that data. A more pragmatic view is that not only should those factors be taken into account but also, and perhaps most importantly, managers should consider the consequences of inaccurate and out of date data being stored on the CMDB.
The scope and level of CIs refers to the depth and breadth of the CMDB, or simply "how much should be included in the database". Attributes are the components (or "fields") which together define a CI (Configuration Item).
Looking at an e-business as a simple example
No break
power
VDU
Keyboard
CPU
DBMS
W.P.
SLA
SCOPE

27. Web World - What to Control?
Multimedia
Formats
URL
Servers
Layout
SMIL
XML
Editors
HTML Tag List
Databases
VRML
Perl
Java
Design
HTML4
JavaScript
Tools
Plugins
CGI
ASP
Cascading
Style Sheets
Open Source
Protocols
Images
You can begin to understand the scale of the problem.
It is NOT one that can be ignored. Saying it is too complex or too costly is the same as saying that we will not attempt to control or understand the changes that are required.
THAT IS NOT AN OPTION.
Faster chaos is still chaos. The only option is to utilise the techniques to manage and control the items and their relationships.
Virtual Library
Software
Icons
Flash
Tutorials
Navigation
Security
Domains
UNIX
DHTML
Browsers
Graphics

28. Role of Status Accounting
What have we Configured?
I’m doing a release,
take the baselines
for me please.
OK, I’ll Get
the pictures
Status Accounting concerns baselines.
Baselines should be taken at every stage of the lifecycle.
Recorded
Baselines

29. Configuration Audit ‘As Built’ Baseline Records Live Infrastructure
App. Server
‘As Built’
Appl. Server
‘Live’
NT Server
‘As Built’
NT Server
‘Live’
Audit Tools &
Scripts
Desktop
‘As Built’
Desktop
‘Live’
And finally Configuration Audit is an audit facility that allows baselines to be compared against delivery.
Requests for Change therefore have a scope of CI’s after an analysis has been done.
Perform audit
Log exceptions
Notify exceptions
Investigate exceptions
Follow up & resolve

30. RFC - Scope and Contents
Change
Sponsor &
Originator
Software
Hardware
Justification
CIs
What, Why,
When
SLA
Documentation
Service
impact
etc..
Change
Request
(RFC)
Environment
Scope also covers the type of activity that comes under formal Change Control as well as the CI involved. Staff need clear guidelines on those activities they can undertake without the involvement/approval of Change Management. A clear definition is required of what constitutes a change and it is helpful to have an explicit list of those activities which do not require formal approval every time they are undertaken.
The sponsor of a change does not necessarily have to be the same person as the change originator. The originator is the person who files the RFC. The sponsor is commonly the person who is willing to pay the bill, but the role might also encompass managerial, political or project authority,
Note that not all changes go to the CAB!
Category
Priority
Resource
Estimates
etc..
Change
Advisory Board
(if appropriate)

31. Change Management Process
Implement
Manage
RFC
Preparation
Categorise
Prioritise
Authorise
Plan
Refusal
Build
CAB
Test
Approve
Release
Although there is a need for final approval before implementation, which in ITIL is vested in the Change Manager, approval is also needed from different players throughout the process. Some of those involved may have the authority to stop a change because they consider it high risk without the corresponding authority to force a change through to implementation. Some of those involved may also be members of the Change Advisory Board (CAB).
And so on to Release Management.
Refusal
Implementation
Backout
Review

32. ITIL Version 2 Release Management
Development
Environment
Controlled Test
Environment
Live
Environment
Release
Policy
Planning
Design,
develop,
build,
configure
release
Fit for
Purpose
Testing &
Acceptance
Roll-out
Comms.,
Preparation
& Training
Distribution
&
Installation
Configuration Management Database
and Definitive Software Library
Life cycle management of related items
Pre-group elements into identifiable release packages and move through the systems lifecycle with individual hardware and software changes
Planning releases, environments & roll out
Ensure we’ve got it all & our actions are appropriate
Making sure we have recoverable positions
Depends on Configuration Management
To successfully identify and manage our configurations through each and every stage of the life cycle
What is to be managed?
Who is responsible for what?
How it will be done? - common approach
How and when the contents and management will be audited
To provide visibility of accurate information on configurations, their status, related problems and changes
Release Activities
Plan the exact content of releases & roll-out
Oversee the release and rollout of software and related hardware to development, test and live environments
Design and implement distribution & installation
Provide secure environments where only correct, authorised and tested versions are installed
Provide formal release documentation for problem, change and configuration management records to be updated accurately and efficiently
Provide controlled back-out mechanisms for incomplete or failed releases

33. Release Management Objectives
Deliver systems that are correctly configured and built first time e.g. 99% of target
Repeatable, consistent process that is cost effective, responsive and flexible
Everyone knows what is happening & when
Accurate updates are fed back to configuration management
Can do OFTEN & QUICKLY!
Maintain quality
Talk Through

34. Platform & Cultural Challenges
Network
Computer
Mainframes
B2B
Systems
Mobiles
Internet
Release
management
Laptops
Compact Disks
Personal
computers
Client/server
Balancing control of corporate, regulated systems with end user flexibility across platforms

35. Release Policy Release policy 1. Roles & Responsibilities 2. Levels of
Authority
8. Business critical
times & risks
3. Identification
& Packaging
Release
policy
7. Emergency
change
Roles & Responsibilities - Document them clearly, Make them practical, Do not link to individuals in the process, agree them
Release Numbering ensures each release is allocated a release number to ensure it can be identified.
There should be a well publicised and predictable release frequency and an agreed limit for change content. Business requirements rather than technical convenience should be the determining factor. Specifications should be frozen sufficiently in advance of the release date to allow for sufficient testing.
Urgent Changes follow the urgent changes procedure, which most likely translates to an urgent SC&D procedure.
Release Unit - the level at which software of a given type is normally released e.g. suite, module or application.
Full Release - release which replaces all components of a release unit, whether all components have changed or not.
Delta Release - a release which only includes CIs which have changed since the last version.
Package Release - a package release of related software CIs introduced into test then live together, such as a desktop environment consisting of , emulator, office suite and operating system.
4. Release
unit - full/delta
6. Release
frequency
5. Release
numbering

36. Release Management Best Practices
Designer/developer should design for change, configuration & release management
Release management should offer advice & info.
Standards, identification, tools, techniques
Release, build and back-out procedures
Re-use of standard procedures & CIs from CM system
Automate installation routines if sensible
Automated one-off jobs need equivalent back-out routines
Design software distribution so that the integrity of software is OK during handling, packaging, delivery & AUTOMATE!

37. CM System Release & Roll-Out Definitive Software Library Build New
CI records
CM System
Release
Record
Build New
Release
Test New
Release
Distribute release

38. Release Planning - Why? What is to be released and to where?
Who is responsible for what?
How it will be done?
How do we know it has worked?

39. Release Planning Release contents & schedule Roll-out planning
Phasing over time and by geographical location, business unit and customers
Site surveys/audits
Obtaining quotes for new hardware, software or installation services
Quality plan
Back-out plans
Acceptance criteria

40. What Does It Mean?
Part 3 - Making it Work.

41. The Brave New World No central computer, no single network
A changing environment where anyone can publish information or read it
Information is on any server
And we need to be able to trust our business partners, suppliers, and customers engaging in e-commerce!

42. WWW By 2003 More than 500 million users
Dominant growth in Europe where 60% of Web users will live & work
No. of devices will be more than 700 million
B2B will be 90% of all internet traffic & B2B e-commerce may be $7 trillion
Related IT services opportunity is estimated at just under $1 trillion
B2B value chain

43. World-wide prototype to B2B
DEV
TEST
LIVE
Support more data, applications , processes across enterprises
Separate information and services (logical) from infrastructure (physical)
Use remote services (internal & external)
Re-engineered IT infrastructure for maximum cost-effectiveness and reliability
Server-centric, thin-client applications, broadband networks, high performance server clusters

44. Business Programme Challenges
Short Lead Time to Market
Fast & clear decision making and risk analysis
Ever More Complex Technical Systems
Need to manage variants and dependencies
Needs clear ownership through the lifecycle
High demand for Deliverables from Organisation and Staff
Need to know ‘true’ status

45. Start with Change Management
Keep It Sufficiently Simple
Appoint Change Manager
Document Scope
Establish Communications
Base it upon
Business Continuity
Necessity but Risk of Change
Ignore Content for now
Appoint a Change Manager

46. Appoint Change Manager
Use BCS Industry Structure Model
Senior appointment
Business AND IT knowledge
Expert Communicator
Programme and Project knowledge
Service Management knowledge
Risk Management experience
People person
Process Person - Process is everything

47. Change Manager - Defines scope and process - Operates process
Process Manager
Manage Change and
Risk
- Defines scope and process
- Operates process
- Manages data and records
- Interface & communicator
- Sets targets & measures
- Reduce Incidents
- Manage risk of change
- Process reviews
- Efficiency & effectiveness
reviews
- Manages improvement cycle
- Evolve sub-processes
- Measure change & effect
Quality
Parameters &
Key Performance
Indicators
- Establish interfaces/ links with
all areas, projects, programmes,
service & support
- Identify Interface Impacts for
Business Impact
Change
Manager & Team
(& all staff)
Change Manager
Change Administrator

48. Possible Problems Systems overload easily Circumvention of procedures
Excessive over-ruling for strategic expedience
Suppliers
Over-zealousness can lead to analysis-paralysis
Unclear responsibilities and definitions

49. Possible Problems Establishing depth and breadth
Interfaces to other systems where CI information is stored
Data collection and maintenance of accuracy
Roles and responsibilities in distributed, client/server environments
Establishing owners for CIs
Over-ambitious schedules and scope
Management commitment to importance of Configuration Management as a foundation block

50. Potential Benefits Increased productivity of customers and IT staff
Less adverse impact of changes on services
Ability to absorb a higher level of error-free change helps speed to market & quality of service
Better up-front assessment of the cost and business impact of proposed changes
Reduction in the number of disruptive changes
Reduction in the number of failed changes
Valuable management information

51. Potential Benefits Improves asset management
Reduces risks from changes
Leads to more effective user support
Improves security against malicious changes
Facilitates compliance with legal obligations
Supports budget process
Facilitates service level management, better planning & design
Improves capability to identify, improve, inspect, deliver, operate, repair & upgrade
Provides accurate information & configuration history
Increased Quality
Facilitates Learning and Knowledge based organisations

52. How - Define the Method & Process
Change & Release Management throughout the life cycle
Validation
Test
Conditions
& Cases
Test
Business
Acceptance
Testing
Requirements
Execution
Rework
Verification Activities
- Release Package
& Signoff
- Configuration Audit
- Change Management
Audit
- Test and Quality
Lifecycle Checkpoint
System
design
Large System
Testing
Component design and build
Unit Test
The V-Model Method
& Process

53. Analyse Current What Processes are currently specified and used?
What Tools are in place?
How many production and development problems are caused by change and release issues?
What are the costs associated with the above?
How much time is spent waiting/wasted?

54. Analyse Current Identify where current practices would need to change
Specify roles & responsibilities
Identify training requirements; tools and process
Create a Cost Benefit Analysis Model
Identify likely tools and general costs
Identify pilot project/release and implementation milestones

55. A Learning Organisation
That can work practically with the Process
Can deliver fast but with quality
Can deliver fast but with control
Protecting the assets of the future
Learns and reuses from the past
Identifies Risks & Prioritises Change

56. Organisation Project Management Business Risk Management Development
Aims, Objectives, Financial, Quality, Principles & Policies
Business Risk
Management
Development
Management
Quality & Verification
Management
Change Management
Risk & Issues DB
Requirements
Catalogue
Release Management
Configuration Management
Business Priority,
Commercial &
Technical Analysis
of Change.
Design Products
Test Management
Audit
Build Products
Management
Implementation
Products

57. Remember Quality e.g. EFQM Business Excellence Model
Enablers 50%
Results 50%
Leadership
10%
People
Management 9%
Policy &
Strategy 8%
Partnership
& Resources
Processes
14%
People
Satisfaction 9%
Customer
20%
Impact on
Society 6%
Business
Results
15%
Innovation and Learning

58. To be successful …… Avoid bureacracy Invest in processes
People
Technology
Avoid bureacracy
Invest in processes
+ people + tools