Chapter 13

Organising the Troops: Transition Projects

In This Chapter

Finding out what a service transition project is

Understanding how the transition processes work in practice

Seeing how ITIL fits with transition projects

Working through an example service transition project

In Chapter 7, I introduce the service transition stage. Now, in this chapter, I bring together the concepts of the service transition stage with the ITIL processes that are most relevant at this stage. More often than not the build, test and implement activities of a service are performed as part of a project, or even as a project in its own right. This chapter contains advice on how you use the service transition processes in practice, and shows how the service transition processes work together.

Service transition is part of the service lifecycle that I explain in Chapter 3. Chapters 4 and 11 look at having a strategy for deciding which services your organisation will provide to your customers. The result is using the service portfolio management process (see Chapter 4) to help with your investment appraisal and deciding where to spend your money or this year’s budget. This results in a charter – communicating the decision to develop a new service, retire an existing service, or modify a service. Once a service has been chartered, it starts its journey through the service design (Chapters 5 and 6) and service transition (Chapter 7) stages of the service lifecycle and into service operation (Chapter 8).

Introducing Service Transition Projects

As I explain in Chapter 7, the service transition stage of the service lifecycle is the bit where you take the paper-based design of a service and turn it into a living and breathing service that delivers value (in the form of utility and warranty) to your customers.

The service transition stage includes all the activities required to build, test and implement an IT service into the live, or operational, environment. Now I don’t know how the service transition activities work in your IT organisation. Maybe you have a dedicated team of engineers who do the work every time a new service or major change comes along. Perhaps certain members of staff get seconded to the build and test activities and are told to do them at the same time as their normal work. But, what I’m fairly sure of is that the work is coordinated as some sort of project. To take the design of a service and create the actual hardware and software and any other related bits and bobs requires coordination, and that coordination normally comes from using a project management methodology. Therefore, in this chapter I talk about service transition projects. (You can find a bit more information about using projects to coordinate activities in Chapter 12. In this chapter I assume you use a similar approach to projects as the one I describe in Chapter 12.)

Now, I don’t believe that the service transition activities are the only bit of an IT service development that is done as a project. In Chapter 12, I describe service design projects and outline how you need a project structure in which to control the requirements and design activities that form part of the service design stage. Often a project is set up for all of the service development activities from the inception up until the service is handed over to the IT operations staff and the business signs off the project.

In some cases there is one single project; in other cases there are many projects, one for each stage in the lifecycle. Whichever is the case in your organisation, there is one important point to note: there must be some form of approval to allow your project to move from the design stage to the service transition stage.

There are many ways in which that approval can be given:

The project management methodology ensures that senior management give their authority.

The service portfolio management process (see Chapter 4) ensures that authority is sought

The change management process (see Chapter 7) gains approval from the change authority.

In some cases all three methods are used and are coordinated. What must be true is that a service design package (SDP) is created as the last activity of the service design stage or project. The SDP contains all the aspects of the requirements and design for a service and, once approval is given, the SDP forms the main input to the service transition stage. If you want to know more about an SDP, have a look in Chapters 5 and 12.

Seeing What Happens in a Service Transition Project

As I explain in Chapter 7, the key activities of service transition are build, test, and implement or deploy. The following sections look at how you carry out each step as part of a project.

Getting started

You need to have a trigger or instruction to get your service transition project started. After someone has fired the starting gun then you can get started.

One important decision to be made is whether you make or buy. In other words, is your organisation going to build, test and implement the service or are you going to get another organisation to do some or all of the work for you? This decision may well have been made during the service design stage, but having a clear understanding of that decision is key to knowing who does what.

The SDP includes the service acceptance criteria (SAC). Just as it sounds, the SAC tell you what the service must do in order for the business to accept the service once it has been deployed into the live environment. Well, you must start with the end in mind. The SAC along with the business requirements are the starting point for the design of the service. Similarly, once you start to build and test the service, you must ensure that nothing happens that may affect the ability of the service to meet these requirements. Therefore the SAC represent the starting point when it comes to planning your testing.

Building services

You build whatever has been designed. Building the service involves building each of the component parts. Once the component parts have been built, they have to be assembled as a complete service. Therefore there may be several phases of building going on.

Building the solution can include building some or all the following:

