Detailed Programme Case Study

Programme Case Study

Implementation of eDRM System

in a Central Government Department

Stephen A. Syder BA, CPM, FAPM, M.I.M.A

Executive Summary

This report describes a Programme undertaken in a Central Government Department to

implement a replacement eDRM system. The starting point for my role was when the

Programme was already in crisis, running late and with a projected overspend.

The implementation date was renegotiated and the new date was subsequently

achieved. The Programme came in below budget as a result of changes I made to the

training strategy, and quality was unaffected.

The Programme was regarded as a success by the Department and all system-users

within the Department, which was a good outcome given the scepticism I encountered

on my arrival.

The programme demonstrates the importance of several things: recruiting the right

programme team, negotiating a good contract with integration partners, not trying to be

leading edge with unproven software. Not least, it demonstrated to me the correlation

between good working relationships and programme success.

Steve Syder – Programme Case Study Page 2 of 28 www.stevesyder.com

Contents

Executive Summary .............................................................................. 2
Contents................................................................................................ 3
1. Introduction ..................................................................................... 4
2. Situation .......................................................................................... 4
3. Client ............................................................................................... 5
4. Objectives ....................................................................................... 6
5. Roles and Responsibilities .............................................................. 6
6. The Programme Team .................................................................... 9
7. The Anatomy of the Programme ................................................... 13
8. Management of the Programme ................................................... 15
9. Distinct Aspect .............................................................................. 17
10. Outcome ....................................................................................... 17
11. Analysis ......................................................................................... 17
12. Lessons ......................................................................................... 23
13. Hindsight ....................................................................................... 27
14. Glossary ........................................................................................ 28


1. Introduction

The programme was for a central government department involving an integration

partner and a software supplier. As an interim Programme Director I am bound by a

confidentiality agreement, so my submission will refer throughout to “The Department”,

“The Integration Partner” and “The software supplier”.

2. Situation

The Department has an obligation to create evidence-based policy, and to correctly

judge which documents and records must be preserved for the National Archives and

which should be destroyed.

In order to fulfil this obligation, it implemented an electronic documents and records

management system (eDRMS) in 2002. At the time, all staff in the Department were

trained in records management and the use of the system, but uptake was patchy, giving

senior managers cause for concern.

The original application had been provided by two separate companies working in

partnership, one creating the front end, i.e. the GUI, and the other creating an integrated

back end – the database, search engine, data manipulation code and metadata.

These two companies subsequently split and went in different strategic directions. As a

consequence, the software became obsolete and unsupported, and so it became a

matter of urgency that a suitable alternative was chosen and implemented as soon as

practicable.

This also gave rise to the need for training in the use of the new application, which, it

was hoped, would produce improved usage figures.

Jointly, the Department and its integration partner agreed on a product produced by one

of the original software suppliers. Two things are important to note at this point:

The software was not an “Upgrade” to the extant system – it was substantially different

in all but the most basic commonality between the GUIs;


The software was new to market and had not previously been implemented at any

comparable site.

Thus, the interested parties were the Department, the integration partners, the software

providers and the National Archives as the ultimate recipient of the data.

I was appointed to manage the programme because it was failing. The integration

partners had declared the software “Not fit for purpose” and the software suppliers were

trying to correct it. No-one would commit to a delivery date, and the user community had

become extremely cynical about the system.

Preparation for training continued anyway, and was a major contributor to the escalating

programme costs.

3. Client

The client was a major central government Department based close to Whitehall, with

1,500 employees whose morale was exceedingly low as a result of redundancies. This

had important implications for stakeholder liaison.

The Department’s structure was typical, with Directorates sub-divided into Management

Units. This programme was housed in the Management Unit responsible for IT.

Day to day reporting filtered through the Heads of Management Units (HMUs) to their

Directors on the Board.

The programme reported through this structure on a monthly basis, providing the typical

data one would expect from a programme of this nature, e.g. progress against plan,

progress against budget – with rudimentary Earned Value Analysis – Risks and Issues

management, major milestones, imminent deadlines etc. However, the programme’s

ultimate reporting line was to the Senior Responsible Owner (SRO), who was the Head

of the Legal Department.


4. Objectives

At the original onset of the programme, its objectives could be stated quite simply as:

To deliver a replacement eDRMS to be used by every person working in the Department

– approximately 1500 people – along with all the necessary training.

