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
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).
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.
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
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
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
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
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
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
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
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
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
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.
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
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.
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.