9 BEFORE YOU START ON IMPLEMENTATION

Before starting on the implementation of an IT governance framework within an organisation it is important to:

• understand what benefits are expected to be realised through the delivery of the framework;
• take a baseline of current activity;
• determine how well current activities are serving the needs of the organisation.

BENEFITS REALISATION

Too often, implementation programmes proceed without first determining expected benefits or setting reasonable goals and milestones for deliverables or establishing a suitable set of metrics. All of these are vital steps. Benefits realisation is one of the most commonly missed areas. There is an assumption that everyone must know what the benefits are, otherwise we would not be doing the implementation. However, the assumption that everyone knows the benefits and that everyone agrees on a common set of benefits is wildly optimistic. It is worth having the discussion around benefits realisation as early as possible in the implementation programme lifecycle. Discussion will open up a number of different sets of answers and you might discover that the plan is either irrelevant or unnecessary. IT-related programmes can proceed on the wobbliest of reasons, where the sign-off is completed by somebody who has no knowledge of IT or who has not been briefed on the alternate options available. Let us suppose I lose my car keys – one of the options is to go and buy a new car. This sounds very ridiculous, but I have witnessed the IT equivalent of this.

The benefits realisation statement for the implementation of an IT governance framework should set out a list of tangible and intangible benefits – and if you cannot think of any benefits, then you should not proceed. Benefits should be about increasing revenue, increasing customer service or reducing costs. The benefit of meeting legislative requirements through the programme would most likely fall under the category of avoiding costs. Setting reasonable goals and milestones will help the business understand the progress and will keep the implementation team focused on deliverables. It is very easy for the team to get distracted and move away from the original agreed deliverables as the business sees the initial outcomes and wants to try for something different. Agile project management encourages an early prototype system, but, often, when business representatives see the prototype they think of additional or different requirements that would make the final solution more useful. This is not a bad thing, as long as the original implementation documents are updated to show the agreed change in scope. The third vital component is good metrics. If you cannot measure your success, how will you know if you have been successful?

One useful tool that you might consider to assist with the development of a benefits realisation statement is the investment logic mapping (ILM) technique developed in 2003 by the State Government of Victoria, Department of Treasury and Finance (DTF) in Australia. The aim of ILM is to prime a discussion with major stakeholders around the rationale for a proposed investment, before any solutions have been identified.

NEED-GAP ANALYSIS

To obtain a thorough understanding of business needs and the true gap between what is provided and what is used, you need to talk to representatives from across the business and from across IT (including operational and developmental managers) and a range of clients from tech-savvy through to Luddite. Given that you are putting in place a governance framework, you will also need to collect the opinions of representatives from the governing board or council.

Of course, if you are the CIO or senior IT executive, you are not best placed for running the gap analysis and interviewing your colleagues. On the other hand, more junior members of the IT team might not be able to extract the required information from their seniors – so who are you going to ask? Your peers are likely to be too busy to carry out this exercise, but a peer would be your best option to drive a successful outcome. You could invite in an external consultant, but unless they know your business inside out, you will have to invest an awful lot of time – at your expense – bringing them up to speed. Here are some pointers to help you in your selection. Your ideal person needs to be:

• neutral and not associated with any of your incumbent IT suppliers or vendors;
• mature and wise enough to carry some authority;
• able to read body language and to read between the lines of messages to pick out the rebels from the loyal supporters;
• available and not likely to disappear on another project half way through.

The next few sections of this chapter covering the gap analysis are written for an external consultant working closely under the direction of the board sponsor, the CEO and/or the CIO.

Business representatives

If possible, aim to talk to the full set of general managers (GMs) over a series of two to three meetings. The first meeting will be an informal meeting with each GM to discuss your approach and what you hope to collect in the way of information and achieve in the way of feeding this information into the resulting governance framework. Depending on the GM, you may want to run through or hand over the full list of questions that will be asked in the second meeting. This second meeting will be a white board or workshop session with the GM and representatives from their team or, better still, their entire team. Depending on the culture of the organisation, this could be a short, sharp brainstorming session or a half day with a break for coffee and cake. Prepare the participants a week in advance by sending through an email setting out the sort of areas you want to cover – but not the full list of questions.

