The Takeover of the NatWest Banking Group by The Royal Bank of Scotland

At the start of the new Millennium, The Royal Bank of Scotland made an audacious bid for the NatWest Banking Group. It was audacious for a number of reasons, including:

• It was made in direct competition to another bidder, The Bank of Scotland.
• NatWest was four times bigger than RBS.
• They had different technology and database platforms.
• The RBS management style and culture were very different to that of NatWest.

Of course, there were many other reasons that were of a non-technology perspective and which have been well documented. This paper looks at what was a key takeover objective and that was the integration and harmonisation of the technology platforms and databases. This paper focuses on one element of this which was the Governance of the Programme and its challenges. Governance is about process, rather than substance. It’s about creating an environment where support and encouragement can be offered and where policing and intervention can take place. It’s about providing appropriate information to different levels of management to enable effective decision making and building confidence with stakeholders.

Producing a paper that describes all the functions undertaken by Governance, and quite a few of the anecdotes that occurred over the period, would take up too many pages. So, to give a flavour of one aspect of the programme, Programme and Project Planning, Appendix 1 attempts to provide an insight into some of the challenges and issues around the creation of Programme and Project Plans and the use of MICROSOFT PROJECT version 98 as the tool. (NB  I would ask the reader to remember, though, that the events took place 20 years and I may have forgotten some aspects. Also, to bear in mind the version of MS Project being used was MS Project 98).

This paper does not try to suggest that what was undertaken was mind-blowingly unique in the world of Programme and Project management. However, in the context of the business opportunity, the impact on the business and the economy should it fail, the challenges faced by the take-over and the personalities involved, the role of ‘Governance’ should not be underestimated.

To appreciate the ‘challenges’ it’s useful to understand a bit of the history and rivalry within Scottish Banking.

In the years preceding the New Millennium, the Scottish banking system was almost 100% focussed on serving customers who lived and/or had business interests within Scotland. There was a small presence in England as well as The City, however, the majority of activity was in Scotland. There were three banks that formed the nucleus: The Bank of Scotland (BoS), The Royal Bank of Scotland (RBS) and The Clydesdale Bank (Clydesdale).  All three banks provided similar services but they each had a persona they liked to project and protect, particularly when it came to the issuing of their own bank notes…a subject dear to the heart of London Black Cab drivers. In fact, to an outsider the banks could be perfectly summed up by the sketch performed by John Cleese, Ronnie Barker and Ronnie Corbett in the 1966 ‘The Frost Report – The Class System.’ The Bank of Scotland represented ‘old money’ whereas RBS was more about ‘opportunity’ a bit like an excited spaniel. Clydesdale was based in Glasgow, enough said for the other two banks who were based in Edinburgh. Each bank had loyal customers who had expectations. In the case of BoS, solid, conservative, risk averse, old fashioned service etc. etc. In the case of RBS, reliable, outward looking, non-boring, opportunities, technology driven etc. etc. In the case of the Clydesdale, well, they are based in Glasgow. OK, a very simplistic assessment and based on anecdote rather than being a Banking ‘expert.’ However, having worked at BoS and RBS, it’s a fair tongue in cheek assessment.

In the years leading up to the new Millennium, there was nothing to indicate that a seismic shift in Scottish banking was about to happen. Then, in 1998, the CEO of RBS, Sir George Mathewson brought in Fred Goodwin, from Clydesdale, to be deputy CEO.