Software applications: The front-end bits that provide the functionality of the service to the user. These are designed by one or many software developers. Building an application is carried out by software programmers, who write and create the software code required to make up the application. In theory the programmers code whatever they are told to by the designers. Of course this all depends on how organised you are. In smaller organisations the design and development of software are not always separate phases of a project and are often done all at once. In other organisations, especially those that provide our well-known software applications, there will be hundreds of programmers working on a new release at any one time.

There are many methodologies for software development which include both the design and building of software applications. I describe these briefly in Chapter 12.

Infrastructure: The IT hardware and networks, and any system software such as operating systems. Infrastructure may include servers, networks, storage, databases, operating systems, messaging protocols and software agents. So, clearly, ‘building’ here is getting physical: this is where you get your screwdriver out. The equipment must be purchased, delivered and assembled in accordance with the plans and designs created in the design stage. Detailed plans may be needed to ensure that the equipment is built in the right way.

Data: ‘Building’ here refers to the building of the database systems. This may include the gathering or migration of the data that will be held in the database.

Support: The operational requirements such as how the service will be delivered and supported on a day-to-day basis. Support will include the skills, process and resources required to ensure that the service is operating correctly and can be recovered in the event of a failure. ‘Building’ here refers to the creation or modification of any processes and procedures that are required to support the service. The new service may require new skills. In this case, staff will be recruited, and this must be timed carefully to ensure that the skills are available when the service goes live.

Physical environment: The data centres, computer rooms and so on, including the air-conditioning systems and the power supplies. The new or changed service that is part of your service transition project may require additions or changes to the computer rooms or data centres. Inevitably, new equipment has to go somewhere. Additional servers and network equipment may be slotted into existing racks. Of course, all this must be done without disturbing existing equipment or disrupting current services. The additional equipment may mean additional air-conditioning or changes to the power supplies.

So who does all this work? Well, the software applications are written by programmers. The physical infrastructure can be built by almost anyone. Many IT organisations have build departments that look like a mad professor’s laboratory: cables sticking out of every drawer, CDs scattered on desks, and piles of computer equipment covering every remaining bit of floor space.

The important point is to make sure that your build activities are coordinated and controlled. This is where the ITIL change management and release and deployment management processes help – skip to the later section ‘Bringing Together ITIL and Service Transition Projects’ to see how.

Testing the service

Testing is a discipline in itself, one in which you can attend training courses and get qualified. But what is testing all about? What does testing mean? Testing what?

Put very simply, testing ensures that the thing being tested will do what it is intended to do. Testing a washing machine ensures that you can use it to wash your clothes. Test driving a car ensures that it meets your requirements. Testing the temperature of a shower ensures that you don’t hurt yourself when you jump in. So testing an IT service ensures that it can be used to help the business do what the business wants to do, and that it performs the way the business expects, or rather performs in the way that has been agreed. In other words, testing an IT service ensures that it is fit for purpose (utility) and fit for use (warranty). I explain utility and warranty in Chapter 2.

Testing for utility and warranty

Here’s how you test for utility and warranty:

Testing the utility of the service: You ensure that the business can use the service to perform its business activities. For example, can it really use the service to record sales orders? Can the factory plan the manufacturing schedule? Can you send emails to those you want to? The functionality is usually provided by the software application. A lot of the training and qualifications that you can gain in testing are related to software testing. When it comes to testing application software, there are two main approaches:

• Ensure that the application performs the functions it is intended to perform.

• Ensure that the application is free from bugs – that there are no errors that will stop the application in its tracks.

Many companies have specialist test departments whose job it is to test software as it is created to ensure that it conforms to its specification.

Testing the warranty of the service: You ensure that the agreed levels of availability, capacity (and performance), security and continuity can be achieved. This cannot be achieved by testing the application alone, but by testing the entire service once it is built. Chapter 6 covers the warranty processes.

Types of testing

Testing includes the testing of the individual components and the complete service, not just testing the software application. There are many types of testing. Here are a few:

Component testing: The testing of individual components or parts of a service – maybe a module of software, a server or a network router. Each part of the service should be tested individually before it is assembled into the service.

System testing: Taking many parts (such as software modules), building them into a system and then testing the assembly.

Service testing: Checking the entire service after it is built and assembled. This is often the only way to test the agreed service levels such as availability, capacity and performance of the service.

If the agreed transaction response time is two seconds (in other words, from the moment you press the return button on your PC, something must appear on your screen in less than two seconds) then the only way to test this is with the entire service working in the way it’s intended to in a replica of the live environment, but without using the live environment.

