11 ARRIVING AT THE DESTINATION – EXECUTING THE PLAN

To recap on the last chapter, you have developed a sturdy training programme that covers all possibilities for learning styles, you have set up a communications plan to keep all the staff in the organisation informed across the parts of the project that affect them and you have established a direct link to a senior executive or board member who will act as sponsor or spokesperson and will shout the team pizzas at critical fatigue points in the project. You have developed some artefacts to help guide you, you have reviewed your organisational structure to identify members for your development and operational teams and you have started a high-level risk register.

This chapter will cover the execution of your plan to deploy the systems, processes, policies, procedures, restructures, solutions and so on that together make up your working IT governance framework. The first half of the chapter will take you through a final set of checklists to make sure that you are ready, with everything in place. The second half of the chapter will take you through the execution of the plan.

PREPARING TO ROLL OUT THE GOVERNANCE FRAMEWORK

On the technical side, you have a set of organisational principles approved and signed off by the board. Using these key principles and working with the senior business managers and senior IT managers, you have developed a charter that sets out the principles and expectations for IT services. From the charter, you have developed a set of IT policies with the senior IT staff to ensure that the organisational principles will be met and adhered to. Through various workshops with operational staff, you have developed a set of procedures for everyday activities. So, for example, associated with the principle of responsibility you have a policy for hiring IT staff, and procedures and forms for carrying out the hiring process in an effective and efficient way. You will also need an organisational policy that assigns IT-related responsibilities to business managers that will most likely result in requirements for monitoring and reporting of IT systems.

In New Zealand we have a Public Records Act (PRA), which

The PRA has policy implications for business managers and IT managers around storing, deleting, maintaining, archiving and restoring information held in electronic format. It also poses some interesting questions around long-term electronic data storage, which are outside the scope of this book. For further reading, track the progress of any local group that have an archive function and see how they are handling media types.

Process checklists

Policy, process and procedure should go hand-in-hand to create an internal compliance framework that ensures everything that happens within your organisation is in line with board requirements for efficiency, effectiveness and legislative compliance. Not all your staff members will be process-minded. In fact, some of them will be so hazy on policy and process, or so easily distracted or forgetful, that you will be left wondering how they manage to catch a train to work in the morning. Others (your anarchists and your test team) will be intent on breaking process where they can – just to see what happens. Your staff will be greatly assisted by process checklists that help them through a process, and some of them will need the discipline of a process that cannot be completed until earlier stages are approved. The completed checklist that says that the process has been completed at the correct time and in the correct order will bring great peace of mind.

There are several ways of delivering process checklists – ranging from workflow mechanisms to wizards, where wizards are a way of delivering automated workflows. Workflow is great until the person who approves a step of the process is away on leave and work backs up like a traffic jam until that person returns to work. Wizards are good if you have very specific processes that are order-dependent. Be very clear on mandatory versus optional requirements in each process, and enforce the completion of the mandatory checklist in such a way that you have a clear audit record of what happened and when.

SUPPORTING SYSTEMS

The key supporting systems to enable you to implement a governance framework are as follows:

• a change management system where changes can be logged (with specific instructions for roll-back should the change fail), changes can be reviewed by peers, authorised by the relevant manager and scheduled by the organisational change controller;
• an incident management system for logging issues for resolution by the support team;
• online service management tools – a stand-alone tool or a tool that integrates into your key enterprise application;
• system monitoring tools to pick up failing elements of the overall framework before business is affected;
• testing tools, such as online tracking systems that allow issues that arise during testing to be prioritised and assigned to members of the team for review;
• training tools such as online documentation with survey questions to test comprehension, or framework simulators to show how the new framework delivers business processes;
• communication tools for developing and circulating attention-grabbing communication updates;
• a document management system for keeping track of document versions, as key organisational documents are developed.

Before you proceed any further, please check that you have all of the above supporting systems in place in a form that is appropriate for your organisational size and culture.

MANAGING PROJECT VERSUS OPERATIONAL WORKLOAD

