|
1
|
- An overview of effective delivery
|
|
2
|
- Introductions
- Why e-government IT Projects Fail
- How to implement e-Government right
- Conclusions and summary
- Questions
|
|
3
|
- West Indies Management
- Charter Member of Holistic Business Services
- Niche consultancy focused on Strategic Business Change Management
- Transformation Management
- Program/Project Management
- Knowledge & Knowledge Transfer Management
- Governance, Steering, Risk
- Program/Project Office Setup and Implementation
- US Corporation founded 2001
- Czech s.r.o. founded 2003
|
|
4
|
- West Indies Management provides Strategic Business Change/
Transformation Management, with end-to-end ownership. This graphic
outlines the top level of the West Indies Management Value Chain.
|
|
5
|
- West Indies Management brings the expertise across various industries
and the processes, organization, tools / technologies and services to
deliver.
|
|
6
|
- Solutions Design distills the Vision & Strategy Roadmap into a
Transformation Plan
|
|
7
|
- Many of the resources for a program will be internal to the customer or
their existing vendors
- West Indies Management can bridge gaps in program resourcing or
expertise
|
|
8
|
- Implementation phase focuses on running the plans and delivering
- Transformation Management
- Governance & Steering
- Risk Management
|
|
9
|
- When done correctly, the customer’s organization is already running
everything before “handover” occurs
- Any outsourced components (such as IT) are integrated transparently
|
|
10
|
- Eur. Ing. Andrew Hardie BSc CEng CITP FBCS FIMIS FIAP
- Independent Consultant, West Indies Management s.r.o.
- After fifteen years industry experience, including posts as technical
director of an electronic engineering company and managing director of
a software and consulting company.
- Since 1990 as an independent consultant to central, local and
international government bodies, including seven parliaments.
- Computerised the production of Hansard at the House of Commons, helped
set up the systems for the Northern Ireland Assembly in Belfast, worked
for several Government Departments and did several projects for the
Parliamentary Assembly of the Council of Europe in Strasbourg.
- Online collaboration and workflow systems, leading to a strong interest
in the theory and implementation of online communities for social and
business networking.
- Specialist in information architecture, requirements capture and
business change projects and has been a long-standing proponent of
human-centred computing, Open Systems, Open Source, the Internet and
the Web.
- Also active in the areas of policy and strategy, especially at the
interface between technology and legislation
|
|
11
|
- Implementing e-Government
- Why IT Projects Fail
|
|
12
|
- CHAOS Report – Standish Group (1994)
- Resolution Type 1, or project success: The project is completed on-time
and on-budget, with all features and functions as initially specified -
16.2%
- Resolution Type 2, or project challenged: The project is completed and
operational but over-budget, over the time estimate, and offers fewer
features and functions than originally specified - 52.7%
- Resolution Type 3, or project impaired: The project is canceled at some
point during the development cycle - 31.1%
|
|
13
|
- OASIG report (1996) to the UK’s Economic and Social Research Council -
findings on the eventual outcomes of IT projects:
- 80% to 90% do not meet their goals.
- 80% are delivered late and over budget.
- 40% fail or are abandoned.
- Over 60% do not address training and skills requirements sufficiently.
- More than 75% do not integrate business and technological objectives
properly.
|
|
14
|
- As many as 75 percent of all large systems may be considered to be
operating failures (Laudon & Laudon, 1996).
- In many of these systems the problems appear to lie, not with the
technology, but rather with the lack of attention paid to the needs of
people who had to use the technology.
|
|
15
|
- A study of 50 government projects over 20 years found that those
involving technical innovation and systems development historically ran
over budget by up to 200% and over the original contract duration by
54%. (McCue, 2002).
- An Oxford University survey reported that only 16% of IT projects were
successful, around 74% were ‘challenged’ and 10% were abandoned. (Saur
and Cuthbertson, 2003).
|
|
16
|
- According to a report from the Royal Academy of Engineering and the
British Computer Society billions of pounds are wasted every year on
badly managed IT system deployments.
- “The UK public sector alone spent an estimated £12.4 bn. on software in
the past year and the overall spend on IT is projected to be 22.6bn”.
- The study suggests that only about 16% of projects can be considered
successful and even conservative estimates put the costs of failures
into the tens of billions of pounds across the EU.” (Jaques, 2004).
|
|
17
|
- Collate those figures for
- IT Project Success Rates:-
- Ten Years on,
- it’s the same!
|
|
18
|
- Lots of reports!
- CHAOS – Standish Group (1995)
- OASIG – Organisational Aspects SIG (1996)
- PAC – Public Accounts Committee(1999)
- Schmidt et al (2001)
- NAO/OGC – National Audit Office / Office of Government Commerce (2002)
- POST – Parliamentary Office of Science and Technology (2003)
|
|
19
|
- Incomplete requirements
- Lack of user involvement
- Lack of resources
- Unrealistic expectations
- Lack of executive support
- Changing requirements and specifications
- Lack of planning
- Didn’t need it any longer
- Lack of IT management
- Technology illiteracy
- Other
|
|
20
|
- Management agenda is too limited in that most IT investments are
technology led and the main investment motive is only to cut costs. This
narrow focus on technical capabilities and efficiency goals means that
inadequate attention is given to the human and organizational issues
that can determine project’s ultimate success.
- Users do not influence development enough.
- Senior managers do not understand the links between technical and
organizational change.
- Project management techniques and IT approaches are too technical.
- Companies fail to organize work or design jobs and roles properly.
|
|
21
|
- IT projects are driven by business (not technical) decisions
- Insufficient involvement from users
- Clear objectives should be set from the start
- Lack of commitment from senior management
- Large projects may be overambitious
- Skilled project managers are essential to keep to time and budget and
appropriate deliverables
- Success depends on good risk analysis and sound methodologies
- Contingency plans should be in place
- User and operator training must be planned and designed
- There should be a post-implementation review
- Need professionalism in the definition, negotiation and management of IT
contracts
|
|
22
|
- Lack of top management commitment to the project
- Misunderstanding the user
requirements
- Not managing change properly
- Failure to gain user commitment
- Lack of adequate user involvement
- Failure to manage end-user expectations
- Unclear / misunderstood scope and objectives
- Changing scope and objectives
|
|
23
|
- Number of organizational units involved
- Lack of effective project
management skills
- Lack of effective project management methodology)
- Lack of required knowledge / skills in the project personnel
- Insufficient / inappropriate staffing
- Improper definitions of roles and responsibilities
- Lack of frozen requirements
- Introduction of new technology
- Conflict between user departments.
|
|
24
|
- Lack of clear link between the project and the organization's key
strategic priorities, including agreed measures of success.
- Lack of clear senior management and Ministerial ownership and
leadership.
- Lack of effective engagement with stakeholders.
- Lack of skills and proven approach to project management and risk
management.
|
|
25
|
- Too little attention to breaking development and implementation into
manageable steps.
- Evaluation of proposals driven by initial price rather than long-term
value for money (especially securing delivery of business benefits).
- Lack of understanding of and contact with the supply industry at senior
levels in the organization.
- Lack of effective project team integration between clients, the supplier
team and the supply chain.
|
|
26
|
- Public sector projects usually attract more media attention and are more
open to scrutiny than private sector projects.
- Policy changes rapidly in the public sector and legislation may require
last minute changes.
- Government personnel may not be sufficiently familiar with the
fundamental concepts and current developments of IT so are unable to
judge if suppliers are overselling to them.
- Advances in technology may occur so quickly that large projects can be
obsolete before they are delivered yet state-of-the-art solutions always
carry greater risk
- User requirements are often unclear at the start and can change at any
stage in the project’s lifecycle.
- Many Government IT projects are large and extremely complex with
millions of lines of code and so it is often impossible to guess how big
a job will be before it starts.
- It is difficult for non-technical management to ascertain the quality or
completeness of software during the development process.
|
|
27
|
|
|
28
|
|
|
29
|
|
|
30
|
- Cobb's Paradox:
- "We know why projects fail, we know how to prevent their failure
-- so why do they still fail?"
- (Martin Cobb, Treasury Board of Canada Secretariat, 1996)
|
|
31
|
- Not making good use of the tools available
- Political pressures and other adverse political interference may lead to
unrealistic timescales
- Insufficient project agility – planning only for a smooth
implementation, not catering for possible problems
- We don’t listen to those on the front line
- We don’t understand the nature of organizational learning
- We don’t invest enough in team training and development.
|
|
32
|
- Protracted period of specification - and under-specification is as bad
as over-specification
- Poor project structure—e.g. PFI has not always worked well
- Failure to analyze and understand the causes of slippage
- Big-bang implementation (although sometimes unavoidable)
- Losing sight of the end goal and a tendency to get buried in the
technical detail in the later stages.
|
|
33
|
- Why don't they want to learn:
- Irrelevance of success/failure.
For example, some stakeholders might only be interested in
association with the high-profile inception of the e-govt project, not
with the implementation and outcomes.
Others might see the project as a means of directing investments
to local IT firms, not as a means to achieve e-government goals. In these and similar cases, the
outcome – whether the project succeeds or fails – is of no importance
to the stakeholders, so they have no interest in trying to learn in
order to do better next time.
- Fear of exposure. Some
stakeholders fear that a learning process will expose their
shortcomings: their ignorance about ICTs, their self-serving
behaviours, their corruption, etc.
They will thus resist a learning process.
|
|
34
|
- Why don't they want to learn:
- Cultural inappropriateness. In
some organizational or national cultures, it is acceptable to admit and
learn from failure. In others,
it is not: failures are to be ignored or denied, certainly not to be discussed
for the purposes of learning.
- Skewing of incentives. In some
situations, there may be incentives for ongoing failure. For example, with some e-govt
applications, "success" can mean that the public agency is
downsized or loses financial resources because of its efficiency gains,
whereas “failure” can mean business, and funds, as usual.
- Stakeholder absence. By the time
an e-govt project ends, key stakeholders have often moved on to other
jobs/projects and have no continuing interest in the original project.
|
|
35
|
- Learning per se costs time and money – often a lot of time and money if
it's to be done properly. Public
services lack both those resources.
E-Govt systems may cost more than most because they are so
complex, involving so many stakeholders in a situation that is typically
very politicised.
- Learning approach needed:
- Recognition.
- Capture Knowledge
- Transfer Knowledge
- Apply Knowledge
|
|
36
|
- Having a narrow focus looking only at the inward-facing project risks
that are tangible and within the project manager’s control, without
considering risks to the organization's business as a whole
- Relying too much on tabulating numerous risks in a register without
prioritizing them or considering the extent to which they may be
correlated with each other
- Failing to understand that the ultimate risks of not meeting the
business objectives or realizing the business benefits, or ending up
with an unsatisfactory delivery of services to the public, cannot be
transferred to a partner or supplier
- Failing to understand or define the boundary between the
responsibilities of the supplier and the purchasing department or agency
- Depending on the contract or its penalty clauses to mitigate risk rather
than taking action or forming effective contingency plans
- Failing to monitor the effectiveness of mitigating action and
contingency plans or to refer risks, which fall outside of tolerance, to
the appropriate level in good time
|
|
37
|
- The bigger the project, the less likely it is any of the staff worked on
the last project – they will have moved up or out
- The bigger the project, the greater the risk of failure and then the
‘catch-up’ project afterwards is even riskier
- Risk/reward structure in public sector wrong – little reward for success
and heavy punishment for failure
- IT project procurement often delegated down to junior staff
- Poor requirements capture – leading to a bad specification
- Not talking to the people who will actually use the system
|
|
38
|
- Feasibility studies deliberately scoped to reinforce original policy
decision, not to investigate feasibility, desirability, benefits, etc
- A negative Feasibility Study can be a good thing!
- Misguided outlook on Pilot Projects
- A pilot project failing can be a good result!
- Pilots should not be ‘grown on’ into a full project
- Suppression or playing down of project problems for political reasons
until it’s too late – e.g. Gateway Reviews
- Failure to conduct a Post Implementation Review or to publish reviews
that are critical of the project
|
|
39
|
- All of these factors, and others, result in:
- Failure to learn – not being a ‘learning organisation’
- No knowledge sharing
- No knowledge accumulation
- No competence development
- …
|
|
40
|
- Implementing e-Government
- How To Do It Right
|
|
41
|
- Ensure timetables are realistic
- allow for early planning and detailed specification
- will save both time and resources in the long run
- Make full use of pilots to test schemes on a small scale prior to
rolling out and testing on a larger scale
- Ensure that pilot schemes are subject to rigorous monitoring and
evaluation
|
|
42
|
- More realistic business cases and timescales.
- Better assessment and management of risk.
- Breaking large complex projects into smaller more manageable components.
- Having reliable contingency arrangements in place.
|
|
43
|
- Taking greater advantage of departments’ buying power to secure better
deals.
- Increased use of professional procurement expertise in framing contract
strategies.
- More awarding of contracts on achieving longer term sustainable VFM than
simply lowest price.
- Greater use of incentives and partnership working with suppliers where
appropriate.
|
|
44
|
- More reliable information on which to base decisions about new policies.
- Clearly thought through implementation plans.
- Not losing sight of existing well established good practice.
- Exercising strong management grip.
|
|
45
|
- Careful planning is a pre-requisite of successful implementation.
- All risks and business requirements must be considered
- Rushed procurement can result in the loss of taxpayers’ money.
|
|
46
|
- Overseeing the development of the project brief and business case
- Ensuring there is a coherent project organization structure &
logical plan's)
- Monitoring and controlling the progress of the project at a strategic
level (at an operational level, this is the responsibility of a project
manager)
- Formally closing the project and ensuring that the lessons learnt from
the project are documented within the end of project evaluation report
- Ensuring that the post-implementation review takes place, the output is
forwarded to appropriate stakeholders and the benefits have been
realized
- Referring serious problems upwards to top management and/or Ministers as
necessary, in a timely manner
|
|
47
|
- Good way of assessing whether a project is likely to work in practice
- Allows observation of user reaction to the planned project
- Gives more realistic indication of the costs of wider implementation.
- Allow departments to identify potential barriers to the implementation
of the project which may not have been seen during the design stages.
- But, the lessons learnt from pilot projects must be used!
|
|
48
|
- Don’t forget the basics:
- Determining and defining operational needs clearly
- Development of a sound business case
- Assigning risk to whoever is best placed to manage it
- Monitoring progress
- Having reliable contingency arrangements in place to maintain services
to the public if something goes wrong.
- Break large complex projects into smaller more manageable components
|
|
49
|
- PPM is about:
- setting agreed goals and milestones
- regularly assessing progress;
- clarity of accountability, roles and responsibilities at all levels;
- transparent reporting of progress and problems –including to Ministers
– so that remedial action can be taken in good time;
- offering a framework within which to balance risk and departmental
capability.
- intelligent application of principles to suit the nature and scale of
the task in hand.
|
|
50
|
- Organizational level
- top team being clear about strategic goals and actively overseeing the
portfolio of major programs, managing risk against capability
- Program level
- understanding strategic departmental priorities, identifying and
managing risk and interdependencies with regular independent scrutiny
of progress
- Senior Responsible Owner (SRO) or equivalent – needs to be accountable
for each major program
|
|
51
|
- Project level
- The team needs clear roles and responsibilities and a vision translated
into a plan with milestones, regular reporting and review, and
stakeholder involvement from the start.
- Projects are about delivering outputs; programs focus on achieving the
resultant outcomes.
|
|
52
|
- Clear focus on objectives, with clear accountability for delivering
results to required time, cost & quality
- Framework for prioritizing and managing resources:
- for cross-boundary working which is almost always needed to deliver
outcomes for government’s customers
- for transparent reporting internally and externally
- a robust factual basis on which to advise Ministers and Management
Boards, giving them the data they need to make informed decisions
- a medium for identifying risk and uncertainty, assessing and managing
them to focus management resources where they will provide most benefit.
|
|
53
|
- Ensuring delivery planning happens at an earlier stage in the policy
process, so Ministerial commitments are underpinned by an understanding
of the risks and challenges of delivery
- Measuring and reducing the administrative burdens on frontline staff, so
more time is spent delivering outcomes, not servicing ‘the machine’
- Using earned autonomy and making smarter use of levers such as targets,
ring-fenced budgets, mandated partnership vehicles or requirements to
produce plans, so as to give local managers scope to implement policy
innovatively and in line with individual customer needs.
|
|
54
|
- Who should use the framework?
- Should it be made mandatory?
- How will the purpose of the framework be communicated to staff?
- What training will they require?
- How will you ensure the ‘lightness of touch’ is appropriate to
program/project risk?
- Will your department’s centre of excellence adapt the framework to your
needs e.g. by including its own procedures and models on the framework?
- How will the framework’s usefulness be monitored?
|
|
55
|
- What programs and projects do you currently have in the department?
- Is there effective integration of policy and implementation?
- Is there the project and program capability to meet current and planned
delivery commitments?
- Do you perform risk assessment to identify the right level of
Ministerial and Management Board oversight and governance?
- Do you have an experienced SRO for each high-risk program?
- Are there additional policy/PSA delivery areas that you should manage as
programs?
|
|
56
|
- Where will the centre of excellence sit in the organization and how will
it relate to other internal functions?
- Which Board member will take responsibility for its establishment?
- What skills will you need within the centre of excellence?
- Do you have access to the right expertise from within or will you need
external recruitment?
- How will the centre of excellence be implemented and its purpose
communicated to the department, including details of support available?
- How will its impact be measured?
|
|
57
|
- Research carried out by the Improving Program and Project Delivery
(IPPD) team showed that those departments with a good track record on
program and project management had built up a permanent central facility
to:
- Provide a strategic overview of departmental programs and
interdependencies to senior management;
- Provide ‘consultancy-style’ support to project teams and boards at
initiation and throughout the lifecycle of the project;
- Ensure ‘Gateway’ disciplines are applied – external and internal
scrutiny;
- Carry out health checks and advise on solutions during the lifetime of
individual projects across the department.
|
|
58
|
|
|
59
|
- Provide departmental Management Boards with strategic overview of major
programs so the Board can:
- Manage priorities and interdependencies
- Make informed, forward-thinking decisions on resourcing
- Monitor of progress towards delivery of objectives
- Provide assurance to Ministers based on real knowledge of current
capacity.
- Provide the information & support to the Management Board and report
directly to the Board on a regular basis. This has two benefits:
- It signals the importance placed on delivery across the department
- It provides the Centre of Excellence with the authority to become
involved in the major programs of the department.
- The Centre of Excellence does not take on the role of managing programs/
projects itself (but can act as resource pool in larger organizations)
|
|
60
|
- Identifying and agreeing with the Board the top [x] delivery areas
critical to success and advising on implications for the department’s
business planning and HR strategy
- Carrying out regular assessments of agreed priority areas to provide
highlight reports to the Board on:
- Current status (time/cost/quality/resourcing/whether to plan or behind)
- Risks, Issues, Areas of Weakness
- Carrying out more detailed reports of major programs at key stages
during the departmental finance and planning cycle
- Ensuring review disciplines are applied appropriately and maximum value
is obtained from the process
- Ensuring program interdependencies are identified, understood and
managed
- Identifying capacity and competence issues as they arise and reporting
these to the Management Board to support strategic HR planning
- Taking part in informal meetings with representatives from other key
departmental functions (e.g. Internal Audit, Finance, Procurement,
Contracting)
|
|
61
|
- Policy development stage
- Involvement at an early stage of policy development to assist analysis
and understanding of scope
- Program/project definition stage
- Information on/provision of developmental opportunities for the SRO
- Expert support and advice to program directors on developing a business
case
- Advice on resources and program structure
|
|
62
|
- Program/project start-up stage:
- Start-up workshop with project team members and/or boards
- Workshop for program/project boards
- Provision of clear guidance on internal approval process for programs/
projects and on management board requirements for oversight
- Advice on the structure of the program and processes for risk
management and control appropriate to its size
- Provision of HR advice on using existing HR systems effectively to
maximize the chance of getting the right people in the right place at
the right time
|
|
63
|
- Program/project delivery stage:
- Standardization of reporting processes and documentation to ensure
information on programs and projects is consistent across the
department
- Regular reviews of the progress of programs and projects
- Program and project scrutiny
- Ad-hoc advice and trouble-shooting to program and project teams
- Guidance on consultants, e.g. firms, procurement & contracts
- Assistance with resource deployment and identification of the right
people for the right projects as required
|
|
64
|
- The following skills and experience should also be available among the
mix of Centre of Excellence staff:
- Proven track record in applying PPM methods to policy formulation and
delivery
- Proven track record in Program/project management and implementation
- Expertise in Program/project management methodologies and processes
- Active experience in risk management
- Business Case and appraisal skills
|
|
65
|
- To effectively implement e-Government, the Czech Government should
urgently consider establishing Centers of Excellence
- Holistic Business Services can assist the Czech Government to build
Centers of Excellence
- Establishment of the Centers within the Ministries and/or Departments
- Mentoring internal specialists
- On-going support
- Governance Frameworks
|
|
66
|
|
Notes