By the time I was appointed, the scale of the task had increased because it was a

programme in crisis. My objectives can be stated thus:

• Gain commitment from the integration partners and software suppliers

• Steer through a successful Performance Proof of Concept (PPoC)

• Ensure a timely implementation of a thoroughly-tested system

• Create and execute a Communications Plan that would rebuild user confidence

• Create and deliver a training package that would enable everyone to successfully migrate

to the new system the day it became live;

• Control spiralling costs.

5. Roles and Responsibilities

5.1. Terms of Reference
The Programme Director will report to the SRO and will be responsible for carrying out

the following work:

• Line management of the Technical Team Leader, the Test Manager and the

Training Team Manager;

• Management of the PMO member allocated to the Programme;

• Management of the Integration Partner’s Project Manager;

• Ensure the creation of all necessary documentation in accordance with MSP

and PRINCE 2 to the satisfaction of an OGC Gateway Review 0;


• With PMO assistance, creation, maintenance and tracking of a programme

plan of project activities, including dependencies and resource constraints;

• With PMO assistance, creation and management of a Risks Register and

Issues and Assumptions Logs;

• With PMO assistance, management within Programme Board tolerances of

the programme budget, using the section’s budget tracking template;

• Deliver monthly reports to the PMO:

o Budgetary;

o Scheduling;

o Progress against red-rated Risks and Issues.

• Schedule Programme Board meetings as appropriate, not more than seven

weeks apart, and publish in advance of the meeting:

o A written report including progress against schedule and budget

o The RAID Log

o Progress against Critical Path milestones.

• Ensure the timely delivery of suitable training for every user in the

Department;

• Ensure the timely delivery of a replacement eDRMS, available to the whole of

the Department on the day of Go Live.

• Encourage skills transfer from contract to permanent staff.


Key Deliverables

The key deliverables will be:

• A successful – i.e. green- or amber-rated Gateway Review 0 by the end

of the PPoC.

• A successful – i.e. green-rated Gateway Review 4 prior to

implementation.

• An updated eDRM system.

• A suitably-trained workforce.


6. The Programme Team

6.1. Organisation Chart

6.2. Integration Partner’s Team

The bulk of the team comprised the Integration Partner’s team (IPT), managed by their

Project Manager (IPPM), who reported to me. Using the Integration Partner to evaluate,

select and implement the eDRMs was a contractual obligation, and so no deliberation

was necessary for the recruitment of this part of the programme team. The IPT provided

a shortlist of three potential systems, with a report recommending one. Once the

Department agreed the choice, the IPT had to work with the software supplier to ensure

that the application was compatible with the existing IT estate and it would satisfy the

Service Level Agreements (SLAs) being demanded by the Department. The IPT was

then to install the application on the network, working closely with the Departmental

Technical Team (DTT). This also involved the successful migration of two databases;

one containing all the existing documents and records and one containing all the

metadata.


6.3. Software Provider

The Software Provider was identified as a result of the evaluation exercise described

above. They were to keep one subject matter expert on site at all times to assist with any

technical queries arising, and it was understood that they would provide additional

resources as/when necessary.

6.4. Departmental Technical Team

The Technical Team Leader was the bridge between the Department’s technicians and

the IPT. It was acknowledged during the concept phase that the Department had no-one

with the technical knowledge and experience to do this job, so a Subject Matter Expert

(SME) was engaged. His role, along with his two team members, was to:

• Technically assure the work of the IPT;

• Ensure that all the reasonable requirements placed on the Department by the

Integration Partner were met in time to keep the project on schedule.

• Evaluate and make recommendations on Change Requests received from

the IPT.

• Ensure the team of librarians was in place, fully briefed and ready to quality

assure the database migrations.

• Ensure the Department Operational Support Team was at all times fully

aware of progress, and was involved in assuring the compatibility of the

application with the whole of the existing network.

• With the IPPM, creation and maintenance of a shared technical project

schedule.


6.5. Departmental Test Team

It was acknowledged during the concept phase of the programme that testing of the

system should be done by an expert, and that the testing methodology would follow the

classic “V Model”.1 Consequently, a Subject Matter Expert (SME) was engaged during

the requirements capture phase.

The Departmental Test Manager (DTM) and his team were required to:

• Assure the approach of the Performance Proof of Concept (PPoC) conducted

by the IPT.

• Assure the approach of system/integration testing conducted by the IPT.

