IT Governance and Project

Original Article
IT governance and project

management: A qualitative study
Received (in revised form): 9th February 2009
Dev Sharma
leads the Delivery Practice at WCL, helping clients improve their overall efficiency, the effectiveness of their delivery and how
they use their IT systems to support these objectives.
Merlin Stone
is a leading author and advisor on CRM programme management and implementation. He is Research Director at WCL, one
of the UK’s fastest growing management consultancies, Professor of Marketing at Bristol Business School and Visiting Professor
of Marketing at a number of universities, including Oxford Brookes.
Yuksel Ekinci
is a Reader in Marketing at Business School in Oxford Brookes University. He specialises in quantitative data analysis, customer
satisfaction measurement and user satisfaction with CRM.
ABSTRACT This paper presents the results of a qualitative study of information

technology (IT) project management and governance. Interviews were carried out with
10 senior managers in different organisations who had been involved in major IT
projects. It follows on from a study carried out by Stone, Ekinci and Foss concerning
success and failure in customer relationship management (CRM) system implementation.
For this research, the net was cast more widely than just customer-focused projects,
because of the need to attract respondents who had recently completed major systems
projects. Most of the projects included the customer as a main focus, however. In
writing this paper, we have also referred to our experience of involvement in CRM
projects. The results supported the idea that project governance and project
management are closely related but not identical. A company may have good project
management, but not good project governance. Governance of IT projects is of course
facilitated by having experienced, well-trained senior project management, and by the
organisation having an established methodology for managing projects. The paper
identifies that project management is not, however, enough, and that project
governance and IT governance in general may be weak even if the project management
is strong. 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. The paper supports the notion that
focusing on project governance increases the chances of better project delivery. This
seems to be a better strategy than risking accidental success.
Correspondence:
Merlin Stone
Journal of Database Marketing & Customer Strategy Management (2009) 16, 29–50.
WCL Office, 83 Victoria doi:10.1057/dbm.2009.6
Street, London
SW1H 0HW, UK
E-mail: merlin.stone@
w-c-l.com,
Keywords: information technology; project management; governance; risk; systems
Web: www.w-c-l.com implementation; systems strategy
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
www.palgrave-journals.com/dbm/
Sharma et al
INTRODUCTION minimising corruption, abuse of power, and

In a paper published in 2008, we explored providing managerial accountability in both
the reasons for customer relationship private and public sector organisations.
management (CRM) system success and Where IT projects are concerned, IT
failure.1 Since then, we have broadened governance and change management are
out our research programme, to include closely related. Change management is a
coverage of major systems projects with structured approach to moving individuals,
some focus on the customer or stakeholder, teams and organisations from a current state
even if they are not ‘pure CRM’. One of to a desired state in a number of phases,
the central topics that came to our attention which ensures a successful and sustainable
during this broadening was the question outcome. In the same way, IT governance
of information technology (IT) governance, is also a continuing process rather than a
and thus we decided to carry out a small one-off project that requires continuous
study focusing on this topic. changes. In a complex IT environment,
IT governance is the process and relatively simple changes can a have a large
structure that ensure that organisations effect on higher-level business processes,
deploy their IT investments appropriately and thus change management tools become
to ensure that the resulting activities – essential to the IT governance process.
whether programmes, projects or operations Typically, IT governance process design
that they fund – are carried out properly starts with an IT governance plan. This
and achieve the desired results.2,3 is followed by its implementation and
Governance covers many different aspects the assessment of the results against the
of IT management – the principles of IT desired outcome. Further changes and
strategy and their relationship to your implementation of the revised plan may
organisational strategy, the architecture(s) be necessary in order to ensure continuous
upon which organisations base their IT improvement. The objective of change
and the extent to which it is integrated management in this context is to ensure
and standardised, an organisation’s policies that standardised methods and procedures
towards IT infrastructure, its organisational are used for efficient and prompt
applications – including how it diagnoses handling of all changes to controlled IT
and fulfils organisational needs, and its infrastructure. There is no standard solution
financial investment in IT. Governance for IT governance, but change management
covers all the assets that may be involved disciplines should be adopted early on
in IT, whether human, financial or physical, in the governance cycle, to support the
or data or intellectual property. development of a comprehensive IT
IT governance is an essential component governance programme.4
of corporate governance. Corporate In recent years, IT governance has
governance relates to how (customers, attracted much more interest from
processes, policies, laws and institutions) practitioners, management consultants
a corporation is directed and to how and academics, and has become the
different stakeholders (directors, managers, responsibility of the board of directors and
shareholders, staff, suppliers, customers, executive management, partly because of
banks, and so on) work with each other the costs and risks of developing IT, partly
to achieve corporate goals. Although because of the knock-on effect of failures,
corporate governance is implemented and partly because of the much wider
through different models, good corporate applications of IT in organisations and
governance allows organisations to work its strategic importance because IT has
productively and efficiently while shown to support, sustain and grow the
30 © 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
business. As suggested by Nolan and — Costs rise beyond what is budgeted,

MacFarlane in their Harvard Business Review and unless the programme, project or
paper, as more and more organisations operational capability is protected, it will
change marketing tactics and other firms have to be descoped in order to remain
choose to adopt new technologies to stay within budget. Even if the budget is
ahead of the competition, board-level increased, the problems caused by the
technology has become increasingly rising costs and slippages may never be
important. Despite the fact that corporate solved, so that the resulting programme
information assets can account for more is weak as well as late.
than 50 per cent of capital spending, in — When management confidence is lost,
managing the governance of IT, many the programme may be cut dramatically,
boards used to apply a set of tacit or to focus on minimal deliverables; it
explicit rules shaped from what they may then be gradually rebuilt over time
perceive to be best practice of other firms. as confidence returns. Meanwhile the
Today, however, it is clear that in most organisation will have suffered.
large companies, the board is now involved — User departments suffer budget
in IT decisions, and that the board freezes until the programme starts to
expects tough governance standards to deliver again, and thus cannot provide
be applied to major projects by senior alternatives or progress elsewhere.
IT management.5 — Final solutions are often extremely
The aim of this study is to investigate scaled down, or are completely
applications of IT governance in written-off.
organisations in the UK, specifically as — Success tends to be accidental, rather
applied to IT projects, rather than overall than delivered with intent.
IT spend.
Good governance results in a framework for
BACKGROUND OF THE STUDY accountability for taking and implementing
IT decisions and for obtaining the desired
Why is IT governance important? results from them. The main attributes of
Most organisations depend critically on the good governance include
successful deployment of their information
and communication systems, to help them — an organisational strategy that is set
deliver efficient and effective operations out so that its IT implications can be
and to achieve the changes they need in identified clearly;
order to translate strategic plans into actions. — clear assignment and governance of
Too often, organisations focus on their IT internal resources;
strategies, policies and budgets, failing to — board sponsorship of, ownership of
recognise that without good governance, and involvement in governance policies;
these are unlikely to be translated into — clarity, quality, consistency and
the desired results. If IT is not governed measurability of governance;
properly, things can go badly wrong. — encouragement of behaviours and
For example internal/external relationships that
support your governance policies;
— Issues and problems are buried and stay — application of governance to external
buried. suppliers as well as to internal activities;
— By the time problems emerge, it is often — appropriate use of shared governance
too late to address them properly, and structures, including main board,
thus programmes and projects slip. executive board, audit committee,
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50 31
Sharma et al
change programme boards and internal — management of human resources and