Operational readiness testing: You ensure that the operations staff can deliver and support the service. This can include service management tests, such as testing whether the service desk staff are ready and prepared for dealing with any incidents related to the new service.

Service acceptance testing: Many of the tests I described here will be done in the privacy of the IT department to ensure that you have done you job properly before putting your head above the parapet. But eventually you have to talk to the customers and users to check that the service does what they expect it to, and in the way they expect. In an ideal world this should be easy. If you have agreed the requirements correctly, designed the service to meet the requirements, built what you designed and tested it to be sure that it works, then everything will be fine . . . won’t it? Service acceptance testing is often the last hurdle before you decide to go ahead and implement the service into the live environment.

Planning the tests

Testing shouldn’t be random. I’ve known occasions when a software application has been more or less thrown at an IT colleague with the words ‘Here – see if you can break this.’ All tests must have a purpose. So every request for a test must be accompanied by a plan describing the purpose of the test and the conditions that are to be tested.

The SAC (see the earlier section ‘Getting started’) are the starting point for testing. They ensure that you focus on making sure that the customer gets the service that it needs.

Don’t test things in the live environment – that is, using the same systems that the users are using to their job. Instead, create a duplicate system (a test environment). It is not always possible exactly to replicate the live environment, so you must decide how near is near enough.

Implementing the service

Once the service has been built and tested (see the previous sections), there is only one thing left to do: make it available for use. In other words, implement the new or changed service into the live environment. Implementation is an all-encompassing word. To implement the service may mean as little as switching it on, or it may refer to delivering and installing equipment and software across your organisation.

Implementation is often referred to as deployment. Is there a difference between implementation and deployment? Well, I think that implementation is a broader expression that refers to the bigger piece of work, especially if you’re preparing to implement a major change or a new service. It can sometimes refer to the build and test activities as well as the actual implementation into the live environment. Deployment refers to the individual activity of taking a piece of equipment or service and deploying it in its intended location. Deployment also refers to adding additional ones, once the implementation project is complete.

Implementation, or deployment, can involve three stages:

Distribution: In the case of hardware, this may involve a white-van man transporting the equipment to each of your sites. In the case of software, automated systems are often used to distribute software automatically over your network, in the same way that your favourite software manufacturer gets you to download updates to the applications you have on your PC at home.

Installation: Once the hardware and software have been distributed, they have to be installed. In the case of hardware this usually involves a technical engineer popping a new PC on a user’s desk and getting it working. Software, too, can be installed by an engineer. However, the installation is often done using the same automated tools that distributed the software. The tools can automatically perform the software installation and, if necessary, prompt the user to press a few buttons at the right time.

Activation: Sometimes hardware and software are installed, but the users are told not to touch it until the official launch date. In some cases users may not even be aware that a new version of an application has been installed on their PCs. When the launch day arrives an automated message is sent to the PC to tell it to put an icon on the desktop or a new entry in a menu – and the service is now live.

Implementation requires careful planning and can potentially involve a lot of logistics – that is, getting the right equipment and the right people in the right place at the right time.

Bringing Together ITIL and Service Transition Projects

The previous section gives you an overview of the activities that form part of a service transition project. Now I describe how the ITIL service transition processes can provide control and structure to your service transition project. There are seven processes described in the ITIL service transition book, and you find descriptions of five of these processes in Chapter 7 of this book. The processes can work together to ensure that when you introduce new services or major changes to your business, you do so with the minimum of fuss and disruption, and you end up with happy customers and users.

There are two service transition processes that I don’t describe in Chapter 7, so I will describe them here.

Service validation and testing

The purpose of the service validation and testing process is to ensure that a new or changed IT service matches its design specification and will meet the needs of the business.

Testing can be triggered from both change management and release and deployment management, and provides factual evidence that the correct assets are in place, and that they are configured correctly such that the service will provide the agreed value to the customer in terms of utility and warranty. In short, you must prove that the service is fit for purpose and fit for use. (You can find out more about utility and warranty in Chapter 2.)

Testing is unlikely to consist of a single test. Even though the change may be to a single component, it’s still necessary to confirm that the entire service will continue to perform as required once the change has been made. Tests must be performed in a coordinated manner from the bottom up.

Figure 13-1 shows an example of a V-model and is taken from the ITIL service transition book. The V-model is a well-known model that comes from a software development background. This version has been adapted to show how changes to components, and hence services, should be tested at various levels.

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

