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.
A 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:
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:
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.
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:
A sample scorecard is illustrated above. The idea is to approve projects over a certain score. However, projects that fail the ‘hurdle’ can re-adjust 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.
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:
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:
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 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:
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:
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:
A typical client might follow some or all of the following six stages:
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.