and external auditors. teams, including incentives;
— management of knowledge relating to
The key questions an organisation needs to IT project, programmes and operations;
answer if it is to achieve good governance — purchasing and supplier management,
are as follows: including staff validation and
performance review;
— Does the organisation understand the — programme, project and process
meaning of governance and the need management and review;
for it? — technology and data management;
— Is governance part of the IT strategy — development and deployment processes
and plan? for policies, systems, and so on, including
— Who owns and who manages usability and stakeholder/user acceptance;
governance? — benefits realisation and measures;
— Who are the stakeholders for — governance ownership, accountabilities,
governance? structures and processes;
— What value do they derive from — problem/issue/risk forecasting,
each programme, project or operations management and resolution;
capability that is the focus of — review management.
governance?
— What are their needs for good For projects of long duration, that is, years
governance? rather than months, frequent review is
— What are their accountabilities in sensible – during development, deployment
governance? and benefit exploitation.
— How does internal and supplier One of the key challenges faced by
programme self-assurance take place, organisations is to answer the question –
and how is it audited and reported? how much IT governance is required?
— Who should manage it (that is ensure Sambamurthy and Zmud6 suggest that
that it takes place and is productive key determinants of IT governance can
and adds value)? be classified into three broad categories:
corporate governance, economies of scope
and absorptive capacity.
How can you ensure good
governance? Corporate governance
The only way to do this is to ‘govern Organisations committed to strong
your governance’, by ensuring that you corporate governance do so partly to lower
regularly review the governance process, their organisational coordination costs.
particularly if you experience problems Also, the mode of corporate governance
that seem to be due to weak governance. strongly influences the mode of IT
This involves reviewing the following: governance. Firms that centralise corporate
governance tend to centralise IT
— involvement and accountability of the governance, whereas firms that have
board/senior management; decentralised their corporate governance
— accountability for innovation; tend to decentralise IT governance.
— strategy, planning, financial cases/returns;
— change capability assessment and change Economies of scope
management; Economies of scope are benefits accruing
— quality of processes, outputs, and so on; to an organisation when it is able to share
its resources across multiple goods/services Defensive strategy establishes how much
(for example, reducing cost due to the organisation relies on cost-effective,
better synergy). They often arise from uninterrupted, secure, smoothly operating
the sharing of knowledge and distinctive technology systems. It relates more to
managerial competencies. This relates to operational reliability. Offensive strategy
absorptive capacity. establishes how much the organisation
relies on IT to gain competitive advantage
Absorptive capacity through systems that provide new
This refers to the ability to value, assimilate value-added services and products or
and apply new knowledge. It demands high responsiveness to customers. It places
knowledge and communication and partly strategic issues either at or above the
determines innovation performance, same level as reliability. Offensive
aspiration level and organisational learning. IT projects tend to be ambitious and
The theory was first introduced in 1990 risky because they often involve significant
by Cohen and Levinthal.7 Two concepts organisational change. Figure 1 shows the
related to absorptive capacity are as follows: IT Strategic Impact Matrix and the four
involvement modes.
— Receptivity: Awareness of, identification As can be seen from Figure 1,
of and taking effective advantage of organisations’ engagement with IT
technology. governance varies according to four
— Innovative routines: Practised routines strategic modes: factory mode, support
that define a set of competencies an mode, strategic mode and turnaround
organisation can use confidently and that mode. Depending on where organisations
are the focus of its innovation efforts. locate themselves on the matrix, IT
governance may be a routine matter best
Where IT governance is concerned, the key handled by the existing audit committee
issues are how strong and well articulated or a vital asset that requires intense
corporate governance is, how it translates board-level scrutiny and assistance.
into IT governance, how both are deployed What board members need to know
over the whole organisation, and whether about IT activities depends on the firm’s
it knows how to use IT governance to strategic mode, as well as firm size, industry
support innovation. and competition. Both the factory and
According to Nolan and McFarlane, support mode are extensions of defensive
IT governance decisions should be based marketing strategy. Organisations in factory
on four involvement modes, shaped by two mode need highly reliable IT systems to
types of strategies: defensive and offensive.5 run operations smoothly and constantly,
Defensive Offensive
High Factory Mode Strategic Mode
If system fails for a minute or more there is New system promises
Need for an immediate loss of business major cost reductions
reliable IT Support Mode Turnaround Mode
Even with repeated service interruptions of IT is more than 50% of
Low up to 12 hours there are no serious capital spending
consequences
Low High
Need for new IT
Figure 1: The IT Strategic Impact Matrix.

Source: Nolan and McFarlane5.
Sharma et al
for example airlines. They do not need also understand and manage the risks
state-of-the-art computing. Those in support associated with implementing new
mode depend less on IT, as they have less technologies. The IT Governance Institute
need for reliability and for strategic IT – suggests that the enterprise’s challenges
they will not suffer terribly if a system and concerns include the following5:
goes down for longer periods. From an
IT project perspective, this means that — aligning IT strategy with the business
it may be better to delay problem projects strategy;
until they can be perfectly or near-perfectly — cascading strategy and goals down into
implemented. the enterprise;
Organisations in turnaround mode — providing organisational structures that
heavily rely on new IT systems that promise facilitate the implementation of strategy
major process and service improvements. and goals;
Here, technology typically accounts for a — insisting that an IT control framework
high percentage of corporate expenditures, be adopted and implemented;
and all the manual systems are transferred — measuring IT performance.
into the new IT system. At the same time,
firms have a comparatively low need for Selig states that effective IT governance
reliability when it comes to existing is built on three critical factors:
business systems, and they can withstand (1) leadership, organisation and decision
repeated service interruptions of up to rights; (2) importance of flexible and
12 hours without serious consequences. scalable processes improvement; and (3)
Organisations in strategic mode favour total the use of enabling technology. The process
innovation as their main business principle. of IT governance starts with setting clear
New technology informs not only how objectives for the organisation’s IT in
they approach the marketplace, but also order to provide the initial directions.
how they carry out daily operations. Like This is followed by strategic planning
turnaround firms, their IT expenditures are and execution of the IT objectives. The
large. According to Nolan and McFarlane, implementation of the IT governance
not every firm wants or needs to be in strategy, policy and action plan will ensure
this mode, but some are forced into it by that IT governance is managed more
competitive pressures, for example if they effectively. A continuous loop is then
fall behind more competitors who use established for measuring performance,
information systems as the cutting edge of comparing it to objectives, leading to
innovation. From an IT project perspective, redirection of activities and changed
this means that it may be better to objectives where appropriate.3 A solid
complete a project even if it is not perfect. foundation for IT governance is published
best practices and guidelines, for example
Organisational responsibility Control Objectives for Information
for IT governance and Related Technology (COBIT) and
IT governance is usually implemented at The Code of Practice for Information
different layers of the organisation. Leaders Security Management (ISO 17799).8
report and receive directions from their
managers, and managers report up to the Our research
executive, and the executive to the board of To explore how IT governance is
directors. Although many organisations implemented in British organisations, we
recognise the potential benefits that decided to do some qualitative research.
technology can achieve, the successful ones We interviewed senior managers in
10 organisations about a recent large IT 8. What were your main learnings from the
project, in terms of how to manage the
project in which they had been involved. The project and deliver it on time, relating to
respondents were one national retailer, five your people, and your stakeholders and
financial institutions, one regulatory authority, suppliers?
9. What was the role of IT and business consultants
two central government departments and in the project? What was the main contribution
one information services provider. they made? Were there any specific weaknesses,
and what did you learn from this?
The respondents ranged from middle 10. Were you following any particular professional
management to the most senior standards or methods in the definition or
implementation of the project? If so were the
management. Two were Chief Technology standards useful or a hindrance?
Officers/CIOs or equivalents, one was a 11. How if at all were your senior managers involved
in the project? Do you consider that your
Director of IT Transformation, and one board of directors or equivalent was sufficiently
managed relationships with internal engaged? What more could they have done
stakeholder, one with suppliers, while the to ensure success?
rest had more specialist roles. Some had Section 3: Governance

