INTRODUCTION

In a paper published in 2008, we explored the reasons for customer relationship management (CRM) system success and failure.1 Since then, we have broadened out our research programme, to include coverage of major systems projects with some focus on the customer or stakeholder, even if they are not ‘pure CRM’. One of the central topics that came to our attention during this broadening was the question of information technology (IT) governance, and thus we decided to carry out a small study focusing on this topic.

IT governance is the process and structure that ensure that organisations deploy their IT investments appropriately to ensure that the resulting activities – whether programmes, projects or operations that they fund – are carried out properly and achieve the desired results.2, 3 Governance covers many different aspects of IT management – the principles of IT strategy and their relationship to your organisational strategy, the architecture(s) upon which organisations base their IT and the extent to which it is integrated and standardised, an organisation's policies towards IT infrastructure, its organisational applications – including how it diagnoses and fulfils organisational needs, and its financial investment in IT. Governance covers all the assets that may be involved in IT, whether human, financial or physical, or data or intellectual property.

IT governance is an essential component of corporate governance. Corporate governance relates to how (customers, processes, policies, laws and institutions) a corporation is directed and to how different stakeholders (directors, managers, shareholders, staff, suppliers, customers, banks, and so on) work with each other to achieve corporate goals. Although corporate governance is implemented through different models, good corporate governance allows organisations to work productively and efficiently while minimising corruption, abuse of power, and providing managerial accountability in both private and public sector organisations.

Where IT projects are concerned, IT governance and change management are closely related. Change management is a structured approach to moving individuals, teams and organisations from a current state to a desired state in a number of phases, which ensures a successful and sustainable outcome. In the same way, IT governance is also a continuing process rather than a one-off project that requires continuous changes. In a complex IT environment, relatively simple changes can a have a large effect on higher-level business processes, and thus change management tools become essential to the IT governance process. Typically, IT governance process design starts with an IT governance plan. This is followed by its implementation and the assessment of the results against the desired outcome. Further changes and implementation of the revised plan may be necessary in order to ensure continuous improvement. The objective of change management in this context is to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure. There is no standard solution for IT governance, but change management disciplines should be adopted early on in the governance cycle, to support the development of a comprehensive IT governance programme.4

In recent years, IT governance has attracted much more interest from practitioners, management consultants and academics, and has become the responsibility of the board of directors and executive management, partly because of the costs and risks of developing IT, partly because of the knock-on effect of failures, and partly because of the much wider applications of IT in organisations and its strategic importance because IT has shown to support, sustain and grow the business. As suggested by Nolan and MacFarlane in their Harvard Business Review paper, as more and more organisations change marketing tactics and other firms choose to adopt new technologies to stay ahead of the competition, board-level technology has become increasingly important. Despite the fact that corporate information assets can account for more than 50 per cent of capital spending, in managing the governance of IT, many boards used to apply a set of tacit or explicit rules shaped from what they perceive to be best practice of other firms. Today, however, it is clear that in most large companies, the board is now involved in IT decisions, and that the board expects tough governance standards to be applied to major projects by senior IT management.5

The aim of this study is to investigate applications of IT governance in organisations in the UK, specifically as applied to IT projects, rather than overall IT spend.

BACKGROUND OF THE STUDY

Why is IT governance important?

Most organisations depend critically on the successful deployment of their information and communication systems, to help them deliver efficient and effective operations and to achieve the changes they need in order to translate strategic plans into actions. Too often, organisations focus on their IT strategies, policies and budgets, failing to recognise that without good governance, these are unlikely to be translated into the desired results. If IT is not governed properly, things can go badly wrong. For example

  • — Issues and problems are buried and stay buried.

  • — By the time problems emerge, it is often too late to address them properly, and thus programmes and projects slip.

  • — Costs rise beyond what is budgeted, and unless the programme, project or operational capability is protected, it will have to be descoped in order to remain within budget. Even if the budget is increased, the problems caused by the rising costs and slippages may never be solved, so that the resulting programme is weak as well as late.

  • — When management confidence is lost, the programme may be cut dramatically, to focus on minimal deliverables; it may then be gradually rebuilt over time as confidence returns. Meanwhile the organisation will have suffered.

  • — User departments suffer budget freezes until the programme starts to deliver again, and thus cannot provide alternatives or progress elsewhere.

  • — Final solutions are often extremely scaled down, or are completely written-off.

  • — Success tends to be accidental, rather than delivered with intent.