A suggested set of questions is listed in Table 9.1. The space for the responses is kept short on purpose – you want to summarise each discussion item in as few words as possible.

Table 9.1 Group questions – collecting requirements

IT team

Independent of the size and structure of the IT team, you will want to meet initially with the executive team member responsible for IT, and then the individual IT managers. Remember that, in general, you are dealing with a team that successfully supplies IT services to their organisation – they might operate in a chaotic or inefficient manner, but they have a working system. In some cases you will be asked to consult to an organisation that has transferred best practice governance from the organisational board practices over to IT and is making a very fine job of governing IT. Whichever of the above apply, be careful not to change the status quo as you develop the needs-gap analysis.

The meeting of the IT executive needs to outline the grand plan for putting in place an IT governance framework. What are your expectations for how it will proceed? What will be the outcome for the executive team, the IT managers, the IT operational and development staff, or the general staff? You will also come across CIOs who have been independently operating happily for years and might see a formalised decision-making model for organisational IT decisions as a threat. My advice is to listen carefully for points of pain as you want this project to be a win-win for the CIO.

Once you are in agreement with the CIO as to how the project will proceed, it is time to talk to the senior IT managers with the CIO present, of course. You need to present a high-level view of the project and the results of the business teams’ need-gap analysis. It is my experience that the business will ask for applications, features and/or functionality that are already provided. The IT team will be indignant that people do not know that the service being requested is already provided. It will be your task to get to the root cause of why the existing solution is not used or even acknowledged. Reasons range from lack of documentation (‘we did not know it was there’) through to just too complicated for non-technical mortals (‘we could not use it because we could not programme in html’).

Also, you need to work through the differences between IT needs and IT wants. I have witnessed organisations where bad communications between the business and IT resulted in some poor acquisitions. In one instance the business said they wanted something – a new server – and that request was promptly and efficiently serviced by the IT team. However, the business representatives complained that they had paid unnecessarily for a new server, when it turned out that they really did not need one. The IT representatives said ‘but you asked for a new server and we delivered a new server’. It turned out that the business only required more disk space. This is a good example of the difference between needs and wants. The business might want and therefore ask for a CRM (client relationship management system), but actually need a single source of the truth for client contact information, which could be provided by cleaning up an existing system.

Once the IT team managers have had an opportunity to digest the results of the need-gap analysis, it is time for a high-level workshop around possible architectures.

By collecting needs across the entire business in one sweep, you will be able to work though needs that can be addressed together. For example, you determine that there is a need for a new finance system and an integrated project management system. By reviewing the requirements for both together, the IT team will come up with a range of possible acceptable solutions:

• a single package that delivers financial control and project management;
• two packages that integrate fully;
• a single package with multiple modules.

Beware of jumping into specific solutions here. The desired outcome of this second meeting is a high-level view of the type of IT systems that could deliver business requirements now and for the next three, maybe five, years. The length of the plan will depend on the maturity of the business, the nature of the business, the sector and the organisational plans for the next three to five years.

Client representatives

Ask your sponsor in the organisation to select two clients from both ends of the technical-savvy spectrum who you can interview. You need to ask them about their perception of the IT-related components of products and services that they buy and/or use. For example, your questions might be around the ease of use of the ecommerce site, the usefulness of information on the organisation’s website or supply chain information embedded in product bar codes, depending on the nature and delivery of the organisation’s business. Keep the questions high-level – ask about generic service or product delivery and ask for suggested improvements and additional features that would help ease of access or their business interaction. Also, do not forget to ask which features of the service and product delivery mechanism they like. It is very easy to make a change to deliver new functionality and to inadvertently destroy old functionality.