• Create a System Test Plan and test data.

• Create test plans for the two database migrations.

• Recruit end-users to conduct system testing.

• Create baseline performance results to compare against performance results

of the new application.

• Oversee the assurance of the data migrations in test and live environments.

• Oversee system testing of the GUI.

6.6. Departmental Training Team

The original system implementation used a team of librarians to create a training

package. It was assumed at the onset of the programme that this team would produce

the training package for the new system.

1
This is not the place to discuss/explain the V Model. Suffice to say, it is a widely-used methodology and is
only mentioned here to explain the need to recruit a Test Manager at the onset of the project.


The team’s brief was to deliver classroom based training sessions, complemented by

“How to” modules on the Departmental intranet.

I disbanded this team within two months of taking charge of the programme, and

outsourced training pack creation to a specialist company. My reasons were:

• Poor uptake of the original system was a direct result of the poor training; the

original team had attempted to turn everyone into experts on every aspect of

the system and records management regardless of what they needed to

know for their daily jobs. The new training package was evolving the same

way.

• The productivity of the team was extremely poor. They took far longer to

produce every document or module than I considered reasonable.

• The team’s work on the programme kept them from their day jobs, which was

causing operational difficulties for the Department, so it was in the corporate

interest to release them from the programme.

• The team had no concept of “Fit for purpose”, instead wanting to create an

exemplary training package.

• Despite the previous point, the quality of the training materials was poor by

the standards set by professional training companies.

• The combination of over-engineering the materials, poor productivity and the

team’s desire to have all their work assured by a specially-convened

committee meant that the projected training costs, at around £700,000, were

out of all proportion for what was required.


6.7. Specialist Training Company
The specialist training company was selected based on European Procurement

Directives guidelines.

Its initial brief was to undertake a Training Needs Analysis (TNA) and to recommend to

the Programme Board the nature, scale and scope of the training required.

If the company’s performance and recommendations were impressive, they would be

invited to create and deliver the training. This proved to be the eventual outcome.

7. The Anatomy of the Programme

The purpose of the Programme was to enable electronic documents and records

management capability to the Department to ensure it continued to meet its obligations.

The objective was to deliver a replacement eDRM system to be used by every person in

the Department along with all the necessary training.

The main features were:

• There were three major parties involved: the Department, the Integration

Partner and the software provider;

• Relationships between the three were very poor;

• The Programme Board lacked faith that the programme could deliver;

• The Department as a whole had become cynical about delivery.


7.1. Programme Lifecycle

The Programme lifecycle stages were2:

• Complete the PPoC

• Deliver Prototype Room

• Migrate data to test environment

• UAT of databases in test environment

• Deliver Front End (GUI & data manipulation code) to test environment

• Deliver integrated special needs software

• System test special needs software in test environment

• UAT of GUI in test environment

• UAT of special needs software in test environment

• Report on Training Needs Analysis

• Create resultant training materials

• Release training to live environment

• Deliver special needs training

• Design and create communications materials

• Release posters

• Hold briefing sessions

2
Many of these stages were conducted in parallel.


• OAT

• Security Acceptance

• Migrate data to live environment

• Check data in live environment

• Implement Front End in live environment

8. Management of the Programme

As the Department regarded this work as a programme, and a Gateway Review had

already been conducted before I was appointed, I continued to run the work as a

programme. Consequently, the governance documentation was created in accordance

with MSP:

• Programme Mandate

• Brief

• Plan

• Business Case

• Organisation Structure

• Projects Dossier

• Benefit Profiles

• Benefits Management Strategy

• Stakeholder Engagement Strategy

• Programme Communications Plan

• Resource Management Strategy

• Resource Management Plan


• Risk Management Strategy

• Quality Management Strategy

• Quality Management Plan

• Benefits Realisation Plan

• Risk Register

• Issue Log

The following scheduled management meetings were held:

Weekly

• 1:1 with Head of PMO – covering consolidated plan

• Meeting with Technical Team Leader

• Progress meeting with Integration Partners and software suppliers

Monthly

• Meeting with PMO covering budget

• Meeting with PMO and team leaders covering Risks, Issues and Change Requests.

Six-weekly

• Technical Programme Board

• Programme Board

I also had frequent, ad hoc, meetings with the SRO, a Board-level Director.

The following management reports were produced:

Monthly

• Budget Report