Good governance results in a framework for accountability for taking and implementing IT decisions and for obtaining the desired results from them. The main attributes of good governance include

  • — an organisational strategy that is set out so that its IT implications can be identified clearly;

  • — clear assignment and governance of internal resources;

  • — board sponsorship of, ownership of and involvement in governance policies;

  • — clarity, quality, consistency and measurability of governance;

  • — encouragement of behaviours and internal/external relationships that support your governance policies;

  • — application of governance to external suppliers as well as to internal activities;

  • — appropriate use of shared governance structures, including main board, executive board, audit committee, change programme boards and internal and external auditors.

The key questions an organisation needs to answer if it is to achieve good governance are as follows:

  • — Does the organisation understand the meaning of governance and the need for it?

  • — Is governance part of the IT strategy and plan?

  • — Who owns and who manages governance?

  • — Who are the stakeholders for governance?

  • — What value do they derive from each programme, project or operations capability that is the focus of governance?

  • — What are their needs for good governance?

  • — What are their accountabilities in governance?

  • — How does internal and supplier programme self-assurance take place, and how is it audited and reported?

  • — Who should manage it (that is ensure that it takes place and is productive and adds value)?

How can you ensure good governance?

The only way to do this is to ‘govern your governance’, by ensuring that you regularly review the governance process, particularly if you experience problems that seem to be due to weak governance. This involves reviewing the following:

  • — involvement and accountability of the board/senior management;

  • — accountability for innovation;

  • — strategy, planning, financial cases/returns;

  • — change capability assessment and change management;

  • — quality of processes, outputs, and so on;

  • — management of human resources and teams, including incentives;

  • — management of knowledge relating to IT project, programmes and operations;

  • — purchasing and supplier management, including staff validation and performance review;

  • — programme, project and process management and review;

  • — technology and data management;

  • — development and deployment processes for policies, systems, and so on, including usability and stakeholder/user acceptance;

  • — benefits realisation and measures;

  • — governance ownership, accountabilities, structures and processes;

  • — problem/issue/risk forecasting, management and resolution;

  • — review management.

For projects of long duration, that is, years rather than months, frequent review is sensible – during development, deployment and benefit exploitation.

One of the key challenges faced by organisations is to answer the question – how much IT governance is required? Sambamurthy and Zmud6 suggest that key determinants of IT governance can be classified into three broad categories: corporate governance, economies of scope and absorptive capacity.

Corporate governance

Organisations committed to strong corporate governance do so partly to lower their organisational coordination costs. Also, the mode of corporate governance strongly influences the mode of IT governance. Firms that centralise corporate governance tend to centralise IT governance, whereas firms that have decentralised their corporate governance tend to decentralise IT governance.

Economies of scope

Economies of scope are benefits accruing to an organisation when it is able to share its resources across multiple goods/services (for example, reducing cost due to better synergy). They often arise from the sharing of knowledge and distinctive managerial competencies. This relates to absorptive capacity.

Absorptive capacity

This refers to the ability to value, assimilate and apply new knowledge. It demands knowledge and communication and partly determines innovation performance, aspiration level and organisational learning. The theory was first introduced in 1990 by Cohen and Levinthal.7 Two concepts related to absorptive capacity are as follows:

  • — Receptivity: Awareness of, identification of and taking effective advantage of technology.

  • — Innovative routines: Practised routines that define a set of competencies an organisation can use confidently and that are the focus of its innovation efforts.

Where IT governance is concerned, the key issues are how strong and well articulated corporate governance is, how it translates into IT governance, how both are deployed over the whole organisation, and whether it knows how to use IT governance to support innovation.

