|
About Z/Yen
History
Clients
People
Testimonials
Z/EALOUS
FAQ
Services
Strategy
Intelligence
Systems
SpecialiZm
Change management
Outsourcing
Sectors
Financial services
Technology
Not-for-Profit
Commercial
Public sector
Activities
GFCI
The London Accord
Events
On-line surveys
c
Products
Compliance workstation
Benchmarking
Investment games
PPRISM
PropheZy
VizZy
Knowledge
Books
Articles
Research &
Presentations
Press
Now & Z/Yen
Media coverage
Press releases
Z/Yen imagery
Fun
Photo gallery
Caption competition
Humour
ExtZy
Links
Reading list
Risk/Reward surfing
© The Z/Yen Group of Companies 2008
| |
Background to Programme Management
All organisations have to change, so an ability to “make things happen” is
important. Z/Yen treats the effective and efficient management of programmes and
projects as a key skill. Not only do we provide programme and project management
for clients, we have to manage our own portfolio of projects. We set out below
the background to programme management and some of the tools and approaches that
Z/Yen finds helpful. Programme management is:
the co-ordination of a portfolio of projects
in order to achieve a set of business objectives
Organisations need programme management in order
to handle either a multitude of projects or a mega-project that initiates a
plethora of sub-projects. Programme management involves the planning,
prioritisation, monitoring, support and evaluation of projects to meet changing
business needs. The objective of programme management is to increase the
likelihood of success within the project portfolio and, through co-ordination,
increase the overall impact of the portfolio on business objectives. Programme
management complements project management, but it differs from project
management in that programmes tend to have a set of objectives rather than a
single objective, be at a larger scale of complexity, involve heterogeneous
projects and require cross-project resource sharing.
For instance, one computer-based entertainment company found that many of its
projects were late, over-budget and failed to achieve what had been expected. Further, some of their larger client relationships were under strain even when
several projects had been successfully delivered because one or two key projects
had failed. They realised that they were:
-
spreading resources too thin by trying to do
too many projects;
-
confused about how decisions were made on
starting, stopping or changing projects and who was responsible for making
these decisions;
-
failing to coordinate design changes or new
timetables with clients and customers;
-
unsure how resources were allocated;
-
often losing track of good ideas, especially
ideas that might benefit several projects;
-
failing to learn from either success or
failure.
The solution to these problems was a significant
project in its own right – putting in place a programme management system along
with a financial project evaluation system and training and development for
their project managers and staff. The programme management system was designed
by the project managers themselves both to ensure that it reflected their needs
and to give them a sense of ownership. It was ‘their’ system. Built
into the system was a strong bias to be ‘customer driven’; customer needs came
first.
After the programme management system was designed, the company appointed a
programme management ‘czar’ with the power to start and stop projects, as well
as the responsibility for monitoring and support. Naturally, there were some
manuals, some structured training and plenty of discussion, but ultimately the
company began to see the benefits:
-
a clear view of the totality of projects in
the organisation, their likelihood of meeting objectives, their resource
consumption and their key risks;
-
projects likely to fail were cancelled,
releasing resources to other projects and increasing overall success;
-
cross-project problems were getting solved,
e.g. a piece of software that was causing all projects problems was replaced
using a quick, mini-project;
-
clients gained more confidence in overall
delivery because projects were more consistently run and they had more
information during the course of projects across projects.
Programme management, as with any system, has
five basic components:
-
governance: setting out the overall
objectives of the business, planning a set of projects to achieve those
objectives and having clarity on go/no-go decisions;
-
input: selecting specific projects to
undertake, gaining stakeholder commitment, assembling resources and
appointing a team;
-
process: supporting the project
managers through cross-project discussion, training, template materials and
methodologies;
-
output: evaluating projects, focused
on a ‘customer’ point-of-view, so that people learn from both successes and
failures;
-
monitoring: providing management
information up to governors, over to customers, down to project managers and
across project managers so that they are co-ordinated. Monitoring also uses
feed-back from project outcomes to feed-forward into new
projects and re-plan the shape of the project portfolio.
Programme management can be represented
diagrammatically as:
There are a number of tools that can be used in
each component, but some of the more interesting tools include:
Governance – Portfolio Analysis
Programme management starts with a strategic review of the organisation and its
objectives. However, as stated at the beginning, programme management is at a
larger scale of complexity than project management, so how can a more optimal
set of projects be selected? Using portfolio analysis to select projects is a
common, useful tool. Portfolio analysis is a well-established practice in the
commercial sector, e.g. financial services or pharmaceuticals, and involves
balancing a portfolio of investments in a way which limits risk (by managing
volatility) and maximises potential rewards.
Companies and not-for-profit organisations adopt a similar technique in
selecting ‘investments’ - activities in which they are involved. A simple
portfolio analysis can be carried out as a paper based exercise, while larger,
more complex organisations may need to use statistical modelling techniques such
as Monte Carlo analysis. Portfolio analysis helps organisations challenge
established thinking by providing a set of plausible but unconsidered options to
generate debate and better, informed decisions.
Input – Project Scorecards
The outcome of governance is a set of ‘themes’ or overall goals for the
organisation and these lead to specific project selection. This is the
evaluation and selection of projects that are aligned with the overall goals,
and frequently linked in complex ways, e.g. we can’t get into Far Eastern
markets until we establish our Singapore office. The programme management team
need to ask some basic questions before approving a project:
-
is this project a good idea?
-
will this project help the organisation and
its stakeholders?
-
is there a clear customer who gets a clear
benefit, perhaps that they are willing to share?
-
is this of acceptable risk to the
organisation?
-
does this advance the mission of the
organisation and have a return-on-investment?
-
do we have consensus and agreement about
this, including agreement outside the organisation?
-
have we researched this idea to an acceptable
level?
-
have we prepared a business case,
quantification of timescales, milestones, costs, benefits and risks?
-
who in the organisation is most suitable to
run this project?
A sample scorecard is illustrated above. The idea
is to approve projects over a certain score. However, projects that fail the
‘hurdle’ can readjust to try again. Ideally, the scorecard becomes more
statistical over time, reflecting what the organisation learns, e.g. projects
with many clients are too risky for us most of the time.
Process – Project Support Office (PSO) and Z/ENITH
Typically, an organisation concerned with “programme” management, by
implication, is likely to benefit by establishing a project support office that
increases the effectiveness of the multitude of projects. For instance, at one
client, projects were very late, substantially over budget and not satisfying
‘target users’. Following a review, Z/Yen recommended forming a Project Support
Office (PSO) headed by a Programme Manager. In discussion with the client, Z/Yen
also recommended the use of interim skills to get the PSO up and running. Z/Yen’s first Programme Manager worked over six months to set out the PSO’s
policies, procedures, methodology, reporting, staffing and training. He drew on
extensive formal project management and business process development skills,
e.g. PRINCE. Moreover, he changed the bias from ‘target users’ to customers. As
the post was new, Z/Yen convinced the client that the first Programme Manager,
who set up the PSO, should be followed by a second, ‘hardened’, interim
Programme Manager before seeking a full-time person. Z/Yen’s second Programme
Manager succeeded in transforming the client’s culture from operationally-based
to project-based over the following 12 months. With a successful PSO running
well, and a much better idea of the personality requirements, the client was
able to specify the requirement for a full-time person more accurately and show
candidates the appeal of the position. By this time, the chosen candidate came
from within the organisation. She had learned enough from the previous two
Programme Managers to take on the position and continue further her professional
development in project and programme management.
Structured programme management needs structured project management. There are
many potential sources for structuring project management ranging from very
thorough, e.g. PRINCE, to a simple control spreadsheet. An important decision is
to choose an appropriate level of management for the scale of programmes. Within
an organisation, programmes and projects can be of varying sizes; the trick for
successful programme management is to have a flexible suite of tools that enable
consistency with scalability. Typically, at a high-level, a six-stage process of
one-page checklists is sufficient. A good example is Z/ENITH:
-
‘Concept’ is a formalised approach to
project definition. It tries to take good ideas and get them into shape for
proper consideration. Ideas become project proposals signed off to proceed
to consideration;
-
‘Accept’ involves project acceptance
and sign-off, e.g. using scorecarding. It allows organisations to define
where responsibility for projects lies, at what level decisions are made and
who has ultimate responsibility for resources and costs and whether to
proceed at all;
-
‘Marshal’ concerns the management of
resources and timeframes. As well as assembling teams and budgets,
marshalling introduces checks and controls such as work plans, project
calendars, staff commitments, progress reports and key stage meetings;
-
‘Deliver’ is the stage at which the
work gets done. During delivery, plans are reviewed, progress reports are
issued, relevant documentation is prepared and distributed, cost and
resource estimates are reviewed and updated and any problems are identified
and resolved;
-
‘Check’ provides a framework for
checkpoints and milestones, for deliverables to be accepted, costings to be
signed off or appraisals and coaching to be performed;
-
‘Live & Learn’ is a formalised
approach to project evaluation, including the final acceptance, review of
the project, debriefing, ensuring that value has been obtained and lessons
learned. One of the crucial questions is not whether the project delivered,
but whether the benefits were realised and the results of the project handed
over successfully to the clients.
Output – Project Appraisal
Just as people should be appraised at the end of major assignments or periods,
so should projects. A formal appraisal process is crucial to organisational
learning. Successes and failures of the project are evaluated and recorded so
that learning can benefit future projects and the people involved in future
projects. Questions asked at this stage include:
-
what did we learn?
-
was the project delivered on time and if not
what can we do to prevent future over-runs?
-
was the project delivered within budget
and if not how can we prevent future overspend?
-
did the project achieve its objectives?
-
have we critically assessed any complaints?
-
have we identified materials and processes
that may be relevant or reusable for other opportunities?
-
are there any further projects that lead
naturally from this or enhance the results of this?
Organisations are different and require different
processes. Tools can be adapted and added additional tools applied, for
example problem-solving methodologies, to a variety of different cultures and
organisations.
Monitoring – Management Information
Monitoring systems are a rich topic, but the key thing is to recognise that
projects are about the future rather than the past. The implication for
monitoring is that management information needs to be able to handle a range of
outcomes, e.g. bottom, expected and top, rather than just a single point of
information, typical of historic information in financial systems. There will be
a range of reports that give management confidence, for instance:
-
project summary data showing dates, costs,
people, benefits, time variations, budget variations, scope variations,
expected returns;
-
expected return on programme portfolio;
-
breakdowns of resource usage, utilisation,
staffing gaps, milestones, risk areas.
For instance, a well-managed programme management
unit should regularly, i.e. weekly or monthly, be able to produce graphs such as
the following showing the overall state of the project portfolio:
Issues
Introducing programme management is not easy. Change generates resistance – will
the new system be too bureaucratic; will key staff be happy to give up
information; will the process be seen as too complex or not sufficiently
complex; what are the training implications? There are also issues surrounding
the programme management requirements – how tight or loose should the management
system be, and how widely and to what depth should it be implemented?
We believe that buy-in to the introduction of programme management systems
starts at the top and board level support is needed. Senior management, in our
opinion, need to understand the costs and benefits of programme management
before designing a programme management system. Research conducted by Z/Yen’s
team, “Vision into Action: A Study of Corporate Culture”, Journal of Strategic
Change, Volume 1, pages 189-201, John Wiley & Sons (1992), identified ten key
themes followed by most successful change programmes, which we believe apply
equally to programme management:
1. Direction from the top.
2. Emphasis on incremental change.
3. The crisis point as a trigger.
4. Culture change as an act of faith.
5. Involvement of staff.
6. Visibility of leaders.
7. Living with change.
8. The management development spiral.
9. Alignment of terms and conditions.
10. Decentralization and delayering.
A typical client might follow some or all of the
following six stages:
-
a clear specification of the problem,
the objectives of a programme management project, the benefits, the costs,
the risks and a suggested project plan for programme management, supported
by facts and figures on things such as project overruns, scope changes,
benefit losses and costs;
-
development of a management information
structure for programme management, i.e. the information a programme
management structure should provide in order to help management control
their myriad of projects;
-
development of the ‘light’ programme
management system, perhaps using Z/Yen’s Z/ENITH management system as a
basic, starter pack. A light system can be developed over time. The light
system then becomes the core control mechanism for project managers
throughout the organisation;
-
development of an initial scorecard,
project appraisal process and portfolio management system;
-
training and roll-out, almost
certainly preceded by a pilot;
-
enforcement and learning –
programme management and project management need strong, top-down leadership
before they become part of the culture.
Next Steps
The first stage, Specification, is more of a ‘study’ than development or
training, but this first stage is crucial for convincing decision makers of the
need and benefit of programme management. Without a clear specification of the
problem and suggested solution, a lot of work could be done on developing a
programme management system that would be rejected by the organisation’s project
managers. Z/Yen would be pleased to discuss how to develop appropriate programme
management for any organisation.
More information:
|