Sir George had a vision for RBS to be transformed from a relatively small national bank into an international one and the acquisition of Fred Goodwin was a major step in that vision. Mr Goodwin worked at Clydesdale Bank and had made a bit of a reputation in his management style and approach to cost cutting. In theory such a move would not normally generate excitement in the Scottish banking world and, certainly, not amongst those in The City. Then, in 1999, the BoS made a bid for the NatWest Banking Group, following NatWest’s own unsuccessful takeover of Legal and General Insurance. For people working in the Scottish banking sector this was unbelievable that a Scottish bank would make such a move. In addition, the NatWest chairman likened it to ‘a corner shop taking over Tesco.’ The technical reasons for the bid can be studied elsewhere but, from a technology point of view, BoS envisioned minimal risk as both parties would continue with their respective computing setups, even though BoS were quoted as being most dismissive of NatWest’s IT plans. At this point in time, the use of technology within BoS was more to do with supporting branch operations rather than being a means of innovation and opportunity. BoS customers were used to going into branches and managing their requirements face-to-face, so, there were very few centralised services for customers to access. It appeared that NatWest were very similar so, why change? BoS started moving through the acquisition process, probably thinking that it was all done and dusted until, RBS made a bid of its own. A summary of the RBS bid can be found as a PDF document here.

As can be seen in sections 5 and 6 of the document, reference is made to RBS plans to integrate NatWest’s platform onto it’s own, rather than the BoS approach of leaving things as they are. As part of RBS’ due diligence of the takeover, a large amount of work had already been undertaken to understand NatWest infrastructure, technology and database structures. This had led to studies by RBS Manufacturing Division, a number of consultancies as well as IBM, who were the mainframe technology provider, to determine how this would be done and whether the existing infrastructure would cope from a performance point of view. From advice given a strategy was devised that included scope, timescales, high level risks and a high level plan of how this programme was to be managed. On the very day the final announcement was published that The NatWest Banking Group was now part of RBS, the strategy was put into action.

As previously indicated, the strategy wasn’t about accommodating NatWest systems and technologies and coming up with a ‘third-way’ solution. RBS wasn’t going to change anything, even if it meant NatWest having to take a step backwards. An example was with its Microsoft Windows technology. In the majority of the RBS estate it was Windows XP, whereas, in NatWest it was Windows 97. So, if Windows 97 was a problem to integrate with RBS applications, NatWest had to change to XP. As can be imagined this caused a lot of friction. But, it was nothing compared with the second part of the strategy which was to consolidate NatWest customers and move them onto the RBS database.

So, with Fred Goodwin heading up the integration team, supported by NatWest management, the scene was set for not only integration to the RBS platform but also imposing RBS management style, governance, responsibility and accountability within NatWest.

Work began on the first part of the strategy with NatWest producing project plans, risk analysis, resourcing requirements and the plethora of other management tasks associated with normal projects and programmes. After a short time, though, it became obvious to RBS management there were two major problems. Firstly, the management structure required to control the programme was unfocused and weak. Secondly, the data from which decisions were being made was unreliable at best and made up at worst. It should be noted that Mr Goodwin had a reputation of being ‘demanding.’ This reputation was well founded in the industry as the nickname he had gained at the Clydesdale Bank was ‘Fred the Shred.’ On the one hand it reflected his ruthless ability to cut costs and dead-wood but it also applied to his grasp of detail and shredding to pieces those who were not up to the task. (NB     an interesting insight into how senior NatWest management were anticipating this takeover can be found here)

Those who came from the RBS side were already well versed in Mr Goodwin’s approach and how you presented yourself, your arguments and how you needed to back them up with reliable and trusted data.  NatWest management were now starting to understand what the future held.  It was after one of these meetings with NatWest management that Mr Goodwin must have decided that a new element of oversight was required that would focus minds, promulgate consistency of approach and ensure the reliability of data from trusted sources. A senior RBS manager was appointed to create a Governance function that would oversee the Programme and ensure that the RBS style, culture and processes were imposed. The first task was to undertake an review of NatWest practices, in particular their approach to managing projects, effective use of tools and the methods used to ensure quality of products produced. The review concluded that:

• The programme of projects had not been designed to ensure projects could be viewed and managed both individually and collectively.
• Individual projects were created with little thought of how they would be managed, interact with other projects, have common and consistent use of tools, how management data would be collected and presented to ensure confident use in reports, how issues, problems and risks would be reported and resolved. In addition, there were no quality plans to show how products from the project would be accepted by those who imported those products into their projects.
• The ability of project managers to acquire resources, particularly staff, was increasingly difficult due to the high rate of people leaving, low morale and the Human Resources department being overwhelmed managing the turnover of Nat West staff.