Board representative

Your final interview, before talking again with your original sponsor, is with the board/council/governance body member responsible for IT. If there is no member responsible for IT, ask for the chair of the audit/risk committee or a board member with an interest in information, intellectual property or general compliance. The aim of this interview is to ensure that everything that you put in place with the executive team is in line with the general governance principles of the organisation. You should also be able to determine the organisation’s appetite for risk and change, and the key links through to the organisation mission and vision. Ideally, you will be putting in place an agile IT governance structure that will flex as the organisation evolves and develops.

You might meet some resistance from the board member if they did not sign up to the exercise but were overruled by other board members. Maybe they do not see the need for a formal IT governance structure, but by now you will have some real examples of where a clear decision-making framework will add value. Better still, you will have a plan to reduce the risks associated with information and IP leakage and to reduce the costs associated with delivering IT across the organisation by introducing efficiency and transparency around IT decisions.

Need-gap analysis report to the sponsor

I am assuming that you have been meeting with your sponsor on a regular basis over the interview period to validate some of the wild claims in the information you have collected. This meeting is the final report back on your findings from the need-gap analysis. By now you will have identified a number of compelling reasons for moving forward with the project swiftly. These could take the form of:

• an imminent need to make a major purchasing decision for IT hardware or software;
• a business risk uncovered through the interview process;
• a need to meet a client or legislative obligation that requires an IT solution;
• a new opportunity for driving revenue through an existing IT system.

SETTING EXPECTATIONS

It is rare for the expectation of IT delivery from the business to match the understanding of the business requirements in the IT department. This might sound a huge overgeneralisation, but having watched a number of organisations struggle to put together an IT service catalogue, I am confident that this is indeed the case in most organisations. The business side often misunderstands what are the true mission-critical IT systems – the ones without which they cannot trade. This is not because they do not understand their business requirements or business model, but because some of the IT use in the organisation is invisible. Or, possibly, there is an expectation that reversion to previous manual processes is easily attainable. An example of this is an international airline that reverted to the manual issue of boarding passes during an IT systems failure. In the ensuing chaos at least two passengers ended up in the wrong country.

Developing a charter

One of the key activities to guarantee the success of an IT governance implementation is the development of an agreed statement on expectations, so that the business is clear on what IT services are delivered by the IT department and the IT department is clear on the list of IT requirements from the business. I have found that this is most quickly achieved through the development of an IT charter (see Appendix B). I came up with the idea of developing a charter for a particular client, having read the history behind Magna Carta, ‘Great Charter’, granted by King John at Runnymede in England in 1215. The principles behind Magna Carta are relevant on two counts. First, Magna Carta enabled the common man to push back on the ‘outrageous’ demands of the Monarchy. Second, large chunks of the charter were copied from an earlier document – the Charter of Liberties of Henry I, issued on his accession to the throne in 1100. This document similarly bound the king to laws that effectively granted certain civil liberties to the church and the English nobility. Thus, it is useful to consider the IT charter as an instrument for ‘pushing back the outrageous demands of the business’. Also it is wise to look to existing documents to form the basis of the charter, rather than write the whole thing from scratch.

The process of developing a charter will result in a clear understanding of what is required and what is delivered.

USING EXISTING DOCUMENTS

There are a number of common organisational documents that you will find useful when planning for a governance framework. These are as follows:

Annual report

The annual report will provide, at a bare minimum, a picture of the financial state of the company and will provide a review of the year’s activities from the viewpoint of the chair and directors. It will probably also list strategic priorities and the planned direction and activities for the next year. The annual report is generally made publically available. If you are part of a US public listed company, you should access your organisation’s Form 10-k, which is a more comprehensive version of the standard annual report. Form 10-k covers company history, organisational structure, executive compensation, equity and information on subsidiaries, besides the audited financial statements.

