PMinFOCUS

The telecommunications world is a successful example of technology standardisation. In the mobile industry GSM gave the ecosystem (operators and suppliers) a set of standards that removed a lot of technology risks, enabled the birth of a large set of suppliers and product offering and gave customers roaming benefits and interoperability.

In the area of project management itself a significant amount of work is being done to develop standards: PMBOK and Prince2 are the leading example.

Those standards are important but not enough as their practical side is not developed at all (at least for PMBOK), they are standards and not methodology. Standardisation has however not fully reached the area of project management when it comes to systems integration within a telecommunication operator environment. Why? A lot of local, cultural practices hinder the application of common approaches, but also and most importantly the variety of project sizes. Another reason is that there is no standardisation body so standards or guidelines have been defined by companies themselves often to industrialise their own processes.

So as a supplier is entering into a working relationship with an operator, it usually has to match its own process with that of the operator. In a way process integration has to happen before the integration of the product or service itself.

This article instantiate this issue and highlights some essential information about french telecommunications operators typical systems integration processes, it is mainly aimed at giving solutions vendors an understanding of the systems integration requirements that will likely to be part of their contractual obligations. This paper was written based on practical knowledge of working with three mobile operators in France. At the time of writing there are only three mobile operators in France (Orange, SFR, Bouygues Telecom) and a 4th operator (Free) has been awarded a 3g licence in late 2009.

1. Documentation

In general the documentation requirements are fairly demanding. Suppliers are likely to be asked to document:

• the logical and physical aspect of the solution,
• the detailed IP flows,
• the configuration of all elements of the system,
• the hardware set-up,
• the racking set-up and the cabling,
• the software releases notes.

Usually English is accepted – however sometimes requirements are documented in French, particularly for “standard” requirements that are imposed on all suppliers. This covers aspects such as Monitoring, Backup and Restore, Security, Remote connection, Database design, …Up to the supplier to get them translated.

Suppliers often are not used to produce all required documentation, leading to extra documentation effort and the need of specific skills for those documentation.

Tips for suppliers: Ensure documentation requirements are understood and that appropriate resources are lined-up to address them.

 

2. Acceptance phases

The overall acceptance life cycle should not be of any surprise to anyone in the industry. The advise here is to look into the details right at contract stage in order to make sure the work to be produced is understood. Before any attempt to deliver anything to the operator premises the supplier may be asked (not all operator request this) to perform some tests at the supplier premises, on an environment similar to that of the operator.

It’s called “Preliminary acceptance test” and should be considered as a FAT (Factory Acceptance test). This is to ensure that what will be shipped to the customer premises will actually be worth testing. Clearly one of the challenge here is for suppliers with highly industrialised processes where usually no FAT is performed.

The acceptance workflow, starts with the Technical verification (“Verification technique”) which is about the verification that the hardware, software versions and configurations are delivered as per specifications. The goal is to catch and fix any issues that would otherwise jeopardise the validity of the next – longer -acceptance phases. Practically speaking this Technical Verification step will involve: checking that the hardware matches the bill of material (servers, processor speeds, memory, hard drive space, power supplies, …), check OS and other third party software licences, checking that the configuration of the system is documented (and check that the documentation is accurate), checking that cables are labelled and the labelling documented, checking power redundancy.

Next step is Interconnection testing (“Tests d’interconnection”) which is about verifying that the supplier’s system can actually connect to the operator environment. This often means testing every single IP flow that the solution needs, even for IP flows within the supplier’s own system and testing basic use cases of the solution to give confidence that the solution is fit to enter the next step, Conditional Acceptance.

Conditional Acceptance (“Acceptance conditionnelle”, or “VABF (Validation Au Bon Fonctionnement)” which means “Functional acceptance”) is usually called “Customer acceptance tests” (CAT) outside of France. This is the lenghtiest of all phases. It is about testing that the solution delivers the product requirements. There is a high probability that the supplier is going to be asked to perform Backup and Recovery testing, Performance testing and Failover testing. Those more “operations” tests are sometimes called “VABE (Validation a la bonne exploitation)”.

Once Conditional Acceptance is granted the systems is usually ready to go live. But that’s not the end of the acceptance process. A last step, VSR (“Validation en Service Regulier” which means “Normal operation acceptance”) is required. VSR is lengthy (we are talking one to two months) but does not eat up a lot of resources. It consists in monitoring the system for a period of time and ensure that agreed KPIs are met over that period. If the KPIs are met then Final Acceptance is granted. Note that VSR only applies to the production environment.

Who does what?

This really depends on the operator and their staffing level (quality and quantity), but in most case the supplier usually drives the acceptance phases, providing test documentation, executing tests and documenting test results. French operators are usually more demanding in documentation and formalism than others. Roles and responsibilities need to be clearly understood.