The recommendation was that the Governance function should create an environment consisting of:

• Common standards
• Common and repeatable processes
• Common reporting structures
• Consistent project planning structures to be used by each project
• Improved project progress reporting, using common milestones and data from managed project plans
• Improved management intervention, based on trusted project data including plans, risk analysis, resource planning and delivery of products that would support the delivery of business benefits
• Defining, using and monitoring of support tools for project planning, product testing, change management, security management and the preservation of agreed and approved products

In addition, an overall topography of the programme should be produced showing individual projects and their interdependence, products to be delivered and mapping their relevance in facilitating the delivery of business benefits.

The reason for this approach was twofold;

• Firstly, there were no common standards and practices that were consistently and rigorously applied, as it was up to individual project managers to organise their projects as best they could. It should be said, though, that this was often a common situation in a wide variety of companies.
• Secondly, many of the staff were being lured away by staff agencies as other Banks took advantage of the situation. This meant that there was going to be a big reliance on bringing in contractors, who needed to be brought up to speed very quickly. On the positive side this was, in fact, an excellent opportunity for RBS to develop and impose standards and practices that could be used to focus the NatWest implementation. Appendix 1 describes how this was achieved in the case of Programme and Project Plans.

The Governance Plan was designed to reflect that approximately 400 projects would be required to deliver both the integration and harmonisation of NatWest data onto the RBS platform and to standardise the technology. In addition, the programme would be operating on a 24 x 7 shift plan during the final three months. The overall design and phasing of the solution and work to be done was undertaken by RBS supported by IBM and a map had been produced that envisioned the pathway to be undertaken. IBM had, as part of RBS’s due diligence, undertaken a number of design and performance simulations to ensure the bank’s technology and ramped-up infrastructure could support and sustain a number of business volumes and scenarios. What NatWest had to do was to implement this design and show to the RBS Board that it would be delivered on time and would deliver the means by which the business benefits required by the Board would be achieved. So, with these challenges ringing in their ears and the confidence of ‘What could possibly go wrong’ the enterprise got underway.

Governance had two distinct workstreams; Programme Security and Governance Management.

Programme Security focussed on addressing all aspects for the security of the programme which ranged from access to sensitive files and accounts, design of secure rooms, personnel vetting, data protection and, of particular interest to the Main Board, the restriction of market sensitive information. This workstream was managed by a senior NatWest manager reporting to the Programme Board, and supported by a small team of security experts.

Governance Management focussed on the design, implementation and management of a wide range of programme support functions. The workstream also supported the Programme Security function by managing the implementation of security projects.

Key challenges for Governance included:

• Predicting and procuring staff, both for support functions and technical project staff.
• Implementing data, access and infrastructure security to ensure sensitive customer information was protected. This was particularly important for some Divisions, particularly those in the private banking sector.
• Producing appropriate reports, using key data sets, for different levels of management.
• Undertaking drains-up audits of potentially struggling projects and assisting with remediation.
• Ensuring products produced by projects were signed-off and adequately secured.
• Ensuring Lessons Learnt, as projects were closed, were acted upon and communicated to other projects.
• Providing the Programme Board with relevant data for presentations to key internal and external stakeholders, including:
  • Data Protection and Computer Misuse regulators
  • HM Treasury
  • HMRC
  • RBS Main Board

For the Programme Board, headed by Mr Goodwin, there were two key milestone dates:

• Database Integration Start Date
• Programme Completion Date

These two milestones had fixed dates and could not be extended. However, the Programme Board were keen that they should be shortened, mainly, they wanted to surprise the Market and Media with a statement that declared the Programme completed, a full monthly cycle had been undertaken and customers had not been aware of it or affected by it. So, it was with a great deal of satisfaction that the RBS Press Department were able to announce:

The Royal Bank of Scotland Announces Completion of NatWest IT Integration

13 November 2002

The Royal Bank of Scotland Group has today announced the successful completion of the integration of the NatWest customer base onto the RBS Group IT platform.

Commenting on the achievement, Group Chief Executive, Fred Goodwin said:

‘The conversion took place in early October and we have now completed an entire monthly cycle of operations on the enlarged IT platform. Systems performance has been excellent, and the IT integration can now be declared complete, and a success.”

“When we acquired NatWest in March 2000, many doubted whether we could migrate a customer base three times the size of The Royal Bank of Scotland onto a single Group technology platform. Whilst the scale and complexity of the challenge was without obvious precedent, I had every confidence that our people would deliver – they have done so and completed the task well ahead of schedule.”

For further information:

Carolyn McAdam

0131 523 2055

Alan Waite

0207 427 9574

There were three reasons why the Programme Completion Date was significantly shortened:

• The Programme got smarter over time about how it went about its work, resulting in elapsed times being significantly reduced. This was through improved use of resources, repeatable tasks that were not a reinvention and the confidence of staff to be honest about issues in a timely manner.
• During the time of the programme, a small number of re-planning initiatives took place, based on real-time data, as opportunities and issues arose. It was the ability to undertake these exercises, using real and current data, that helped to reduce the programme delivery time by 4 months from the publicised date of end of March 2003.
• The fact that a proactive Governance function was in place to monitor activity, support Project Managers who had issues but, also, had the backup of the Programme Board to take decisive action to resolve issues no matter where they occurred or with whom.

Although the Programme Plan finished at the end of the Programme Completion date, it was moved into a new plan that was designed to track and report on the realisation of business benefits, that the Main Board had identified as part of the overall justification for the takeover. The work that had been undertaken under the Integration of the NatWest customer base onto the RBS Group IT platform did not, itself, produce the business benefits. What it did do, though, is to facilitate the realisation of those business benefits through the successful integration and harmonisation of data and technology. This, then, became a piece of work that the broader bank undertook and it is gratifying that the approach that had been taken was adopted by this group. The Benefits Plan took the outputs from the Integration of the NatWest customer base onto the RBS Group IT platform and used them as the products that would facilitate the realisation of Business Benefits, through a series of procedures, processes, measurements and project plans.

In February 2001, I had been contracted by the Royal Bank of Scotland to work on an assignment to review some of the processes that were being introduced in the Manufacturing Division which, amongst other things, included the IT function. As I had undertaken an assignment a few years earlier, managing Year 2000 Compliance of their Voice and Telecommunications infrastructure, I had some experience of how Manufacturing went about managing projects.  I reported to a Senior RBS manager but after a couple of weeks I was asked to undertake a review of NatWest’s management of IT-focussed programmes and projects, with particular emphasis on scope, structure, reporting, use of tools and reliability of reporting data. I was also asked to compare my findings with the RBS approach. At this stage I wasn’t advised why the review was being undertaken, just that it was required. Following my report and a short presentation, my boss was tasked by Mr Goodwin to create a Governance division that would be overseen by RBS but implemented and managed by NatWest. You could say that it was the starting of a Programme Office except that, it had far more influence and clout of any Programme Office I’ve seen. The NatWest manager who was to run this office was, it has to be said, not that keen on the role, so, I was asked to support him. We had a meeting and we really got on well together. He’d been with NatWest all his working life and knew an incredible number of people and this proved valuable. We agreed on a way we could work together; he would still be responsible for the Governance function, as that was a requirement by RBS, and I would report to him and manage the creation, implementation and day-to-day operation of the department. This was signed off by RBS through the newly created Programme Board, with my RBS manager ensuring I had a dotted-line to her.

