Gathering Requirements – Getting to the what

Chris and I arranged workshops with the customer’s project, operations, IT, and CIO representatives including network SME’s. Chris planned all the workshops to be completed within one week to try and reduce costs, which was difficult due the notice period given to the audience and my insistence that they must start in the morning, as I believe brains are more active in the mornings and you reduce the affects of the nodding head and eye closing syndrome.

I put together an agenda for each of the meetings and sent it out to the participants in advance. I wanted to ensure that everyone knew what was expected of them and the objective of each workshop. I have attendended so many meetings where the objective was not clear and I asked myself what was all that about.

I also tried to keep the attendance down to a few people as possible and not mix the teams until the last workshop, this was to try and reduce the long periods of debate.

The last workshop was to enable all teams to review each other’s requirements and assess the impact and resolve conflicting requirements, though it did result in the long debates and the meeting overran by an hour. Despite the overrun, I made sure the debate reached a surefire conclusion.

The table below details the major objective for each of the workshops. In each of the workshops the business analyst, John Curry took down each requirement and categorised them as functional and non functional.

Audience	Objective
Project Representatives	Obtain understanding of the project deliverables and constraints, (high-level project requirements)
Operations Representatives	Obtain requirements for data representation within the system, capturing usability requirements, for example, formatting rules and capture source systems and data origin.
IT Representatives	Obtain requirements for legacy system data extraction, data formats, security requirements, development, test, and production requirements and impact of extracting data on the legacy systems.
Network/General Subject Matter Experts,	Obtain requirements for network modelling in the new system, also understand how the existing network is represented in the old system.
CIO/CTO Representatives	Obtain strategic direction of the company, in particular future services to be delivered and market aspirations. This is to ensure that any modelling configurations are future proofed or will adapted as far as possible to the future changes.
All	Go through each requirement, identify any impact on the other teams, for example new modelling requirements may result in extra data to be populated by the operations teams. Resolve conflicting requirements and gain agree for each requirement.

The biggest project requirement was that the inventory system will represent the inventory using the out the box system capability, which meant that no custom data elements or coding will be required, which was a good thing as I knew we did not have the budget for any custom development.

The First Customer Meeting – Project kick off

Chris and I were taken to very large meeting room 10 minutes before the meeting to set up and get ready. The room consisted of a single desk just below a large presentation screen and rows of chairs radiating out from the desk. On one side of the room there was a wall of glass over looking London, the view was breath taking.

Whilst I was taking in the view, Chris was trying to get the slides to show on the large screen, but as per normal the overhead projector ceased to function.  I am sure that these things know you have an important meeting and decide, hay I am going play a joke on these guys and get them crawling on the floor under the desks before the meeting, so when everyone comes in they are sweating, their shirts are hanging out and they look a mess.

By this time the room was full of people, and a guy comes over and presses a combination of buttons, (which I am sure that only he knew), and everything works and we were looking inadequate, which again I think is part of the joke.

The number of people in the room was overwhelming, there were so many, there were not enough seats in the room and they needed to bring their own seats in. The introduction took a while and they ranged from, Customer relationship, Operations and Billing managers, CTO’s, CIO’s and number of IT and subject matter experts.

Chris presented the migration activity plan, and everyone in the meeting seemed to be mildly comfortable with it, but there was a number of concerns around the impact of such a migration on their various teams, and was worried that it would result in extra work on an already stretched work force.

This is a valid concern. Any introduction of a system will result in extra work and will impact the business as usual processes. But with careful planning, phasing and working closely with the operations teams/users the transition will be smooth and will minimise the business impact.

I have seen a number of projects where an introduction of a system was done without the operational units being involved. This approach led in some cases, to resentment and resistance as the system was completely alien to them. It is human nature to oppose change, so including the operation team/users at an early stage in the migration is key to reduce the operational impact.

In the meeting I stated that a migration process will be provided and that the operations team will be involved in the construction of this process. I said that the success of the project does not just lie with the System Integrator (SI) and project teams but lies with collaboration with all the various operations teams/users, after all they will end up working with it when we have gone.

A question arose around the need to carry out the data analysis, specifically around understanding the data quality. It was stated with some conviction that the data quality is excellent and that there is no need to carry out a quality audit. I ensured him that this was not about the actual data itself, rather that the legacy data has the required data fields present to populate the new target system.

Migrating data from one system to another is rarely a case of copy and paste. The new system usually requires more data to satisfy an ever increasing complicated data model to enable it to automate functions, which was previously manual. It is common that an existing system will run perfectly fine, but migrating the data into another system may require extra data, which is not there in the old system.