Workflow: Test and Live system

As a general rule: activities on the production environment cannot start unless Conditional Acceptance is reached on the Test environment. This is a general rule however in practice Technical verification and Interconnection testing on production could be run in parallel to the Test environment Conditional Acceptance.

Tips for suppliers:

1. Ensure that the payment milestone at Final Acceptance is small and that most payment is done at Conditional Acceptance.
2. French are heavily “contract” driven so: spend time understanding your contract commitments (review those Annexes with “standard” requirements that contains things that you don’t do as “standard”).
3. Be upfront on the workload that operators are requesting from you with there documentation and testing requirements – are they ready to pay for all this?
4. Do involve a project manager during the pre-sale activity.
5. Negociate what happens to the VSR if Conditional Acceptance does not lead to an immediate go-live for reason outside of your control. This could indeed delay the Final Acceptance payment milestone.
6. If your integration staff is based abroad and travel to Paris to perform the Acceptance tests then you will be better off (and they will be happier) if you rent a flat for a short term.

3. Management: decision making, project management

As with many big organisations decision making will appear opaque, fuzzy, complex and more annoyingly: slow. This is more of a characteristic with large organisations than with French organisations, however because French corporations are usually more hierarchical than Anglo-Saxon’s the problem is more evident. The main day to day problem a supplier’s team will encounter is the lack of end-to-end ownership by the operator’s project manager.

As part of the integration requirements suppliers could find some ‘management’ related requirements. They should not overlook them:

• Quality management systems
  Operator will have an interest in the supplier’s quality management system. When no certification is available operators are keen to understand the steps taken to get to some level of certification in the future. Suppliers will have to figure out how strongly the operator feels about those requirements and this depends on the criticality of the system delivered.
• Specific reporting
  Supplier may be asked to report on project progresses with specifics metrics and KPIs. This should not be a problem or cause significant efforts.
• Audits
  Audits are always mention in a standard contract and could happen so suppliers should ensure they understand the requirements and get ready to open their HQ doors to auditors. The scope of the audits is usually the Quality management system.

Tips for suppliers:

1. Do not overlook “standard non-technical requirements” – failing to meet them could expose you to not meeting “Acceptance” and potentially could lead to penalties.

4. A few cultural tips

A few tips about french work culture and practices – take it with a pinch of salt though.

1. Meetings and conference calls. Expect people to be late for meetings and conference call. This is annoying for most but french usually find it normal to be late by 5-15 minutes. In meetings you will sometimes witness an separate discussion starting in french, in parallel to the main one.
2. Technical background. As a rule of the thumb expect attention to details specially when dealing with technical topics. The french education systems favors scientific studies over business studies and you will probably feel it when dealing with french companies. It comes to a point where the purpose of the project, the business purpose, seems to be less important than the technical aspect of the project.
3. Start late-finish late-lunch. Empiracal evidence shows that management usually tend to start their day late and finish late in the evening. So the english “9 to 5″ is more likely to be “9.30 to 7 with a 1 hour lunch break”
4. Outsourced workforce. Current employment legislation in France makes it hard for companies to decrease their workforce at will, so to limit the number of permanent employee they are using IT services companies, “Body shops”, to provide temporary workforce. The operators’ technical team usually has a good share of those temporary staff. They usually are quiet integrated. Note: the freelance market is nearly non existant in France.

5. Final words

Managing systems integration projects with French operators is usually challenging but it does not has to be this way. As with all contracts suppliers have to understand what they are signing for, getting to that understanding is where the difficulty is.

Suppliers should take particular care at pre-sales stage to understand in details what is asked from them.

During project execution suppliers should make sure that communication management is particularly taken care of to remove misunderstanding and constantly seek validation of what is being communicated, this is an extra effort required because of the generally average english speaking skills in France.

This paper suggests a standard set of phases that are involved in the provision of outsourced IT solutions and this from the Selling organisation’s perspective. Those phases are presented in relation to each other and form a Phase Review Discipline (PRD).

The phases identified belongs to 3 distinct groups, Win Business, Delivery and Support and we will discuss all three groups here but in particular the Delivery group.

This paper aims at: – stressing the strong relation between sales processes and project delivery processes, and what it means for the supplier’s organisation. – suggest a standard approach for the entire lifecycle, from sales to support, and how it benefits the organisation, – suggest what role a PMO may have in an organisation adopting such a PRD approach.

Note that we deliberately excluded product development from our analysis which does not mean there are no relationship with the phases introduced here.

PRD phases and phases groups

A “phase review discipline” or PRD splits a set of activities aimed towards the same goal into time based phases (so sequential) with each phase corresponding to a number of deliverables and milestones.
In project management a PRD aims at defining a standard approach across projects in order to enhance re-usability, enhance control over projects, standardise deliverables, facilitate communication and provide a sound base for process improvement.

