Programme management can be used to assist in the identification of legacy systems. Glenn Strange of Logica tells us how placing them into a structured environment can provide improved levels of control to facilitate change management.
Legacy systems are defined as those systems that cannot be ‘switched off’ because they are mission-critical to the successful running of the business; such systems require special treatment when considering potential retirement or replacement. It is important that any transitions are smooth, transparent to the business and convert without any stress or turbulence to the business operation. Financial systems often fall into this category. Accounting and cash flow information is vital for the on-going operations of a business; all departments rely on current and historical financial information. Any interruption to these systems may have serious ramifications throughout the whole business network.
If it became necessary to replace an organisation’s financial systems for a modern more integrated package, the procedures would require a great deal of careful consideration. The ideal situation would be a smooth transition from the existing platform to the new platform with a minimum amount of interference to the business. Financial systems are helpful in this context as they are modular whilst having a degree of integration: for example, general ledger, purchase ledger, sales ledger, cash book, books of prime entry (journals). It would be possible to place such applications into a managed framework for systems conversion. Data transfer would not propose a serious problem. It would not be as easy, however, to replace systems that cannot be broken down into constituent parts.
Programme management would assist the strategic directives of legacy system replacement by:
protecting the legacy systems in a managed framework;
establishing projects for managed and controlled change;
providing a future ‘business blueprint’ whereby legacy systems pass smoothly through a systems integration process with a minimum disturbance factor to the business; and
enabling other development activities to continue whilst managing the sensitive legacy systems critical to the successful mission of the business.
Adopting programme management
Programmes should be selected on the basis of all legacy systems under review. This may be for a particular business unit or the organisation as a whole. It should be led by the divisional managers responsible, whose participation and commitment are essential to the process. The initial objectives should be to:
define current legacy systems;
define future business requirements;
develop a business case;
develop future business blueprint;
identify change management issues;
identify areas of modularity;
construct programme framework;
identify, assess and manage risks;
introduce quality management system.
The above steps may be further optimised into the following stages: scoping the programme; developing the blueprint; programme management framework; and benefits realisation.
A replacement financial system is a good example, and an accounting system may be considered as a legacy system. The current system is in excess of five years old and the financial director wishes to obtain a new software application that reflects current technology and improved reporting procedures. They have completed an initial feasibility study and selected package ‘A’ as being the most suitable to meet future needs.
It is paramount that the change over is smooth with no delays. The following objectives have been identified:
Switch-over from the legacy system will not occur until all of the projects have been successfully completed and implemented. The realisation of the benefits then occurs after the new systems are in operation.
The system will comprise of replacement ledgers: nominal, sales, purchase, cash hook and journal. There will be a new application called report writer which will produce an improved level of statistics and financial reporting information.
Each ledger replacement will be considered as a project in its own right. It will be set up on the new system and thoroughly tested with live data.
There will he a period of parallel running of both the legacy system and the suggested replacement system. The new system should match as a minimum the existing performance criteria of the old system. Future enhancement modules may then be added.
This exercise should then be placed into a properly managed environment, so as to assess potential risk and minimise any potential exposure to the organisation.
Scoping the programme
Scoping of the programme is a management concern and it should call heavily on the IS strategy direction.
The programme should consist of a number of discrete manageable projects. There should be a defined start position (from current system). through a
managed period of change (implementation of the projects) to a future business blueprint (the desired state that realises the new business benefits).
The illustration above illustrates the assembly of these requirements into an acceptable programme management framework. This provides an architectural framework that is easy to understand and meets the business objectives. This will be further refined from the future business blueprint.
The model illustrates IS strategy and business planning applications spanning the entire programme. Commencement is with analysis of the current legacy systems. These are allowed to continue in operation while new requirements are being developed. The new requirements take the form of numerous projects, each with varying levels of dependencies. These are managed through a series of review points until the design specified in the future business blueprint is achieved. The review points facilitate QA reviews, refinement of iterations and
provide places of stability where consolidation positions can be reviewed. The switch over from the legacy systems will not take place until all of the projects have been successfully implemented and tested for completion. Benefits realisation takes place once the new systems have gone into a live operational environment.
Developing the business blueprint
All future business operations should have a blueprint that sets out how the revised systems will operate once the programme has been completed. This is an iterative document that requires refining and maintaining throughout the life-cycle of the programme. The blueprint is normally conducted in the programme definition phase, considering that the generic life-cycle of a programme might go through the following phases (courtesy of CCTA programme management Life-cycle model):
programme identification;
programme definition;
programme execution; and
benefits realisation.
The blueprint aligns to the IS strategic direction and must provide a clear vision of the future business operations; it should cover the following areas:
There are four compontents of benefits management in the context of legacy systems replacement plans.
providing the detail behind each risk. This should either be included as a volume within the programme Control Log or interlock to the same.
Quality plan
The entire programme team is responsible for achieving a high level of quality. Views will differ, however, as to what constitutes quality within the programme. The design authority will be focusing on technical quality; change management will be concerned with transition and quality of end products; the programme manager will be concerned with levels of standards over the broad spectrum of the programme being accomplished. Quality plans, in general terms, must include:
quality planning for the business operations within the programme. This should consider formal certification requirements such as BS 5750, ISO 9000, TickIT where appropriate;
procedures that cover change control, document control and process control within the programme; and
how to police and enforce a level of quality standards over third parties introduced to the programme.
Benefit plan
One of the key attributes of programme management is the realisation of potential benefits to the organisation. These are considered as fundamental to the objectives of programme management. Programme management is concerned with benefits realisation, as opposed to project management where the responsibility halts when a project has been completed, accepted and handed over. Key attributes include:
baseline performance measures;
statement of projected benefits;
detailed benefits management plan;
alignment to IS Strategy;
the monitoring, measurement and fine tuning of programme benefits to ensure an optimum rate of success from the programme; and
roles and responsibilities for those involved in benefits realisation.
Management plan
The management plan should work in
unison with the benefits plan. Management actions should focus on the support of the benefits regime. Particular attention should be paid to the individual benefit profiles considering how and when these are to be achieved. The management plan should provide a schedule for monitoring delivery and alignment to IS strategy objectives.
Project portfolio plan
This plan establishes the plan of work to be carried out by all of the projects within a programme. This will include contracted out (third party) projects, other in-house service providers etc. The project portfolio plans should define:
a schedule for implementing the projects which sets out the dependencies between projects within the programme;
details of costs, resources and infrastructure requirements for all projects; and
how control of progress will be carried out on the projects.
IS strategy alignment plan
It is important that the programme objectives are carefully aligned to the IS strategy,
particularly in terms of deliverables and benefits. The future business blueprint is a key management control document that requires interlock to the IS strategy directional statement.
Design management plan
A plan will be required in order to safeguard the overall integrity of the design. A design management plan should embrace the following issues:
supporting technical architecture including a configuration management plan;
policies and standards appropriate to the programme activities deliverables;
interlock to transition plans for new or changed infrastructure requirements within the programme; and
a plan for the monitoring and control of technical deliverables within the programme.
Resource plan
All programmes will need suitable resource allocations. These should span over programme staff, user staff and business areas. The resource plans should identify: who will be providing resources for individual requirements within projects contained within the overall programme; how such resources will be funded; and details of contracts or service level agreements.
Communications plan
Numerous programmes have failed because of a lack of attention to detail in preparing a proper communications plan. It is important that the objectives of any programme are properly communicated in a structured and coherent manner. This may also include press releases, notices to third parties and outside suppliers, notification of any special considerations to clients, overseas interested parties. It is important that communications have a proper ‘cascade’ of events, in line with approved authorisations, security clearances, appropriate channels etc.
Security and audit plans
Security plans are required to outline the levels of security required over a programme. This of particular importance on Ministry of Defence projects, chemical plants, petrochemical projects where a high level of business security needs to be maintained. Consideration should be given to: authorised personnel; levels of authority; levels of computer access; restricted levels of information; access restrictions; security clearance procedures; and badging of personnel.
Audit plans are concerned with ‘traceability’ within the system. The ability to navigate throughout the programme and obtain intelligent data. In addition, the prevention of fraud, security breaches, virus prevention. Effective configuration control is an important element within the audit plan. The plans will include: configuration control procedures; audit tests verification requirements; route maps; security investigations; audit plans; computer interrogation plans; checkpoints; and key data information requirements.
Benefits framework
The benefits management of a programme falls into a structured framework (see illustration on page 22). There are four components of benefits management: programme identification, programme definition, programme implementation and benefits realisation. A programme management framework can achieve:
the production of an equilibrium between the old and new systems, while providing the minimum of disruption to existing business operations;
the provision of alignment to strategic objectives;
identification of the business functions to be placed into a change management environment;
the facility to obtain critical review points where appropriate fine tuning could be made.
Conclusion
Programme management therefore has a number of different definitions and interpretations. In the context of legacy systems, however, the focus is on the co-ordinated management of a portfolio of projects with a set of predetermined objectives. Programme management can provide a framework for a control mechanism, so that legacy systems can be successfully handled. It is important that this framework is constructed and remains in place throughout the transition from an old system to a new one.