So, that’s what we did. Through this approach RBS were able to introduce its standards, practices and management style and we were able to feedback and improve those standards etc. within RBS as the Programme developed. My NatWest manager was able to use his network of contacts to promote what was being introduced and imposed and to get senior NatWest Directors and Management on board. It should be noted that not everybody was keen on the RBS-way but, as Mr Goodwin had already made clear, the success of the Integration was paramount and the Programme Board would not be wasting time by going round road-blocks, or, pandering to sensitivities.  Some management took it personally and, in many cases, moved on to ‘seek other opportunities’ whilst others decided to ‘give it a go.’ It has to be said, though, that a few who had decided to ‘give it a go’ were later advised to ‘seek other opportunities.’

My NatWest manager and I were fortunate to see out the Programme and I was drafted back into RBS to review and strengthen Governance from what had been learnt from the NatWest experience. Along with a number of NatWest colleagues, including my manager, I was presented with an RBS Ovations Award which, in my case, was unusual as it was reserved for RBS employees. My contract was extended until the end of 2002 and I then moved on to new opportunities.

This was the last time I worked for RBS, although, I was contacted when RBS took over ABN Amro, but I was working for other clients….in hindsight I’m glad I was. I did have an interesting experience in 2003 when working with the IT function of Churchill Insurance Group. The IT Director came to me and said that  Churchill had received a take-over bid from RBS and, as he knew I’d done some work for them, did I have ideas about how it might affect the IT division?

So, what made this programme of work more successful than the majority of programmes?

It‘s a complex question and, to be honest, I wouldn’t want to give the impression I have those answers. From my point of view though and, in the role I undertook, the most significant factor was the clarity of purpose, focus, support, motivation, appropriate intervention and letting people get on with it, albeit in a control manner, demonstrated by Mr Goodwin and the Programme Board.

The value of the way the Programme Plan was developed and managed could be summed up in a simple cascade of accountability. For instance; if a Programme Board meeting was taking place, Mr Goodwin would ask the Programme Director if the two key, critical path dates (Database Integration start and Programme Completion dates) were still going to plan if the Programme Director said there was an issue, Mr Goodwin would expect the Programme Director to present a detailed plan of how it was going to be brought back in line. On other occasions the Programme Director might say that the dates were still on track. Mr Goodwin, in many cases, would be pleased and move onto the next item on the agenda. However, sometimes he said “Where’s your evidence?” The Programme Director never knew when that question might be asked and, if you couldn’t provide that evidence at the meeting, there was big trouble that cascaded all the way down the ‘accountability tree.’ So, it could be said that the reason why the Programme Planning approach was successful was based on a) That’s what a successful Programme required and b) FEAR….of being asked “Where’s your evidence.” and not having it. Personally, I would say, to the outside world, that the balance between a) and b) was 60:40. In reality it was 30:70.

The idea of ‘Governance’ in the way it was implemented and managed, was not accepted by all factions of NatWest management. In fact, there was resistance. However, there were three factors that overrode these resistances:

1. The CEO, Mr Goodwin, was personally responsible for the success of the takeover, not only in the eyes of the main board, but in the eyes of the market and the Government.
2. RBS wanted to encourage/impose NatWest to adopt common standards and ‘Governance’ was seen as the vehicle to do this.
3. Mr Goodwin, as head of the Programme Board would, if necessary, personally intervene if resistance could be shown to threaten the delivery of the Programme. From a Governance perspective this level of involvement had to be justified because, if it turned out not to be justified the backlash would be huge. Intervention was requested on a small number of occasions and involved senior divisional Directors. Of course, attempts would have already been made to resolve the issue and this would have been a final action, although these attempts would not have been over a protracted time; we are talking about two or three days from the time an issue was raised, attempts to resolve and the final word from Mr Goodwin. For NatWest, this speed of issue resolution was something they were not used to.

The approach to Programme/Project Planning basically remained the same during the life of the Programme. Some subtle changes were made through Lessons Learnt and anticipating future Programme changes. The use of Planning tools and Testing tools were developed as a central resource, rather than relying on the ability of individual Project Managers to master the complexities of those tools and the application of activities and tasks within those tools.