One of the main considerations of service validation and testing is to perform an appropriate set of tests at the appropriate level of detail. Testing should not be limited to testing the software application. While testing the software application is clearly important, once the application is tested you should test it as part of the service. In some cases this is referred to as system testing or integration testing. ITIL suggests several levels and types of testing to ensure that the entire service provides both the utility and warranty agreed with the customer. Some examples of tests are as follows:

Component tests

Service test

Service management tests

Operational readiness tests

The V-model also helps us to understand that testing starts right at the top with the business requirements, as shown at the top left in Figure 13-1. For every business requirement there should be SAC. It is the SAC that will be used in the design and transition lifecycle stages to establish the appropriate test plans and criteria.

The V-model can also be used to indicate that each level on the left-hand side of the diagram involves validation. The layers on the left-hand side reflect the activities of service strategy and service design that establish the requirements and design of the new or changed service. When each document is created it should be validated against the documents created at the previous level. For example, when the service design is complete, the design should be compared with the service requirements specification to ensure that all requirements have been included in the design.

Change evaluation

The purpose of the change evaluation process is to provide a consistent and standardised means of determining the performance of a service change in the context of likely impacts on business outcomes and on existing and proposed services and IT infrastructure. The actual performance of a change is assessed against its predicted performance. Risks and issues related to the change are identified and managed.

Every change should be evaluated, but not every change will follow the formal change evaluation process. The change evaluation process should be used for more significant changes. You must decide which types of change will use the process.

Change evaluation is different from service validation and testing. Whereas the latter ensures that the new or changed service meets its specification, change evaluation is comparing an actual outcome with the intended outcome and reporting on any deviations to change management. Change evaluation also ensures that risks have been managed and helps to determine whether to proceed with a proposed change.

Change evaluation is performed at many points during the change, release and deployment cycle. Here are three possible points at which you may perform a change evaluation:

At the assess and evaluation step in the change management process. Prior to authorising the change, the change manager may send a request to the change evaluation process to trigger the evaluation of the design of the new or changed service to review the intended effects of the change.

Just prior to the deployment of the change or release, a second evaluation will be performed. Now the results of testing can be used to represent the actual performance of the service after the change, such that the predicted and actual performance can be compared.

When the deployment or transition is complete and early life support is coming to its end, a final evaluation will be carried out.

In some organisations, changes and releases may have been deployed using good change management and release and deployment management processes. The implementation is completed successfully and service levels are met. However, users or customers may not be satisfied. This is sometimes mystifying. In these cases, performing change evaluation may identify the unpredicted effects that influenced user satisfaction, or, in this case, dissatisfaction.

Linking the service transition processes

Figure 13-2 shows most of the service transition processes and how they link together. Hopefully, you can see from the picture that there is a logical flow of requests for change (RFCs) coming into the change management process and travelling from the left to the right of the picture. (I’ve not shown the service asset and configuration management (SACM) process in this figure simply because it’s difficult to show in a picture, but the SACM process is present throughout the service transition project.)

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

Change management is the controlling process that provides authority for all other work to start. It also makes sure that each change is a good use of your organisation’s time and money. There are likely to be many RFCs involved in transitioning a new or changed service. Inevitably, there will be the RFC that is authorised for the overall change or new service. This provides the trigger for the service transition project. There will also be an SDP associated with the RFC and the project. Once the project is authorised, the transition planning and support process will take the RFC and the SDP and plan the project. The SDP will include overall details of the resources required to build, test and deploy the new service or major change, and the transition planning and support process will take this information and put flesh on the bones. The transition planning and support process can start to allocate resources to the different parts of the project. It also raises more RFCs to control the build, test and implementation of parts, or components, of the new service or major change.

As the RFCs are raised, the change management process assesses and evaluates each change. It also decides which changes should be grouped into releases. The release and deployment management process is involved in helping to make this decision. The build, test and deployment activities are ultimately controlled from change management, but where releases are used, the release and deployment management process will take delegated control of the build, test and deployment of the release.

It is normal that the coordination of build and test of some components or parts of the service will be done by the change management process. Sometimes those components that will, later, form part of a release may be built and tested as separate units under the coordination of change management. In the case where a release is used, all the parts that have been built and tested separately are now assembled as a release, and the release can now be built, tested and prepared for deployment. So testing is triggered from both change management and release and deployment management. Once all the build and test is complete, the release and deployment process prepares and deploys the release.

As each ITIL process becomes involved in the transition project, it triggers its own sequence of activities.