Before you look at the annual report for your own organisation, download three reports from organisations that you are familiar with – pick a range of differently sized organisations from different sectors. By the time you have read through three reports, you will have a number of questions and you will be ready to read the report from your own organisation.

Statement of intent or equivalent

Government agencies in most jurisdictions are required to regularly publish a plan setting out the aims for service delivery for the next few years. The plan covers ministerial priorities and planned outcomes against the agency budget. In New Zealand, this document is called a Statement of Intent and it covers a three- to five-year planning cycle. Reviewing the priorities for the future work programme in light of the organisational values will give you a clear idea of areas where new or enhanced IT services and systems will be required. For example, The New Zealand Treasury Statement of Intent 2012–2017 lists goals, roles, values and vision and describes the strategic direction that will result in the intermediate and final outcomes to deliver the vision – ‘Higher Living Standards for New Zealanders’. If you were planning to deliver IT services to the Treasury, it would be foolish to ignore the goals, values and outcomes listed in this document.

Shareholder report

The shareholder report is generally a subset of the annual report. It covers the financial summary (profit and loss account, balance sheet, auditor’s report and so on) and details of the past year’s activities. Be sure to read the notes against the accounts as they can be very illuminating.

Corporate policies

These policies, signed off by your board or governing body, provide some insight into perceived threats and opportunities that direct or restrict corporate strategy, and the activities of the organisation’s executive team. They should provide valuable insight into specific restrictions or requirements for new IT services and solutions.

Company profile

The company profile is generally a snapshot introduction to the organisation for all stakeholders – not just shareholders. It is a view of your organisation that is designed to be engaging, informative and interesting. More usefully for you, it will place emphasis on your organisation’s market differentiator or unique assets, as perceived by your board. Good IT governance can help protect your organisational intellectual property and support the process for developing new unique assets.

Awards

Company awards can be very revealing. For example, if your organisation regularly takes part in one of the internationally acclaimed quality management programmes, such as the Baldrige Foundation Excellence Programme, there will be great interest in improving the company score year-on-year. If your company is in the list of the Deloitte’s Top 50 fast growing companies, everybody will be energised to build on the achievement. Good IT governance, policies and processes can help with this.

TAKING AN INVENTORY OF EXISTING GOVERNANCE ACTIVITY

Before you jump into implementing an IT governance framework, you need to complete an assessment of governance activities throughout your organisation. A good place to start is to look for the use of standards and frameworks across the organisation. If you already have a culture for embracing and adopting standards, then 38500 will become part of your compliance framework. There will most likely be a manager, or even a team, with responsibility for standards. If your organisation has not used standards before, then you need to work with the senior management to link the implementation work you are doing with the portfolio of one of the senior executives. If your organisation has previously had a bad experience with standards then you need to proceed with great care and caution. I am working with an organisation that had a bad experience with ISO 9000 certification. Now they have clients who are asking them to seek certification with the business continuity management standard, ISO 27031: 2011. They realise that they need to do it, but nobody really wants to own it.

The more seamlessly your framework fits with existing policies and processes, the more readily it will be adopted. Also, you need to assess your external stakeholders such as your IT vendors, providers and suppliers and your customers. You might discover that your suppliers already have excellent processes in place that you can work with. One of my clients is going from batch processing of orders to real-time processing. They were greatly relieved to visit the supplier who finishes their product and find that the supplier had recently installed a job queue management system that made it significantly easier for him to deal with real-time processing of orders. Alternatively, you might need to educate your suppliers on what you are doing and why, and work with them to create new processes that work well for both parties. And remember that some of your improvements will result in a loss of business for your suppliers. If you have previously been purchasing items that you do not need or using consultancy services to salvage failing IT projects, then your suppliers will notice – so giving them a ‘heads-up’ would be a good idea.

Let us now run through your internal and external stakeholders and work out who needs to know what.

Internal stakeholders

