SlideShare a Scribd company logo
1 of 28
Download to read offline
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




Steve Syder – Programme Case Study                         Page 3 of 28                                                   www.stevesyder.com
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
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
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
•   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
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
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
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
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
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
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
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
•   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
•   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
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
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
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
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
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
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
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
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
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
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
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
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

More Related Content

Similar to Detailed Programme Case Study

FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docx
FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docxFIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docx
FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docxmydrynan
 
Software Development Project Charter
Software Development Project CharterSoftware Development Project Charter
Software Development Project CharterElizabeth Temburu
 
8.project management chapter 8
8.project management chapter 88.project management chapter 8
8.project management chapter 8Warui Maina
 
PROJECT FAST INVENTORY Delivere.docx
PROJECT FAST INVENTORY  Delivere.docxPROJECT FAST INVENTORY  Delivere.docx
PROJECT FAST INVENTORY Delivere.docxwoodruffeloisa
 
IT Application Development - with SDLC.pptx
IT Application Development - with SDLC.pptxIT Application Development - with SDLC.pptx
IT Application Development - with SDLC.pptxdjualaja88
 
Project Plan For A Project Management Project
Project Plan For A Project Management ProjectProject Plan For A Project Management Project
Project Plan For A Project Management ProjectMary Stevenson
 
How To Develop A Project Management Plan
How To Develop A Project Management PlanHow To Develop A Project Management Plan
How To Develop A Project Management PlanOrangescrum
 
Software Project Management (SPM)
Software Project Management (SPM)Software Project Management (SPM)
Software Project Management (SPM)RubySaud
 
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...IRJET Journal
 
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 Project Risk Management Plan © 2015 by Jones & Bartl.docx Project Risk Management Plan © 2015 by Jones & Bartl.docx
Project Risk Management Plan © 2015 by Jones & Bartl.docxgertrudebellgrove
 
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 Project Risk Management Plan © 2015 by Jones & Bartl.docx Project Risk Management Plan © 2015 by Jones & Bartl.docx
Project Risk Management Plan © 2015 by Jones & Bartl.docxaryan532920
 
Free video lecture bca
Free video lecture bcaFree video lecture bca
Free video lecture bcaEdhole.com
 
CHAPTER 3PROJECT MANAGEMENTT.docx
CHAPTER 3PROJECT MANAGEMENTT.docxCHAPTER 3PROJECT MANAGEMENTT.docx
CHAPTER 3PROJECT MANAGEMENTT.docxwalterl4
 
Section 1a d lessons learned_guliford as of 21_apr15
Section 1a d lessons learned_guliford as of 21_apr15Section 1a d lessons learned_guliford as of 21_apr15
Section 1a d lessons learned_guliford as of 21_apr15Crystal Guliford
 

Similar to Detailed Programme Case Study (20)

FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docx
FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docxFIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docx
FIN320 – Gallaher – Prep for Exam 3 – Computational Questions1.docx
 
ATCO-BaasKaar Roadmap to SAP Quality Award 2014
ATCO-BaasKaar Roadmap to SAP Quality Award 2014ATCO-BaasKaar Roadmap to SAP Quality Award 2014
ATCO-BaasKaar Roadmap to SAP Quality Award 2014
 
Software Development Project Charter
Software Development Project CharterSoftware Development Project Charter
Software Development Project Charter
 
8.project management chapter 8
8.project management chapter 88.project management chapter 8
8.project management chapter 8
 
Quality Management Practice in IT Projects
Quality Management Practice in IT ProjectsQuality Management Practice in IT Projects
Quality Management Practice in IT Projects
 
Agile pgm
Agile pgmAgile pgm
Agile pgm
 
PROJECT FAST INVENTORY Delivere.docx
PROJECT FAST INVENTORY  Delivere.docxPROJECT FAST INVENTORY  Delivere.docx
PROJECT FAST INVENTORY Delivere.docx
 
Guide to Software Estimation
Guide to Software EstimationGuide to Software Estimation
Guide to Software Estimation
 
IT Application Development - with SDLC.pptx
IT Application Development - with SDLC.pptxIT Application Development - with SDLC.pptx
IT Application Development - with SDLC.pptx
 
Project Plan For A Project Management Project
Project Plan For A Project Management ProjectProject Plan For A Project Management Project
Project Plan For A Project Management Project
 
How To Develop A Project Management Plan
How To Develop A Project Management PlanHow To Develop A Project Management Plan
How To Develop A Project Management Plan
 
Software Project Management (SPM)
Software Project Management (SPM)Software Project Management (SPM)
Software Project Management (SPM)
 
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...
Planning, Scheduling and Allocation of Resources for Multi-Storied Structure ...
 
lecture 1-5.pdf
lecture 1-5.pdflecture 1-5.pdf
lecture 1-5.pdf
 
PM
PMPM
PM
 
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 Project Risk Management Plan © 2015 by Jones & Bartl.docx Project Risk Management Plan © 2015 by Jones & Bartl.docx
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 Project Risk Management Plan © 2015 by Jones & Bartl.docx Project Risk Management Plan © 2015 by Jones & Bartl.docx
Project Risk Management Plan © 2015 by Jones & Bartl.docx
 
Free video lecture bca
Free video lecture bcaFree video lecture bca
Free video lecture bca
 
CHAPTER 3PROJECT MANAGEMENTT.docx
CHAPTER 3PROJECT MANAGEMENTT.docxCHAPTER 3PROJECT MANAGEMENTT.docx
CHAPTER 3PROJECT MANAGEMENTT.docx
 
Section 1a d lessons learned_guliford as of 21_apr15
Section 1a d lessons learned_guliford as of 21_apr15Section 1a d lessons learned_guliford as of 21_apr15
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