It is always a challenge to manage the project and operational workload in parallel. There will be times when you will need to invest in your current systems, even though you know that they are about to be replaced. It is annoying but unavoidable. In a small organisation it might be exactly the same set of staff who are working on the project to deliver new systems and services and running the operational environment. Here are a few things you can do to assist the team:

• Set reasonable delivery dates. Do not set a date that is so far out that the team loses interest, and do not set the date so soon that the team is overwhelmed.
• Backfill your key resources where available. Traditionally, when the IT group runs out of resource they contract in staff to work on the project delivery. I would advise you to release your internal staff to work on the project as long as they are capable and interested, and use your contract staff to keep your existing systems running. That way your internal staff get up to speed on the project deliverables and do not feel left out or overlooked.
• If you cannot backfill your key resources, look at getting competent contractors to take on specific pieces of the delivery work. For this to work well, your key resource needs to be on the same wavelength as the contractor. Ensure that your key staff member is part of the interview process, however busy they are.
• Be on hand to help deal with bottlenecks as they arise, before the team get too distressed.
• Assign tasks based on capability, accessibility and stress levels – not solely on your needs to get a task completed.
• Listen to your team, and be on the constant look-out for signs of tiredness or exhaustion towards the end of a project.

TRAINING AND TESTING

Unfortunately for many of the failed IT projects I get to review, training and testing were considered very late on in the development cycle. There will be a number of elements of the testing and training programmes that will not be able to be finalised until just before go-live, but generally the sooner the basic programmes can be put together and reviewed, the better.

If you can complete the test strategy early on in your implementation cycle, it will possibly highlight areas where the solution design might not be fit for purpose. The test plan should be written once the strategy is in place – it will cover the management and operational side of testing – who does what, where and how. Closer to the time of deployment you will be able to write final test scripts.

The most successful way to carry out testing is to assign subject matter expert owners to each module or part of the system or solution that you are rolling out. Whether you are using spreadsheets or sophisticated testing tools, your test owners will need clear unambiguous scripts with clear expected outcomes, space to describe what happened for each test and space to mark each test as a pass, fail or part-pass. Test scripts should be written in such a clear, unambiguous and foolproof way that you really should not need people from your own organisation to carry out the testing. If you run out of capacity with your own staff, consider hiring students to come in and run through the scripts. You will need to brief your testers very clearly and set expectations as to how the testing sheets should be marked up. I have witnessed some lazy and some well-intentioned testers sending very confusing messages back to the project team by skipping tests or ignoring tests that failed.

Once testers have run through the scripts, the test owners will be responsible for discussing failed or part-passed tests with the project team. In some cases a simple work-around will be possible, but often further coding or modification will be required. The key thing here is to start the first round of testing with plenty of time to allow for further coding, unit and integration testing, as required. It is not just test failures that will need retesting – you will need to retest for every last minute system change. You might well end up rerunning all tests many times.

At some point you might have to make a call as to whether you go live with your framework supporting systems with known bugs and temporary workarounds, or whether you delay the implementation of your programme. The decision you make here will depend on the nature of your organisation and business, and the risk of going live late balanced against the risk of going live with known errors.

As for training, different people learn in different ways. If you have the time to put together a training programme that caters to diverse learning styles, it is more likely to be successful than a programme that pushes out one set and style of material to all. If you opt for classroom-style training, do everything you can to make sure that the staff who attend can remain focused throughout the session by removing unnecessary distractions. For example, make sure that everybody attending training is able to turn off their mobile phones and other electronic devices. Find out beforehand if any staff think they will need to remain in contact with the outside world throughout the training, and put in place a mechanism for collecting calls on their behalf, or backfill them if they have vital operational roles. If you are going with a train-the-trainer approach, make sure that your trainers have a very clear and thorough knowledge of the training material before you let them loose on their colleagues.

And finally, remember to time your training carefully. Remember that organisations that train their staff before the big summer break, expecting them to be ready to run with new systems on their return, generally end up rerunning training at the end of the break. Avoid clashes with particularly busy times. If you are deploying your new IT governance framework at the beginning of a new financial year, be sure not to organise training just as your staff are closing off the previous financial year.

