Detailed Programme Case Study
Upcoming SlideShare
Loading in...5
×
 

Detailed Programme Case Study

on

  • 558 views

Case study of an assignment Steve undertook for a Central Government Department

Case study of an assignment Steve undertook for a Central Government Department

Statistics

Views

Total Views
558
Views on SlideShare
538
Embed Views
20

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 20

http://www.linkedin.com 12
https://www.linkedin.com 5
http://www.lmodules.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Detailed Programme Case Study Detailed Programme Case Study Document Transcript

    • 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