• Progress Report to HMU

Six-weekly

• Report to Programme Board covering progress against milestones, progress against

budget and major Risks & Issues.


9. Distinct Aspect

The programme was considered important because it was to deliver an essential enabler

for the Department to continue to meet its commitments to the National Audit Office.

Additionally, the Department was already regarded as an exemplar for records

management within Whitehall, and this was a status it was keen to maintain; failure of

this programme would have led to the loss of this status.

The programme was distinctive because when I took it over it was already failing. I had

to rescue a poor technical position, a mediocre governance position, a completely failing

training plan, an out-of-control budget, a cynical user community and a relationship with

an integration partner that was rapidly becoming hostile on both sides.

10. Outcome
The original date for implementation had already been abandoned by the time I took

over.

The newly agreed date, established as described below in section 11.2, was achieved,

and the system was released to a receptive, well-trained workforce.

The software worked well, uptake exceeded that of its predecessor, and the programme

came in under budget as a result of the savings realised from the training budget.

11. Analysis
I had to “attack” the rescuing of the programme on several fronts, and whilst I prioritised

them, most of the rescue activities had to be done in parallel:

11.1. Relationship with the Integration Partner

The Department’s relationship with the Integration Partner had become extremely poor,

to the extent that even comparatively junior members of staff from both parties would

openly cite the contract in meetings as a reason not to do something, or to demand


something. This breakdown was one of the two major reasons for the lack of an agreed

delivery date.

To overcome this, I forged a close working relationship with my opposite number on the

Integration Partner’s side of things, and we agreed several things:

1. We would work together as partners, defining “Partnership” as both sides being

prepared to make concessions for the overall greater good of the programme.

2. Communication between us would be face-to-face whenever practicable, thereby

avoiding the potential misinterpretation often arising from emails.

3. We would reach decisions and agreements together and then present them to our

respective Senior Management Teams as a mutual agreement to be “Rubber

stamped”; historically, the SMTs had been presented with problems, not solutions,

and this caused friction, disputes and delay.

4. Discussions about the contract would be off-limits for members of the programme

teams, and we would monitor what was being done via our respective programme

plans. This meant that a much stronger “Can do” attitude prevailed than had been

the case in the past.

11.2. Technical Issues with the software

There were technical issues with the software because it was new and relatively

untested.

The software providers said they were fully committed to overcoming the issues, not

least because they saw the Department as their flagship site in the UK. Their words,

however, did not match up with their actions, especially after they signed a huge contract

with a multinational for a newer version of their software; they saw the multinational as

“The future”, and consequently stopped giving the Department due consideration.

The way I resolved this was to arrange a weekly tripartite meeting, attended by senior

people from the Department, the Integration Partners and the software suppliers. Actions


were minuted, all with the intention of driving the programme forward to successful

implementation. The three parties agreed quickly to commit to a delivery date, and peer

pressure drove things forward from that point on.

The Integration Partner appreciated the Department’s help in applying some pressure to

the software suppliers, and in turn they committed their own resources to helping

overcome the technical issues.

This partnership approach also encouraged the Department to tone down the demands

it made of the application and its performance, and so both the Integration Partner and

the software suppliers felt they were being set more reasonable goals.

11.3. Stakeholder Liaison

Trades Unions

At a time when the workforce was suffering from low morale as a result of impending

redundancies, the programme had largely ignored the Departmental Trades Unions

(DTU).

I arranged regular meetings with DTU representatives, and kept them informed about

progress. It was clear that their main concern was that their members were suitably

trained, as their performance appraisals depended on it, and so I involved them in

the TNA and the subsequent UAT of the training materials.

For their part, they began to see the programme in a much more positive light, and

conveyed this to their members.

Disability Advisory Group

The Department had a large Disability Advisory Group (DAG), and many of its

members needed special software, e.g. because they were partially-sighted and so

needed “Talking” software or extra-large fonts or could not type and so needed

speech-recognition software.


Like the DTU, the DAG had been ignored. I arranged a meeting with its officers and

they explained to me that, as the programme had fallen into disrepute in the

Department, so their members lacked confidence that the new system would work

with the special needs software essential to their work.

I attended DAG meetings and kept them informed regarding the state of the

programme. I also involved them in the TNA and ensured that they were involved in

UAT of the system as it interfaced with the special needs software from a very early

stage.