Your internal stakeholders fall into two groups – the IT team and general business users. Unless the IT team are totally dysfunctional – and that is very unlikely if you are running a successful business – then they will have adopted good practice and they will be carrying out governance activities, even if they are not aware that they are. It is your job to capture their existing good practice, however patchy it is, and place it into your new governance framework.

Three things in particular to discuss with general business users are:

1. What is their requirement for IT governance, and how will the implementation of 38500 affect them directly and indirectly?
2. What existing agreements are in place that relate to IT governance and therefore will need to be considered as part of an organisational IT governance framework?
3. What are the current business activities around the reporting, monitoring and evaluation of IT services and systems?

The important thing with internal stakeholders is to communicate in lots of different ways and to communicate often. If they do not take an interest, they are very unlikely to take ownership, and the implementation will be short-lived. Staff who are forced to take on something they do not want to do will react in several ways – the brightest and best will find jobs elsewhere, the middle layer will try to shift responsibility to somebody else, and you will be left with a team from the least able layer who could possibly be silently revolting.

End users

By end users I mean the clients or customers who have interaction with your IT systems and services. Any change in rules, regulations, policies, structures, internal or external compliance could result in changes for your end users. It is likely that end users of government services will be required to go through an additional security layer before they will be granted access to a system that contains data relating to personal information. As a user, this might appear to be a degradation of the current service – access will be slower, and more complex passwords or security procedures are harder to remember. However, if the user knows that this increased activity will help protect their personal information, this can be turned into a positive message.

If your IT governance changes are going to change the user experience, then give them a timely warning. Do not overdo it or you will instil unnecessary fear. Make your communications very clear and concise and set expectations of how your changes might affect them. Too often we assume that what appears as a minor change to us will appear as a minor change to our customers.

To quote the World Usability Day website, which is aimed at raising awareness for end users:

IT providers

It is important to keep your IT providers in the loop of what you are doing with IT governance, as they might need to adjust the way they deal with your organisation on a business level and on a service/system provider level. I have found this particularly to be the case where an organisation has adopted the ITIL framework or certified to ISO/IEC 20000 as part of their governance implementation. The relationship with the IT providers moves from being ad hoc and reactive to being proactive and more formal. Eventually, the introduction of formal service management processes leads to more realistic service level agreements, but it can take a few iterations to balance new requirements against an existing service.

You will need to work out how your new governance processes activities will fit with your providers’ governance processes and activities. Before you can do this, you need to work out how they can participate in your requirements-gathering workshops. Depending on the closeness of your relationship with them, you will have expectations of how they will participate and how much information will be shared.

Customers

It is always worth letting your general customers and shareholders know when you are running a programme that will enhance efficiency and provide a better customer experience. Personally, I think it is best to wait until you are about to launch. One of our telecommunication companies sends out leaflets with every monthly bill describing forthcoming improvements to service. It gives the impression that they are always busy changing things, but there is not any visibility of anything being completed. Time your communications well and be very clear as to what the benefits are for the customers. If you can easily survey your customers, check with them after every roll-out to see whether they think you are improving things, and you can fine-tune your governance upgrade activities accordingly. Some of our recent major telecommunications upgrades have involved digging up the pavement, and on two occasions we have coincidentally and mysteriously lost power. The customer experience got a lot worse before it got better. Eventually we will have faster broadband, and the discomfort will be worthwhile, no doubt.

Monitoring agencies/parent companies/subidiaries

As far as implementing 38500 is concerned, you need to evaluate the current governance activity at the interface of your parent, sibling or child organisations, and to identify areas where changes could be made. As part of your planning for implementation, it will be a useful exercise to assess the IT governance activities of your related organisations. Given that there is an existing requirement for information to flow between the organisations, this activity will help define your final framework. Your implementation might act as a ‘proof of concept’ activity for the rest of your group. In this case you will be expected to communicate your project administration activities as well as your change activities. When an organisation makes a major change to IT service provision out of line of its related companies, the resulting confusion can lead indirectly to revenue or reputation loss through miscommunications with customers and potential customers.

