The document summarizes a programme to implement a replacement electronic document and records management (eDRM) system for a central government department. The programme was in crisis when the author took over as interim programme director, with delays, cost overruns, and lack of user confidence. Key steps taken by the author included negotiating a new implementation date, outsourcing training to reduce costs, and rebuilding relationships between stakeholders. Ultimately, the programme was completed on time and under budget, and was seen as a success by the department and users.
Section 1a d lessons learned_guliford as of 21_apr15
Detailed Programme Case Study
1. Programme Case Study
Implementation of eDRM System
in a Central Government Department
Stephen A. Syder BA, CPM, FAPM, M.I.M.A
2. 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
3. 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
Steve Syder – Programme Case Study Page 3 of 28 www.stevesyder.com
4. 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;
Steve Syder – Programme Case Study Page 4 of 28 www.stevesyder.com
5. 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.
Steve Syder – Programme Case Study Page 5 of 28 www.stevesyder.com
6. 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;
Steve Syder – Programme Case Study Page 6 of 28 www.stevesyder.com
7. • 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.
Steve Syder – Programme Case Study Page 7 of 28 www.stevesyder.com
8. 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.
Steve Syder – Programme Case Study Page 8 of 28 www.stevesyder.com
9. 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.
Steve Syder – Programme Case Study Page 9 of 28 www.stevesyder.com
10. 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.
Steve Syder – Programme Case Study Page 10 of 28 www.stevesyder.com
11. 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.
Steve Syder – Programme Case Study Page 11 of 28 www.stevesyder.com
12. 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.
Steve Syder – Programme Case Study Page 12 of 28 www.stevesyder.com
13. 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.
Steve Syder – Programme Case Study Page 13 of 28 www.stevesyder.com
14. 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.
Steve Syder – Programme Case Study Page 14 of 28 www.stevesyder.com
15. • 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
Steve Syder – Programme Case Study Page 15 of 28 www.stevesyder.com
16. • 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.
Steve Syder – Programme Case Study Page 16 of 28 www.stevesyder.com
17. 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
Steve Syder – Programme Case Study Page 17 of 28 www.stevesyder.com
18. 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
Steve Syder – Programme Case Study Page 18 of 28 www.stevesyder.com
19. 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.
Steve Syder – Programme Case Study Page 19 of 28 www.stevesyder.com
20. 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
Steve Syder – Programme Case Study Page 20 of 28 www.stevesyder.com
21. 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.
Steve Syder – Programme Case Study Page 21 of 28 www.stevesyder.com
22. 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
Steve Syder – Programme Case Study Page 22 of 28 www.stevesyder.com
23. 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.
Steve Syder – Programme Case Study Page 23 of 28 www.stevesyder.com
24. 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.
Steve Syder – Programme Case Study Page 24 of 28 www.stevesyder.com
25. 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.
Steve Syder – Programme Case Study Page 25 of 28 www.stevesyder.com
26. 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.
Steve Syder – Programme Case Study Page 26 of 28 www.stevesyder.com
27. 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
Steve Syder – Programme Case Study Page 27 of 28 www.stevesyder.com
28. 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
Steve Syder – Programme Case Study Page 28 of 28 www.stevesyder.com