been in IT for many years, while others 12. What was your general governance approach
to the project?
were relatively new to the discipline. 13. Did you have a governance budget, and if
Most had been extensively trained – some not, why not? Did you use a particular
externally or internally developed governance
at university level – in project management, framework?
while others were involved in project 14. Was any particular software used to support
the governance process? How was
management through another role. organisational accountability allocated?
15. What was the role of any of suppliers in
We asked them the following questions: governance? What was their contribution
of knowledge of about typical risks of such
projects? Did they share risk? How did they
Section 1: About you participate in reviews? What did they do well
and what could they have done better?
1. What is your role? 16. Were rules and rights drawn up for those
2. How long have you been in it, and what roles involved in the project, either in delivery or as
did you hold before? stakeholders?
3. What is your experience of project management? 17. How were project requirements gathered and
Have you been trained in it? validated, and what governance process was
used for maintaining and controlling these
Section 2: The project requirements?
4. What was the most significant large IT 18. How was alignment with business objectives
programme that you have undertaken in the last and requirements secured?
5 years and what did it involve? What were the 19. Who determined the change management or
objectives, scope and focus of programme, what project management approach and how was
resources were required, which suppliers were this implemented?
involved, what contributions were they supposed 20. What was your project budgeting approach and
to make, what organisational activities were how was it governed?
supported by the project and what benefits were 21. How were governance metrics determined?
expected? 22. Who determined and then implemented criteria
5. What was the duration and cost of the for prioritising projects and activities and
programme? If it is still running, what is the making decisions?
expected cost and duration of the programme? 23. How did you review progress?
If the programme is completed, what was 24. How were risks identified and managed?
the cost and duration compared to the plan? 25. How did you undertake problem analysis
6. What was the split between IT and other costs, and resolution?
for example, people costs in other departments, 26. What were your governance processes to
on the programme and within IT, between ensure application of accountability, processes
hardware, software and implementation? Did and criteria?
the costs turn out as expected?
7. Who were the main stakeholders in the
programme? What contribution did they make
to the programme and what benefits did they
expect and get? How did you keep stakeholders FINDINGS
informed about the progress of the project, The questionnaire was completed via
and any problems? What process did you have
in place for getting feedback from stakeholders face-to-face or phone interview. The main
as the project progressed? points that emerged were as follows.
Sharma et al
The projects governance approach, attending programme