TEST AND TRAINING STRATEGIES

The best time to consider the plan for testing your new systems, policies and processes, and training for your staff, is at the point where you are developing an implementation plan. This way, testing and training can be closely aligned to the expected benefits to be realised by the implementation programme.

Test strategy

A good test strategy will start with a risk and quality workshop with all key stakeholders.

First, testing effort must be concentrated on the areas of highest risk from operational, reputational and financial viewpoints. Once the test team understands the risks associated with rolling out your implementation plan, they can identify the key risk indicators (KRIs) and balance tests and testing time appropriately. Also, it is often a useful exercise for stakeholders to hear the risks stated by their colleagues. During the development of the test strategy is the best time to work through compliance and conformance requirements with the business. These requirements generally point to high-risk areas. What have you agreed as the conformance principle for your organisation? What performance goals has your organisation set around compliance?

Working through these areas will help you understand the risk profile and identify some key focal points for testing.

Second, testing effort must be focused on delivering quality outcomes, based on the quality requirements of the business. These quality goals should align closely with the benefits realisation statement presented at the start of the programme, KPIs and the key business goals associated with the programme. We often hear the phrase ‘good enough is good enough’ especially when people are cutting corners on delivery, but for your programme, what does ‘good enough’ look like?

And, finally, the ‘good enough’ discussion will feed nicely into a prioritisation exercise across the risk and quality statements. The programme is not going to have the resources to address all known risks or to deliver to the highest quality in all areas. The test team need to understand the compromises that the business stakeholders are willing to make in order for the programme to be delivered on time and on budget.

Training strategy

A good training strategy will ensure that all staff receive appropriate training at a time close enough to implementation so that they cannot forget what they have learned, and far enough away so as not to interfere with any roll-out duties they have. Most organisations adopt a train-the-trainer approach as it is the most cost-effective and efficient way to train a number of people in a short space of time. However, there are drawbacks and if you ask somebody who does not quite understand what they have been told to explain it to somebody else, the result is confusion and staff who only partially understand the overall operation of the rolled-out system, or fully understand only parts of the rolled-out system.

One of the most important tasks in developing the training strategy is to identify the training that will be required by each different stakeholder group. You will most likely have some foundational or basic training that will be rolled out to everybody, but then you will need some role specific training on top of that for specific user or audience types. Giving training to staff who do not need it, or omitting to train staff in certain areas is costly and causes confusion. Understanding that there will be dependencies between your training modules is a key part of the strategy so that training programmes can be tailored to individual staff members, or at least to role groups.

Given that you are unlikely to have the time or money for your experts to train all your staff, you need to plan mop-up training as part of your training strategy. Identifying who needs extra help can be problematic as your staff might not know what they do not know, and even if they are aware that they are lacking expertise, they might not be keen to admit it. So there are three options for the training strategy. You can run a survey post-implementation to weed out the staff who need extra assistance, you can run mop-up training for all staff or you can provide some supplementary training materials that staff can run through as and when required.

At this stage you are just developing strategies for, and approaches to, testing and training – you are not yet ready to develop plans. The plans will come together as you address the risks identified in the test strategy risk management workshop, and as you evaluate what training will be needed for each different stakeholder group. This approach is described in Chapter 10.

RECAP

Before you start executing the implementation plan, you need to have the core elements of the IT governance framework in place. These are as follows:

• a version of the 38500 principles, tailored to your organisation and signed off by your governing body;
• systems for carrying out the IT and information transfer functions in a way that supports the principles;
• a supported and maintained infrastructure capable of hosting the systems above;
• process and policy to enable all staff to align activities to the principles;
• a charter to state business expectations from IT and information management and vice versa;
• an organisational chart that reflects new responsibilities and authorities required to carry out the principles;
• a test strategy that sets out an approach based on the risk profile and quality goals;
• a training strategy to ensure that all stakeholders are confident in using the new framework, and that they understand any new responsibilities they have.