Librarians (electronic and hard copy)

The Department had two kinds of librarians; those who maintained the Record Plan,

looked after the databases and set records management policy and those who

looked after the vast warehouse of paper documents. All were concerned, as they

had not been involved fully in the programme.

I met with the warehouse-based librarians and found that they had very different

needs to the rest of the Department. They were used to working with a very simple

interface to automate their work. I arranged for them to have time with a dedicated

Business Analyst, and ensured that their requirements were fed into the overall set of

Business Requirements.

They were invited to see system testing of their unique part of the system as a

precursor to doing UAT. Consequently, they too felt that they were part of the

programme, and championed it at the warehouse.

The librarians responsible for the electronic part of the system – 90% of the whole –

had been consulted in the early days during requirements capture, but had

subsequently largely been ignored when the programme focussed excessively on

the technical problems.

I arranged monthly meetings with senior representatives of this group, where I

briefed them on progress. I also provided them with a written report a week in


advance of their monthly Librarians’ meeting, and involved them in the TNA and

UAT. A far more positive attitude surfaced amongst them, which was crucial,

because they were effectively the programme’s mouthpiece to the main users of the

system.

General User Population

The general users were disaffected and doubted the new system would ever see the

light of day. In addition to dealing directly with their representatives or colleagues as

described above, I arranged for the programme to have its own intranet pages,

updated very regularly with news, FAQs etc.

The flood of additional information coming their way stimulated interest, stopped

speculation and returned some enthusiasm for the new system.

Programme Board

Programme Board members were under a great deal of pressure because they had

to champion the programme daily in their departments, and they were hearing little

from the programme that gave them confidence.

I forged excellent working relationships with every member of the board, and held

monthly one-to-ones with each of them, where I was candid about progress and did

my best to address their concerns.

This, along with my regular reports to the whole Programme Board, boosted

confidence, and they became extremely supportive, which was helpful when I

needed them to supply resources for UAT and other tasks.


11.4. Training Plan

As discussed in section 6.6, the training plan was extremely convoluted and costly, so I

called in a specialist firm. They recommended and subsequently delivered a

comprehensive set of Computer Based Training (CBT) modules, complemented by “Crib

sheets” on the intranet and classroom training for the handful of people who had

specialist roles.

The modular approach meant that staff could concentrate on those areas they needed to

know to do their jobs. If their roles changed, they could access other modules to learn

their new activities. Similarly, if they needed a refresher course, the modules were

always available.

This meant that we could train a lot of people in a short space of time, enabling them to

be almost 100% productive from Day 1.

The training materials were very well-received and further boosted confidence in what

the programme was trying to achieve.

11.5. Communications Plan

There was concern in the Department that the impending business changes had to be

well communicated. Historically, changes were communicated via posters in common

areas such as kitchens or close to printers. The posters all followed the same bland

format in the same colours and as a result over time they had become “Invisible” to

people.

We decided on a “Teasing” campaign. We commissioned three posters from a graphic

artist, to be released at fortnightly intervals. The first showed merely a keyhole with a

flash of red behind it. The idea was to stimulate a reaction from people, and start them

talking. In the second poster, the keyhole had moved back, revealing a large part of the


red system logo behind it. In the final poster the keyhole was removed, leaving just the

logo and the implementation date.

In addition to this, we ran full-page advertisements in the Departmental magazine, and

we ran features on the Departmental intranet news pages.

This approach was subsequently described by OGC Gateway Reviewers as “One of the

most imaginative and innovative communications campaigns (they had) ever seen”, and

it was very well received across the Department.

12. Lessons

12.1. Lesson 1

The clash of cultures between staff doing policy-based business as usual and

project-oriented staff can be a source of confusion.

Explanation

Staff involved in policy are used to a culture of perpetual refinement and

improvement, where documents may be revised repeatedly. Project staff expect

documents, code etc. to be baselined at a set point during the project lifecycle.

These two different cultures are at odds when policy staff are used on projects;

project staff become frustrated that documents are not “complete” on time and policy

staff become frustrated that they cannot revise documents that have been used by

the project already.

Suggested Solution

When using policy staff on projects they should receive an overview of PRINCE 2

methodology, enabling them to understand the concept of baselining and controlled

change within a project. Similarly, project staff should be made aware of the different

working styles of policy staff.


12.2. Lesson 2

Integration partners should not be given the sole “Go/No Go” decision during early