The Programme Board were able to undertake a number of ‘what if’ scenario exercises using the trusted and reliable data being produced, which helped to shorten the Programme timescales.

It was decided, fairly early on in the programme, that the usual practice of leaving it to Programme Mangers and Project Managers to develop the various tools and practices needed to support the programme would not be sustainable in such a fast paced and nationally important piece of work. The main focusses were:

• Planning the programme using Microsoft Project Plan
• Testing tools including WINRUNNER, TEST DIRECTOR, LOAD RUNNER etc.
• Quality Reviews, sign-offs and Audits
• Managing Risks
• Managing Document and Project Reviews
• Project and Phase Acceptance Testing
• Managing the security of information and access to information

There were four main reasons that such an approach was necessary:

• Mr Goodwin was taking personal responsibility for the success of the programme.
• Key non-bank stakeholders included HMRC, the Treasury and the Data Protection Commissioner. The concern for HMRC was the risk to the transfer of daily payments from this enlarged bank; the Treasury was concerned about the risk to the economy if a protracted blow-up of the system occurred; and the Data Protection Commissioner was concerned about security loopholes and access to accounts by Project staff as a well as a request was made for a depersonalised copy of the database to be used for system performance testing. Inspections were undertaken by these stakeholders so, the use of verifiable evidence was particularly important.
• Consistent practices were required to ensure decisions could be taken using reliable, comparative and trusted data
• Project managers and other staff were required to contribute with minimum lead-in time

In any project it is important that not only are detailed requirements agreed and articulated but staff understand the underlying expectations of senior management. In this case, Mr Goodwin made it very clear what his expectations were:

• The programme will go live before the published date at the end of March 2003
• The outcome of the programme will be to ensure that customers are not affected and, in fact, will not realise the programme has transitioned
• Key non-bank stakeholders will be confident the programme will be successful because of the use of trusted data to support decisions and as the basis of sharing information with them
• There will be no unauthorised leaks of information to the media
• All resources required will be provided and, whilst there was no blank cheque, funding would not hold the programme back

This was never written down but it’s the essence of Mr Goodwin’s expectations.

The selection of a project planning tool was very important. However, both RBS and NatWest used Microsoft Project as the tool for managing the tasks, activities and milestones of a project and it was felt that the introduction of new products, even though they might have better functionality, would be counter productive. At the time, 2001, Microsoft Project 98 was not the easiest tool to use both in the way the project plan could be transcribed to the tool and the ease by which the plan could be maintained and used as a trusted source of information. Add to that that not every Project Manager knew how the tool worked or, indeed, how they should use it in a proactive way and you have a recipe for inconsistency and frustration. In fact, it was often the case that Project Managers spent more time trying to get MS Project to produce a sensible plan than managing the project and, even if they did, it wasn’t maintained in a proactive manner. At the time, NatWest staff were no better or worse than the majority of companies in the use of MS Project which, basically, was woeful. So, the challenge was “ How do we use MS Project to actively support Project Managers and produce meaningful and trusted management data and improve the usefulness of MS Project” After careful consideration and reading the findings of the Review, it was decided that we needed a strategy for the use of MS Project.

• Although other planning tools were coming to the market, MS Project would be used because NatWest and RBS were already familiar with it.
• Project Managers would not be responsible for the creation of project plans. Governance would be responsible for delivering the structure of MS Project plans to ensure consistency and repeatability across all projects. It would further ensure that a daily snapshot is available of project tracking, project slippage and remedial actions is available for Senior Management review.
• Project Plans would be designed with six key features:
  • The overall concept and design of Project Plans would be the responsibility of Governance, not Project Managers
  • Every plan would have common Milestones, with fixed delivery dates and deliverables, that would be used for progress tracking within the project and to interdependent projects
  • Activities and tasks that supported each milestone would be in the form of templates that could be dropped into a project plan.
  • Project Managers would be responsible for planning the activities and tasks in terms of resources, effort in man-hours, elapsed time for the task to be completed, contingency, dependencies etc. Other task descriptors included, Risk Assessments, Quality Reviews, Drains-up Audits, Management Sign-offs etc
  • At 4:00pm each day a wash up session would take place between members of the project, Project Managers and Planners, at which each task would be appraised for completion and its percentage recorded.
  • At 6:00pm each evening the Programme Board would be informed if the fixed dates for the Database Integration and Programme Completion were at risk. If there was a risk, a plan had to be presented to the Programme Board by 9:00am the next morning describing the remedial actions to be taken.