ITIL and build, test and implement

You can find details of the basic process flows for each of the service transition processes in Chapter 7. In the following sections I provide a little more detail about their involvement in a service transition project.

Transition planning and support

The transition planning and support process provides coordination to the whole service transition project. It’s a bit like a project or a programme office – a team or individual who hands out the work instructions and tells you which bit of work to do next. Such people don’t necessarily have authority, but they coordinate work that has been authorised.

Transition planning and support also ensures that the agreed policies, strategies, standards, process and procedure are used. For example, it may have been agreed that all deployments of your sales office IT service are always implemented using the big bang approach (deploying everything all at once; see Chapter 7), and this decision is documented as a policy. It is the role of the transition planning and support process to recognise when the policy is appropriate and gather together all the documentation appropriate to the big bang deployment.

The transition planning and support process often identifies and raises the necessary RFCs for the project.

Change management

This is the controlling process: everything stops and starts here. Control is a great thing. It is sometimes perceived as bureaucracy, but when you consider the number of activities that must happen in order to built, test and implement the parts of an entire service, an awful lot can go wrong. So change management provides the authority to perform the activities.

Change management also works with release and deployment management (see the later section on this process) to decide which changes to group into releases.

For each RFC, the change management process ensures that each change is assessed, evaluated and authorised before building of the change commences. Authority is often sought from change management a second time for each change after the build and test is complete and prior to deployment.

Service asset and configuration management

Service asset and configuration management (SACM) is the provider of the information about the services and their component parts. It is critical that the impact of any change is understood, and the configuration management system (CMS) that is maintained by SACM will provide this information.

Baselines are often used to simplify your IT infrastructure. A baseline shows the intended build of a component or service. A good example of a baseline is the standard build of a desktop PC: every PC that leaves the IT department is built in exactly the same way. Baselines will be unique and recorded as configuration items (CIs) in the CMS. Baselines are often used to automate the build of some components and assemblies. For example, using the same example as earlier, the standard build of a PC can be configured using an ‘imaging’ tool that allows the configuration of the PC to be copied easily to create many PCs with the identical build.

Release and deployment management

Release and deployment activities are triggered by authority from change management (see the earlier section on this process). Release and deployment management looks at the release policy and release units to help decide how to group changes into releases and which type of release is appropriate, and discusses this with change management.

When the release is part of a new service or major change, the release and deployment management process creates further RFCs in order to get authorisation from change management to deploy the release.

Release and deployment management is responsible for any pilots that are required. A pilot is a deployment of a service in advance of the formal deployment. A pilot tests:

The software on real business transactions

The deployment activities and mechanisms

Choose a site for the pilot where representative business activities are performed and representative technology is used.

Service validation and testing

Testing will be triggered from both change management and release and deployment management (see the earlier sections on these processes). The service validation and testing process ensures that all agreed tests are performed.

The outline of the testing should be designed at the same time as the service, as part of the service design. Testing will be driven by the SAC. The SAC will be included in the SDP. During the design of the service, a top-down approach is taken ensuring that the business requirements are clearly understood. Then service requirements are created from the business requirements: the service is broken down into parts until the requirements of each service component are established. Each component and the service are then designed to meet these requirements. As each service is built, a bottom-up approach is taken. First the components are built and each component is tested. Then systems are created from the components and the system tested. When the whole service is assembled, it will be tested again. These service tests must prove that the SAC can be met. Go to Chapters 5, 6 and 12 for more discussion on design.

Create test plans to ensure that the right tests are performed at the right time by the right people.

Change evaluation

Change evaluation is triggered from the change management process and aims to provide an independent view of what’s going on so that change management can alert the customer to any unexpected effects of the change. In some cases, if an evaluation report shows that the change in performance of a service after the change has been made is unacceptable, the change manager may reject the change.

Finishing off the projects: business acceptance and sign-off

In the good old bad old days it was considered acceptable for the IT department to throw new systems ‘over the wall’ into live use and pop off down the pub to have the end-of-project party. Fortunately, this is no longer the case. Here are some important activities that must be performed at the end of a service transition project:

Early-life support/handover to service operation

Early-life support (ELS) is part of the release and deployment management process, but can be viewed as a mini process in its own right. It involves the activities required for service transition staff to work alongside service operation staff during the first few weeks of live operation of the service. The purpose is to make sure that service operation staff know what is considered to be normal in terms of how the service works. Also they should know what to do when something abnormal happens.