According to Nolan and McFarlane, IT governance decisions should be based on four involvement modes, shaped by two types of strategies: defensive and offensive.5 Defensive strategy establishes how much the organisation relies on cost-effective, uninterrupted, secure, smoothly operating technology systems. It relates more to operational reliability. Offensive strategy establishes how much the organisation relies on IT to gain competitive advantage through systems that provide new value-added services and products or high responsiveness to customers. It places strategic issues either at or above the same level as reliability. Offensive IT projects tend to be ambitious and risky because they often involve significant organisational change. Figure 1 shows the IT Strategic Impact Matrix and the four involvement modes.

Figure 1
figure 1

The IT Strategic Impact Matrix.Source: Nolan and McFarlane5.

Full size image

As can be seen from Figure 1, organisations’ engagement with IT governance varies according to four strategic modes: factory mode, support mode, strategic mode and turnaround mode. Depending on where organisations locate themselves on the matrix, IT governance may be a routine matter best handled by the existing audit committee or a vital asset that requires intense board-level scrutiny and assistance. What board members need to know about IT activities depends on the firm's strategic mode, as well as firm size, industry and competition. Both the factory and support mode are extensions of defensive marketing strategy. Organisations in factory mode need highly reliable IT systems to run operations smoothly and constantly, for example airlines. They do not need state-of-the-art computing. Those in support mode depend less on IT, as they have less need for reliability and for strategic IT – they will not suffer terribly if a system goes down for longer periods. From an IT project perspective, this means that it may be better to delay problem projects until they can be perfectly or near-perfectly implemented.

Organisations in turnaround mode heavily rely on new IT systems that promise major process and service improvements. Here, technology typically accounts for a high percentage of corporate expenditures, and all the manual systems are transferred into the new IT system. At the same time, firms have a comparatively low need for reliability when it comes to existing business systems, and they can withstand repeated service interruptions of up to 12 hours without serious consequences. Organisations in strategic mode favour total innovation as their main business principle. New technology informs not only how they approach the marketplace, but also how they carry out daily operations. Like turnaround firms, their IT expenditures are large. According to Nolan and McFarlane, not every firm wants or needs to be in this mode, but some are forced into it by competitive pressures, for example if they fall behind more competitors who use information systems as the cutting edge of innovation. From an IT project perspective, this means that it may be better to complete a project even if it is not perfect.

Organisational responsibility for IT governance

IT governance is usually implemented at different layers of the organisation. Leaders report and receive directions from their managers, and managers report up to the executive, and the executive to the board of directors. Although many organisations recognise the potential benefits that technology can achieve, the successful ones also understand and manage the risks associated with implementing new technologies. The IT Governance Institute suggests that the enterprise's challenges and concerns include the following5:

  • — aligning IT strategy with the business strategy;

  • — cascading strategy and goals down into the enterprise;

  • — providing organisational structures that facilitate the implementation of strategy and goals;

  • — insisting that an IT control framework be adopted and implemented;

  • — measuring IT performance.

Selig states that effective IT governance is built on three critical factors: (1) leadership, organisation and decision rights; (2) importance of flexible and scalable processes improvement; and (3) the use of enabling technology. The process of IT governance starts with setting clear objectives for the organisation's IT in order to provide the initial directions. This is followed by strategic planning and execution of the IT objectives. The implementation of the IT governance strategy, policy and action plan will ensure that IT governance is managed more effectively. A continuous loop is then established for measuring performance, comparing it to objectives, leading to redirection of activities and changed objectives where appropriate.3 A solid foundation for IT governance is published best practices and guidelines, for example Control Objectives for Information and Related Technology (COBIT) and The Code of Practice for Information Security Management (ISO 17799).8

Our research

To explore how IT governance is implemented in British organisations, we decided to do some qualitative research. We interviewed senior managers in 10 organisations about a recent large IT project in which they had been involved. The respondents were one national retailer, five financial institutions, one regulatory authority, two central government departments and one information services provider.

The respondents ranged from middle management to the most senior management. Two were Chief Technology Officers/CIOs or equivalents, one was a Director of IT Transformation, and one managed relationships with internal stakeholder, one with suppliers, while the rest had more specialist roles. Some had been in IT for many years, while others were relatively new to the discipline. Most had been extensively trained – some at university level – in project management, while others were involved in project management through another role.

We asked them the following questions:

illustration

figure b

FINDINGS