Each phase is therefore associated to: – a standard set of deliverables (technical or management deliverables) – a milestone – the activities aimed at producing the deliverables

The groups
We are covering here the activities starting from the presence of a sale opportunity, through project delivery, and ending with the end of the support activities following the termination of support obligations. The three groups are Win Business, Delivery and Support. Those groups are dictated by common departmental organisation, with a clear distinction between sales and delivery teams, and delivery teams and support teams (though in case of large programs, delivery and support teams can sometimes be nearly merged).

Groups description
This section describes phases for each of the groups, the description is not extremely detailed as it should be but provides a good overview of what each of the phases is about.

Group: WIN BUSINESS

We will simplify the win business phases group to two phases: Analyse and Bid. Note that we are here reducing sales to activities dealing with a addressing a specific opportunity, we are not adressing other type of sales activities should they be internal or external.

The first phase (W1-Analyse) is generally triggered by a request for information that would give the elements to our company to understand in sufficient details what is the opportinity about, this first phase is concluded by a decision to bid or not to bid for this opportunity.

The second phase (W2-Bid) leads from the decision to bid to – hopefully – winning the business. The main outputs are the contractual, technical (requirements, high level design) and project (project plan) documentation.

W1-Analyse
Qualify the opportunity and decide if we should bid or not for this work. Is our product a match for the customer’s needs? Is the customer “strategic”? Is the opportunity in line with the business objectives for the company? Are other initiatives with higher priority ongoing?

If the decision to bid for the work is made then the scope of work for the next phase needs to be produced, essentially: what effort is needed and what skills we need to mobilise to support the bid work.

inputs: – customer’ RFI, RFP or other materials – product documentation – sales objectives

deliverables: – analysis supporting the decision – scope of work for the coming phase, including what resources are needed to undertake the S2 phase

milestones: – decision to bid or not

W2-Bid / Requirements
This is the core of the Win Business phase group, it defines the scope by matching the capabilities of the company’s products or services to the requirement, If the requirements are not defined or not clear then effort should be spent to do so. It defines the project plan: deliverables, schedule, communications plan, risk plan, resources plan. This is where the planning effort is essential.
The design of the solution is a product of this process, it needs to be done in sufficient details to allow the planning of the project and the validation of the technical feasibility of the project.
This is probably the most important phase of the project – even if it has not started yet as the contract is not awarded, any changes to the scope of the project after this phase is very likely to have impact on the contract itself. Key resources to support this process: pre-sales consultants, project manager and solution architect, also inputs from product managers are often required. In important to realise that this Win Business phase is heavilty supported by resources more commonly assigned to the project delivery.

inputs: – customer materials (RFI, RFP), W1 outputs

deliverables: – agreed requirements – solution design, scope of work, scope description – contract – project plan (with at least the first part of the project planned in details)

milestones: – contract award decision

Group: DELIVERY

It follows the Win Business phases group and so kicks off once the contract is awarded. The project plan should already be produced and validated – though maybe not in too much details – this phase is really about delivering the work and updating the plan as we go along.
The processes in this phases group are organised like a traditional waterfall model lifecycle, however it does not have to be this way OR it can be adapted as see fit.
This process group would belong to the Operations side of the business rather than the Sales side, this is important as this would require significant collaboration and communication to ensure smooth transition from one to the other, task often overlooked.

Phases are: – D1-Design – D2-Build – D3-Verify – D4-Validate – D5-Launch

D1-Design
First, there is no Requirements phase here as one would expect. The work to establish the requirements is part of the Win Business phase group instead, in the Bid phase.
Even the design for the solution is itself largely known as it is required to support detailed pricing for the contract.
This phase concentrates in clarifying the elements of the solution design that need to be worked on further, also it finalises the detailed requirements (should it be necessary)
But the key delivery of this phase is the detailed design.
Those technical deliverables are now in the hands of the project team that is build up at the beginning of this phase, prior to that the team involved is the sales team with technical leads and business analyst, the full project team is assigned once the contract is signed. It means that a key role for the project manager in this phase is to build up the team, assign work, ensure knowledge is transferred from the sales team to the delivery team.

deliverables: – revised solution design (high level design) – clarified requirements – detailed design

miltestones: – detailed design agreed

D2 – Build
The completion of the build phase is when all software and hardware are created/built. This can be hardware build, custom development, specific configuration set-up. The key outputs are the physical components for the hardware and software and associated documentation.
Together with the build comes unit testing of each of the components, individually.
In this phase we also build the tests plan and instruction that we will use in the next phase.

deliverables: – hardware and software components – unit tested – hardware and software documentation – unit test instructions and results – factory acceptance tests plan and instructions