• Governance would employ MS Project trained and experienced Project Planners who would assist Project Managers to identify activities and tasks and insert them into the MS Project tool.
• The strategy would be signed-off by the Programme Board, headed by Mr Goodwin, to ensure it would be accepted by all divisions of NatWest, as it was known that some divisions would resist.

To ensure MS Project plans were robust, manageable and fit for purpose, it was decided to engage MICROSOFT themselves to help design the structure of the project plans, linkages between inter-project milestones, boiler-plate activities and task modules. They were also engaged to train the Project Planners and create an Induction Pack for new Programme and Project Managers. The most complex task, though, was the creation of a database that enabled changes to a key Milestone, in an individual project, to be reflected in dependant milestones either in peer projects or projects yet to be undertaken. The driver for this were the two Milestones being observed by the Chief Executive, Mr Goodwin, which were the Database Integration Start Date and Programme Completion Date. These two dates represented the points when all the preparation projects had been completed so the Integration and harmonisation of databases which was, itself, represented by 12 work streams, could begin leading to the Programme Completion date. At this point a Press Release would be issued stating that the integration had been completed and a full, live monthly processing cycle had been undertaken. So, how was this achieved:

Each project plan had five milestones:

Discovery, the Project Manager would ensure they understood what was required, the deliverable, dependant projects, resources, risks etc. This would result in a Project Plan which contained activities, tasks, risks, dependencies imported from other projects and exported to other projects, resources, elapsed time and effort, together with a percentage contingency (the thresholds for contingencies were set at within scope and alert). Discovery required sign-off from the Programme Manager and appropriate staff as identified within the RACI document. The Project Manager would work with the Project Planner to embed this into the MS Project planning tool.

Solution Design, the Project Manager, together with the project team, would identify the product(s) to be produced and how they would be achieved. Any imported products from other project teams would be identified and an agreement reached on the Milestone date for delivery and the criteria from which the product would be assessed and judged.

Product Development, the creation of the solution and its testing culminating in a defined product being produced.

Product Acceptance, either by a dependant, follow-on Project Manager or to be deposited in a holding area. This exercise of Product Acceptance is where the receiving Project Manger would sign-off its acceptance, or not, using acceptance criteria previously agreed.

Product Handover, this is when the product is formally handed over to the recipient and is the key Milestone date, that is used in the tracking of project progress. The date is fixed and would only be altered following a drains-up review and approvals.

Each of the activities and tasks had a percentage amount of contingency to provide Project Managers with some flexibility and this was reflected when assessing whether each of the milestone dates were to be achieved. The Product Handover was the Critical Path influencer and it was used to determine whether the Integration Start Date and/or the Completion Date would be exceeded. So, how did that work?