There should be criteria agreed for when ELS starts and when it finishes. ELS will end when service levels are achieved consistently and the users can use the service as intended. Hopefully, when the ELS period is over, the business will be in a position to sign off the service.

Business sign-off

The final acceptance of the new or changed service must be done by the business. The IT department must demonstrate that the SAC have been met, and that the service not only supports the business outcomes but can be delivered and supported in a way that meets the service level targets.

This is a good time to make the business aware of any unexpected variations in performance and agree any actions that should be taken to resolve them, if necessary. SLAs can be finalised and signed off, if this is not already done.

Looking at an Example of a Service Transition Project

Dummy Co. is a manufacturing organisation that sells its own products through its sales departments. Dummy Co. has implemented ITIL and allocated many of the service management roles to members of the technical teams.

The IT department is in the middle of a project to implement a new customer relationship management (CRM) IT service into the sales departments across four sites. The new CRM service has been chartered using the service portfolio management process (which I explain in Chapter 4). A service design project is complete and an SDP produced. The SDP has been reviewed along with an updated business case, and senior management have approved the project to go ahead into the service transition stage.

The new service consists of the following components and systems:

Software application to be installed on the sales staff’s PCs

New server equipment to be installed in the data centres

New database to be installed on the servers

Take a look at Figure 13-3, which shows an overview of the activities that take place in Dummy Co. in order to transition the service. The figure is incomplete (I can only fit so much on a page of this book), but you get the picture. (Do remember this is an example, and you need to make your own process flow for your organisation.) I’ve shown in italics any ITIL roles that have been assigned to people in Dummy Co.

Now I look at some of the steps of the process in more detail.

The SDP along with senior management approval has gone to Eric. Eric is the administration manager in the IT service team and has been allocated the role of transition planning and support manager. Now Eric has the SDP he can start planning the transition project. This includes allocating the resources and ensuring they are available. So, in this case, he needs to be sure that resources are available for building and testing the software application, building and testing the database system, and building and testing the server equipment. These resources come from the technical engineer teams and the application developers. The other thing that Eric does is to raise lots of RFCs for all the individual components.

The RFCs go to Jenny, the change manager. Jenny follows her change management process. She must ensure that each change is assessed, evaluated and authorised. To do this, she involves the appropriate people from the technical teams and the business.

Jenny also chats to Stan, who has the role of release and deployment manager. They decide how the individual changes will be grouped into releases. In fact, they have decided to include some other changes in the release packages, because this will make best use of resources and minimise the impact on the sales teams. The Table 13-1 shows you the decisions that Jenny and Stan come to. They also decided that although release 1 and release 2 are individual releases, they can be deployed at the same time, therefore these two releases will be grouped into a single release package.

Table 13-1 Dummy Co. Agreed Changes

Release Number	Changes	Description
Release 1	RFC1	New CRM software application
Release 2	RFC2	Anti-virus client upgrade
	RFC3	Updates to desktop build baseline
Release 3	RFC6	CRM server hardware
	RFC7	CRM server software
	RFC8	CRM database installation

Once the changes are authorised, the work can start. Jenny and Eric will work together to raise works orders and allocate them to the application development and technical staff.

The build and test of individual components will be done first. This will be done by the usual suspects: the software application programming will be done by Dummy Co.’s application developers, and the building of the servers and databases will be done by Dummy Co.’s technical engineers. Once these are complete, the release building and testing can start. The build and test of the release will include the build and test of the deployment mechanisms. So, in this case, the software application will be distributed using an automatic software distribution tool that uses the network to send the software release package to each PC. So this tool is tested as well.

Jenny and Stan also decide on the type of deployment to be used – a big bang or a phased approach. In this case they decide on a phased approach. In fact they choose as a pilot site the local sales department, which is in the same building as the IT department, and do this one first. This allows the IT department to check that the deployment mechanisms work as planned and that the sales team is happy with the new IT service. The remaining three sales offices will be deployed at one-week intervals.

I’ve now talked through all the activities that are shown on Figure 13-3, but this isn’t the end of the story. Once the service is deployed, the early-life support process must kick in. Members of the technical and application teams will be put on standby to deal with issues as they arrive within the first few weeks after deployment.

Finally, Jenny must liaise with the sales director to ensure that the aims of implementing the new CRM system have been achieved. Hopefully this is the case and the sales director will sign off the project as a success. Yippee!