These were very varied. One involved board meetings. Suppliers were not,
developing a system to sell the product of however, invited to all meetings.
another large financial institution, which Communication was a problem:
had very stringent security requirements.
Suppliers delivered on time and to budget but
The retailer’s project aimed to replace its could have communicated better (particularly
back-office systems and business processes with regard to issues and problems.
and implement an Enterprise Resource
Panning (ERP) system. One government Suppliers were not open about programme
project was to manage the authorisation, level risks but were better at code level risks,
control, accountability and assurance for though they were good at coming up with
European funding being distributed to mitigating actions for the risks the client
projects within regions, including the identified.
development of new business and financial One mentioned in particular the need for
processes to transfer roles from centre to the suppliers with ‘fierce attention to detail’. The
regions. Another financial project involved same respondent mentioned that the IT
the development of a completely new supplier was deemed not to be a necessary
point-of-sale system. Another involved member of the main project board:
development of a new credit-modelling
system. The other one related to improving Suppliers’ input into the project management
access support. The regulatory authority’s process had often been too detailed, and that the
system was developed to centralise data on suppliers should have considered more carefully
the audience for the information they were
all transactions carried out by regulated
bringing or sending to the main project board.
companies. One was the replacement
of a bank’s core banking platform, another The above findings highlight the
bank developed a platform to integrate importance of a number of communication
finance and risk. factors. A key part of good project
management is that the different parties
The suppliers agree what is to be communicated, to
The suppliers used varied. In one case, whom, how and when, and at what level
there were two major change partners: of detail. IT projects are generally very
one a partner who combined two roles – complicated, and thus too much or too
business change partner and a software little information can cause problems to
implementation partner – and the other an be obscured. Where project governance
infrastructure partner. In another case, a is concerned, a central part of good practice
large software developer was developing is ensuring that the significance of the
the software. Another only used in-house information that suppliers and clients pass
development as a matter of policy. Another to each other is appreciated by the other
used a large system implementer who party. It is not enough to hide behind the
was the prime contractor with a number lame excuse ‘we did tell/warn you’. Where
of sub-contractors, for delivery and information indicating serious problems
hosting. Another outsourced most of its or risks is concerned, the true partnership
modernisation work to India. Another used that should exist between supplier and
a mix of in-house, partner and external customer should lead to each party
development. One used a mix of IT and checking that any such information has
business consultants. not only been received, but also that its
The suppliers were in some cases an significance has been understood and that
integral part of the project management and it has been acted upon.
Budgets and timings who later moved on to other responsibilities.

The projects were all large, ranging from All this moving around destroyed trust and
£0.5 million to nearly £30 million, communication, led to a lot of rework,
although several respondents pointed out re-evaluation and often reduced budgets.
that the total commitment was hard to
Senior management must be involved from
quantify, for example because part of the
the beginning.
effort was effectively business as usual, or
because of the involvement of non-IT If senior executives involved in a project leave
resources. IT costs varied as a proportion of half-way through, it may be worth ‘turning the
all costs, from being most of the cost to less clock back to reposition the whole project’, as
than 10 per cent. Most project budgets and otherwise there may be severe problems with
timescales were adhered to. Timescales were the project, ranging from lack of understanding
typically 1 to 2 years, but one was 3 years to lack of stakeholder commitment.
and one was 5 years. In two cases, the
Thus, for project management and
advent of the respondent as a new project
governance to work in projects of longer
manager had led to a great tightening up of
duration, new personnel, particularly
a previously slightly lax budgeting situation.
senior personnel, need to be fully briefed
The long duration of projects clearly
on project management and governance
puts project management and governance
processes, and warned against changing
processes under stress, for reasons associated
project specifications.
with stability of the team, as we describe
in the next section.
Stakeholder involvement and
Involvement of senior managers governance
All respondents realised the importance of The main stakeholders in the programme
senior management involvement. Some had were the heads of the user department,
problems with achieving the desired level although in one case where the systems
of engagement and had to work hard at it. involved interface with the other companies
system, the stakeholders included the
We set up a sponsoring group, including equivalent senior user from the partner
executive management within the partner organisation. Most projects had a strong
organisation, and used this as our governance approach to governance – which is not
approach, with all projects reporting to the group.
surprising, as we were looking for good
Some respondents, however, had examples. In two cases, it was tiered, with
experienced the problem of ‘musical chairs’ meetings at regular intervals for each level,
among senior management. with clear escalation procedures. In some
cases, the governance approach was based
We had five changes in the senior user
manager during the course of the programme.
on PRINCE ideas.9 Regular meetings of
different stakeholder groups were the norm.
Another respondent said that this was a There was high awareness of the need for
very good reason to get projects done what one respondent called a ‘robust and
quickly. rigorous process’. Companies used a mix
The involvement of senior managers of progress reports, highlight reports,
had interesting consequences: newsletters, bulletins and video conferencing
Senior management insecurity about the to communicate with key stakeholders.
project led to the involvement of too many Performance criteria were generally clearly
consultancies. A significant problem was the specified and reported upon. One public
lack of vision by a key sponsoring director, sector respondent put particular emphasis
Sharma et al
on the importance of e-mailing the wider We had to ensure that we devoted adequate
group of stakeholders (which included business resource to support the workload,
a variety of public and third-sector clarifying requirements, testing etc, right across
organisations) when there was something the project lifecycle.
significant to update them on.
We focused on getting the right people to
Process was important:
do the right things; getting buy-in to plans;
We have a joint IT-business planning process, getting the contract right for all parties and
directed from the Board to drive operating ‘putting it in the drawer’; agreeing on the
planning. It requires submissions from all terms of reference for all stakeholders.
departments including IT. This planning
One respondent identified that the informal
group agrees on priorities and develops a
balanced portfolio.
way people would commission work was
a problem.
We use a steering committee approach, with There were too many informal projects going
a Project Review Board (the top sixteen on that were not part of the project tracking
managers in our company). We use audit to and resource management process, and this
identify irregular attendance at this board. caused problems in resource management.
No respondents allocated a separate budget Having an independent viewpoint was
to governance (other than a budget for important:
project communication).
An independent project management
It seems that companies with strong
organisation is key. If an external contractor
awareness of the connection between is used to develop a particular part of the
project management and stakeholder deliverable, it is important to ensure that that
management were more satisfied that their project be managed by another company.
governance approaches were robust.
Stakeholder management is a relatively Methodology was also important:
new management discipline – although it We used a strong project management
has long been part of communications disciplines (based upon PRINCE), from the
management – whether in public relations very earliest days of set-up, particularly where
or human resources. It has recently emerged it came to identifying roles and responsibilities.
as a very important discipline in the
The value of the rigour introduced by such
public sector, which is ahead of the private
methodologies was a common theme, and
sector, where it is conventional to break
the importance of weekly reporting on
it up into the management of different
deliverables was stressed. The difficulty
communities, for example staff, customers,
of managing risk and the difficulty of
owners and other departments.10
embedding learning from managing the
project into the company’s culture were
Project management and also identified.
learnings One respondent mentioned the learning
Some of the main learning points from from another project that had gone less
the projects related to governance and well:
the deployment of resources to achieve
The learning from the clear project
the desired outputs:
management approach adopted for this
Simply recognising the work as a formal project (the subject of the interview) was not
project was key. transferred. However, we now have a change
manager, with the duty of ensuring that all
A strong focus on delivery was essential. projects are well managed.
Stakeholder relationships were key: including project structure and the people
involved. Others had formal terms of
Our main learning was about the management
of relationships. What made the project work reference for everyone involved in the
was the strong relationship between the project, including stakeholders, delivery
business team and the IT development team. teams and governance.
Focus was generally maintained on
The response was clear-cut across the objectives, rules and rights through constant
respondents – all used structured project engagement of business stakeholders, regular
management methodologies and associated project meetings and frequent sign-off
software, whether PRINCE, another public points. One respondent, however, voiced his
software or one proprietary to their doubts, mentioning that he was not sure
company. Another respondent identified that his business appreciated that there was
the importance of not underestimating a problem that needed fixing. He described
how long it would take to work through his company’s change management process
user acceptance testing, and of accepting as ‘complex’.
that this might delay a project. We have already discussed the issue of
One respondent learnt how to deal with communication above. This section highlights
the offshore supplier. ‘They always said Yes, but the importance of a framework within
this actually often meant ‘No’ or a ‘Yes but….’ which the communication should take place.
So from Mid Development onwards we
added 30 per cent to all of their estimated
timings’. Another respondent pointed to the Gathering project requirements
importance of tracking consultants and other This process seems to have been thorough
external suppliers, to ensure that they for all respondents. Some used their
delivered their plans and promises.
The main conclusion from this part of the tiered governance structure as the channel.
research relates to the importance of broad Several had formal phases in which user
awareness that project management and requirements were gathered and then
project governance are significant worked on by technical teams and with
management disciplines, which are both business users, and signed off by senior
essential to the successful management of managers. One respondent stressed that
large projects. They are helped by the use of getting project participants to map out
standard project management tools, but these requirements, process flows visually and
are the start point, not the end point. compare them with the existing situation
Stakeholder management is key, as we have was critical to success.
already mentioned, but so is a stable We engaged stakeholders, through ‘heavy duty
approach, and a proper balance of incentives. process mapping’ to understand the relevant
processes and how to change them.
Objectives, rules and rights,
project charters In a large organisation like ours, gathering
requirements is very hard – with subject
One respondent mentioned that the project
matter experts and many different stakeholders
did have a project charter. Another had a needing to be consulted, requiring a full time
project delivery method that included person just to book diaries, set workshop dates,
specification of these aspects of the project. book locations all over the country and make
One had this just for the board of directors, travel arrangements, just to make sure right
but not for stakeholders. One respondent people were working together. If people don’t
referred to the way in which his company turn out, they are unhappy about decisions
drew up terms of reference for the project, and want to retake them. However, once the
Sharma et al
requirements were gathered, we had very clear organisation moves on, requirements change,
version control, including final sign off at every and thus change management (and its
stage by our senior sponsor (CFO), who was governance) becomes particularly important,
supported by a full time project manager. especially in long-duration projects.
Several mentioned the importance of
change control, and one stressed the Project budgeting
importance of tying contractual change In general, the approach followed here was
control to budgets. highly structured.
The software chosen can pose a choice:
There were budgets for each key activity, with
It is critical not to modify the package to fit costings provided for changes, while costings
processes but rather to do it the other way were owned by the project office and reported
round. Many of our processes are ‘commodity’ in to the board. Our finance director was on
and could be changed and improved through the project board.
the package. However, this led to a different
question – where does a company like Costings were governed by business case
ours differentiate itself where it concerns submission based on their business case scope
processes? Some processes must be kept review and driven by priorities. The steering
as differentiators or sources of competitive committee authorised the budget and changes.
advantage.
Formal estimating of costs (including supplier
This area is one of the most critical in all costs) was carried out for all workstreams,
complex projects. Requirements cover a including provision for cost changes during
very wide range of topics, from technical programme life and an overall risk buffer,
which was different for different workstreams.
requirements that concern only IT staff,
to the functional requirements of users, Costs were reported weekly to the programme
through to usability requirements, which board.
determine whether useful functions end
up being used as they should be. Projects This was not, however, always so:
in marketing, sales and service often involve
Costing was more of an art than a science,
two groups of non-specialist users – staff and it was not always clear where the money
who interface with customers and was coming from.
(increasingly, because of self-service) the
customers themselves. Customers are Thus, while organisations may have good
rarely asked about their requirements. formal cost control, this may mask some
Non-specialist staff may be asked about uncertainty as to how much is being spent
them but may not be able to articulate, and where it is coming from. The authors’
still less anticipate, the requirements that experience of major CRM projects
they may have in the future (and as we confirms this. At a high level, budgets may
have seen, it may be between 2 and be reallocated from marketing or customer
5 years before a system for which the service to systems if the project is exceeding
requirements are being gathered is its estimated cost. Project costs may be
implemented). Thus, the term ‘requirements hidden by reallocating staff formally
gathering’ must not be interpreted as working under other budget codes. This
‘gathering objective requirements’ – much should not, however, be regarded as ‘bad
judgement, interpretation and insight is practice’. Few large systems projects have
required to arrive at a set of requirements the luxury of perfect predictability –
that will truly meet the needs of users whether this relates to development
when the system goes live. Similarly, as the activities or costs. It is natural that user
departments that are anxious to see the separate metrics other than normal project
completion of ‘their’ system do what they progress metrics, or simple box-ticking
can to expedite its completion, even if exercises. There was one star exception:
it means that some other activities suffer.
We applied corporate governance metrics
A user department must make its own along with CMMI (Capability Maturity
judgement about its priorities. Perfect Model Integration).
budgeting and innovation rarely go together.
In one case, the respondent taking up the
Governance role of manager of the project led to the
Where governance to ensure the application introduction of different metrics.
of accountability, processes and criteria This does not necessarily indicate poor
was concerned, some respondents said that practice. Good governance is primarily
this took place through normal project a cultural phenomenon, which cannot
management and board management be measured simply, for example solely
processes. In some cases, however, a tougher by complying with a checklist. This is
approach was needed: similar to our view that good customer
management is the result of the interaction
Our internal audit function was involved, to keep of many factors.11 We would, however,
people ‘honest’ and to ask difficult questions.
certainly argue that an assessment process
The project steering committee provided a
can be developed for governance – our
governance pack for the capital expenditure checklist at the end of this paper indicates
committee and the company Board. When its possible components,
a project was approved, accountabilities and
involvement were reviewed. Project prioritisation
Project prioritisation was handled in all
In one company, however, there were no companies within projects by their project
processes for this, and another had management and/or business planning
difficulties: framework.
This was a tough area, with appointments Priorities between projects are down to
to the governance board being based on individual business units, and then requirements
the organisation or department for which become part of the wider set of business
they worked and their role, rather than their requirements for IT, for which priorities are
capability to be board members, so sometimes discussed and set at the CIO level.
we had a skills mismatch.
Overall prioritisation is a board matter.
Our main learning was the need to shake up
governance regularly. We also needed to get The good news here is that all respondents
the right balance between academic/research indicated that they had a framework for
work and ‘real’ project work that produces prioritising projects. This is a fundamental
deliverables. The mix was wrong at the component of good governance.
beginning of the project, with not enough
delivery, and this hampered the project
manager’s attempts to engage some important Project reviews
stakeholders. We had problems with control Generally, project reviews were weekly,
too – it was frustrating to have project with various techniques used for identifying
managers working for me that did not belong
success and problems, such as RAG
to my organisation.
(red-amber-green) scoring, highlight reports
In some cases, respondents admitted that and slips against milestones identified
they had no metrics for governance, or no in the project management software.
Sharma et al
The seniority of those involved in weekly would have made things better, and given
reviews varied. us a better capability to respond.
The interesting point here is the Our conclusion here is that the
frequency of reviews – which was high. independence of consultants is valued,
This suggests that companies have learnt although companies are wary of the costs
the risks of infrequent reviews. and the introduction of self-interested
agenda. In our experience over more than
Role of consultancies and 20 years, clients that place everything in the
other externals hands of consultancies and those that place
Most companies did not use consultants. nothing in their hands take large though
Where they were used, the experience dissimilar risks. Refusing to use consultants
of using consultancies was generally shuts the door to the introduction of
positive. experience from similar projects. Some
clients believe that they can overcome this
Consultants introduce experience to the
by hiring people who have implemented
planning process – the consultancy we used
asked each workstream to develop an initial similar systems in other companies, but in
plan and then pulled the plans together, our experience these people may become
challenging inter-dependencies and allowing absorbed in their particular roles in the
cross-workstream challenges. The consultancy project, so that they cannot contribute
also chaired the workstream meetings, and their full experience. In addition, the
developed a matching governance structure. experience of one similar implementation
We had a consulting partner who really is not as valuable as experience of many
did have the required breadth of experience similar implementations. At the other end
and resources to handle the project. of the spectrum, giving consultants too
Many consultancies claim that they have great a role in project implementation and
more experience and capability than they
governance can increase costs – not just
actually have.
because of higher day rates, but also
We used consultants for their specific business because of expansion of the consultants’
expertise and technical knowledge, plus role. A golden mean is of course the ideal
support. approach, but in the fray of a large project,
it is usually hard to know where that
The experience was not, however, always golden mean is.
positive:
We used an IT consultant (expert in our
Change management approach
development environment) to improve
the company’s testing capability, and three Here there were two main approaches.
contractors to work on business acceptance. Some companies had a standard change
These consultants absorbed quite a lot of management approach, with prescribed
time as they were not familiar with either tools, documents and templates covering
us or our systems. configuration and change management.
Others did it through their own efforts
In some cases, the major management and/or through appointing experienced
consultancies were closely involved in the project managers.
governance approach, perhaps sitting on The discipline of change management,
project boards. One respondent, however, which is much wider than project
commented: management, is becoming more widely
Suppliers were not sufficiently open quickly understood, but still has some way to
enough. More transparency and openness go. We look forward to a time where it
is regarded as a normal and constantly we escalate the problem so as to get resources

used discipline. allocated.
Risk and problem management The key is to get the right people in the
and resolution room together to thrash out a solution.
Most companies covered risk and problem
management and resolution through We identify problems and resolve them in
normal weekly team meetings.
their change management and project
management processes (in particular regular Our three biggest problems are scope creep,
project meetings), though one respondent project management skills, and estimating
identified that it was difficult where business timings for different elements of the
partners were involved. Typical risks project plan. So I have appointed a software
identified were where stakeholders changed, development manager, with whom I work very
where projects were very large, and where closely in estimating timings, or in checking the
system usage was low and affecting timings that the development team proposed.
performance. In fact, as one respondent This does lead to the occasional mistake, but the
stated, usage can be too high or too low key is to ensure that we learn from them (eg
(for given tasks), and thus it was important identifying one particular manager who always
to model this. Another respondent identified said things were on track when they were not).
the importance of planning for mitigating We were pleased to see a relatively high level
risk at project planning stage. Good practice of maturity in risk and problem management.
was exemplified by several respondents: Too often, risk management is given lip
service. Particularly dangerous is weak
We have a standard risk management approach
communication, as we have already identified.
of identifying owners of the risk, planning for
mitigation, identifying the cost of mitigation
actions and of bringing contingencies into CONCLUSION
place. This allows go/no go decisions to be Our research showed that most companies
factored into the plan well ahead of bringing that responded had strong project
in the contingencies. management approaches and strong, well-
qualified project managers, for the major
We keep a risk register throughout each projects that were the subject of the
project, running RAG reports on them. enquiry, and that respondents perceived
that these two factors were very important
We use a risk-based project management in ensuring successful project delivery and
approach, reviewed monthly.
in the successful governance of projects.
In some cases, the project management
We run risk workshops. For each risk
identified, we assign a budget for mitigation, to approach had been long established; in
be included in the overall project budget. The others it had been established as a result
budget is generated by a formula containing an of the efforts of the individual respondent.
estimated impact and likelihood and the costs The project management and governance
required to fix each risk. methods used by the respondents’
organisations helped them to cope with
Where problem analysis and resolution were most of the vagaries of their IT projects.
concerned, experiences and approaches A few problem areas stood out, however,
varied: such as coping with senior management
The key is to identify the issue first. Then we churn and ensuring that consultants and
use consultants for process mapping and skills other suppliers were managed appropriately.
transfer. If consulting resources are insufficient, These are two prime problem areas in
Sharma et al
project governance and IT governance, and Data governance is a continuing need,

thus the findings hint at a general weakness irrespective of the state of IT development.
in IT governance that might be infecting To help organisations determine their
project governance. overall governance approach and the
Our findings support previous studies approach for particular projects, we have
that suggest that successful implementations produced a checklist of the points that
of IT governance depend on senior companies should review in determining
management involvement (and constancy) their approach to project governance.
and good project management ability. Project Typically, these should be used by the
management, project governance and IT IT department as part of its management
governance are not the same thing, however, development process, to train project
and it is possible to have strong project managements and senior IT and user
management and weak project (and indeed managers, and in the business and project
IT) governance. Our findings also supported planning processes of the IT department (by
the idea that changing how projects are identifying the importance of each factor
governed played a significant role in to the company, and the need for action).
delivering success. This seems a better
approach than relying on accidental success. ACKNOWLEDGEMENTS
Whether this works or is advisable depends Our thanks go to Bryan Foss of Foss
on the stage at which this is carried out. Initiatives for reviewing parts of this
paper and suggesting some additions.
Management implications
The main implication for management REFERENCES
is that as soon as a major IT project is 1 Foss, B., Stone, M. and Ekinci, Y. (2008) What makes
envisaged, an organisation should ask for CRM system success or failure. Journal of
Database Marketing and Customer Strategy Management
15(2): 69–78.
(a) Whether it needs governance? 2 The IT governance institute. (2008). http://www.
(b) Whether – if the organisation has a itgi.org/template_ITGI.cfm?Section=About_IT_
general approach to governance – the Governance1&Template=/ContentManagement/
HTMLDisplay.cfm&ContentID=19657, accessed
project in question has any special 10 October 2008.
governance requirements? 3 Selig, G. (2008) Implementing IT Governance – A Practical
(c) If so, what are the requirements? Guide to Global Best Practices in IT Management. New
York: Van Haren Publishing, (ISBN 9087531192).
4 Jennings, T. (2004) Change Management: An
In our view, the findings show that Essential Tool for IT Governance. White Paper
governance sometimes needs to be Butler Direct Limited 1–18.
challenged and ‘shaken up’. It may require 5 Nolan, R. and McFarlane, F. (2005) Information
technology and the board of directors. Harvard
investment and work to ensure senior Business Review 83(10): 96–106.
management commitment, as well as an 6 Sambamurthy, V. and Zmud, R. (1999) Arrangements
injection of governance skills, and possibly for information technology governance: A theory of
multiple contingencies. MIS Quarterly 23(2): 261–290.
even articulation or re-articulation of 7 Cohen, W. and Levinthal, D. (1990) Absorptive capacity:
governance culture. Governance should also A new perspective on learning and innovation.
address IT strategy alignment and return on Administrative Science Quarterly 35(1): 128–152.
8 http://www.isaca.org/.
investment, as well as project completion. 9 PRINCE (PRobjects IN Controlled Environments)
For projects involving large customer is a de facto project management standard used
databases, it is important to distinguish extensively by the UK Government and is widely
between IT governance and data recognised and used in the private sector, both in
the UK and internationally. It covers the
governance – a very different topic that management, control and organiztion of a project.
sometimes gets confused with IT governance. PRINCE2 refers to the second major version of this
method and is a registered trademark of the Office project management or both, and
of Government Commerce (OGC), an independent
office of HM Treasury of the United Kingdom. scored them (A as critical, B as
10 For more on stakeholder management, seeStone, important, C as nice to have and D as
M. Semmens, A. and Woodcock, N. (2008) not relevant) based on our research
Managing Stakeholders in the Public Sector. Report
for the Public Management and Policy Association,
and experience for their general
September 2007 and Stakeholder Management and importance for each type of governance.
Engagement – Lessons from Public and Private Of course, their importance for a
Sectors, WCL. particular organisation may vary
11 For more on the assessment of customer
management, seeStone, M. Woodcock, N. and Foss, according to the type of organisation,
B. (2003) The Customer Management Scorecard. its general experience with projects
London: Kogan Page. and the particular project. The point
of scoring them is really indicative,
APPENDIX to stimulate readers into considering
how important the factors are for
GOVERNANCE TOPICS their particular situation, rather
In this list, we have classified the topics than to pronounce upon their general
as being important for project governance, importance.
The board Importance for Importance for

project management project governance
Awareness of past performance as a board, knowledge of results D A

of actions
Objective setting process, including core purpose (of organisation, D A

change programme, supplier), measures of success, financial case,
SLAs, and so on
Strategy – clarity, organisational and financial realism, D A

communication, allowance for risk, compliance
Innovation process with clear governance C A
Evaluation of programmes by risk/reward//urgency/timescales A A
Development of options, choice process/criteria, prioritisation A A
Clarity and comprehensiveness of frameworks for assigning D A

accountability and governance
Clarity and comprehensives of measurement frameworks A A
Process for debating, setting and monitoring service-level B B

agreements and monitoring possible conflicts between
efficiency and performance, within and between departments,
suppliers, and so on
Ability to describe governance structures and processes D A
Awareness of interdependence between different aspects of board D D

accountabilities, including policy interdependence and financial
interdependence
Adequate assignment and governance of internal resources D A

including directors’ (or other senior managers’) sponsorship and
involvement, organisational resources (eg requirements, testing and
deployment), funding, audit and risk management support
Understanding of sources of power and relative strength in the D B

organisation and how these can be transformed into advancing the
organisation
Sharma et al

Adequate attention to external requirements including supplies, D B
contractors, contracts, external risk management and other
dependencies
Appropriate use of shared governance structures including main D A

board, executive board, audit committee, internal and external
auditors
Lack of conflict of interest – internally and externally B A
Process for assigning governance, including identifying stakeholders B A

for it, identifying the benefits they should expect to be yielded for
properly governed activities, and their roles and responsibilities in
governance
Process for monitoring success of governance (ownership) B A
Clarity on how performance and financial measures are used B A
Capability to structure change management approaches B A
Capability to structure supplier management approaches B A
Openness to evidence on failure A A
Capability to manage recovery after failure A A
IT principles
Clarity of principles, for example, enterprise operating model (eg low D B

cost, customer intimacy, product leadership), speed of deployment,
focus on costs, flexibility, integrity, measurement approaches,
standards – technology and data, reuse, use of commodity products,
financial criteria
Clarity on decision-making principles for architecture, data B B

management and infrastructure – what capabilities and activities
should be standardised organisation-wide
Prioritisation of capability requirements and associated infrastructure C A
Plan and process for updating IT capabilities B A
Outsourcing principles B A
Approach to testing and piloting B B
Exception management A C
Ownership of IT change B B
Portfolio management of IT investments and management efforts B A

reflecting departmental/unit and overall priorities
Focus on asset utilisation C B
Organisation and processes
Structure for governance C A
Relationships and behaviours that support governance B A
Relationship between organisation-wide and departmental/ A A

unit-specific decisions and implementation
Existence of executive/senior management committee focused on C A

governance

Existence of IT leadership committee C A
Organisational process and change teams with IT members, and IT B B

teams with functional or departmental members
Relationship managers in IT and units/departments, teaming, internal A C

relationship management
Service-level and charge-back agreements between IT and B B

organisation/functions/units
Commitment to identifying non-conforming individuals and B B

departments and to gaining reform
Incentives for compliance, disincentives for non-compliance A A
Stability in governance organisation and processes over time, while A A

allowing planned evolution
Communication of and education in governance principles and B A

processes and their rationale, using all relevant means – Intranet etc
Regular planning processes incorporating review of governance, B A

including classic SWOT of current approach, given organisation-
wide strategy and operational requirements
Assessment of CIO and other top managers for their governance C A

performance (financial, service levels, value to the organisation,
management of process)
Quality/issue management
Quality plan B B
Processes for monitoring and testing quality B B
Process for logging and managing change and tactical requests, A B

including ensuring resources are not diverted
Agreement on quality metrics, and on how to revise them A B
Testing process management – functional and non-functional A B

requirements, usability, acceptance, beta testing, regression testing
(to ensure any problems resolved do not cause more problems),
performance testing (stress, load, stability, reliability), benchmark/
comparison testing, security testing
Involvement of users/stakeholders in defining quality requirements A B
Process for searching for issues/problems based on past history A A
Process for identifying issues/problems and documenting them A B
Process for resolving them and revising any downstream A B

dependencies and budgets, including escalation processes
Involvement of users/stakeholders in identifying and resolving A A

problems/issues
Process for revisiting resolution A B
Supplier management
Clarity of objectives or outcomes A A
Realistic expectations of deliverables A B
Sharma et al

Analysis of competence, quality, trustworthiness, motivations and A A
incentives of suppliers
Quality of contracts or contract management A A
Assurance (and self-assurance) of programme management A B
Assurance (and self-assurance) of working methods or application of A B

new methods
Identification and deployment of appropriate skills A B
Interlock of supplier’s work with work of rest of organisation (not just A B

deliverables but incentives and motivation)
Supplier selection process – including understanding supplier A A

profiles, development of clear set of criteria for assessing suppliers’
cultures, process for reviewing non-price or product issues
Ensuring staff actually involved in programmes, projects or A B

operational delivery are as promised at contracting stage, and
validated to have the required quality
Supplier segmentation – from strategic partners to tactical suppliers, D B

with appropriate justification
Coupling of purchasing management with management responsible B A

for downstream delivery, to ensure that downstream delivery
requirements properly taken into account in purchasing
Process for ensuring knowledge/skills transfer B B
Aware of own culture and tendency to gravitate to certain kinds of B B

supplier
Establishing values and incentives of suppliers and individual B B

players within the supplier (eg sales versus delivery) and
ensuring match with own – as applied to change and routine
operations
Process for taking up and challenging references (beyond those B A

provided), researching and probing successes and failures, awards
and legal actions, identifying who is supplying successful clients,
and who is supplying failures
Understanding the organisation’s specific needs and matching them B B

to supplier capabilities
Process (and associated governance) for managing problems and B A

issues before you encounter the first ones
Supplier relationship management process, agreed with supplier B B
Evaluating supplier capability – from listening to your needs, B B

understanding them, providing relevant propositions and solutions
and measuring delivery of them
Address the relationship before the event(s) which put the A A

relationship at risk
Conflict resolution process A A
Use of relationships and contracts to share risk and reward, B B

include ‘repeat game’ opportunity and recovering deliverables,
time and money even when the programme faces difficulties
or changes

Monitor performance with the supplier at all levels, using internal A B
audit and assurance capabilities with suppliers and programme
streams as required to increase delivery confidence and early
warning of issues
Benefits, outcomes and measures
Codification and sharing with staff the ‘core purpose’ of the B B

organisation
Aligning organisational purpose with customer’s perspective and B B

the benefits they expect and staff’s perspective and the culture and
values required for successful delivery
Clear objectives and outcomes for programmes and departmental A B

operation, with a logical understanding of what programme features
and work contributes to specific benefit delivery
Programme and operations definition fully interlocked with the B C

board’s growth and other primary objectives, and with their
documented personal responsibilities for organisational risk
management, to ensure that the board gives proper attention
Evidence-based assessment of management capabilities, capability B B

and experience (of staff, suppliers and customers/stakeholders)
‘gaps’ as a basis for the whole board to agree on a prioritised plan
with mutual allocation of resources and responsibilities
Clear set of supporting processes that ‘measure benefits to get B B

better’, rather than ‘measure transactions to get busier’
Tracking of investments and benefits over time A A
Management of programmes, projects and operational

delivery
Processes to define programmes/tasks and allocate accountability A B

for their design, management and success
Clearly defined objectives and scope, ensuring programmes, A B

projects and operational activities are split into packages of
deliverables with intermediate objectives, control over scope creep
Agreed formal tracking processes for different levels and stages of A B

projects and programmes
‘Objective’ assessment of past programme, project and operational A B

management performance – delivery, budgets, and so on and
learning from successes and failures
Clearly defined programme, project and operational management A B

processes with appropriate system support
Clear hierarchies of programmes, projects, portfolios and operational A B

delivery with interlock issues managed, particularly where major
programmes or projects may disrupt operational delivery
Processes for ensuring resource availability A B
Processes for assuring programme, project and operational delivery A B

quality (including self-assurance)
Process for milestone and checkpoint definition and management A B
Processes for identifying non-conforming programmes, projects or A A

operational delivery
Sharma et al

Processes for governance of contribution of external suppliers, B A
including self-audit if appropriate
Processes for ensuring and maintaining user/stakeholder involvement A B
Processes for recruiting, training and deploying programme/project/ A B

operational managers
Processes for building and managing programme, project A B

and operational delivery teams, based on requirements, skills,
capabilities, and so on
Validation processes for any programme, project or operational A B

delivery package definitions
Processes for involving externals in developing and implementing A B

governance processes where internal resources are not available
Processes for managing stakeholder/user expectations and A B

communicating with them
Processes for transferring to operations of any new developments that A B

are outcomes of supplier initiatives or internal programmes or projects
Involvement of organisational representatives, stakeholders, users A A

and suppliers in definition, prioritisation, trade-off etc of programme,
project or operational delivery requirements, the adoption (where
appropriate) of associated organisational change and the achievement
of objectives and outcomes (delivered benefits), including
methodology for managing trade-offs if all objectives cannot be met
Testing strategy for new services, systems, and so on, for example, A C
early walk-through and acceptance of documented requirements,
organisational logic, information flows, user requirements, user
acceptance testing for any changed facilities
Training and organisational change carried out in parallel to any C B

changes in specific functions, with final usability training deferred
just before deployment
Parallel development strategies for new services, functions, systems, C B

and so on
Processes for managing internal diffusion of innovations C C
Minimisation of dependencies is used wherever possible to de-risk A B

the critical path/s and enable unbundling or other organisational
trade-offs or changes to occur during the programme
Risk planning and management
Published risk plan that considers all significant risks including A A

external risks, major and minor programme risks
Risk plan reviewed at every programme board meeting A A
Allocating to board members individual and shared responsibilities A A

for risk management, documented and accepted within the annual
personal and board review processes
Internal and external professional assurance of programme and risk A A

management approaches
Specific review points (‘gates’) where internal and external A A

stakeholders get an unbiased checkpoint review
Process to ensure response to problems A A
Process for identifying and rescuing troubled/overspent/overdue A A

programmes

IT Governance and Project

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IT Governance and Project

Caricato da

Copyright:

Formati disponibili

Original Article

IT governance and project

ABSTRACT This paper presents the results of a qualitative study of information

INTRODUCTION minimising corruption, abuse of power, and

business. As suggested by Nolan and — Costs rise beyond what is budgeted,

change programme boards and internal — management of human resources and

Figure 1: The IT Strategic Impact Matrix.

rest had more specialist roles. Some had Section 3: Governance

The projects governance approach, attending programme

Budgets and timings who later moved on to other responsibilities.

is regarded as a normal and constantly we escalate the problem so as to get resources

project governance and IT governance, and Data governance is a continuing need,

The board Importance for Importance for

Awareness of past performance as a board, knowledge of results D A

Objective setting process, including core purpose (of organisation, D A

Strategy – clarity, organisational and financial realism, D A

Innovation process with clear governance C A

Evaluation of programmes by risk/reward//urgency/timescales A A

Development of options, choice process/criteria, prioritisation A A

Clarity and comprehensiveness of frameworks for assigning D A

Clarity and comprehensives of measurement frameworks A A

Process for debating, setting and monitoring service-level B B

Ability to describe governance structures and processes D A

Awareness of interdependence between different aspects of board D D

Adequate assignment and governance of internal resources D A

Understanding of sources of power and relative strength in the D B

The board Importance for Importance for

Appropriate use of shared governance structures including main D A

Lack of conflict of interest – internally and externally B A

Process for assigning governance, including identifying stakeholders B A

Process for monitoring success of governance (ownership) B A

Clarity on how performance and financial measures are used B A

Capability to structure change management approaches B A

Capability to structure supplier management approaches B A

Openness to evidence on failure A A

Capability to manage recovery after failure A A

Clarity of principles, for example, enterprise operating model (eg low D B

Clarity on decision-making principles for architecture, data B B

Prioritisation of capability requirements and associated infrastructure C A

Plan and process for updating IT capabilities B A

Approach to testing and piloting B B

Portfolio management of IT investments and management efforts B A

Focus on asset utilisation C B

Organisation and processes

Structure for governance C A

Relationships and behaviours that support governance B A

Relationship between organisation-wide and departmental/ A A

Existence of executive/senior management committee focused on C A

The board Importance for Importance for

Organisational process and change teams with IT members, and IT B B

Relationship managers in IT and units/departments, teaming, internal A C

Service-level and charge-back agreements between IT and B B

Commitment to identifying non-conforming individuals and B B

Incentives for compliance, disincentives for non-compliance A A

Stability in governance organisation and processes over time, while A A

Communication of and education in governance principles and B A

Regular planning processes incorporating review of governance, B A

Assessment of CIO and other top managers for their governance C A

Processes for monitoring and testing quality B B

Process for logging and managing change and tactical requests, A B

Agreement on quality metrics, and on how to revise them A B

Testing process management – functional and non-functional A B

Involvement of users/stakeholders in defining quality requirements A B