The daily 4:00pm wash-up meeting would examine each task that was being undertaken. The project team would assess how much of that task had been completed and the figure would be entered by the Project Planner. Challenges and clarifications would be discussed to ensure to ensure the claim was realistic. If the completion of that task remained within the predicted completion date, including the first threshold level, it would be assessed to still be on track for its completion date. If the prediction, though, fell outside the first contingency and into the second, alert, contingency it would be considered to still complete on time but an alert would be highlighted for the Project Manager to take action. If, however, the completion date went beyond the contingency date an alert would be sent to the Programme Manager. Where a task’s completion date exceeds the planned completion date, the rest of the dependant tasks would be adjusted. If that resulted in a Milestone being affected, remedial actions would be required to mitigate the issue. Where this is critical is if the Product Handover Milestone is affected as this could affected other, dependent projects. This, of course, could affect the Critical Path which would involve Project Directors as part of an effort to support the project get back on track. Of course, if the adjustment of the plan got to the level of Integration Start Date and/or Project Completion Support Date, the Programme Board would be alerted. If this happened there would be serious implications, which was the case on a few occasions, so, Programme Directors and Programme Managers would be in direct line of Mr Goodwin’s laser focus. As the updating of the Programme Plan was automated and could not be manipulated, outside the Governance function, the mechanics had to be flawless. Hence the reason for the involvement of MICROSOFT to create the structure of the plan. Of course, as remedial actions took effect any issues being resolved could bring the issue back into line. To make this function properly, the project team had to be confident that their honest appraisal of task completion that resulted in alert flags being raised, they would be supported by management to help with those remedial actions. It quickly became clear to Project Managers that whilst a certain amount of subjective estimation could be tolerated, they could quickly become subjected to an audit if their estimation did not appear realistic. In the early days of the programme some managers did have a problem appreciating what this meant. In some cases, albeit a small number, contract staff were removed, NatWest staff were reassigned.

The next level of Milestones were at the Programme level. The Programme Milestones of Integration Start Date and Project Completion Date were replicated on the Programme Plan and allocated to the 12 workstreams that formed the drive to the Programme Completion Date of end of March 2003. This provided the overview of the Programme. To achieve this Microsoft had developed the means by which data from each Project Plan automatically updated Milestones within the Programme Plan. This meant weekly/monthly Project progress meetings were not required, using best guess estimates from Project Managers. As each 4:00pm wash-up meeting concluded each of the Project Plans would be updated which triggered Project Milestones to be revised, if contingencies were exceeded, which updated Programme Plans and Milestones. This approach had a number of key benefits:

• Project Managers did not spend time trying to get MS Project to work and could get on with their main job.
• It saved Project Managers an enormous amount of time they would have spent in progress meetings.
• Senior managers were no longer behind the decision making curve, using outdated and unreliable data. Accurate Project Progress information was available in reports by 6:00pm each evening, seven days a week.
• It also meant that the selection of Project Managers could be based on skills other than their experience of MS Project.
• Many of the projects were similar in nature and this enabled Project Managers and technical staff to be moved around and undertake roles on more than one project at a time. An example was during the time products were being tested by a dedicated team releasing the Project Manager and staff to undertake, say, the Discovery tasks of another Project. Or, to be allocated as additional staff to a struggling project. Governance had a dedicated team analysing and predicting staff resourcing and it was like watching the conductor of an orchestra bringing different elements into play.
• If, at a Programme Board meeting, Senior Management were required to produce evidence of claims they were making, this could be provided all the way down to task level.
• If the Programme Board wanted to see the effect on the Plan of scenarios, this was achieved using a copy of the real data, introducing the scenario and producing an outcome.

As the strategy was being created and MS Project was being developed, thinking had to turn about how the Governance of the project plan was going to be resourced. Although roughly about 40 Project Planners were required, it took a couple of weeks to resource them. As the usual channels for recruiting contract staff were under pressure in other areas, the Governance team took the initiative and developed a skills and experience specification and then engaged with two contract agencies to begin the selection, interviewing and procurement of staff. Contractors were engaged in batches of 10 allowing training to be undertaken to educate them in the structure of the project plan and to upskill them to use newly developed MS Project functions. As the recruitment drive took place, it was obvious that some contractors had good experience in analysing project plans from an overview perspective that would enable the team to look for opportunities to reshape the overall programme and to react to influences created within the programme or external to it. This enabled the team to undertake simulation exercises and present options to the Programme Board. This approach, together with the ability to base judgements on trusted data, from the project plan and the testing plan, enabled the Programme Board to make decisions that were to have a profound effect on the Completion Date of the programme.