stages of a programme.

Explanation

During the programme, we undertook performance testing of the software. It was

written into the contract that the Integration Partner effectively decided after this

whether or not to continue with the same software. This meant that, if the

Department considered performance unacceptable but the Integration Partner

wanted to continue, the Department was at the Integration Partner’s mercy. Similarly,

if the Integration Partner wanted to drop the software in favour of an alternative but

the Department felt it was worth pressing on with the same product, the Department

would be hard-pressed to do so.

Suggested Solution

When using integration partners, ensure they are contractually obliged to give

recommendations based on their expertise, but ultimately the decision rests with the

Department.


12.3. Lesson 3

Organisations running projects using matrix management and a resource pool need

portfolio management.

Explanation

When applying for Project Pool resource for the programme, it became clear that

there was no overall register spanning the whole of the Department listing and

prioritising every programme and project it was undertaking; rather, only those

requesting Resource Pool staff are listed. This is not good practice, and can result in

wasting money and not using resources to everyone’s best advantage.

Suggested Solution

At the inception of each programme/project the Project Pool should be notified and it

should maintain a comprehensive, prioritised list for the whole of the Department.

12.4. Lesson 4

Departments must insist on plan sharing with integration partners.

Explanation

Any programme of work involving the Department and third parties should be well-

planned in advance to increase its chances of success. These plans must then be

monitored and controlled during the full life of the programme. To do this effectively,

both parties must have full visibility of each other’s plans, and those plans should

have dependencies clearly embedded.

Suggested Solution

This should be an expressed condition at the ITT stage of any item of work.


12.5. Lesson 5

When a COTS (Commercial Off The Shelf) application or an approach is new and

untested, the Department should fully investigate whether or not it will be able to be

implemented in a timely and cost effective manner.

Explanation

This effectively means the Department should not be leading edge. The programme

implemented a brand new COTS application, leapfrogging two versions, so both the

software and the approach were unproven. These two things explain almost entirely

the reason for long delays with the programme.

Suggested Solution

Organisations should consider a “Latest minus one” policy for all applications and

insist on talking to reference sites for any application/approach.

12.6. Lesson 6

Departments should, from the earliest opportunity, vigorously manage integration

partners where workstreams they are involved in can impact the programme,

programme or portfolio Critical Path.

Explanation

Left to work at their own pace, integration partners may fail to appreciate the knock-

on effects of tardiness with individual tasks that impact the programme timescales, or

impact on other programmes in the Department portfolio.


Suggested Solution

There is a balance to be made between micro-managing integration partners, which

is costly and time-consuming, and leaving them entirely to their own devices, trusting

to luck that they will deliver on time. It is the responsibility of Project Managers to

manage this balance by regular but not excessive checks on progress against all

plans and liaison with other PMs where they share dependencies. If time overrun is

predicted, PMs must intervene without hesitation to encourage integration partners to

bring work back on schedule.

13. Hindsight
The things that would be done differently with hindsight are mainly those implied by the

lessons above:

• Choose the right staff and fully brief them;

• Do not over-empower integration partners;

• Avoid unproven software and approaches;

• Achieve the right balance in controlling the overall plan;

• Never underestimate the importance of good stakeholder liaison.

14. Additional Information
For additional information, contact Steve Syder via the form on the website:

www.stevesyder.com/contact.htm


15. Glossary

CBT Computer Based Training

COTS Commercial Off The Shelf (software)

DAG Disability Advisory Group

DTM Departmental Test Manager

DTT Departmental Technical Team

DTU Departmental Trades Unions

eDRMS Electronic Documents and Records Management System

FAQs Frequently Asked Questions

GUI Graphical User Interface (Screens)

HMU Head of Management Unit

IPPM Integration Partner’s Project Manager

IPT Integration Partner’s Team

ITT Invitation To Tender

MSP Managing Successful Programmes

OAT Operational Acceptance Testing

OGC Office of Government Commerce

PD Programme Director

PMO Project Management Office

PPoC Performance Proof of Concept

RAID Risks, Assumptions, Issues and Dependencies

SLA Service Level Agreement

SMT Senior Management Team

SRO Senior Responsible Owner

TNA Training Needs Assessment

UAT User Acceptance Testing


Detailed Programme Case Study

More Related Content

Similar to Detailed Programme Case Study (20)

Detailed Programme Case Study