If you are planning to train your staff online or using a series of video clips, make sure that your staff can all open the clips and navigate to the online materials. Similarly, if all your system help documentation is available once you have logged into the system, somewhere you need some training material that shows you how to log on.

Before you proceed beyond this stage, check that your testing and training programmes have completed successfully.

PUSHING THE BUTTON

With the framework development in place with associated charter, policies, procedures and other artefacts, supporting infrastructure, systems and services ready to deploy, training and testing complete, documentation and supporting maintenance systems in place, communications to all stakeholders completed, it is time to go live.

It is unlikely that everything will be 100 per cent ready for your published go-live date, but often it is better to go live on the planned date with some minor issues than to delay the roll-out – especially if your external stakeholders are intending to change their processes and practices as you go live. The second half of this chapter covers the roll-out, starting with the most important task – communicating through deployment.

Deploying the governance framework

However well you plan, however many staff you have assisting with the roll-out, however carefully you choose the roll-out date to coincide with your quietest time, there will always be some glitches. You will not be measured on whether you have glitches or not, you will be measured on how you deal with them. As long as you are prepared for problems and you are quick to respond and you keep your users and stakeholders up to date with progress to rectify matters, your users will be patient.

On deployment day, make sure you have plenty of subject matter experts and project champions on hand, walking the floor, ready to assist any staff with difficulties. Choose your project champions from your internal and your external project team and then you will be better set up to handle any questions that arise, or to fix any errors.

If you have staff located at other offices, then check log-in statistics to make sure that they are all connecting in with the new systems and other framework elements. Also, have a manned service desk set up for the first few days to answer questions, reset passwords and generally assist staff with finding information and using new processes and procedures. If you capture the details of all the calls that come in, you can build a set of FAQs to go up on your intranet once the temporary service desk has closed. There will always be staff members away on holiday or off sick who will need some assistance catching up when they return to work. The published FAQs will be very useful for them to get up to speed with the new systems and feed into staff induction materials.

Pitfalls and problems

To avoid disappointment, prepare for everything that can go wrong to go wrong. Of course, you will have roll-back procedures in place for anything that is deployed and found to be not working, but you need to be sure that everybody on the team is crystal clear about when and how these roll-back procedures will be invoked. You would be surprised to see how reluctant technical people are to roll back solutions – especially if the solution is working in some areas and they think they can fix the problem areas.

If your implementation involves a data migration step, allow enough time to carry out the migration at least twice. Remember, you would not be moving your data unless you had some sort of problem with your old system, so expecting it to perform flawlessly on your go-live day might be over-optimistic.

If your implementation relies on staff signing on to a new system with different user names and passwords, or if the new system looks different from the system it is replacing, have a service desk person on hand to answer access problems and to reset passwords.

If your implementation relies on new process and policy, make sure you have the quick reference guide on hand for all staff, and if the new processes are radically different, consider video ‘YouTube’ clips to get your staff through the first week.

Eventualities outside of the IT environment that you might want to consider are storms and weather events that might prevent your staff getting to work, or might put an abnormally heavy load on your customer services, and major events that are happening in your home town that might affect traffic – physical and electronic. Of course, if you prepare for all eventualities and everything runs smoothly, you would think that the implementation team would be delighted, but if you have prepared them to be ready for anything and nothing happens, they might just be a bit disappointed and feel deflated.

Project management and sign-off – handing over to regular management

Once everything is deployed and your full IT governance framework has been implemented, you will want to do an audit to ensure that everything is running according to plan. You will want the project team to be on hand to answer questions for the first week, but soon it will be time to formally hand over to the teams who will be taking ownership of different parts of the framework. These would typically be as shown in Table 11.1.

Table 11.1 IT governance framework – assigning ownership

Handover is best carried out with the deployment team and the ownership team working together over the deployment period to ensure that the owners know exactly what is being delivered and how it should be kept up to date and maintained. Support processes are very different from development processes, so the handover has to allow for this for handover to be completed successfully.

Note that just because some of your operational staff have been part of the project team does not mean that they are trained and qualified to become the new owners – choose wisely. Successful project people are unlikely to make good owners because they will have a different mindset – the project mentality drives changing the system, the operational mentality drives keeping the system stable.