Content uploaded by Merlin Stone
Author content
All content in this area was uploaded by Merlin Stone on Aug 26, 2015
Content may be subject to copyright.
www.palgrave-journals.com/dbm/
Correspondence:
Merlin Stone
WCL Offi ce, 83 Victoria
Street, London
SW1H 0HW, UK
E-mail: merlin.stone@
w-c-l.com ,
Web: www.w-c-l.com
Original Article
IT governance and project
management: A qualitative study
Received (in revised form): 9 th February 2009
Dev Sharma
leads the Delivery Practice at WCL, helping clients improve their overall effi ciency, 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
identifi es 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.
Journal of Database Marketing & Customer Strategy Management (2009) 16, 29 – 50.
doi: 10.1057/dbm.2009.6
Keywords: information technology ; project management ; governance ; risk ; systems
implementation ; systems strategy
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
30
Sharma et al
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 fulfi ls organisational needs, and its
fi nancial investment in IT. Governance
covers all the assets that may be involved
in IT, whether human, fi nancial 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 effi ciently 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 effi cient 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
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
31
business. As suggested by Nolan and
MacFarlane in their Harvard Business Review
paper, as more and more organisations
change marketing tactics and other fi rms
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 fi rms.
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, specifi cally 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 effi cient 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 confi dence is lost,
the programme may be cut dramatically,
to focus on minimal deliverables; it
may then be gradually rebuilt over time
as confi dence 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
identifi ed 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,
—
—
—
—
—
—
—
—
—
—
—
—
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
32
Sharma et al
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, fi nancial 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;
benefi ts 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 benefi t exploitation.
One of the key challenges faced by
organisations is to answer the question –
how much IT governance is required?
Sambamurthy and Zmud
6
suggest that
key determinants of IT governance can
be classifi ed 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 infl uences the mode of IT
governance. Firms that centralise corporate
governance tend to centralise IT
governance, whereas fi rms that have
decentralised their corporate governance
tend to decentralise IT governance.
Economies of scope
Economies of scope are benefi ts accruing
to an organisation when it is able to share
—
—
—
—
—
—
—
—
—
—
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
33
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 fi rst introduced in 1990
by Cohen and Levinthal.
7
Two concepts
related to absorptive capacity are as follows:
Receptivity : Awareness of, identifi cation
of and taking effective advantage of
technology.
Innovative routines : Practised routines
that defi ne a set of competencies an
organisation can use confi dently 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 signifi cant
organisational change. Figure 1 shows the
IT Strategic Impact Matrix and the four
involvement modes.
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 fi rm ’ s
strategic mode, as well as fi rm 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,
OffensiveDefensive
High
If system fails for a minute or more there is
an immediate loss of business
Strategic Mode
New system promises
major cost reductions
Need for
reliable IT
Low
Support Mode
Even with repeated service interruptions of
up to 12 hours there are no serious
consequences
Turnaround Mode
IT is more than 50% of
capital spending
HighLow
Need for new IT
Factory Mode
Figure 1 : The IT Strategic Impact Matrix.
Source : Nolan and McFarlane
5
.
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
34
Sharma et al
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,
fi rms 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 fi rms, their IT expenditures are
large. According to Nolan and McFarlane,
not every fi rm 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 benefi ts 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 following
5
:
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 fl exible 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
—
—
—
—
—
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
35
10 organisations about a recent large IT
project in which they had been involved. The
respondents were one national retailer, fi ve
fi nancial 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
Offi cers / 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:
Section 1: About you
1. What is your role?
2. How long have you been in it, and what roles
did you hold before?
3. What is your experience of project management?
Have you been trained in it?
Section 2: The project
4. What was the most signifi cant large IT
programme that you have undertaken in the last
5 years and what did it involve? What were the
objectives, scope and focus of programme, what
resources were required, which suppliers were
involved, what contributions were they supposed
to make, what organisational activities were
supported by the project and what benefi ts were
expected?
5. What was the duration and cost of the
programme? If it is still running, what is the
expected cost and duration of the programme?
If the programme is completed, what was
the cost and duration compared to the plan?
6. What was the split between IT and other costs,
for example, people costs in other departments,
on the programme and within IT, between
hardware, software and implementation? Did
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 benefi ts did they
expect and get? How did you keep stakeholders
informed about the progress of the project,
and any problems? What process did you have
in place for getting feedback from stakeholders
as the project progressed?
8. What were your main learnings from the
project, in terms of how to manage the
project and deliver it on time, relating to
your people, and your stakeholders and
suppliers?
9. What was the role of IT and business consultants
in the project? What was the main contribution
they made? Were there any specifi c weaknesses,
and what did you learn from this?
10. Were you following any particular professional
standards or methods in the defi nition or
implementation of the project? If so were the
standards useful or a hindrance?
11. How if at all were your senior managers involved
in the project? Do you consider that your
board of directors or equivalent was suffi ciently
engaged? What more could they have done
to ensure success?
Section 3: Governance
12. What was your general governance approach
to the project?
13. Did you have a governance budget, and if
not, why not? Did you use a particular
externally or internally developed governance
framework?
14. Was any particular software used to support
the governance process? How was
organisational accountability allocated?
15. What was the role of any of suppliers in
governance? What was their contribution
of knowledge of about typical risks of such
projects? Did they share risk? How did they
participate in reviews? What did they do well
and what could they have done better?
16. Were rules and rights drawn up for those
involved in the project, either in delivery or as
stakeholders?
17. How were project requirements gathered and
validated, and what governance process was
used for maintaining and controlling these
requirements?
18. How was alignment with business objectives
and requirements secured?
19. Who determined the change management or
project management approach and how was
this implemented?
20. What was your project budgeting approach and
how was it governed?
21. How were governance metrics determined?
22. Who determined and then implemented criteria
for prioritising projects and activities and
making decisions?
23. How did you review progress?
24. How were risks identifi ed and managed?
25. How did you undertake problem analysis
and resolution?
26. What were your governance processes to
ensure application of accountability, processes
and criteria?
FINDINGS
The questionnaire was completed via
face-to-face or phone interview. The main
points that emerged were as follows.
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
36
Sharma et al
The projects
These were very varied. One involved
developing a system to sell the product of
another large fi nancial institution, which
had very stringent security requirements.
The retailer ’ s project aimed to replace its
back-offi ce 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 fi nancial
processes to transfer roles from centre to the
regions. Another fi nancial 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
fi nance 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
identifi ed.
One mentioned in particular the need for
suppliers with ‘ fi erce 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 fi ndings 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 signifi cance 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
signifi cance has been understood and that
it has been acted upon.
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
37
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 fi ve 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 signifi cant 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 specifi cations.
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
specifi ed and reported upon. One public
sector respondent put particular emphasis
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
38
Sharma et al
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
signifi cant 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 satisfi ed 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 identifi ed 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 diffi culty
of managing risk and the diffi culty of
embedding learning from managing the
project into the company ’ s culture were
also identifi ed.
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.
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
39
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 identifi ed
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 signifi cant
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
specifi cation 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 fi xing. 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 fl ows 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
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
40
Sharma et al
requirements were gathered, we had very clear
version control, including fi nal 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 fi t
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 offi ce and reported
in to the board. Our fi nance 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
confi rms 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
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
41
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 diffi cult 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
diffi culties:
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 identifi ed
in the project management software.
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
42
Sharma et al
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 specifi c 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 suffi ciently 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
confi guration 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
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
43
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
identifi ed that it was diffi cult where business
partners were involved. Typical risks
identifi ed 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 identifi ed
the importance of planning for mitigating
risk at project planning stage. Good practice
was exemplifi ed 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
identifi ed, 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 fi x each risk.
Where problem analysis and resolution were
concerned, experiences and approaches
varied:
The key is to identify the issue fi rst. Then we
use consultants for process mapping and skills
transfer. If consulting resources are insuffi cient,
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 identifi ed.
CONCLUSION
Our research showed that most companies
that responded had strong project
management approaches and strong, well-
qualifi ed 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
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
44
Sharma et al
project governance and IT governance, and
thus the fi ndings hint at a general weakness
in IT governance that might be infecting
project governance.
Our fi ndings 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 fi ndings also supported
the idea that changing how projects are
governed played a signifi cant 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
(a) Whether it needs governance?
(b) Whether – if the organisation has a
general approach to governance – the
project in question has any special
governance requirements?
(c) If so, what are the requirements?
In our view, the fi ndings 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).
ACKNOWLEDGEMENTS
Our thanks go to Bryan Foss of Foss
Initiatives for reviewing parts of this
paper and suggesting some additions.
REFERENCES
1 Foss , B . , Stone , M . and Ekinci , Y . ( 2008 ) What makes
for CRM system success or failure . Journal of
Database Marketing and Customer Strategy Management
15 (2) : 69 – 78 .
2 The IT governance institute . ( 2008 ). http://www.
itgi.org/template_ITGI.cfm?Section=About_IT_
Governance1 & Template=/ContentManagement/
HTMLDisplay.cfm & ContentID=19657 , accessed
10 October 2008 .
3 Selig , G . ( 2008 ) Implementing IT Governance – A Practical
Guide to Global Best Practices in IT Management . New
York: Van Haren Publishing , (ISBN 9087531192) .
4 Jennings , T . ( 2004 ) Change Management: An
Essential Tool for IT Governance . White Paper
Butler Direct Limited 1 – 18 .
5 Nolan , R .
and McFarlane , F . ( 2005 ) Information
technology and the board of directors . Harvard
Business Review 83 (10) : 96 – 106 .
6 Sambamurthy , V . and Zmud , R . ( 1999 ) Arrangements
for information technology governance: A theory of
multiple contingencies . MIS Quarterly 23 (2) : 261 – 290 .
7 Cohen , W . and Levinthal , D . ( 1990 ) Absorptive capacity:
A new perspective on learning and innovation .
Administrative Science Quarterly 35 (1) : 128 – 152 .
8 http://www.isaca.org/ .
9 PRINCE (PRobjects IN Controlled Environments)
is a de facto project management standard used
extensively by the UK Government and is widely
recognised and used in the private sector, both in
the UK and internationally. It covers the
management, control and organiztion of a project.
PRINCE2 refers to the second major version of this
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
45
method and is a registered trademark of the Offi ce
of Government Commerce (OGC), an independent
offi ce of HM Treasury of the United Kingdom .
10 For more on stakeholder management, see Stone ,
M . Semmens , A . and Woodcock , N . ( 2008 )
Managing Stakeholders in the Public Sector . Report
for the Public Management and Policy Association,
September 2007 and Stakeholder Management and
Engagement – Lessons from Public and Private
Sectors, WCL .
11 For more on the assessment of customer
management, see Stone , M . Woodcock , N . and Foss ,
B . ( 2003 ) The Customer Management Scorecard .
London: Kogan Page .
APPENDIX
GOVERNANCE TOPICS
In this list, we have classifi ed the topics
as being important for project governance,
project management or both, and
scored them (A as critical, B as
important, C as nice to have and D as
not relevant) based on our research
and experience for their general
importance for each type of governance.
Of course, their importance for a
particular organisation may vary
according to the type of organisation,
its general experience with projects
and the particular project. The point
of scoring them is really indicative,
to stimulate readers into considering
how important the factors are for
their particular situation, rather
than to pronounce upon their general
importance.
The board
Importance for
project management
Importance for
project governance
Awareness of past performance as a board, knowledge of results
of actions
D A
Objective setting process, including core purpose (of organisation,
change programme, supplier), measures of success, fi nancial case,
SLAs, and so on
D A
Strategy – clarity, organisational and fi nancial realism,
communication, allowance for risk, compliance
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
accountability and governance
D A
Clarity and comprehensives of measurement frameworks
A A
Process for debating, setting and monitoring service-level
agreements and monitoring possible confl icts between
effi ciency and performance, within and between departments,
suppliers, and so on
B B
Ability to describe governance structures and processes
D A
Awareness of interdependence between different aspects of board
accountabilities, including policy interdependence and fi nancial
interdependence
D D
Adequate assignment and governance of internal resources
including directors ’ (or other senior managers ’ ) sponsorship and
involvement, organisational resources (eg requirements, testing and
deployment), funding, audit and risk management support
D A
Understanding of sources of power and relative strength in the
organisation and how these can be transformed into advancing the
organisation
D B
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
46
Sharma et al
The board
Importance for
project management
Importance for
project governance
Adequate attention to external requirements including supplies,
contractors, contracts, external risk management and other
dependencies
D B
Appropriate use of shared governance structures including main
board, executive board, audit committee, internal and external
auditors
D A
Lack of confl ict of interest – internally and externally B A
Process for assigning governance, including identifying stakeholders
for it, identifying the benefi ts they should expect to be yielded for
properly governed activities, and their roles and responsibilities in
governance
B A
Process for monitoring success of governance (ownership) B A
Clarity on how performance and fi nancial 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
cost, customer intimacy, product leadership), speed of deployment,
focus on costs, fl exibility, integrity, measurement approaches,
standards – technology and data, reuse, use of commodity products,
fi nancial criteria
D B
Clarity on decision-making principles for architecture, data
management and infrastructure – what capabilities and activities
should be standardised organisation-wide
B B
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
refl ecting departmental / unit and overall priorities
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 /
unit-specifi c decisions and implementation
A A
Existence of executive / senior management committee focused on
governance
C A
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
47
The board
Importance for
project management
Importance for
project governance
Existence of IT leadership committee
C A
Organisational process and change teams with IT members, and IT
teams with functional or departmental members
B B
Relationship managers in IT and units / departments, teaming, internal
relationship management
A C
Service-level and charge-back agreements between IT and
organisation / functions / units
B B
Commitment to identifying non-conforming individuals and
departments and to gaining reform
B B
Incentives for compliance, disincentives for non-compliance
A A
Stability in governance organisation and processes over time, while
allowing planned evolution
A A
Communication of and education in governance principles and
processes and their rationale, using all relevant means – Intranet etc
B A
Regular planning processes incorporating review of governance,
including classic SWOT of current approach, given organisation-
wide strategy and operational requirements
B A
Assessment of CIO and other top managers for their governance
performance (fi nancial, service levels, value to the organisation,
management of process)
C A
Quality / issue management
Quality plan
B B
Processes for monitoring and testing quality
B B
Process for logging and managing change and tactical requests,
including ensuring resources are not diverted
A B
Agreement on quality metrics, and on how to revise them
A B
Testing process management – functional and non-functional
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
A B
Involvement of users / stakeholders in defi ning 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
dependencies and budgets, including escalation processes
A B
Involvement of users / stakeholders in identifying and resolving
problems / issues
A A
Process for revisiting resolution
A B
Supplier management
Clarity of objectives or outcomes
A A
Realistic expectations of deliverables
A B
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
48
Sharma et al
The board
Importance for
project management
Importance for
project governance
Analysis of competence, quality, trustworthiness, motivations and
incentives of suppliers
A A
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
new methods
A B
Identifi cation and deployment of appropriate skills
A B
Interlock of supplier’s work with work of rest of organisation (not just
deliverables but incentives and motivation)
A B
Supplier selection process – including understanding supplier
profi les, development of clear set of criteria for assessing suppliers ’
cultures, process for reviewing non-price or product issues
A A
Ensuring staff actually involved in programmes, projects or
operational delivery are as promised at contracting stage, and
validated to have the required quality
A B
Supplier segmentation – from strategic partners to tactical suppliers,
with appropriate justifi cation
D B
Coupling of purchasing management with management responsible
for downstream delivery, to ensure that downstream delivery
requirements properly taken into account in purchasing
B A
Process for ensuring knowledge / skills transfer
B B
Aware of own culture and tendency to gravitate to certain kinds of
supplier
B B
Establishing values and incentives of suppliers and individual
players within the supplier (eg sales versus delivery) and
ensuring match with own – as applied to change and routine
operations
B B
Process for taking up and challenging references (beyond those
provided), researching and probing successes and failures, awards
and legal actions, identifying who is supplying successful clients,
and who is supplying failures
B A
Understanding the organisation’s specifi c needs and matching them
to supplier capabilities
B B
Process (and associated governance) for managing problems and
issues before you encounter the fi rst ones
B A
Supplier relationship management process, agreed with supplier
B B
Evaluating supplier capability – from listening to your needs,
understanding them, providing relevant propositions and solutions
and measuring delivery of them
B B
Address the relationship before the event(s) which put the
relationship at risk
A A
Confl ict resolution process
A A
Use of relationships and contracts to share risk and reward,
include ‘ repeat game ’ opportunity and recovering deliverables,
time and money even when the programme faces diffi culties
or changes
B B
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
IT governance and project management
49
The board
Importance for
project management
Importance for
project governance
Monitor performance with the supplier at all levels, using internal
audit and assurance capabilities with suppliers and programme
streams as required to increase delivery confi dence and early
warning of issues
A B
Benefi ts, outcomes and measures
Codifi cation and sharing with staff the ‘ core purpose ’ of the
organisation
B B
Aligning organisational purpose with customer’s perspective and
the benefi ts they expect and staff’s perspective and the culture and
values required for successful delivery
B B
Clear objectives and outcomes for programmes and departmental
operation, with a logical understanding of what programme features
and work contributes to specifi c benefi t delivery
A B
Programme and operations defi nition fully interlocked with the
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
B C
Evidence-based assessment of management capabilities, capability
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
B B
Clear set of supporting processes that ‘ measure benefi ts to get
better ’ , rather than ‘ measure transactions to get busier ’
B B
Tracking of investments and benefi ts over time
A A
Management of programmes, projects and operational
delivery
Processes to defi ne programmes / tasks and allocate accountability
for their design, management and success
A B
Clearly defi ned objectives and scope, ensuring programmes,
projects and operational activities are split into packages of
deliverables with intermediate objectives, control over scope creep
A B
Agreed formal tracking processes for different levels and stages of
projects and programmes
A B
‘ Objective ’ assessment of past programme, project and operational
management performance – delivery, budgets, and so on and
learning from successes and failures
A B
Clearly defi ned programme, project and operational management
processes with appropriate system support
A B
Clear hierarchies of programmes, projects, portfolios and operational
delivery with interlock issues managed, particularly where major
programmes or projects may disrupt operational delivery
A B
Processes for ensuring resource availability
A B
Processes for assuring programme, project and operational delivery
quality (including self-assurance)
A B
Process for milestone and checkpoint defi nition and management
A B
Processes for identifying non-conforming programmes, projects or
operational delivery
A A
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
50
Sharma et al
The board
Importance for
project management
Importance for
project governance
Processes for governance of contribution of external suppliers,
including self-audit if appropriate
B A
Processes for ensuring and maintaining user / stakeholder involvement
A B
Processes for recruiting, training and deploying programme / project /
operational managers
A B
Processes for building and managing programme, project
and operational delivery teams, based on requirements, skills,
capabilities, and so on
A B
Validation processes for any programme, project or operational
delivery package defi nitions
A B
Processes for involving externals in developing and implementing
governance processes where internal resources are not available
A B
Processes for managing stakeholder / user expectations and
communicating with them
A B
Processes for transferring to operations of any new developments that
are outcomes of supplier initiatives or internal programmes or projects
A B
Involvement of organisational representatives, stakeholders, users
and suppliers in defi nition, 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 benefi ts), including
methodology for managing trade-offs if all objectives cannot be met
A A
Testing strategy for new services, systems, and so on, for example,
early walk-through and acceptance of documented requirements,
organisational logic, information fl ows, user requirements, user
acceptance testing for any changed facilities
A C
Training and organisational change carried out in parallel to any
changes in specifi c functions, with fi nal usability training deferred
just before deployment
C B
Parallel development strategies for new services, functions, systems,
and so on
C B
Processes for managing internal diffusion of innovations
C C
Minimisation of dependencies is used wherever possible to de-risk
the critical path / s and enable unbundling or other organisational
trade-offs or changes to occur during the programme
A B
Risk planning and management
Published risk plan that considers all signifi cant risks including
external risks, major and minor programme risks
A A
Risk plan reviewed at every programme board meeting
A A
Allocating to board members individual and shared responsibilities
for risk management, documented and accepted within the annual
personal and board review processes
A A
Internal and external professional assurance of programme and risk
management approaches
A A
Specifi c review points ( ‘ gates ’ ) where internal and external
stakeholders get an unbiased checkpoint review
A A
Process to ensure response to problems
A A
Process for identifying and rescuing troubled / overspent / overdue
programmes
A A
© 2009 Palgrave Macmillan 1741-2439 Database Marketing & Customer Strategy Management Vol. 16, 1, 29–50