After all the people left, Chris informed me that the System Integrator (SI) only quoted a third of the price it would take to complete the migration project, and to reduce costs where we can. I now understood why Chris was so keen on completing the project quickly.

This is quite common as I have seen a number of data migration projects that have been under estimated. It seems there is this view that data migration is a simple case of copying the data from the old system and loading it into the new system. There is no thought about possible missing data fields that are required to drive the new data model, extracting and handling large quantities of data from different sources, in varying data formats, data cleansing, data security and building processes that enable the migration to be carried out with little or no risk to the operation of the business.

Project Planning – Setting the beat

A meeting was arranged between my project manager and various Systems Integration technical people, as well as the customer’s project manager to set out the project plan and the tasks that were required to complete the work. Of course this fell to me as the technical consultant, to set the tasks, to enable the project manager to monitor progress of the tasks on a daily basis.

I scribbled down the activities that needed to be completed on a white board, whilst the project managers took notes and the technical guys preoccupied themselves by surfing the net, or attending to emails. I said that I would send a mail with the activities, as I was conscious of my poor hand writing, but this was not required as Chris offered to write them up in a project plan.

I suggested at the meeting that we should present the high-level project activities to the customer in particular operational managers and project sponsors, to ensure that they have exposure to the plan and they know what would be expected from them. Tony agreed to a kick off project meeting and hastily arranged it for the following week and Chris would prepare the slides for the meeting.

To find out the high-level tasks that I set for the team in order to accomplish the migration, you will need to download the plan PDF document – details below:

Downloadable plan PDF that contains the tasks (available free) can be found here – http://portal.halogence.co.uk – and can be located within the resources tab.  You will need to register and verify your email address before you can download the PDF.

The First day – The glass building

The first thing that I noticed was how busy London was, being squashed in the tube and the atmosphere that felt like it was buzzing. The walking past the historic buildings and following the other business people gave me sense of grandeur and determination, I enjoyed the walk from the tube station to the customer’s site.

The customer premises was a far cry from my previous building, (steel and concrete building with limited sunlight), it was mostly glass and overlooked London. The office was open plan and we were guided to hot desks that happen to be opposite the senior management of the company. This seemed somewhat strange as normally large corporations hid their senior management in offices. I thought this was a good move as this made them more accessible and enabled them to understand what is happening on the ground floor, however if privacy was required a room would be available for this purpose, a move that I myself encouraged while I was at my previous company.

My System Integrator (SI) Company allocated a project manager, Chris Johnson and the customer also allocated their own project manager, Tony Harris, who was also technical and was our main point of contact for the duration of the project.

Chris was very keen and eager to complete the project quickly as possible and made a point in sitting with us at our desks everyday, which I assumed was to ensure that we were working, this came as a bit of a shock to me, but we learnt to live with it, and I had no room to question this approach as I was after all just a contractor.

Corporation Interview – Coffee in London

Finally I landed an interview in London with a large System Integrator, (SI). The interview was conducted over coffee in a very nice part of London. The interview was with 4 people of which come from varying technical backgrounds, though none had specific data migration technical expertise, hence why the position was created.

The job role was for a Technical Consultant. The role was to be the technical lead on a project to migrate data into an Inventory Management System that a large telecoms operator had purchased.

This was exciting, as this was a 3 month contract based in the city of London at the customer’s site.

After a few days of waiting, I finally got the call to start. I was so glad that I finally got a job, even if it was only going last for 3 months, or so I thought!!

Introduction – About me

My name is Rickey King and I have worked in the telecoms industry for over 20 years, covering various roles from planning network infrastructure, researching ways to use artificial intelligence to optimise networks and encapsulate in state of the art network provisioning and planning tools, provided complex technical pre-sales and consultancy to large telecom operators around the world and later ran a professional services team.

In the middle of my career I founded a company, (spin out of a large telecom operator), which specialised in network data migration, and I was involved in a number of large projects to convert paper network records into intelligent data, which were loaded into a new shiny GIS (Graphical Information System). My team and I developed software that could take the raw digitised lines and convert the data into a telecoms network. It also validated the data and inferred missing network, by taking the raw connectivity data and reverse engineered the network by using the old design rules to infer cables and civils infrastructure.  Everything was going very well, but unfortunately due to economic downturn the company closed and my team and I were made redundant.

The rush was on to get a job!!