miletestones: – unit tests completed

D3-Verify
Internal verification that the build delivers what it should be. The tests in this phase are about making sure the solution as one is working – that’s factory acceptance testing, in the previous phase we did focus more on testing individual components. Here the focus is on the bigger picture. Note that this is not compatible with using a more “agile” and less “waterfall” approach, the gates are not necessary organised in a strict waterfall model, for example here the Verify phase can start even if the Build phase has not completed.
This phase also includes rework activities should the solution be found not to be inline with the requirements.
Upon completion the system is ready for customer validation, which means that the system is ready for shipment.

In this phase we also build the tests plan and instruction that we will use in the next phase.

deliverables: – factory acceptance test results – shipment plan and associated documents – customer acceptance test plan and instructions

miletestones: – shipment

D4-Validate
This phase leads to the acceptance of the solution by the customer, usually called the customer acceptance testing. Could be made up of few different test phases, technical verification, interconnection testing and functional and non-functional acceptance testing.
At the end of this phase the solution is accepted and ready to be “used”.
With this phase the transfer to support should also be initiated and appropriate deliverable created.
Also the migration plan that defines what is next phase about is created.

deliverables: – customer acceptance test results – support book – migration plan

milestones: – accepted solution

D5-Launch
All activities required after the validation phase and before the service is fully launched.
This could be a very swift phase, containing little activities. However it may not be and here are some examples of more complex things to do: – migration of data before service is launched and/or complex activation of service – roll-out of multiple identical platforms on multiple sites (IF this we decide to manage it in this phase and use a single site for the validation)

In any case the main deliverable here is the execution of the migration plan.

deliverables: – go-live report

milestones: – go-live completed

Group: SUPPORT

Support phases are handled by – usually – an other department of the organisation. Their involvement is of extreme importance to ensure the first few weeks after launch are trouble free and when trouble comes that they are managed the way the customer expects them to be managed. Spending time to train the support organisation is then crucial and this is done in the Validate and Launch phases which really means from a support point of view the “Initiate support” phases.

Taking into account that the support has been initiated we only have 2 phase now: – S1- Run – S2- Terminate

S1-Run
This is about fulfilling our support obligations. That phase can be very very very long, could be years!
Activities are focused on: – fixing live issues – applying standard upgrades to the system
That’s about it – I won’t go here into more details of outputs and deliverables.

S2-Terminate
This phase kicks off when support is terminated for whatever reason. It includes all activities necessary to close the maintenance for this solution.

A quick workd on managing end of phases

Each end of phase is a “gate” where associated deliverables are checked for completion and authorisation to go onto the next phase is given by management. End of phases is a time where the management/PMO of the Project Manager should be looking at the project in details. I would even suggest that management really gets involved in the project at the gates stages only UNLESSsignificant deviations from the plan or critical issues are raised during a phase.

At the end of each phases there should be: – a review of the project plan and particularly an update of the next phase plan – a review of the risks and update of the plan to make sure actions are taken for those risks – a review of the project status from a financial, quality and time perspective

Final words

Benefits

A PRD really structures the flow of projects from sales to support. This has a number of direct consequences and benefits that we are summarising here:

- it creates a shared language within the company, so everybody talks about the same thing and communication is greatly eased. – it drives project planning throughout the organisation, as the structure of the plan and key deliverables are dictated by the PRD, this create an environment where standardisation of deliverables is possible which is the basis of process improvements. – it glues together different part of the organisation (sales, operations/project delivery, support) by adopting phases that involves all of them. This is important as the Buyer organisation team is usually more ‘united’ behind the project than the Seller team. – by creating a unique way of planning and thus reporting on the projects it enhanced upper management visibility of the portofolio of projects. – by adopting a common language it facilitates training and coaching of staffs and help build a skilled force.

Impact on the organisation

Implementing a PRD needs top management back-up as it requires, and in this example very much so, different departments to align their processes with an end-to-end process that goes beyond each department responsibility. A PRD requires them the adapt to another way of workingAND also report at each phases to the organisation in a way they did not report before. This could be a significant change.

For example the Win Business second phases rely a lot on resources that normally belongs to the project delivery side of the business (Project management and Solution Architect) – this requires strong alignment between both department to ensure resources are lined-up.

PMO Role

The Program Management Office’s mission in such a context is to create, maintain, communicate the PRD in the organisation: it creates the standard and makes sure it is applied. It also leads the improvement initiative by checking if the standard are met and comparing the standard with the state-of-the-art in the industry.

Another mission is more operational: manage the end of phases reviews, manage the portofolio (if not entirely then maybe only manage its reporting to upper management), possibly manage conflicts in resources and priorities between projects.

Finally I have attached an overview of deliverables and milestones for this example PRD, the end of phase review and the activities per phases.

PRD table