The questionnaire was completed via face-to-face or phone interview. The main points that emerged were as follows.

The projects

These were very varied. One involved developing a system to sell the product of another large financial institution, which had very stringent security requirements. The retailer's project aimed to replace its back-office systems and business processes and implement an Enterprise Resource Panning (ERP) system. One government project was to manage the authorisation, control, accountability and assurance for European funding being distributed to projects within regions, including the development of new business and financial processes to transfer roles from centre to the regions. Another financial project involved the development of a completely new point-of-sale system. Another involved development of a new credit-modelling system. The other one related to improving access support. The regulatory authority's system was developed to centralise data on all transactions carried out by regulated companies. One was the replacement of a bank's core banking platform, another bank developed a platform to integrate finance and risk.

The suppliers

The suppliers used varied. In one case, there were two major change partners: one a partner who combined two roles – business change partner and a software implementation partner – and the other an infrastructure partner. In another case, a large software developer was developing the software. Another only used in-house development as a matter of policy. Another used a large system implementer who was the prime contractor with a number of sub-contractors, for delivery and hosting. Another outsourced most of its modernisation work to India. Another used a mix of in-house, partner and external development. One used a mix of IT and business consultants.

The suppliers were in some cases an integral part of the project management and governance approach, attending programme board meetings. Suppliers were not, however, invited to all meetings. Communication was a problem:

Suppliers delivered on time and to budget but could have communicated better (particularly with regard to issues and problems.

Suppliers were not open about programme level risks but were better at code level risks, though they were good at coming up with mitigating actions for the risks the client identified.

One mentioned in particular the need for suppliers with ‘fierce attention to detail’. The same respondent mentioned that the IT supplier was deemed not to be a necessary member of the main project board:

Suppliers’ input into the project management process had often been too detailed, and that the suppliers should have considered more carefully the audience for the information they were bringing or sending to the main project board.

The above findings highlight the importance of a number of communication factors. A key part of good project management is that the different parties agree what is to be communicated, to whom, how and when, and at what level of detail. IT projects are generally very complicated, and thus too much or too little information can cause problems to be obscured. Where project governance is concerned, a central part of good practice is ensuring that the significance of the information that suppliers and clients pass to each other is appreciated by the other party. It is not enough to hide behind the lame excuse ‘we did tell/warn you’. Where information indicating serious problems or risks is concerned, the true partnership that should exist between supplier and customer should lead to each party checking that any such information has not only been received, but also that its significance has been understood and that it has been acted upon.

Budgets and timings

The projects were all large, ranging from £0.5 million to nearly £30 million, although several respondents pointed out that the total commitment was hard to quantify, for example because part of the effort was effectively business as usual, or because of the involvement of non-IT resources. IT costs varied as a proportion of all costs, from being most of the cost to less than 10 per cent. Most project budgets and timescales were adhered to. Timescales were typically 1 to 2 years, but one was 3 years and one was 5 years. In two cases, the advent of the respondent as a new project manager had led to a great tightening up of a previously slightly lax budgeting situation.

The long duration of projects clearly puts project management and governance processes under stress, for reasons associated with stability of the team, as we describe in the next section.

Involvement of senior managers

All respondents realised the importance of senior management involvement. Some had problems with achieving the desired level of engagement and had to work hard at it.

We set up a sponsoring group, including executive management within the partner organisation, and used this as our governance approach, with all projects reporting to the group.

Some respondents, however, had experienced the problem of ‘musical chairs’ among senior management.

We had five changes in the senior user manager during the course of the programme.

Another respondent said that this was a very good reason to get projects done quickly.

The involvement of senior managers had interesting consequences:

Senior management insecurity about the project led to the involvement of too many consultancies. A significant problem was the lack of vision by a key sponsoring director, who later moved on to other responsibilities. All this moving around destroyed trust and communication, led to a lot of rework, re-evaluation and often reduced budgets.

Senior management must be involved from the beginning.

If senior executives involved in a project leave half-way through, it may be worth ‘turning the clock back to reposition the whole project’, as otherwise there may be severe problems with the project, ranging from lack of understanding to lack of stakeholder commitment.

Thus, for project management and governance to work in projects of longer duration, new personnel, particularly senior personnel, need to be fully briefed on project management and governance processes, and warned against changing project specifications.

Stakeholder involvement and governance

The main stakeholders in the programme were the heads of the user department, although in one case where the systems involved interface with the other companies system, the stakeholders included the equivalent senior user from the partner organisation. Most projects had a strong approach to governance – which is not surprising, as we were looking for good examples. In two cases, it was tiered, with meetings at regular intervals for each level, with clear escalation procedures. In some cases, the governance approach was based on PRINCE ideas.9 Regular meetings of different stakeholder groups were the norm. There was high awareness of the need for what one respondent called a ‘robust and rigorous process’. Companies used a mix of progress reports, highlight reports, newsletters, bulletins and video conferencing to communicate with key stakeholders. Performance criteria were generally clearly specified and reported upon. One public sector respondent put particular emphasis on the importance of e-mailing the wider group of stakeholders (which included a variety of public and third-sector organisations) when there was something significant to update them on.

Process was important:

We have a joint IT-business planning process, directed from the Board to drive operating planning. It requires submissions from all departments including IT. This planning group agrees on priorities and develops a balanced portfolio.

We use a steering committee approach, with a Project Review Board (the top sixteen managers in our company). We use audit to identify irregular attendance at this board.

No respondents allocated a separate budget to governance (other than a budget for project communication).

It seems that companies with strong awareness of the connection between project management and stakeholder management were more satisfied that their governance approaches were robust. Stakeholder management is a relatively new management discipline – although it has long been part of communications management – whether in public relations or human resources. It has recently emerged as a very important discipline in the public sector, which is ahead of the private sector, where it is conventional to break it up into the management of different communities, for example staff, customers, owners and other departments.10

Project management and learnings

Some of the main learning points from the projects related to governance and the deployment of resources to achieve the desired outputs:

Simply recognising the work as a formal project was key.

A strong focus on delivery was essential.

We had to ensure that we devoted adequate business resource to support the workload, clarifying requirements, testing etc, right across the project lifecycle.

We focused on getting the right people to do the right things; getting buy-in to plans; getting the contract right for all parties and ‘putting it in the drawer’; agreeing on the terms of reference for all stakeholders.

One respondent identified that the informal way people would commission work was a problem.

There were too many informal projects going on that were not part of the project tracking and resource management process, and this caused problems in resource management.

Having an independent viewpoint was important:

An independent project management organisation is key. If an external contractor is used to develop a particular part of the deliverable, it is important to ensure that that project be managed by another company.

Methodology was also important:

We used a strong project management disciplines (based upon PRINCE), from the very earliest days of set-up, particularly where it came to identifying roles and responsibilities.

The value of the rigour introduced by such methodologies was a common theme, and the importance of weekly reporting on deliverables was stressed. The difficulty of managing risk and the difficulty of embedding learning from managing the project into the company's culture were also identified.

One respondent mentioned the learning from another project that had gone less well:

The learning from the clear project management approach adopted for this project (the subject of the interview) was not transferred. However, we now have a change manager, with the duty of ensuring that all projects are well managed.

Stakeholder relationships were key:

Our main learning was about the management of relationships. What made the project work was the strong relationship between the business team and the IT development team.

The response was clear-cut across the respondents – all used structured project management methodologies and associated software, whether PRINCE, another public software or one proprietary to their company. Another respondent identified the importance of not underestimating how long it would take to work through user acceptance testing, and of accepting that this might delay a project.

One respondent learnt how to deal with the offshore supplier. ‘They always said Yes, but this actually often meant ‘No’ or a ‘Yes but….’ So from Mid Development onwards we added 30 per cent to all of their estimated timings’. Another respondent pointed to the importance of tracking consultants and other external suppliers, to ensure that they delivered their plans and promises.

The main conclusion from this part of the research relates to the importance of broad awareness that project management and project governance are significant management disciplines, which are both essential to the successful management of large projects. They are helped by the use of standard project management tools, but these are the start point, not the end point. Stakeholder management is key, as we have already mentioned, but so is a stable approach, and a proper balance of incentives.

Objectives, rules and rights, project charters

One respondent mentioned that the project did have a project charter. Another had a project delivery method that included specification of these aspects of the project. One had this just for the board of directors, but not for stakeholders. One respondent referred to the way in which his company drew up terms of reference for the project, including project structure and the people involved. Others had formal terms of reference for everyone involved in the project, including stakeholders, delivery teams and governance.

Focus was generally maintained on objectives, rules and rights through constant engagement of business stakeholders, regular project meetings and frequent sign-off points. One respondent, however, voiced his doubts, mentioning that he was not sure that his business appreciated that there was a problem that needed fixing. He described his company's change management process as ‘complex’.

We have already discussed the issue of communication above. This section highlights the importance of a framework within which the communication should take place.

Gathering project requirements

This process seems to have been thorough for all respondents. Some used their tiered governance structure as the channel. Several had formal phases in which user requirements were gathered and then worked on by technical teams and with business users, and signed off by senior managers. One respondent stressed that getting project participants to map out requirements, process flows visually and compare them with the existing situation was critical to success.

We engaged stakeholders, through ‘heavy duty process mapping’ to understand the relevant processes and how to change them.

In a large organisation like ours, gathering requirements is very hard – with subject matter experts and many different stakeholders needing to be consulted, requiring a full time person just to book diaries, set workshop dates, book locations all over the country and make travel arrangements, just to make sure right people were working together. If people don’t turn out, they are unhappy about decisions and want to retake them. However, once the requirements were gathered, we had very clear version control, including final sign off at every stage by our senior sponsor (CFO), who was supported by a full time project manager.

Several mentioned the importance of change control, and one stressed the importance of tying contractual change control to budgets.

The software chosen can pose a choice:

It is critical not to modify the package to fit processes but rather to do it the other way round. Many of our processes are ‘commodity’ and could be changed and improved through the package. However, this led to a different question – where does a company like ours differentiate itself where it concerns processes? Some processes must be kept as differentiators or sources of competitive advantage.

This area is one of the most critical in all complex projects. Requirements cover a very wide range of topics, from technical requirements that concern only IT staff, to the functional requirements of users, through to usability requirements, which determine whether useful functions end up being used as they should be. Projects in marketing, sales and service often involve two groups of non-specialist users – staff who interface with customers and (increasingly, because of self-service) the customers themselves. Customers are rarely asked about their requirements. Non-specialist staff may be asked about them but may not be able to articulate, still less anticipate, the requirements that they may have in the future (and as we have seen, it may be between 2 and 5 years before a system for which the requirements are being gathered is implemented). Thus, the term ‘requirements gathering’ must not be interpreted as ‘gathering objective requirements’ – much judgement, interpretation and insight is required to arrive at a set of requirements that will truly meet the needs of users when the system goes live. Similarly, as the organisation moves on, requirements change, and thus change management (and its governance) becomes particularly important, especially in long-duration projects.

Project budgeting

In general, the approach followed here was highly structured.

There were budgets for each key activity, with costings provided for changes, while costings were owned by the project office and reported in to the board. Our finance director was on the project board.

Costings were governed by business case submission based on their business case scope review and driven by priorities. The steering committee authorised the budget and changes.

Formal estimating of costs (including supplier costs) was carried out for all workstreams, including provision for cost changes during programme life and an overall risk buffer, which was different for different workstreams.

Costs were reported weekly to the programme board.

This was not, however, always so:

Costing was more of an art than a science, and it was not always clear where the money was coming from.

Thus, while organisations may have good formal cost control, this may mask some uncertainty as to how much is being spent and where it is coming from. The authors’ experience of major CRM projects confirms this. At a high level, budgets may be reallocated from marketing or customer service to systems if the project is exceeding its estimated cost. Project costs may be hidden by reallocating staff formally working under other budget codes. This should not, however, be regarded as ‘bad practice’. Few large systems projects have the luxury of perfect predictability – whether this relates to development activities or costs. It is natural that user departments that are anxious to see the completion of ‘their’ system do what they can to expedite its completion, even if it means that some other activities suffer. A user department must make its own judgement about its priorities. Perfect budgeting and innovation rarely go together.

Governance

Where governance to ensure the application of accountability, processes and criteria was concerned, some respondents said that this took place through normal project management and board management processes. In some cases, however, a tougher approach was needed:

Our internal audit function was involved, to keep people ‘honest’ and to ask difficult questions.

The project steering committee provided a governance pack for the capital expenditure committee and the company Board. When a project was approved, accountabilities and involvement were reviewed.

In one company, however, there were no processes for this, and another had difficulties:

This was a tough area, with appointments to the governance board being based on the organisation or department for which they worked and their role, rather than their capability to be board members, so sometimes we had a skills mismatch.

Our main learning was the need to shake up governance regularly. We also needed to get the right balance between academic/research work and ‘real’ project work that produces deliverables. The mix was wrong at the beginning of the project, with not enough delivery, and this hampered the project manager's attempts to engage some important stakeholders. We had problems with control too – it was frustrating to have project managers working for me that did not belong to my organisation.

In some cases, respondents admitted that they had no metrics for governance, or no separate metrics other than normal project progress metrics, or simple box-ticking exercises. There was one star exception:

We applied corporate governance metrics along with CMMI (Capability Maturity Model Integration).

In one case, the respondent taking up the role of manager of the project led to the introduction of different metrics.

This does not necessarily indicate poor practice. Good governance is primarily a cultural phenomenon, which cannot be measured simply, for example solely by complying with a checklist. This is similar to our view that good customer management is the result of the interaction of many factors.11 We would, however, certainly argue that an assessment process can be developed for governance – our checklist at the end of this paper indicates its possible components,

Project prioritisation

Project prioritisation was handled in all companies within projects by their project management and/or business planning framework.

Priorities between projects are down to individual business units, and then requirements become part of the wider set of business requirements for IT, for which priorities are discussed and set at the CIO level.

Overall prioritisation is a board matter.

The good news here is that all respondents indicated that they had a framework for prioritising projects. This is a fundamental component of good governance.

Project reviews

Generally, project reviews were weekly, with various techniques used for identifying success and problems, such as RAG (red-amber-green) scoring, highlight reports and slips against milestones identified in the project management software. The seniority of those involved in weekly reviews varied.

The interesting point here is the frequency of reviews – which was high. This suggests that companies have learnt the risks of infrequent reviews.

Role of consultancies and other externals

Most companies did not use consultants. Where they were used, the experience of using consultancies was generally positive.

Consultants introduce experience to the planning process – the consultancy we used asked each workstream to develop an initial plan and then pulled the plans together, challenging inter-dependencies and allowing cross-workstream challenges. The consultancy also chaired the workstream meetings, and developed a matching governance structure. We had a consulting partner who really did have the required breadth of experience and resources to handle the project. Many consultancies claim that they have more experience and capability than they actually have.

We used consultants for their specific business expertise and technical knowledge, plus support.

The experience was not, however, always positive:

We used an IT consultant (expert in our development environment) to improve the company's testing capability, and three contractors to work on business acceptance. These consultants absorbed quite a lot of time as they were not familiar with either us or our systems.

In some cases, the major management consultancies were closely involved in the governance approach, perhaps sitting on project boards. One respondent, however, commented:

Suppliers were not sufficiently open quickly enough. More transparency and openness would have made things better, and given us a better capability to respond.

Our conclusion here is that the independence of consultants is valued, although companies are wary of the costs and the introduction of self-interested agenda. In our experience over more than 20 years, clients that place everything in the hands of consultancies and those that place nothing in their hands take large though dissimilar risks. Refusing to use consultants shuts the door to the introduction of experience from similar projects. Some clients believe that they can overcome this by hiring people who have implemented similar systems in other companies, but in our experience these people may become absorbed in their particular roles in the project, so that they cannot contribute their full experience. In addition, the experience of one similar implementation is not as valuable as experience of many similar implementations. At the other end of the spectrum, giving consultants too great a role in project implementation and governance can increase costs – not just because of higher day rates, but also because of expansion of the consultants’ role. A golden mean is of course the ideal approach, but in the fray of a large project, it is usually hard to know where that golden mean is.

Change management approach

Here there were two main approaches. Some companies had a standard change management approach, with prescribed tools, documents and templates covering configuration and change management. Others did it through their own efforts and/or through appointing experienced project managers.

The discipline of change management, which is much wider than project management, is becoming more widely understood, but still has some way to go. We look forward to a time where it is regarded as a normal and constantly used discipline.

Risk and problem management and resolution

Most companies covered risk and problem management and resolution through their change management and project management processes (in particular regular project meetings), though one respondent identified that it was difficult where business partners were involved. Typical risks identified were where stakeholders changed, where projects were very large, and where system usage was low and affecting performance. In fact, as one respondent stated, usage can be too high or too low (for given tasks), and thus it was important to model this. Another respondent identified the importance of planning for mitigating risk at project planning stage. Good practice was exemplified by several respondents:

We have a standard risk management approach of identifying owners of the risk, planning for mitigation, identifying the cost of mitigation actions and of bringing contingencies into place. This allows go/no go decisions to be factored into the plan well ahead of bringing in the contingencies.

We keep a risk register throughout each project, running RAG reports on them.

We use a risk-based project management approach, reviewed monthly.

We run risk workshops. For each risk identified, we assign a budget for mitigation, to be included in the overall project budget. The budget is generated by a formula containing an estimated impact and likelihood and the costs required to fix each risk.

Where problem analysis and resolution were concerned, experiences and approaches varied:

The key is to identify the issue first. Then we use consultants for process mapping and skills transfer. If consulting resources are insufficient, we escalate the problem so as to get resources allocated.

The key is to get the right people in the room together to thrash out a solution.

We identify problems and resolve them in normal weekly team meetings.

Our three biggest problems are scope creep, project management skills, and estimating timings for different elements of the project plan. So I have appointed a software development manager, with whom I work very closely in estimating timings, or in checking the timings that the development team proposed. This does lead to the occasional mistake, but the key is to ensure that we learn from them (eg identifying one particular manager who always said things were on track when they were not).

We were pleased to see a relatively high level of maturity in risk and problem management. Too often, risk management is given lip service. Particularly dangerous is weak communication, as we have already identified.

CONCLUSION

Our research showed that most companies that responded had strong project management approaches and strong, well-qualified project managers, for the major projects that were the subject of the enquiry, and that respondents perceived that these two factors were very important in ensuring successful project delivery and in the successful governance of projects. In some cases, the project management approach had been long established; in others it had been established as a result of the efforts of the individual respondent.

The project management and governance methods used by the respondents’ organisations helped them to cope with most of the vagaries of their IT projects. A few problem areas stood out, however, such as coping with senior management churn and ensuring that consultants and other suppliers were managed appropriately. These are two prime problem areas in project governance and IT governance, and thus the findings hint at a general weakness in IT governance that might be infecting project governance.

Our findings support previous studies that suggest that successful implementations of IT governance depend on senior management involvement (and constancy) and good project management ability. Project management, project governance and IT governance are not the same thing, however, and it is possible to have strong project management and weak project (and indeed IT) governance. Our findings also supported the idea that changing how projects are governed played a significant role in delivering success. This seems a better approach than relying on accidental success. Whether this works or is advisable depends on the stage at which this is carried out.

Management implications

The main implication for management is that as soon as a major IT project is envisaged, an organisation should ask

  1. a)

    Whether it needs governance?

  2. b)

    Whether – if the organisation has a general approach to governance – the project in question has any special governance requirements?

  3. c)

    If so, what are the requirements?

In our view, the findings show that governance sometimes needs to be challenged and ‘shaken up’. It may require investment and work to ensure senior management commitment, as well as an injection of governance skills, and possibly even articulation or re-articulation of governance culture. Governance should also address IT strategy alignment and return on investment, as well as project completion.

For projects involving large customer databases, it is important to distinguish between IT governance and data governance – a very different topic that sometimes gets confused with IT governance. Data governance is a continuing need, irrespective of the state of IT development.

To help organisations determine their overall governance approach and the approach for particular projects, we have produced a checklist of the points that companies should review in determining their approach to project governance. Typically, these should be used by the IT department as part of its management development process, to train project managements and senior IT and user managers, and in the business and project planning processes of the IT department (by identifying the importance of each factor to the company, and the need for action).