Role Of The Executive Project Sponsor

The Role of the Executive Project Sponsor FT Prentice Hall FINANCIAL TIMES In an increasingly competitive world, we ...

Author: Robert Buttrick

33 downloads 889 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

The Role of the Executive Project Sponsor

FT Prentice Hall FINANCIAL TIMES

In an increasingly competitive world, we believe it’s quality of thinking that will give you the edge – an idea that opens new doors, a technique that solves a problem, or an insight that simply makes sense of it all. The more you know, the smarter and faster you can go. That’s why we work with the best minds in business and finance to bring cutting-edge thinking and best learning practice to a global market. Under a range of leading imprints, including Financial Times Prentice Hall, we create world-class print publications and electronic products bringing our readers knowledge, skills and understanding which can be applied whether studying or at work. To find out more about our business publications, or tell us about the books you’d like to find, you can visit us at www.business-minds.com For other Pearson Education publications, visit www.pearsoned-ema.com

The Role of the Executive Project Sponsor ROBERT BUTTRICK

FT Prentice Hall FINANCIAL TIMES

An imprint of Pearson Education London ■ New York ■ Toronto ■ Sydney ■ Tokyo ■ Singapore ■ Hong Kong New Delhi ■ Madrid ■ Paris ■ Amsterdam ■ Munich ■ Milan ■ Stockholm

■

Cape Town

PEARSON EDUCATION LIMITED Head Office: Edinburgh Gate Harlow CM20 2JE Tel: +44 (0)1279 623623 Fax: +44 (0)1279 431059 London Office: 128 Long Acre London WC2E 9AN Tel: +44 (0)20 7447 2000 Fax: +44 (0)20 7447 2170 Website: www.briefingzone.com

First published in Great Britain in 2003 © Robert Buttrick 2003 The right of Robert Buttrick to be identified as author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988. ISBN 0 273 65945 6 British Library Cataloguing in Publication Data A CIP catalogue record for this book can be obtained from the British Library. All rights reserved; no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without either the prior written permission of the Publishers or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1P 0LP. This book may not be lent, resold, hired out or otherwise disposed of by way of trade in any form of binding or cover other than that in which it is published, without the prior consent of the Publishers. 10 9 8 7 6 5 4 3 2 1 Typeset by Monolith – www.monolith.uk.com Printed and bound in Great Britain by Ashford Colour Press Ltd, Gosport, Hants. The Publishers’ policy is to use paper manufactured from sustainable forests.

About the author

Robert Buttrick, is the author of the best-selling Project Workout, which has been published in the UK, Asia, USA, France, Russia and China. It is also available as an eBook on Pearson’s innovative ‘Safari’ service. He currently works in one of the world’s most turbulent industrial sectors, IP and data communications, as the Design Authority for a project-based framework for managing change within Cable and Wireless. Before joining Cable and Wireless in 1993, Robert worked for PA Consulting Group, the management and technology consultancy. There, he specialized in business-led project management, advising clients such as TSB Bank, National Rivers Authority, Property Services Agency, Avon Industrial Polymers and National Westminster Bank. His early career was as a civil engineer. After graduating from the University of Liverpool with a first-class honours degree, he joined Gibb Ltd, who provide consulting, design and management services for infrastructure projects worldwide. He has lived and worked in countries as diverse as Kenya, Mauritius, North Yemen, Senegal and Sudan, involved in the design and supervision of a number of marine and water resource projects. He also worked at the World Bank in Washington DC on investment appraisals for major development projects. Following this, he became Gibb’s manager for marketing strategy and analysis. Robert is a contributor to a number of management journals. He chairs and speaks at conferences, both public and corporate, and provides high-level coaching for project sponsors in both the public and private sectors. Robert is a Master of Business Administration (MBA – Henley Management College), a Member of the Chartered Institute of Marketing and a Member of the Institution of Civil Engineers. Robert may be contacted through his web site: projectworkout.com.

v

This book is dedicated to my wife, Sandra, and my son, Rhodri.

vii

Contents

List of tables

xii

List of figures

xiii

Preface

xv

Acknowledgements

xvii

Using this briefing

xix

PART ONE: UNDERSTANDING THE NATURE AND BENEFITS OF PROJECTS 1

2

3

4

The driving need for projects

3

Projects as vehicles of change The Project Sponsor as leader Summary

5 6 7

Ten lessons towards excellence

9

The lessons and their implications Summary

11 20

Introducing a staged approach to managing projects

23

The project framework Stages Gates

25 28 30

What is expected of you?

35

Your accountabilities as Project Sponsor Your key interactions Your personal style Reviewing your project Some tough choices for you to make Summary

37 40 44 45 48 52 ix

Contents

5

Benefits – realizing value for your organization

53

Benefits and drivers Tangible and intangible benefits Difficulties with measurement Conditions of satisfaction Forecasting benefits Timing of benefits Summary

55 55 56 57 57 58 59

PART TWO: RUNNING SUCCESSFUL PROJECTS 6

7

x

Initiation – setting up for success

63

Why formally initiate a project? Selecting the right project manager Project team and organization Project definition and planning Engaging your stakeholders Summary

65 66 70 73 76 79

Running a project in stages

81

Proposal Initial Investigation Gate Checklist Initial Investigation Stage Detailed Investigation Gate checklist Detailed Investigation Stage Development Gate checklist Develop and Test Stage Trial Gate checklist Trial Stage Ready for Service Gate checklist Release Stage Project completion checklist Post-Implementation Review Checklist at Post-Implementation Review Summary

83 84 85 86 87 89 91 92 93 94 95 97 98 99 99

Contents

8

Closure – being confident that you have reached 101 the start! Why closure? The closure report Formal closure review and approval Closure actions Summary

103 103 104 106 106

PART THREE: MANAGING SCHEDULE, COSTS AND RISKS 9

10

Schedule, cost and scope planning

111

Fundamentals The project schedule Summary and detailed schedule plan Critical chain Inter-project dependencies Project finances Authorization of funds Financial reporting Monitoring progress Summary

113 113 114 117 118 119 122 123 124 125

Risk, issues and change – your key indicators

127

Risks, opportunities, issues and change Considering the possible risks and opportunities Issues management – what has gone wrong Managing changes to the project Summary

129 130 136 138 141

Appendices A B C D

Glossary Further reading Roles and accountabilities Health check

145 153 155 159

xi

Tables

3.1

The stages of a project

29

3.2

The gates of a project

33

6.1

The three parts of a Business Case

66

6.2

Project management aptitude

68

10.1 Project change approval levels

xii

141

Figures

2.1

The context for project management and other processes

11

2.2

The project balance

15

2.3

Working across functions

16

3.1

The project framework in diagrammatic form

26

3.2

Address all aspects of the project in parallel

29

3.3

The three decisions required at each gate

31

5.1

Cash flow for a project ‘on time’

58

6.1

A typical stakeholder influence map

76

7.1

The staged project framework

100

9.1

A typical schedule plan

115

9.2

Putting the padding where it counts – towards the end

118

9.3

Estimating accuracy – the further away the stage, the softer the estimate 121

10.1 Risk, opportunities, issues and change

129

10.2 Risk matrix

131

10.3 A typical risk and opportunity log

132

10.4 Scenario analysis

135

10.5 A typical issues log

137

10.6 The change management process

140

AD.1 Project health-check analysis

160

xiii

Preface

Now we understand what we need to do, please tell the Project Sponsors what they need to do. This is the most frequent question I hear in a room full of hard-nosed, experienced project managers. No matter how well trained or experienced the project managers are, corporate objectives will never be achieved if there is not someone leading and directing the change. This is the tough challenge faced by the people this briefing is directed at: the Project Sponsors. Niccolò Machiavelli said that nothing is more perilous than creating a new order, and this is as true today as it was back in 1515 when he published The Prince. He continues by neatly summarizing an eternal situation: And it ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. This coolness arises partly from fear of the opponents, who have the laws on their side, and partly from the incredulity of men, who do not readily believe in new things until they have had a long experience of them. Thus it happens that whenever those who are hostile have the opportunity to attack they do it like partisans, whilst the others defend lukewarmly, in such wise that the prince is endangered along with them. Most organisations have now come to realize, in today’s faster-moving, integrated world, that the traditional functional hierarchy alone, with its line command structure is inappropriate. But many who realize this haven’t done anything about it! Why? Could it relate to the fact that many of the current leaders reached their positions through the rough and tumble of just such structures, with their interdepartmental rivalries and politics? It is a safe place for them, simply because it is familiar and they know how to work within it. However, the ‘safe and familiar’ place may not be the best place from which to direct and manage a modern organization or major change. The perceived ‘unsafe’ place to be is in a situation where you are trying to ‘create a new order’, working with and across many departments where the organization is primarily functionally managed. It takes great courage to move out of the safety zone and into a new cross-functional, benefits-driven project world. However, even in a more fluid environment, leading change can be just as

xv

Preface

fraught; it’s just that one dimension of organizational politics has been removed or reduced. You will still need to energize your stakeholders, win round the doubters and create an environment for delivery and benefits realization. Whether you are in a functional hierarchy or a cross-functional role-driven organization, you will have to draw on all your personal leadership qualities. If you are really serious about being a ‘senior manager’, vice-president or CEO, one of the skills you need is the ability to lead change, and this is where the role of Project Sponsor comes in. Leading beneficial change may not feel safe, but it is certainly the right place to be: when an organization fails, nowhere is safe – it is too late. Can you afford to ignore that?

xvi

Acknowledgements

I would like to thank all my colleagues at Cable and Wireless who have supported my efforts to bring enterprise-wide project management into reality in a very challenging environment. There are too many to mention; they know who they are and how important they are to me. While it is tough being the prophet in his own land, there is nothing better to keep you grounded in reality than living and working with the very people who have to make the aspirations described in this book happen on the ground. I would also like to thank the many organizations who have shared their knowledge and experience with me, either on a company-to-company basis, as part of formal benchmarking, or on a personal basis. This especially applies to Terry Cooke-Davies and the Human Systems Knowledge Network. The value of sharing ideas with others from a range of industries should not be underestimated. Companies are all different, but they have one important factor in common: they all comprise people … and people are at the heart of change. My publisher, too, has had its fair share of corporate change! I am now on my third brand! Thanks to Stephen Partridge and Martin Drewe. Working full time in the ‘real world’ of never-ending change takes its toll on employees. Writing a book in the evenings takes its toll on the family. Many thanks to the support of my wife, Sandra, and my son, Rhodri, to whom this briefing is dedicated.

xvii

Using this briefing

WHO ARE YOU? The target readers for this briefing are those senior managers, directors and executives charged with creating a new ‘order’ in their organizations. This may be new structures, policies, processes, capabilities, services or systems. It could also be major change resulting from reorganization, restructuring, mergers or acquisitions. The key question being answered is: What do I have to do to ensure that my change initiatives reap the benefits I require? As such, the briefing is as applicable in the public sector as the private sector, across all industries, whether service or manufacturing. It aims to provide you, as a leader, with the knowledge and skills to drive change effectively to the benefit of your organization and your own career. In this briefing, we will call this leadership role the Project Sponsor. The role of ‘Project Sponsor’ is typically taken on by very senior executives and often the Chief Executive him or herself. Throughout the briefing, when I address ‘you’, I mean you in your role as the Project Sponsor. The amount of autonomy you have will depend on your position in your organization. If you are the Chief Executive of an autonomous company, you will have far more freedom and authority than, say, one of your reports, or even one of their reports. This becomes important when choices have to be made between different projects. If you are directing the company as a whole, it is likely that you will make such decisions yourself. If you are not the Chief Executive, these decisions may need to be made by another person or group, with higher-level authority. If you are the Chief Executive of one of a group of interrelated companies, beware: you probably are not as independent as you would like. If the changes you want require the input of sister companies, you are really in the same position as a head of function in a traditional company!

WHAT YOU NEED TO KNOW AND DO The briefing covers a number of topics you will need to know about if you are to undertake your role successfully, some of which you will have to address yourself and others which will be undertaken by the project manager and team. If you and the project team share a common understanding of how a project is run, the scope for misunderstanding is reduced.

xix

Using this briefing

There are fundamental differences between line management and project management which underpin everything in this briefing: ■

Line management is about maintaining the status quo. It is performed in a relatively stable environment. It often abhors change as it spoils the everincreasing drive for efficiency by tuning the current operations within particular departments. People work in defined jobs and have a specific scope of activities. It is often predictable.

■

Project management is about change. Projects are one-off activities, carried out over a fixed time period, costing a set amount and aimed at achieving a stated set of business objectives. They often break new ground and step into the unknown. As such they are often unpredictable. They require management which can react and adapt to changing circumstances, conflicting pressures and unfamiliar situations. They are staffed by people from many functions and locations who have no set job description.

Part one, ‘Understanding the nature and benefits of projects’, very much sets out ‘what you need to know’. Once you understand the principles here, what you need to do becomes easier to understand. Embedded in the chapters are pointers to the actions you need to take and the aspects you need to consider when directing projects. Part two, ‘Running successful projects’, takes you through the stages of a typical project, providing you with an understanding of each stage, together with checklists and key questions. It also has chapters concentrating on setting up a project and closing a project. Part three, ‘Managing schedule, costs and risks’, centres around the key tools for managing projects. Around each of the topics are a number of activities you will need to undertake as part of your role. These are well marked in the text and often accompanied by checklists to lead you through.

THOSE UNFAMILIAR WORDS Project management, like many disciplines, has its own jargon, much of which may be unfamiliar to you. Some words and concepts may be new, while others may be familiar but are used in a different way. This is compounded by the fact that there is no single agreed glossary for the discipline as a whole. Different associations and organizations will use different words for the same thing. The differences between USA English and UK English also pose problems. If you come across a word you are uncertain about, take the time to consult the Glossary in Appendix A. Add to the glossary with either new words or your own organization’s alternative wording. A little time spent checking these as you work through the briefing could prevent confusion later. xx

Part one Understanding the nature and benefits of projects

■

1


■

2


■

3

Introducing a staged approach to managing projects 23

■

4


■

5


3 9

35 53

1

1 The driving need for projects

■

Projects as vehicles of change

5

■

The Project Sponsor as leader

6

■

Summary

7

3


PROJECTS AS VEHICLES OF CHANGE All organizations have to change at some time: some more frequently than others. There is always something, somewhere needing to be created or improved. Many leading organizations are now directing and managing change by using businessled project management techniques. Put simply, a project is a finite sequence of activities, undertaken within cost and time constraints, directed at achieving a stated business objective. Project management can be applied not only to traditional activities such as large engineering projects, but also to any business change initiative aimed at putting a part of a business strategy into action. As organizations have become more integrated through the use of complex systems and processes, the effectiveness of managing change through the traditional functional hierarchy has diminished. Projects, in the modern sense, are now strategic management tools, ideally suited to the complex organizations of today, and you ignore the reborn discipline of enterprise-wide project management at your peril. It is no longer the preserve of specialists in the engineering or IT sector but something for every director and manager to have in their ‘tool box’. Well-managed projects will enable you to react and adapt speedily to meet the challenges of your competitive environment, ensuring that you drive towards attainable and visible corporate goals. Most companies are never short of good ideas for improvement. Ideas can come from anywhere within the company or even outside it: from competitors, customers or suppliers. However, deciding which out of all these good ideas should actually be initiated is not easy. In all probability: ■

you don’t have enough money, staff or energy to pursue all your ideas;

■

undertaking ill-conceived projects, which are not aligned to your strategy, will almost certainly degenerate into conflict and confusion and ultimately threaten the success of your operations.

Choices will have to made or your organization, its people, customers and stakeholders will suffer. Some initiatives will be chosen to continue, some will not even be started, while others will have to be terminated. Project managementtechniques provide an excellent framework for making such decisions. Well-directed and managed projects will increase the likelihood of business success by ensuring visibility, accountability and control over business change activities. In particular by: ■

linking your business needs directly to visible actions plans;

■

enabling you to manage across every department in your organization;

■

ensuring that you can assign accountability, safe in the knowledge that any gaps are covered;

5

Part One: Understanding the Nature and Benefits

■

providing a flexible and responsive way of responding to changing needs;

■

focusing on priorities;

■

enabling you to track progress towards your objectives.

THE PROJECT SPONSOR AS LEADER As an executive, you are a leader of change within your organization. For some of you, still ascending the corporate ladder, this may be a new experience. You will be in the position of advocating a new order, acting in the interests of the wider company needs rather than those of the department or line director you serve. For the first time, you will operate outside your own departmental or functional boundaries. You will have to work with people you don’t have direct authority over. This will require you to exercise all your influencing and leadership skills in order to achieve your aims. In summary, the Project Sponsor is the business advocate who is accountable for directing a project to ensure that the business objectives are met and benefits realized. He or she may be supported by a Project Board, typically by ensuring that the needs of the customer, operational organization or other key grouping are represented. The Project Manager, on the other hand, is accountable for the dayto-day management of the project, defining and delivering a suitable solution. (These roles are described more fully in Chapter 4 and Appendix C.) In some organizations the Project Sponsor role is well defined and established. You will find your accountabilities detailed in process documentation, usually associated with a project management approach. In other organizations nothing will exist and you will have to create your role and accountabilities for yourself. (Chapter 4 will help you with this.) You will also need to work harder to influence those around you to undertake complementary roles, such as your project manager or Project Board. There is little point in you acting as a perfect Project Sponsor when the project manager you are relying on does not understand the approaches you are taking and the demands you are placing on him or her. Similarly, you have to set the expectations of your peers and the executive team to whom you report or on whom you rely for resources and expertise. You have to agree with them the degree of freedom you have and the formal authority they have vested in you. The more mature an organization is with regard to project management, the easier it will be for you to exercise your role as a Project Sponsor. Conversely, the less mature an organization is, the more difficult you will find that role … but as a leader, you will relish that challenge!

6


SUMMARY ■

The fact the status quo is untenable means that change is inevitable for all organizations. The key is making sure that all change represents progress, rather than change for the sake of change.

■

Projects are vehicles by which you can implement effective change, increasing the likelihood of meeting your business objectives.

■

The role of the Project Sponsor is to lead change and direct projects with the benefits in mind as opposed to managing projects with delivery in mind.

■

The effectiveness of the Project Sponsor is related to the maturity of the whole organization in project management.

7

2 Ten lessons towards excellence

■

The lessons and their implications

■

Summary

11

20

9


THE LESSONS AND THEIR IMPLICATIONS If project management is to be effective in any organization, a number of factors need to be applied. These affect not only the individual projects but also the environment in which all projects are carried out. The lessons described below were derived from a number of studies and benchmarking networks, involving a large number of organizations from a wide range of industries and public-sector bodies. Benchmarking confirms that: ■

the staged project framework is widely used for business change projects and is delivering better results than more traditional, functionally based project processes.

■

a cross-functional, project management-based approach is essential.

The challenge lies in having processes, systems, structures and a culture which address this, both at a working level and at the decision-making level (see Fig. 2.1). Processes exist to ensure consistency, when consistency adds value. Systems make the processes more efficient, accurate, faster and cheaper to operate. Structure provides the line management and cross-functional groups and accountabilities which own and operate the processes and systems. Culture provides the values which inform us how the processes, systems and structures need to be defined and operate.

Fig. 2.1

The context for project management and other processes

Process

Systems

Structure

Culture

Not addressing these will result in: ■

the wrong projects being undertaken;

■

late delivery;

■

failure to achieve expected benefits. 11


1 Make sure that your projects are driven by benefits which support your strategy. If you have no strategy, how do you know that what you intend to do will benefit your organization? When two radically different projects appear to have the same benefits, how do you choose between them? All companies have to make choices at some time. If you are to be effective, you must screen out the unwanted or suboptimal projects as soon as possible. At the very start of a project, there is usually insufficient financial information to make a decision regarding the viability of the project. You should, however, be able to assess strategic fit from the beginning. Not surprisingly, those companies with clear strategies are able to screen far more effectively than those without. Strategic fit is often assessed by means of simple questions such as: ■

Will the results of this project help ensure long-term relationships with our customers?

■

Will this new product ensure that we maintain our leadership position?

■

Will this operational method ensure that overall operating costs continue to reduce?

The less clear your organization’s strategy, the more likely ‘poor’ projects are to pass such initial screening. In these cases, there will be more projects competing for scarce resources, resulting in your organization losing focus and jeopardizing its overall performance. Remember, a clear strategy is also useless if you have not communicated it in a way managers can apply to their day-to-day decisions.

2 Use the same, simple and well-defined framework, with a staged approach, for all projects in all circumstances. A staged (or phased) framework was found to be well established in all the organizations surveyed which demonstrated excellence in project management. Rarely is it possible to plan a project in its entirety from start to finish; there are simply too many unknowns. By using defined project stages, it is possible to plan the next stage in detail, with the remaining stages planned in outline. As you progress through the project from stage to stage, your end point becomes clearer and your confidence in delivery increases. Chapter 7 will ensure that you become familiar with this. It is apparent that companies are striving to make their project frameworks as simple as possible, minimizing the number of stages and cutting down the weight of supporting documentation. Further, the same generic stages were used for all types of project. This makes the use and understanding of the framework very much easier and avoids the need for learning different frameworks and processes for different types of project. This is particularly important for project sponsors or 12


those who are infrequently involved in projects. By having one basic framework they are able to understand their role within it and do not have to learn a new language and approach for each situation. A common fallacy is that a staged approach slows projects down. This was explored in the interviewing and found not to be the case. In contrast, a staged approach speeds up desirable projects; it only slowed down the ‘dud’ projects. The existence of so-called ‘fast-track’ processes to speed up projects was also investigated. In all cases, the companies said that their ‘usual process’ was the fast track. Doing anything else, such as skipping stages or going ahead without fully preparing for each stage, increases the risk of the project failing. The experience of some companies was that ‘going fast’ actually slowed the project down; the amount of rework required was nearly always much greater than the effort and time ‘saved’.

3 Address and revalidate the marketing, commercial, operational and technical viability of the project throughout its life. Projects are not just about technology. I often argue that there is no such thing as an ‘IT project’ – just projects with a high IT component! Figure 2.1 emphasized this point. An IT system with no processes to support it and people to run it is useless! In practice, many things need to happen across an organization before any benefit can be realized; these often revolve around training, operational processes and the deployment of people and equipment. A project must include all aspects which are prerequisite to benefits realization, regardless of whether the skills or resources come from inside or outside the organization. For example, I reviewed a ‘project’ where the necessary power and air-conditioning upgrades relating to a computer hardware installation were considered ‘outside the scope of the project’ as they were not IT! And yet without this, the computer equipment simply would not work. Projects always require a mix of people, skills, organization, processes and technology: no single one of these aspects should be allowed to proceed at a greater pace than the others. As the project moves forward, the level of knowledge increases and the overall level of risk should decrease. At particular points in the project, you should ask yourself: ■

Is the project still needed and viable?

■

Are the benefits still there for the taking?

■

Can the technology be made to work?

■

Have we the operational resources to manage the outputs?

■

Can we maintain this at an economically low cost?

In addition to this, every organization must have the ability to terminate projects. There is little point in reviewing the overall viability of a project if there is no will 13


on behalf of the decision makers to accept termination as an option. It’s a tough world, requiring tough decisions, but we might as well make sure that they really do benefit the business!

4 Incorporate stakeholders into the project to understand their current and future needs. The involvement of stakeholders, such as users and customers, in projects was seen as essential in all stages of a project. Usually, the earlier they are involved, the better the result. The more ‘consultancy-oriented’ companies must, by the nature of their work, talk to customers to ascertain their needs. But even these companies say that they often misinterpreted the real needs of the customer despite great efforts to avoid this. Where project teams are more removed from their users or customers, there is even greater scope for misunderstandings. Many innovative ways have been used to obtain this involvement, including: ■

focus groups;

■

facilitated workshops;

■

early prototyping;

■

simulations and walk-throughs.

Involving the stakeholders is a powerful mover for change, while ignoring them can lead to failure. When viewed from a stakeholders’ perspective, your project may be just one more that they have to cope with as well as fulfilling their usual duties; it may even appear irrelevant or regressive. If the stakeholders’ consent is required to make things happen, you ignore them at your peril!

5 Build excellence in project management techniques and controls across the company. To ‘make it happen’ on the ground, a wide range of project management techniques need to be applied – this is the skill set of your project manager. Project management techniques include: ■

planning and monitoring;

■

risk and issues management;

■

change management.

‘Planning’ ensures you achieve the benefits within defined cost, resource scope and schedule constraints (see Fig. 2.2). All of this is done in an environment of assumptions, constraints and risk. Part 3 of the brief will ensure that you are familiar

14


enough with these techniques to be able to judge whether or not your project is being managed effectively. Planning as a discipline is essential. If there is no plan, terms like ‘early’, ‘late’ or ‘on time’ have no meaning. It is also far too important for the project manager to delegate to junior members of the project team. A project plan is, in fact, a model of what is likely to happen. Together with risk management, planning enables a project manager to understand the different futures that may lie ahead. He or she is able to model ‘what if’ scenarios and define an approach to avoid the major pitfalls and risks. Risk management is often quoted as being the most important project management tool. It is vital to take risk into account when producing a project plan and to keep revisiting the risk environment throughout the project. Projects are inherently risky, but in business-led projects it is not only the risks to the project deliverables we must consider but, more importantly, the risks to the benefits – and that is where you, as the Project Sponsor, come in. Risks to benefits may dwarf all other deliverable-related risks. Analysis and planning around risk needs to be undertaken in the investigative stages and the approaches firmly built into the plan. Fig. 2.2

The project balance Cost

Area of benefit viability

Project Time

Scope

Despite excellent planning and risk management, things will go wrong! Unforeseen issues will arise and need to be addressed. These, if not resolved, may threaten the entire success of a project. Monitoring and forecasting against the agreed plan will ensure that events do not take those involved in the project by surprise. Always focus more on the future than on what has already happened. A project sponsor or project manager can only influence the future: the past is fixed. Similarly, completion of activities so far is only evidence that progress has been made, not necessarily an indication that progress will continue to be made. Your Project Manager should be continually checking to see that the plan is still fit for the purpose and likely to realize the benefits it was set up to achieve. Ultimately some issues cannot be resolved without some redefinition of the project. It may require a scope change, an extension of time or additional funds.

15


In such circumstances change control comes into play. Change control ensures that only changes which are beneficial to the business are implemented and that the project is not derailed by bright ideas or good intentions. Changes are a fact of life and cannot be avoided, but preventing negative change is possible. In some circumstances, the right decision is to terminate the project – the ultimate change! Many companies which have been aiming to realize the benefits of business-led project management have concentrated solely on project management techniques and training: they have been disappointed by the results. This is because they need to apply the other nine lessons and ensure the leadership of the organization promotes a culture which fosters cross-company working, decision making and collaboration. Without these, even the best project manager using the best techniques will find it very hard to succeed.

6 Break down functional boundaries by using cross-functional teams. As we have seen above, a business-led project requires resources and skills from across the whole company. It therefore stands to reason that any organization serious about change must be able to work in cross-functional teams, drawing people from wherever is necessary (see Fig. 2.3). Running projects in functional silos and ‘co-ordinating’ between them is always far slower, produces less satisfactory results and increases the likelihood of errors and conflict. Companies recognizing this have working practices which encourage lateral communication rather than hierarchical communication and thrive better than those still stuck in the functional hierarchies of the 1970s. Fig. 2.3

Working across functions Chief Executive

Services Marketing

IT

Finance Manufacturing

Cost

Project Sponsor

Project 1 Project Time

Scope

Cost

Project Sponsor


Project 2 Project Time

16


Scope


In some cases, cross-functional co-operation goes as far as removing staff from their own departmental locations and relocating them in project-team work spaces. In others, departmental staff who frequently work together are located as close as is practical in the company’s premises. Generally, the closer people work, the better they perform. Unfortunately, close working proximity is not always a practical solution in these days of global projects. However, frequent meetings and good communication can compensate for a lack of physical proximity. This can be encouraged by using techniques such as video-conferencing, audio-conferencing and shared-project ‘web spaces’ which include discussion groups and chat rooms where everything on the project is available to all the team, anytime, night or day. For the first time in history, projects can continue while one half of the team is in bed in the Europe and the rest are working in the Far East. Cross-functional team working, however, is not the only facet. Direction and decision making also have to be on a cross-functional basis, and you are key in this. There is little point in people working in teams across the whole company if directors and decision makers in different parts of the company give conflicting instructions, make contradictory decisions or are working to different agendas. For companies still tied to the functional hierarchies or where the executives do not work well as a team, a movement to cross-functional decision making can be very difficult. In practice, this can mean very senior people giving up some personal authority (and often perceived ‘face’) to another individual or body with accountabilities to direct the work, in the best interests of the company as a whole. Adequate financial management is another key component and, in immature organizations, can be a significant braking factor. It is far easier to run the accounts using a simple functional hierarchy, and often this is the only approach some accountants know. As we have seen, however, modern organizations do not work that way. They require cross-functional direction and management, which should, in turn, be supported by cross-functional management accounting.

7 Use dedicated resources for each category of development and prioritize within each category. The assignment of resources to projects is something most companies still have not managed to grasp. In many companies, internal projects are resourced by people who both work on the day-to-day processes within the company and have a role to play in projects. The challenge has always been how to deploy these resources effectively in such a way that neither the business of today nor the business of tomorrow suffers. There are two extreme approaches which can be taken. The first approach is to ‘separate’ your resources. That is to say, apply dedicated resources to each type of project, say, aligned around a business unit, and take this principle as deep into the company as possible. In other words, organize your

17


functional structure to ensure that the teams and departments are arranged so that they can be readily deployed into project teams for the particular type of project they are set up for. This approach has a number of advantages. Potential conflicts are limited and decision making more localized – local decision making is usually far quicker. In fact, the deeper you take this approach, the more localized (and hence quicker) your decision making can be as you have fewer people to consult and engage. There is, however, a major disadvantage. By building such teams into your functional structure and head count, you severely limit your flexibility to react to emerging market and business imperatives. You will have to reorganize and resize your resource pools continually to meet demand and any other challenges in the marketplace. In a fast-moving industry, this may mean that you have the right number of people in the organization, but they may be in the wrong place! At worst, it will lead to continuous, expensive and damaging reorganizations. If your organisation is very interdependent across its functions or business units, the scope for localizing project resources is very limited, and this approach to resource management will not deal with the more far-reaching business change projects, only local ones. The second approach is to have staff organized into resource pools, based on their skills and knowledge. Most consulting organizations follow this approach. Any individual could be working on any number of projects in a week and there may be many hundreds of projects in progress at any point in time. It is very effective, conceptually simple and totally flexible. The need for major reorganization is less frequent. Unfortunately, it is also the most difficult to implement in an organization with a strong functional management bias. As we learned in lesson 6, functional hierarchies tend to find cross-functional working and decision making extremely difficult. Neither approach is ‘right’ or ‘wrong’; they are just different and need managing differently. Whatever approach your organization chooses to take, it is vital to make sure that your resource management, accounting and project systems are all able to support management reporting on both functional and project/process axes.

8 Place great emphasis on the early stages of the project. A Finnish company told me: ‘Skipping the first stage is a driver for failure.’ Both research and observation have shown that paying attention to the investigative stages of a project pays dividends. One American company found that 40–50 per cent of the project timescale could effectively be spent on investigation before any deliverable is built. Not only that – they found that such attention to the investigative stages made final delivery quicker and more reliable.

18


Good investigative work means clearer objectives and plans; work spent on this is rarely wasted. Decisions taken by you in the early stages of a project can have a far-reaching effect on the outcome. By choosing alternative solutions and approaches to projects, it is possible to double, or even treble, the benefits, cut costs by a fraction and slash delivery time by months. However, once a plan is set and the approach has been defined, the opportunities for improvement are very much smaller. Good up-front definition reduces the likelihood of changes later in the project: most changes on projects result from misunderstandings, misinformation or lack of definition from work done in the early stages. The faster you force the Project Manager through these, the more likely you are to be storing up problems for the future. The further you are into a project, the more costly changes to the definition become. You should resist the pressure (for what superficially appear to be all the right commercial reasons) to force or encourage the Project Manager to skip investigative and planning work and ‘get on with the real work’. Companies with a more mature approach to the management of change have often learned, from bitter experience, that they can’t move any faster by missing out essential work. They know that skipping investigative stages leads to commercial failure, and whenever they have tried this for the sake of speed, they have always paid the penalty in higher operating costs, reduced revenues and dissatisfied customers and employees.

9 Build the business case into the company’s forward plan as soon as the project has been formally approved. In a business-led environment, projects are about creating the ‘company of tomorrow’. Projects are the vehicles for creating future business change and often form the basis of future revenue generation. It is, therefore, essential that the company knows which projects are being undertaken and how they fit into the wider corporate objectives. (See lesson 1.) Taking this one step further, it is vital for the executive team of a company not only to see the full list of projects they are undertaking, but also to see how each is contributing to the cost base of the company and to its revenue generation. It is for this reason that costs and benefits resulting from the business case in each project need to be built into the business plan as soon as a project case is proven. Unless this is done, the business leaders will have no idea how they will fill the gap between where they are now and where they want to be in the future. They will also find it impossible to prioritize projects as they will have no basis on which to make the selection, even if the strategy is clear. In this context, the project (or projects) you are sponsoring are a slice of the future business plan which, if they fail, will leave a gap in performance which will need to be filled by alternative means or will lead to under-performance of the organization as a whole.

19


10 Close the project formally to build a bridge to the future, to learn any lessons and to ensure a clean handover. If you are in an organization with tight margins, closing projects as soon as they are finished is a ‘no-brainer’. Such companies simply can’t afford the luxury of wasting money by tinkering with project deliverables they have already completed. Tinkering with that final deliverable and polishing the final output is not an option for them. For other companies, in industries operating under a strict regulatory environment (for example aerospace), the concept of not having formal project closure is again unthinkable. They are required to keep full records of every step of the development of a new aircraft and each of its components, together with the testing certificates. Not to have full records on these critical components is unimaginable. And yet, project closure is something many organizations ignore. The project team moves rapidly onto the ‘new’, leaving the ‘old’ not quite finished. Companies with a mature outlook on project management all have a formal closure procedure. This usually takes the form of a closure report highlighting outstanding issues, ensuring explicit handover of accountabilities and making it crystal clear, to those who need to know, that the project is finished. Another reason for closure is the need to learn the lessons of the past and make sure that they can be applied in the future. This can be a vital time for collecting the views and opinions of those engaged on the project to see how the methods, practices, relationships and systems work towards helping people deliver the results. One final thought: if you don’t have project closure and you keep a list of the projects you are doing (a project register), the list of projects you are sponsoring will grow longer and longer and longer and longer and longer and longer and longer and longer.

SUMMARY ■

Make sure that your projects are driven by benefits which support your strategy.

■

Use the same, simple and well-defined framework, with a staged approach, for all projects in all circumstances.

■

Address and revalidate the marketing, commercial, operational and technical viability of the project throughout its life.

■

Incorporate selected users and customers into the project to understand their current and future needs.

■

Build excellence in project management techniques and controls across the company.

■

20

Break down functional boundaries by using cross-functional teams.


■

Use dedicated resources for each category of development and prioritize within each category.

■

The start of the project: Place strong emphasis on the early stages of the project. Do not force your team to skip this vital work, which sets the pace and tone for the remainder of the project and has such a large impact on downstream benefit realization.

■

The middle of the project: Build the business case into the company’s forward plan as soon as the project has been formally approved.

■

The end of the project: Close the project formally to build a bridge to the future, learn any lessons and ensure a clean handover.

21

3 Introducing a staged approach to managing projects

■

The project framework

■

Stages

■

Gates

25

28 30

23


THE PROJECT FRAMEWORK Projects draw on many resources from a wide range of functions within an organization. Ensuring that these are focused on achieving specific, identified benefits for the company is a key challenge for you as the Project Sponsor. You can increase the likelihood of success for your project, and hence for your business, by following a project framework which: ■

is business-led, i.e. benefit-driven;

■

is user- and customer-focused;

■

harnesses the skills and resources in the company;

■

builds ‘quality’ into the project deliverables;

■

helps manage risk;

■

allows many activities to proceed in parallel (hence greater velocity); and

■

is used by people across your whole organization.

As we have seen from lesson 2 in the previous chapter, sound approaches to tackling projects achieve all these objectives by breaking each project into series of stages and gates forming a framework within which every project in the organization can align itself. This enables you to gain control of two key aspects of your business: ■

For an individual project: – You know that each project you are sponsoring is being undertaken in a rational way with the correct level of checks and balances at key points in its life. – You do not have to make a decision for a project at a single point in time. By having a staged approach, you decide whether or not to continue the next stage, bearing in mind the risks and likely outcomes. – As risk decreases as you move through the stages of a project, you can use the ‘stage’ as an indicator of the confidence you can have in realizing the benefits.

■

For many projects: – A common framework makes it easier to compare projects. – Common terminology makes communicating with the team easier as you and they will use the same language. – If this is applied to all projects in your organization, your executives will be able to view the entire portfolio of projects at a summary level. By using the generic stage descriptions, everyone will know where each project is at, and the implication this has on risk and commitment.

25

Identify opportunity Assess fit with strategy and other project portfolios Identify stakeholders

Proposal

■

■

■

■

■

■

■

Initial Business Case

Evaluate, in outline, operational, technical and commercial viability Assess impact on organization Check any legal, regulatory or patent issues Identify options Undertake initial investment appraisal Plan the next stage of the project

Initial Investigation

■

■

■

■

■

■

■

■

■

■

■

■

■

Development Gate

Output Definition Feasibility Report Test Plan Business Case

Define technical and operational requirements Assess possible solutions Design solutions in outline Obtain quotes from suppliers Undertake Feasibility Review Define the chosen solution Do investment appraisal Recheck legal, regulatory and patent issues Plan remainder of project

■

■

■

■

■

■

■

■

■

■

■

Test Results Trial Plan Ready for Trial Review Report

Develop the solutions Manage quality of deliverables Develop training and train users Finalize supplier arrangements Obtain legal, patent and regulatory permissions Test solutions Prepare for trial Check and refine plans for remainder of project

■

■

■

Direct and manage a project

Trial

Trial Results Ready for Service Review Report

■

■

■

■

■

Release

Project Closure Report

■

■

■

PIR

Post-Implementation Review Report (PIR)

Assess the effectiveness of project in meeting the business objectives Check that operational aspects are working effectively

(Post-Implementation Review)

Project completed

Completion ■ Ensure the project scope is completed, lessons learned and team demobilized

Launch/release capability/service Carry out remaining training and other tasks Hand over solutions for ongoing management Carry out closure review

RFS Gate

RFS Gate ■ Ensure the service is ready to be used under full, operational conditions ■ Confirm launch date

Conduct trials in operational environment and refine solution

Trial Gate

Trial Gate ■ Review if the service is ready to be used in a trial environment

Develop and Test

Development Gate ■ Review Business Case ■ Commit development and operational resources

Detailed Investigation

Detailed Investigation Gate

Detailed Investigation Gate ■ Review Initial Business Case ■ Commit resources to at least the next stage

Note: The deliverables in bold are the key control deliverables on which gate decisions are made. Other deliverables are optional, depending on the project.

■

Deliverables

■

■

■

Major activities

Ideas!

Initial Investigation Gate

Proposal

Gate Reviews

Initial Investigation Gate ■ Decide if the idea should be investigated further ■ Confirm sponsorship ■ Confirm strategic fit

The project framework in diagrammatic form

Needs!

Fig. 3.1


But what do these ‘stages’ look like and what are they for? The project framework is shown in Fig. 3.1 as a diagrammatic overview. The stages are described more fully in Chapter 7 and are, briefly, as follows:

Identify the need – Proposal A need is first formally recognized by describing it. State what the business need or opportunity is. Say why you want to initiate a project. If known, you may also describe what you believe the project will produce (i.e. its output), but do not jump to conclusions on this!

Have a quick look – Initial Investigation Stage The first stage in the project is to instruct your Project Manager to undertake a quick study of the Proposal, outline the scope and make a rough assessment of the possible ways forward, benefits, resources and costs needed to complete it. At the end of this stage you should be sure of why you are doing it. You may also know what you are doing, although this may comprise a range of defined possibilities. You will know how the Project Manager will approach the next stage, if not the full project. You should know roughly how much it will cost, the resources likely to be needed and the order of magnitude of the benefit you can expect. This will be defined in an initial business case.

Have a closer look – Detailed Investigation Stage A feasibility study is carried out to determine the best solution to the business need. This is followed up by the Project Manager and team defining the chosen option and then preparing a project plan to make it happen. From this, a full investment appraisal is done to see if it makes sense. This stage culminates in your deciding either to proceed with development or to abandon the project. At the end of this stage you should have high confidence in all aspects of the project, and ‘What you wanted to do’ becomes ‘What you are going to do’!

Do it! – Develop and Test Stage The Project Manager and team undertake the actual development work.

Try it – Trial Stage If necessary, a trial of all aspects of the development in the users’ or customers’ operational and working environment is undertaken. What has been created may work very well under ‘test conditions’, but does it work under normal operational conditions? 27


Use it – Release Stage This is the last stage in the project, when you unleash your new order on the world! This is when products are launched, new computer systems cutover, new manufacturing plant goes into production, new organization units start operating to the ‘new rules’, new processes are invoked, acquisitions sealed and disposals shed. The ongoing operational aspects are embedded in the business and the project is formally recognized as complete.

How did we do? – Post-Implementation Review About three to six months after completion, a check, known as a PostImplementation Review, is done to verify the project is achieving its business objectives and realizing the expected benefits and that its outputs are performing to the standards expected.

STAGES Stage or phase? Some organizations refer to what I call ‘stages’ as ‘phases’. This is a matter of choice. In the UK, the word ‘stage’ is more common; in the USA the word ‘phase’ is used. I have chosen ‘stage’ as it leaves the word ‘phase’ free to describe a project within a programme of projects: Phase 1 project, Phase 2 project etc. The Glossary in Appendix A defines all the terms used in this briefing, as well as giving common alternatives.

What is a stage? Stages are specific periods during which work on the project takes place. These are when information is collected and outputs (deliverables) created. During each stage of the project, the full range of work, covering the entire scope of functional inputs required, should be covered (see Fig. 3.2). These functions should not work in isolation but as a cross-functional team, in a continuous dialogue with each other, thus enabling the best overall solution to be developed. In this way knowledge grows on all fronts at a similar pace and solutions are designed, built and tested in an integrated way. No one area of work should advance significantly ahead of the others. The solution will not be what is merely optimal for one function alone but will be a pragmatic solution best for the company as a whole.

28


Fig. 3.2

Address all aspects of the project in parallel

Marketing Commercial

Operational Technical

During each stage it is essential for the Project Manager continually to forecast and reforecast the benefits, resources and costs needed to complete the project. He or she should always keep the relevant functions informed and check on behalf of you, as Project Sponsor, that the project still makes sound business sense. Before you approve the start of work on any stage, you should always know what the project team is going to do next in order to increase confidence in delivery and decrease risks; you should check that there is a detailed project plan for at least the next stage and a summary for the full project.

Stage names used in this briefing and possible alternatives Different organizations have different names for the stages. I have included some alternatives in Table 3.1 so that, whatever the environment you are working in, you will be able to reference it to this briefing. If your organization has a standard staged framework, map it to the one in this briefing by writing your terms in the relevant box in the left-hand column. Table 3.1

The stages of a project

Terminology used in this briefing

Alternative terminology

Proposal ‘Identify the need’

Ideation Concept Initiation Idea generation

Initial investigation ‘Have a quick look’

Pre-feasibility Initial assessment Preliminary investigation Evaluation Research

29




Detailed investigation ‘Have a closer look’

Feasibility Definition Business case Evaluation Solutioning Authorization

Develop and test ‘Do it’

Implementation Execution Develop Realization Production Construction Build

Trial ‘Try it’

Beta test Validation Commissioning

Release ‘Use it’

Launch Implementation Handover Acceptance Closure Completion

Post-Implementation Review ‘How did we do?’

Business review Post-Project Review Project audit

GATES Gates are the decision points which precede every stage. Unless specific criteria have been met, as evidenced by certain approved deliverables, you should not approve the start of the subsequent stage. Gates serve as points for you to: ■

Check that you still require the project and that the risks associated with it are acceptable.

■

Confirm its priority relative to other projects.

■

Agree the plans for the remainder of the project.

■

Make a go/no-go decision regarding continuing the project.

Gate criteria are often repeated at consecutive gates to ensure that the same strands of the project are followed through as the project progresses. You should

30


expect a greater level of confidence in the responses to the criteria the further you move into the project. At each gate, three distinct questions will need to be answered (see Fig. 3.3): ■

Is there a real need for this project and, in its own right, is it viable?

■

What is its priority relative to other projects?

■

Do I have the funding and resources to undertake the project?

It is convenient to think in terms of these questions because, in most organizations, discrete people or groups are needed to address each of them. Fig. 3.3

The three decisions required at each gate

Project in isolation

Project relative to other projects High

Yes Viability? No

Priority? Low

Funding?

Go!

No

Terminate project

The first question concerns the viability of the project assuming no other constraints. Does it fit your strategy? Does it make business sense? Are the risks acceptable? You as the Project Sponsor are accountable for answering this. The second question (priority) concerns the project, in its context. Your project may be a very worthy project, but how does it measure against all the other projects your organization needs to do or is currently doing? Are there more worthwhile projects to address? Is it just ‘one more risk too far’, in view of existing commitments? This is a question for the management board, unless you are also the sponsor for the competing projects. The third question involves funding and resources. Traditionally, organizations have discrete and very formal rules concerning the allocation of funds, and these are generally managed by a finance function. So, you might have a viable project and it may be the best of those proposed, but is there the cash to finance it? Not so many organizations have formal ways of committing the resources to projects across all functions. Organizations which are mature in their business-led project management will often have a single body making the choices on Questions 2 and 3.

31


Gates – end points or start points? Gates have traditionally been defined as end points to the preceding stage. The logic is that the work in the stage culminates in a review (the end of stage assessment) where a check is done to ensure that everything is complete before the next stage is started. However, because of time pressures, it is often necessary to start the next stage before everything in the previous stage has been fully finalized. For example, in the typical framework in Fig. 3.1, we see that it may make sense to undertake a trial operation of our new output before all the process, training and communication work is completed. What is essential is that we have sufficient work done to enable us to start the next stage with confidence. We are, therefore, left with the difficulty of having a traditional ‘rule’ that common sense encourages us to break. The solution to this dilemma is to treat gates as entry points to the next stage. In this way you can start the next stage (provided relevant criteria and checks have been done) as soon as you are ready, regardless of whether the full work scope of the previous stage has been completed. In this way, stages can overlap, reducing timescales without increasing the risk associated with the project. This approach also opens another powerful characteristic of the staged framework. Gates are compulsory; stages are not. In other words, provided the work needed to pass into a stage has been completed, how you arrived there is not material. This allows you to follow the strict principles of the staged process even if a stage is omitted. By treating gates as entry points to the next stage, you can approve the start of the next stage as soon as you are ready, regardless of whether the previous stage has been completed. What happens next is far more important than what happened in the past; you are, after all, creating a new order.

Gate names used in this briefing and possible alternatives Different organizations have different names for the stages, and the same applies to the gates. Table 3.2 includes some common alternatives. If your organization has a standard gated framework, map it to the one in this briefing by writing your terms in the relevant box in the left-hand column in the table.

32


Table 3.2

The gates of a project




Concept Gate Proposal Gate Initiation Gate


Feasibility Gate Evaluation Gate Initial Business Case Gate

Development Gate

Business Case Gate Authorization Gate Implementation Gate Execution Gate

Trial Gate

Beta Test Gate Validation Gate Commissioning Gate

Ready for Service Gate

Operation Gate Implementation Gate Handover Gate

Project completed

Closure Gate Project End Gate

Questions for you to ask yourself at the gates ■

What overall business objectives is the project driving towards?

■

Is this still a valid business need or opportunity?

■

After what length of time will the project cease to be viable?

■

How big is the overall risk to the company with/without this project?

■

Do you have enough cash to carry out the project?

Questions for you to ask line managers at the gates ■

Are you satisfied that the project team is taking due account of your needs in the design and development of the solution?

■

When will you have the capacity to undertake the project (in terms of people and other resources)?

■

When/can you accept this change into the operational environment together with all the other change projects being undertaken?

33


Questions for you to ask the Project Manager at the gates ■

What stakeholders have you engaged? Can you demonstrate that they are positive (or at least neutral) about the project? If not, what action is planned to engage the antagonists?

■

What other projects depend on this project? Show me a list of the dependent deliverables.

■

Have you prepared a detailed plan for the next stage? Show it to me.

■

Does your plan take account of the known risks to both delivery and realization of the benefits? How?

34

4 What is expected of you?

■

Your accountabilities as Project Sponsor

■

Your key interactions

■

Your personal style

■

Reviewing your project

■

Some tough choices for you to make

■

Summary

37

40 44 45 48

52

35


YOUR ACCOUNTABILITIES AS PROJECT SPONSOR The Project Sponsor with single-point accountability Do you often find people in your organization hunting around for someone to ‘sponsor my project’? If so, you need to consider carefully who you think is running the organization! A Project Framework is not a sophisticated ‘company suggestion scheme’ which collates ideas from everywhere and assembles them into ‘good ones’ and ‘bad ones’. Rather, projects are ways of implementing strategy on the ground, moving the organization towards the business leaders’ vision. It therefore follows that it is the business leaders who should be proactively seeking the ‘Project Sponsor’ role and looking for people to manage ‘their projects’, not the other way round. This established, it is essential to determine who is accountable for directing and leading what. One of the principles of project management is that of single-point accountability. This refers not only to the management of projects and the constituent work packages, but also to the direction of a project. There should be only one Project Sponsor per project. In this respect, the term ‘sponsorship’ should not be used in the same sense of ‘sponsoring Tom to run a marathon’, where the objective is to have as many sponsors as possible. Such people are better termed ‘stakeholders’.

Your role and accountabilities You will need to be a: ■

business leader;

■

change agent;

■

decision maker.

As a business leader We have seen from Chapter 1 that your role is primarily one of business leadership. As the Project Sponsor, you are the primary risk-taker and accountable for the realization of the benefits to the organization. This is an active role and includes ensuring that the project always makes sound business sense, involving all benefiting units (using a Project Board if appropriate), approving key deliverables and making decisions or recommendations at critical points in the project’s life. Consequently, you will probably be a director, executive or senior manager. In particular you will: ■

ensure that a real business need is being addressed by the project;

■

ensure that the project remains a viable business proposition, bearing in mind any changes to the environment; 37


■

initiate project reviews;

■

ensure that the delivered solution matches the needs of the business;

■

represent the business in key project decisions;

■

sign off key project deliverables and project closure;

■

resolve project issues outside the control of the Project Manager;

■

chair the Project Board (if one is required);

■

appoint the Project Manager and facilitate the appointment of team members.

This is not merely a ‘figurehead’ role. You are fundamentally accountable for ensuring ‘why’ the organization is spending time and resources on a particular project, making sure that whatever is being created is really needed and that the need is fulfilled in a viable way. The project team will have their heads down developing whatever outputs and deliverables are needed. You have to keep your head up, making sure that the need still exists and that the capabilities being produced will fit the need. The degree of confidence you show in your leadership will critically influence how others behave towards you, and therefore communication and influence are skills you need to have.

As a change agent Some may see the roles of change agent and leader as synonymous. If so, that is good. For others, I have separated these out so they can be related to what consultants and academics often refer to as ‘the management of change’. Every project will create some change in the organization, otherwise there is no point in undertaking it! However, some changes are ‘easier’ to effect than others as they align with the status quo and do not cross any politically sensitive boundaries. In essence, most of the people carry on as they always have done. Other changes, however, are fundamental and will result in shifts in power bases internal to the organization or even external, for example involving unions, suppliers or customers. All organizations are ‘political’ to some extent, and the greater your project’s scope to change the status quo, the more you will need to be tuned in. You will need to identify the power bases you and others are operating from. These include: ■

position power, which results from rank and formal authority;

■

status, which results from how people perceive an individual; it is often related to their charisma and leadership qualities, and may bear no relationship to facts of any particular project!

■

resource power, where a person has direct authority over resources and can therefore smooth the way for or block any initiative requiring those resources;

38


■

expertise, where the knowledge or skill of an individual is such that others listen to and follow them.

As decision maker The decisions you will need to make will fall into two categories: ■

decisions which steer the project in a certain direction;

■

approval of certain deliverables.

The first category relates to go/no-go decisions at the gates, decisions regarding how to react to issues and changes, decisions on when to close the project. The second category relates to particular outputs from the project. It should not be necessary for you to approve every single deliverable. But it is necessary for you to agree who should have approval authority over which deliverables. You may also believe that certain deliverables are critical and therefore retain approval for yourself. If you are unable to make decisions, the role of Project Sponsor is not likely to be a role you will be comfortable with. Most of the decisions you will have to make will be predictable (in terms of timing, if not outcome!) and backed up by evidence. The key control deliverables are designed to provide you with the information you need (see Fig. 3.1). In addition, you can call for supplementary information (for example a Feasibility Report) to help you. Make sure that you do not spring the requirement for these onto your Project Manager as a surprise; you should make your needs plain from the start, when a particular stage of the project is being planned.

What if you haven’t the time to undertake the role? Quite often a project requires high-level sponsorship from a vice-president or even from the company president or CEO him or herself. Unfortunately, senior ranks do not always have the time to carry out all the duties that being a Project Sponsor entails. If this is the case for you, there are two choices: ■

assign the role to someone else;

■

nominate a ‘project champion’ to act for you.

If you haven’t the time and it is not essential that you personally are involved, it is best to delegate the role and name someone else as sponsor. Half-hearted sponsorship can be very de-motivating for the team and may even lead to the failure of the project. Alternatively, you may retain the role for yourself, but assign another person to act on your behalf. This person is often called a ‘project champion’ and is as

39


committed to the benefits as you are and is someone you trust. In all practical terms, the project champion acts on a day-to-day basis as the Project Sponsor, only referring decisions to you as required.

YOUR KEY INTERACTIONS Potentially, you will need to interact with four other roles: ■

the person or Board to whom you are accountable (if any);

■

the Project Board (if you believe that one is required);

■

the Project Manager;

■

key stakeholders.

Any interactions you have, whether formal, informal, written or verbal, should take into account who you are interacting with and what their accountabilities are relative to your own. If you are personally confused as to who is accountable for what and to whom, that uncertainty will ripple through the team and project stakeholders, and conflicts will result. Time spent in the early days of the project establishing the roles is well spent and will lead to less potential for disagreements later. Appendix C contains a set of accountabilities for all the key roles, including your own.

The person or Board to whom you are accountable You know from the first part of this chapter what you are accountable for. However, unless you know to whom you are accountable, you are not accountable! As projects are cross-functional, the person you are accountable to may not be your own line director. Some organizations are mature with respect to how project accountabilities coexist with other formal company roles. In these, projects are often corralled into portfolios (sometimes called Business Programmes), directed at realizing similar sets of benefits. In other organizations, the top-level tie in for cross-functional projects is somewhat opaque. If this is your situation, you will need to do some detective work to determine who you are accountable to with respect to the project, and it may not necessarily be your line director or the CEO. Ask yourself:

40

■

Who asked me to undertake the role?

■

What authority does he or she have to ask me to do this?

■

What resources does he or she have to contribute?

■

What level of interest or supervision will he or she exert?


■

Where does this project sit relatively to others?

■

Who else may think that they can legitimately direct me on this role?

■

Who has the authority to terminate the project?

Obviously, if the Chief Executive has asked you to undertake the role, your accountability line is clear. However, do make sure that you have interpreted correctly what you thought you heard. Corporations are full of ‘the CEO said …’ projects which the CEO had no intention of initiating or of taking a personal interest in. Often the CEO was merely ‘flying a kite’. Also, do check what level of authority you have if there are no company guidelines to define them. Again, many CEOs’ intentions to investigate a problem are incorrectly interpreted as ‘spend a fortune to do xyz’. In other words, if you hear the words ‘approval’ or ‘authority’, don’t jump to the conclusion that you can do whatever you want. In some cases it can do no harm to confirm your understanding in writing. If the direction is not coming from the Chief Executive, it may still be just as valid. However, check with the relevant person that your understanding and theirs match. Remember that ‘your project’ may be just one of a number and may not be the highest priority. A short, open conversation, supported by a ‘Proposal’ document (see Chapter 7) will serve to clarify minds and significantly reduce the likelihood of misunderstandings. Look for who else may believe that they have a legitimate right to direct you. Find out why this should be the case. It may, in fact, be that they are a more appropriate reporting line. But a word of warning: the more immature your organization is in project management, the more likely it is to have the senior reporting line, in project terms, completely wrong. A common example is the belief that an IT Director or CTO should have ultimate accountability for projects containing significant IT deliverables (an ‘IT project’). However projects should be directed on the basis of the benefits they realize, rather than the deliverables they produce. For example, it would be more appropriate for a Customer Service Director than the IT Director to sponsor a new customer relationship management system. The IT Director should have accountability for the architectures and quality of the IT deliverables and so will be a key stakeholder and possibly a candidate for membership of the Project Board, but that is quite different from being accountable for directing the project. If you are the Chief Executive, the direction to undertake a project (fill a business need) will have been generated to you as a critical strategic need, from the Board or from a regulatory or fiscal requirement. You are still accountable, but it may be that the level of supervision placed on you will be less than you would place on a sponsor who is accountable to you.

41


The Project Board You will usually need a Project Board for projects which span a number of functional boundaries and/or where the benefits are directed to more than one market segment or business units. In such cases a Project Board acts as a vehicle to ensure that the key, senior stakeholders are engaged and given the opportunity to shape the project. Unfortunately, unless bodies such as Project Boards are well led, they can prove ineffective, adding little value to the project. It generally falls to the Project Sponsor, as chair of the board, to keep group members focused on the key aspects of the project where their experience can be used to best effect. The role of the Project Board is to enable you to realize the project benefits, and in particular to: ■

monitor project progress and ensure that the interests of your company are best served;

■

provide a forum for taking strategic, cross-functional decisions, removing obstacles and resolving issues.

The Board is not there to shadow the project manager and team checking on every step they take. A Project Board is often called a Steering Group or Steering Board.

The Project Manager The Project Manager is there to run the project on a day-to-day basis, ensuring that all members of the project team are gainfully employed on the creation of the project deliverables. He or she will be accountable to you and will be looking for you to: ■

provide direction;

■

make decisions;

■

keep the team informed of the prevailing business environment;

■

remove blockages;

■

engage key stakeholders;

■

approve key deliverables.

In return, you should expect to: ■

receive regular progress updates (see Chapter 6);

■

be kept informed of key risks, issues and changes (see Chapter 10);

■

be asked to approve deliverables and make decisions.

This requires you to have regular meetings with the Project Manager and to be available, often at short notice, if required. Remember that it is your project!

42


However, do ensure that you do not take over the Project Manager’s role, delving too deeply into aspects which are beyond your direct accountabilities. Each project manager will have his or her own style and ways of approaching the work. Imposing your style may be counter-productive. Rather, you need to enquire just deep enough to ensure that you are confident the deliverables will be fit for purpose and your business objectives will be realized. If the project is being undertaken in an unstable, political or emotionally charged environment, do share your views with the Project Manager. The more you have a common understanding of the goals and risks, the more likely the Project Manager is to ensure that your needs are fully met while paying attention to any sensitive issues or to shifts in the environment. Do not expect your Project Manager to have all the answers and be the technical expert on every facet of the project. The role of the Project Manager is to manage the project, not to be the design expert; that it what the team is for. Do ensure that the Project Manager uses the full team capability and ensure that you do not inadvertently block this, for example by insisting that only the Project Manager attends your progress meetings.

The stakeholders Stakeholders are those who are affected by the project. All those involved in the project are, therefore, stakeholders. However, there are also those who take no direct part in the project as team members, but whose activities will in some way be changed as a result. These could be users of new systems, people in new departments resulting from reorganizations (or those made redundant), those taking roles in new processes as managers, supervisors and workers. Often the project is of little importance to them, but they are of great consequence to the project if their consent is critical to success. It is essential to identify them because it is essential to enrol them at an early stage in the project to ensure that their power does not cause the project to fail later. Never underestimate stakeholders’ ability to ruin the best-laid plans! It is both the Project Manager’s and Project Sponsor’s role to ensure that all stakeholders are adequately briefed on the project. Too much communication will drown them – they won’t read it. Not enough will mean that your project will be lower down their priority list than you want it to be. Enrolling stakeholders and keeping them enrolled is a taxing but essential task. It is accomplished both by a formal communication plan and by ‘enrolling behaviour’ on behalf of all the project team on both a planned and opportunistic basis. Stakeholder influence mapping is discussed later, in Chapter 6.

43


YOUR PERSONAL STYLE There are probably more books and seminars on effective personal style than any other management topic, and yet time and time again projects go wrong for very human reasons. During the 1990s it was estimated that ten academic papers a day were published on the subject, and nowadays, virtually every organization includes leadership as a topic within its management or executive development programmes. The Project Sponsor role is interesting in this respect as it defies many of the conventions associated with power and leadership. Prime amongst these is the likelihood that: ■

You may be leading across an organization, affecting people and capabilities outside your traditional line management remit.

■

Traditional hierarchy and ranks may be sidestepped, with apparently senior line managers accountable to managers they perceive to be junior.

■

You may have no direct authority over the project manager and teams as seen from a line management perspective where the report is subservient to the manager and takes instructions from that manager. The normal disciplinary sanctions for non-performance of individuals may not exist.

In such situations, certain aspects of ‘pushy’ or ‘blue’ styles, such as assertion and persuasion, can be ineffective. Persuasion is useful if the issue is open to rational debate and you are perceived as being competent in the topic under discussion. It is notoriously poor if used in a highly charged emotional environment. Assertiveness can be powerful if your needs are legitimate and you stand to lose if those needs are not met. The list of accountabilities associated with your role gives you your legitimacy, but do check what incentives you can offer or sanctions you can impose to gain agreement or compliance with your wishes. If you can provide neither, assertion can be fruitless. ‘Pull’ or ‘green’ styles such as bridging and attraction may be more effective for you. Bridging involves gaining others’ commitment and is most valuable if it is seen that you are open to influence and value their opinions. Look at your stakeholders and you will probably find that this form of influence will be appropriate for many situations involving them. Attraction or envisioning is all about generating enthusiasm and excitement, taking people beyond the everyday to higher plains and new possibilities. It is often seen as totally irrational, but is no less effective for that. If shared values and trust are what you need to achieve your aims, this is a good influencing style. In summary, the ‘best style’ to use depends on the situation the Project Sponsor is in and whom he or she is trying to influence. However, on the whole, open even-handed styles which foster a common sense of purpose and trust will always

44


win in the long run over leadership based on bullying and fear. If you find yourself saying the following, think again: ■

‘Don’t come to me with problems, come with solutions.’

■

‘I only accept “can do” as an option.’

■

‘Don’t come moaning to me; just do it.’

■

‘I want action

NOW!’

All these expressions may lead to over-optimistic reports of progress, the truth being hidden and blaming others for failure to deliver. It is more powerful for a leader to surround him or herself with ‘constructive dissenters’ who are prepared to tell the truth or ask awkward questions than with ‘yes men’ who merely repeat what the leader wants to hear. Finally, remember that a successful project is one which meets its business objectives. An enabling part of that is producing the project deliverables on time, to quality and to budget (see Fig. 2.2). Against this background a project team can perform as expected or can fail. If the project is well planned, the team should not be expected to produce a higher-quality, quicker and cheaper solution than the one defined. If the expectations were higher, the project should have been planned to meet those higher aspirations. If carried out properly, the investigative stages of the project will assure that the most appropriate solution is chosen and defined; this is when the big gains are made or lost, not during the development and build stages of the project. A project which completes on time and to budget is not necessarily an easy project; it could be a very difficult project which has been managed well by the Project Manager. You should give credit where credit is due.

REVIEWING YOUR PROJECT Your project is under way and may have been running for some time. The Project Manager and team will be immersed in the day-to-day work of building and delivering the required outputs. This is when they are in danger of losing focus on the real business objectives which initiated the project in the first place. It is vital that you lift yourself above your day-to-day workload and review whether: ■

the project still serves a valid business need;

■

the conditions of satisfaction are clearly understood and are being pursued;

■

continuation of your project is still justified before there is a commitment to further costs (for example signing a major contract);

■

your project is being effectively managed and the team is confident that the project will be completed.

45


Such reviews are an indispensable part of good project management, reassuring you, as Project Sponsor, that the benefits you require will in fact be realized. A review gives you, as the Project Sponsor, the opportunity to: ■

remind yourself why you started the project;

■

check that what is being done is still appropriate;

■

assess the approach being taken;

■

confirm when it is going to be completed;

■

confirm how much it will cost you;

■

and … whether you still need it!

If a review is to be welcomed in this way you will have to make sure that it is conducted in an open and honest way with ‘fault’ and ‘blame’ rarely, if ever, voiced. Witch hunts during the course of a project rarely benefit anyone – be tough on the problem, not on the people. If you can foster this atmosphere of trust, an open and honest review will: ■

give you the confidence that your money is being well spent to provide clear business benefits which are highly likely to be realized (or conversely, a project which is no longer viable is terminated);

■

give the Project Manager and team confidence that what they are doing is really supported by you, on behalf of the business.

Conversely, a review conducted in an atmosphere of retribution, fear and blame will not uncover a reliable picture of the status of the project. It is important to distinguish between a ‘review’, a ‘decision’ and a ‘progress check’. ■

A review takes place when advice and comment are requested. Such advice may or may not be followed, but if you do choose not to follow it, do tell those who gave you the advice why.

■

A decision, on the other hand, follows a review and is a choice between possible futures. Such a decision may draw on the collective ‘wisdom’ of the reviewers, but ultimately rests with the person making the choice. The role of the reviewers is to ensure that decision makers make informed choices.

■

A progress check differs from a review in that it is conducted by the Project Manager and focuses on the execution of the project (what, when, how much) rather than its overall objective (why).

Notice that most reviews will be ‘event-driven’ and occur when a particular point in the project has been reached; usually a gate in the Project Framework. They are not driven by calendar lapse time. Such reviews will have been built into the project

46


schedule in advance. Those reviews which are driven by unplanned events will come about as a result of an unacceptably high level of risk or major issues being identified (for more on risks and issues, see Chapter 10). In addition, if your organization undergoes a strategic shift in its direction or comes under a major constraint (for example loss of cash), this may also trigger a review to determine whether the project is still required or can be afforded. It is you, the Project Sponsor, who are accountable for benefits realization and it is, therefore, in your interest that reviews take place. There is little point in the Project Manager completing a project on time, within budget and to the expected standard only to find that it is no longer needed. You must be clear on the purpose of each review and know: ■

the scope of each review (total project, subpart, etc.);

■

the driver for the review (the event which triggers the review);

■

the names of the review manager (if you are not leading this yourself) and team members;

■

the evaluation criteria to be used (checklists, etc.).

Except for names and actual dates, the above are all predefined in the staged framework for the gate reviews, closure review and Post-Implementation Review (see Chapter 7). Generally, all reviews assess the deliverables, documentation and performance of the project to date. This is coupled with interviews with the project team, users, customers, third parties, suppliers and functional managers so you can gain different perspectives on and perceptions of the project from the different stakeholders. Do also include the Project Manager. If the review comes up with recommendations concerning the running of the project, it is important that the Project Manager is enrolled to implement them. Unless included in formal gate deliverables, the review manager should record and communicate his or her findings in a brief report covering: ■

the key findings from the review;

■

recommendations for improvements/changes needed together with who should be actioned to implement them;

■

areas where the project has performed well.

On the basis of this report you should agree with the Project Manager (or other impacted parties) which recommendations should be incorporated into the project, by when and by whom. If there are lessons which could usefully benefit other projects or which provide useful feedback on the project processes, these should be recorded and sent to the relevant people.

47


When undertaking reviews: ■

Look for facts – don’t take anyone’s word.

■

Look for corroborating or conflicting stories; follow rumour to its source; everyone will see things from their points of view, all of which may be right, but none of which provides the whole story.

■

Listen to how people say things as well to what they say.

■

Use the Health Check in Appendix D to determine the inherent risk.

■

Look for ‘weasel words’ in any written documentation which may be indicative of a deliberately hidden issue. It may be just poor writing, or it may be a clever smoke screen.

■

Don’t be put off by words like ‘if you waste time on a review, you will make us late’ or ‘Don’t you trust me?’ Reviews are bigger than delivery: they are about setting the scene for benefits realization. Excellent delivery on a poor premise may make the project team feel good, but will it take the organization where it needs to go? Trust, to be really meaningful, must flow two ways.

SOME TOUGH CHOICES FOR YOU TO MAKE People within organizations will seldom act as you expect them to. Defining roles and accountabilities which are agreed at the start of a project (see Appendix C) can help prevent misunderstandings but will not guarantee it. Very senior managers will do what they want to do, regardless of any agreements, ‘rules’ or best practice. The more immature an organization and/or the more political the senior tiers, the more likely you are to come across potentially dysfunctional behaviour. Four potentially difficult situations are described below.

Being given a project which does not fit the strategy If you are asked to sponsor a project for which you are unable to see a link to strategy or which you believe is counter to the stated strategy, what should you do? Should you: 1 decline to sponsor it? 2 sponsor it regardless? Both actions are potentially career-limiting. In the first case, you may be perceived as an ineffective or timid manager. In the second, you will be tying your reputation to something you may not believe in and for which you may ultimately be held to account.

48


If you can engage whichever executive is requesting you to take on sponsorship of the project and discuss the potential misfit, that is well and good. The divergence may in fact be less than you thought. You really need to understand why the senior executive needs the project and where he or she perceives the fit lies. You also need to understand where his or her power base is which enabled him or her to give you the instruction in the first place. If engagement is difficult, you should harness the principles of business-led project management and stakeholder engagement to build a coalition and case for (or against) the project. During the investigative stages, poll the thoughts of other impacted executives to determine whether it is you who are out of line or your senior executive. On the basis of such information decide whether, in the context of the whole business, this project is something which really matters. If not, keeping a low profile and undertaking it may be an option. If it does matter, ensure that you keep your senior executive engaged and do not let him or her walk away from it: ■

Ask him or her to address a meeting of key stakeholders to explain the imperatives behind the project; make sure the questions you need answering are asked.

■

Ask him or her to chair the Project Board so he or she hears ongoing questions and queries as they arrive. This will ensure he or she is directly involved in key decisions, especially at the gates.

■

Refer crucial decisions to him or her and ensure that he or she makes them – give your own views and recommendations.

■

Ensure that he or she underwrites any crucial communications personally so it is clear to all where the drive for the project is coming from.

By ensuring involvement you increase the chances of: ■

having any misperceptions you have corrected;

■

protecting your base by making the executive visibly own his or her own decisions;

■

exposing the executive to counter-arguments and hence opening the opportunity for a reversal of his decision, without losing face (‘… detailed investigation resulting from the project has uncovered some important new facts and has led me to review this project. As a result I have decided to terminate it’).

Picking up a project in mid-flight Some organizations are being reorganized almost constantly, which can lead to a project sponsor leaving the company or being deployed elsewhere. Even in stable organizations, people often move on. It is therefore possible that you will be asked

49


to take on the sponsorship of a project which is already under way. What should you do? Undertake a formal review of the project. The following actions should help you gain an understanding of the project. ■

Interview the Project Manager. You need to build a relationship, so start as soon as you can. Ask for: – his or her perception of the business objectives and likelihood of meeting them; – a list of stakeholders who have been or need to be engaged; – a copy of the most recent formal documentation (Proposal, Project Business Case, etc.); – a progress update covering performance against cost and schedule; what he or she believes the key risks and issues are and what the outlook is for the remainder of the project.

■

Interview (if still available) the outgoing Project Sponsor: – determine if his or her departure is related to the project; – ask for a one-minute summary: what the project will deliver, why it is needed, the benefits which will be realized and the scope; – determine who the stakeholders are who have been or need to be engaged; – ask where he or she perceives the key risks to lie and what key issues are currently being faced.

■

Compare the views you received from the Project Sponsor and Project Manager. Note any mismatches. Informally gauge the opinions of team members and some of the stakeholders.

■

Use the gate checklists in the second half of Chapter 7 to determine what stage the project should be in.

Such a review will meet two objectives: ■

You will meet most of the key players, demonstrate your willingness to listen and make the handover of the sponsorship role to you explicit. No one should be in any doubt that the role holder has changed.

■

You will gather facts and rumours upon which you can make a value judgement on the overall health of the project and what needs to be addressed as a priority.

Terminating a project which is no longer viable Throughout this briefing you will see many references to the advice that if a project ceases to be viable it should be terminated. This is very obvious, but termination

50


can be very difficult in practice. Some projects simply refuse to die! As the sponsor, you are in a prime position to determine whether termination is required. You are, after all, accountable for the realization of the benefits, and if they are unlikely to flow, you will fail to meet your objectives. Do not expect the Project Manager to recommend termination. Unless the deliverables are proving impossible to deliver, the Project Manager and team are likely to want to carry on regardless. Expecting them to terminate their source of employment is like expecting turkeys to vote for Christmas. The following actions should lead you to a correct decision: ■

Have whatever event prompted you to consider termination placed in the issues log (see Chapter 10). Use workshop techniques to define the source problem, look for possible solutions (including termination) and gain consensus from the project team and key stakeholders.

■

If termination is the recommended option, treat this as a formal ‘change’ to the project. Undertake an impact assessment on what effect termination will have on other projects, operations and the ability of the organization to meet the objectives in the business plan.

■

If termination is the preferred action, do it without delay. Follow the closure process given in Chapter 8.

Remember that it is not usually sufficient for you to know that termination is the right course of action. Many people at a senior or influential level may be personally associated with the project and regard termination as ‘losing face’ or failure. Some would rather see the project continue than face reality. You need to bring the stakeholders with you and make the decision ‘safe’ by putting it in as positive a light as possible; after all, think of the money and reputation you have saved by stopping something which would either deliver nothing or worse, reflect badly on the organization.

On being given a strategic project It may sound like a career-enhancing dream to be asked to sponsor a ‘strategic’ project and be at the leading edge of the company. However, treat such opportunities with caution. ‘Strategic’ projects usually happen at the top of the business cycle, are often associated with a new executive appointment and sometimes relate to the latest management fad. In good times, the threshold for spending large sums of money on such projects is very low. However, when the downturn comes, organizations usually focus on cash and efficiency, neither of which many strategic projects have any direct link to. Real strategic projects will address one or more of three areas:

51


■

enhancing customer intimacy, leading to greater sales and market penetration;

■

improving operational excellence, reducing bottom-line costs and delivery times;

■

promoting product leadership in the chosen market segment.

If you have been given a strategic project, make sure that you can demonstrate linkage to the above and the project is likely to be a sound investment. If you cannot demonstrate such linkages, break the project down into smaller packages of deliverables, to keep interest from stakeholders, demonstrate progress through ‘quick-wins’ and maintain momentum. If you cannot do this, the project is probably not really strategic (see above on projects which do not fit strategy!).

SUMMARY ■

You, as Project Sponsor, are accountable for realizing the business benefits to the company and directing the project. You are the primary risk-taker. You may draw on the support of a Project Board if this adds value to the project and helps you build a guiding coalition.

■

Your role involves being a business leader, decision maker and change agent, drawing your power from whatever sources are available to you.

■

Your key interactions are with the person to whom you are accountable for the project, the Project Board (if you have one), the Project Manager and the key stakeholders who will be affected by your project.

■

It is your role to ensure that the project is at all times viable, and hence you should review its viability at appropriate times during the project. Usually this will be at the gates.

■

The way a Project Sponsor appears, or is perceived, as a leader can have a far greater impact than many people realize.

■

Reviews should be forward-looking, not dwelling on past problems and failures, and should focus on the business objectives and benefits.

52

■

Don’t assume that performance to date is an indicator of future performance.

■

If the project is no longer viable – terminate it!

5 Benefits – realizing value for your organization

■

Benefits and drivers

■

Tangible and intangible benefits

■

Difficulties with measurement

■

Conditions of satisfaction

■

Forecasting benefits

■

Timing of benefits

■

Summary

55 55 56

57

57 58

59

53


BENEFITS AND DRIVERS Realizing benefits is the sole reason for undertaking a project. If benefits are unlikely to be realized, there should be no project. It is for this reason that your role as the Project Sponsor is vital. You are the person in the business who requires the benefits to fill a particular need, in pursuit of a stated business objective. To be ‘legitimate’, a project must fulfil at least one of the following aims now or in the future. It must: ■

maintain or increase profitable revenue to the business;

■

maintain or reduce the operating costs of the business;

■

maintain or reduce the amount of money tied up within the business;

■

support or provide a solution to a necessary or externally imposed constraint (for example a legal or regulatory requirement).

In short, benefits are about making more money, about using existing resources and assets more efficiently and about the continuity of the organization. Drivers are frequently defined by words such as ‘growth’, ‘efficiency’, ‘protection’ and ‘demand’, which reflect the company’s focus at any point in time. The first three aims relate to the net cash flow into the business. Money is a company’s key measure of commercial performance. It includes measurement of revenue, investments and the costs of running the business. The fourth aim is often referred to as a ‘must-do’ project. Nevertheless, it is essential that such projects are fully costed in order to determine the least-cost, highest-value approach to fulfilling the need. This cost can then be placed in the context of the business as a whole in order to determine whether the company, or the affected part of the company, can afford the change and remain a viable commercial concern.

TANGIBLE AND INTANGIBLE BENEFITS Benefits can be: tangible – those which can he stated in quantitative terms intangible – those which should be described as far as is possible. Wherever possible, benefits should be tangible and clearly articulated. Tangible benefits may be measured in either financial or in non-financial terns. Financial benefits describe the business objectives in terms of ■

revenue;

■

contribution;

55


■

profit enhancement;

■

savings in operating costs or working capital.

Non-financial benefits describe the value added to a business which is directly attributable to the project but which cannot be described in financial terms. These benefits are often associated with a ‘balanced scorecard’ and should be tangible and measurable, including: ■

operational performance measures;

■

process performance measures;

■

customer satisfaction measures;

■

Key Performance Indicators (KPI).

Care should he taken, however, to query why you should spend money addressing any particular measure or indicator if it doesn’t eventually help you achieve any of the four aims given at the start of this chapter. You may argue that increasing service quality could help you to retain customers or attract new customers, in which case a financial benefit should result. Also, increasing service quality may enable you to remain in business. You should be able to justify any such assumptions even if the calculation of financial effect and measurement is somewhat imprecise. You should also ensure that you can afford the cost of taking such initiatives, making sure that they are affordable.

DIFFICULTIES WITH MEASUREMENT While all the quantitative benefits above can be measured at corporate level, they cannot always be measured directly for an individual project. Consider: ■

Using a surrogate measure: it is not always possible to measure profit for products. In such cases, an alternative measure should be chosen which can be measured and which has a known relationship to profit. Revenue and margin may be such measures. You may also use measures such as numbers of customers, churn, percentage utilization of an asset.

■

Measuring at a higher level: it is not always possible to relate an increase in demand for a service directly to a recent enhancement to that service; it might be the result of other dynamics in the market. In such cases, the project should he tied to a higher-level node, where the benefits can be measured in a meaningful way. For example, an enhancement to a service may be bundled with the overall service which is tracked at product level rather than by the individual projects and initiatives which make up the product plan.

56


CONDITIONS OF SATISFACTION Despite difficulties with measurement, every project should have a recognizable method for knowing whether it has been a success. Conditions of satisfaction are used to supplement benefits measurements. They are the conditions which, if met, enable you to declare your project a success and take the form: ■

description of the measure;

■

value to be reached;

■

date the value will be reached.

They need to be chosen to be indicative of meeting benefits and may relate to achievement of revenue, a reduction in faults, increase in customers or similar, measured at a particular, defined point in time. These need to be as clearly stated as possible as there may be other people who have a different perspective on what represents ‘success’. These dates and measures are crucial to you as the Project Sponsor undertaking your role effectively. They are your ‘milestones’ and measures (indicative of benefits realization), as opposed to the milestones in the project, which are indicative of delivery.

FORECASTING BENEFITS An initial estimate of the benefits and costs must be prepared during the Initial Investigation Stage. During the Detailed Investigation Stage the estimates must be turned into firm forecasts and be agreed by you as Project Sponsor. Forecasts serve two purposes: ■

first, they enable evaluation of the project;

■

second, they provide information against which the post-launch performance of the project can be measured.

There are three guiding principles for forecasting revenues and benefits: ■

forecasts must be realistic;

■

benefits must be matched by the costs of achieving the benefits;

■

benefits (prices, sales volume, etc.) and costs must be based on the same assumptions.

57


TIMING OF BENEFITS You should always consider timing when evaluating benefits. The earlier you can obtain benefits, the better it is for your business and the quicker you will recover your investment. Discounted cash-flow calculations are designed to ensure that the time value of money is taken into consideration when comparing different projects and when deciding whether to invest. This is also why you need to look for opportunities to influence the approach taken to your projects to ensure early benefits realization. Just as early benefits are good, so delayed benefits are bad. The cost of delays can far outweigh any investment costs and turn a viable project into a financial embarrassment. Figure 5.1 shows the cash flow for a project over a four-year period. The company is looking for a 30 per cent return on investment and this meets it adequately. If this project were to slip two quarters, the benefits would also slip, reducing the present value of the project by about 30 per cent. It would actually be worth overspending by 50 per cent in order to prevent this delay in benefits and to regain some of the potential loss. This is not to say that project overspends should be encouraged, especially in a situation when you cannot be sure that injecting money will actually improve anything. It all comes down to risk. What is important is to understand how sensitive a particular project is to slippage and plan accordingly. Sensitivity analysis is dealt with in Chapter 10.

Cash flow for a project ‘on time’

Fig. 5.1

Project on time 30

Financial units

25 20 15 10 5 0

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17

–5 –10

Time

58

Project cost

Revenue

Operating costs

Net cash flow


SUMMARY ■

Be sure that you understand the driving need behind your project. Is it to create revenues, save costs, reduce working capital or fulfil a legal or regulatory requirement?

■

Wherever possible, benefits should be both tangible and measurable. If direct measures cannot be made, choose surrogate measures, which are indicative of benefits realization.

■

Look for and take into account unwanted side effects of your project. Not every performance measure may improve.

■

Define the ‘Conditions of Satisfaction’ for declaring the project a success. These should be indicative of benefits realization, not delivery.

■

Ensure that you use the same measures for forecasting your benefits that you do for measuring actual realization of benefits.

■

Look for ways to bring benefits forward, never neglecting the value of time or the losses slippage can result in.

■

Monitor milestones which are indicative of the start of benefits realization, especially for larger, more complex projects or programmes.

59

Part two Running successful projects

■

6


■

7


■

8

Closure – being confident that you have reached the start! 101

63

81

61

6 Initiation – setting up for success

■

Why formally initiate a project?

■

Selecting the right project manager

■

Project team and organization

70

■

Project definition and planning

73

■

Engaging your stakeholders

■

Summary

65 66

76

79

63


WHY FORMALLY INITIATE A PROJECT? This chapter explains the steps to be taken during the Initial Investigation Stage to ensure that the project is set up for success with direction and control being established from the very start. Projects usually fail for one or more of the following reasons: 1

lack of leadership;

2

inappropriate team membership;

3

poor team organization;

4

poor definition and planning;

5

ignoring the stakeholders.

The purpose of formally initiating the project is for you to avoid those pitfalls by demonstrating leadership and stating explicitly the business drivers, scope and business objectives for the project, i.e. ■

why you want it done;

■

what it is likely to produce;

■

when it needs to be produced;

■

how the project is likely to be approached;

■

who needs to be involved;

■

how much can be afforded.

At the end of the Initial Investigation Stage, these expectations are converted into a firmer plan and gathered in a document (the Initial Business Case) which, together with the associated plans, provides the starting point (baseline) on which all subsequent project decisions will be taken by you, and others, and against which you can measure project progress and performance. Typically, a Business Case can be looked at in three parts: Part 1, Finance, is primarily aimed at the finance function. Financial managers will be interested in this section as a priority. The Project Sponsor will also be interested in this as it sets out the financial criteria to be met. Part 2, Project Definition, is of interest to the Project Sponsor, stakeholders and project team. It is the meat of the document. Part 3, Project Organization, is of most interest to the Project Manager and team as it sets out how they are organized. The sponsor will need to ensure that adequate review points are defined for the duration of the project and that criteria are set for who can make decisions regarding any changes to the project. These three parts are summarized in Table 6.1.

65

Part Two: Running Successful Projects

Table 6.1

The three parts of a Business Case

Section

Section heading

Question answered

1 1.1 1.2

Financial justification Financial appraisal Sensitivity analysis

How much? How much?

2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11

Project definition Background Business objectives Benefits Output definition Scope, impacts and interdependencies Deliverables Timescale Risks and opportunities Prerequisites, assumptions and constraints Project approach Analysis of options

Why? Why? Why? What? What? What? When? Context Context How? How?

3 3.1 3.2 3.3 3.4

Project organization Review and appraisal points Change control Progress reporting Project team and stakeholders

How? How? How? Who?

SELECTING THE RIGHT PROJECT MANAGER You should identify a project manager before the project starts (prior to the Initial Investigation Gate). The selection of the project manager for your project will have a considerable impact on the success of the project. Depending on who you are, you will have differing degrees of freedom in selection. You may be in a position to select anyone from inside or outside; in other situations the pool you select from may be very small. However, always remember that you do have choice. Ultimately, if there is not an adequate project manager available to undertake the project, it is highly likely that the project will fail and you will not realize the benefits you set out to achieve … which makes the project pointless. In selection, you need to consider matching the nature of the project with the right project manager.

The role of the Project Manager The Project Manager is accountable to you for the day-to-day running of the project, working with the whole project team, across all necessary functions in the organization and with suppliers outside the organization. Depending on the scale and complexity of the project, the Project Manager may be supported by a project office (see Appendix C). In particular the Project Manager will: 66


■

assemble, direct and motivate the project team, with the agreement of the relevant line managers;

■

engage the Project Sponsor and other stakeholders;

■

set up and maintain project administration;

■

ensure the proposed solution represents value to the organization;

■

prepare the project definition and plan (business case);

■

manage the project through all key decision points (gates);

■

define the responsibilities, work scope and targets for each member of the team;

■

monitor and manage project progress in terms of cost, time, scope and benefit;

■

provide progress reports to the team, Project Sponsor and other stakeholders;

■

monitor and manage risks and opportunities;

■

manage the resolution of project issues, escalating as appropriate;

■

manage the scope of the project and control changes;

■

forecast likely business benefits;

■

deliver the project deliverables on time, to budget, at an agreed level of quality;

■

manage relationships and contracts with suppliers and contractors;

■

manage the closure of the project.

Levels of project management experience The bodies of knowledge of various associations such as the Association for Project Management or the Project Management Institute seek to define the attributes of project managers. These attributes, however, are not easy to apply in practice. It is simpler to consider three types of project manager: ■

Intuitive: the intuitive project manager is capable of managing a small or simple project very effectively with a small team. He or she relies on his or her own acquired common sense, much of which is inherent in good practice in project management. He or she intuitively engages stakeholders, seeks solutions, plans ahead, allocates work and checks progress.

■

Methodical: the methodical project manager is capable of managing larger, more complex projects where it is not possible to keep the whole venture on track using simple tools and memory. Formal methods, procedures and practices are put in place to ensure that the project is managed effectively.

■

Judgemental: the judgemental project manager can cope with highly complex and often difficult projects. He or she can apply methods creatively to build a project approach and plan which is both flexible and effective, while keeping true to all the principles of good project management.

Source: citi Ltd, Project World Seminar, October 2001

67


Dimensions of project management aptitude Performance in any role can be looked at as a combination of four factors: knowledge, experience, skill and behaviours. ■

Knowledge comprises learning a set of tools and techniques which are unique to project management. This may be tested through the use of questionnaires. These are included in the bodies of knowledge of the project management associations.

■

Skills are the application of tools and techniques; these do not necessarily relate just to project management but are often the skill set for line managers as well.

■

Behaviours represent the attitude and style used by the Project Manager towards team members, sponsor, board and stakeholders. This especially relates to the cross-functional nature of projects and the impact this may have on an individual with more than one reporting line (for example to the line manager for day-to-day jobs, to the Project Manager for project tasks). These are often measured through the use of psychometric profiling.

■

Experience: measures the depth to which any knowledge, skills and behaviours have been applied. It may bear no relation to the length of time a person has been undertaking a role!

Table 6.2 summarizes these. Table 6.2

68

Project management aptitude Knowledge

Skills

Project definition Project planning Benefits management Schedule management Financial management Risk and opportunity management Issues management Change management

Team building Facilitation and coaching Conflict resolution Analytical thinking and problem solving Organization Administration Technical expertise Communication (verbal; written and active listening)

Behaviours

Experience factors

Integrity Self-motivated – proactive Comfortable with ambiguity Open Even-handed Approachable

Evidence of delivery Evidence of problem solving Size and complexity of teams managed Number of projects managed Complexity of projects managed Evidence of effective leadership


Good reasons to select a person and good reasons not to The preceding paragraphs should give the dimensions to look for when selecting a project manager and are sufficient for you to discuss a brief either with other managers or your HR department. However, when it comes down to it, how would you distinguish between people who have similar skill sets? What should you avoid?

Good reasons Good reasons for selecting a particular project manager include: ■

Inherent enthusiasm: he or she needs to understand the role and what it entails or be willing to learn and have the aptitude to cope. Look for the spark that tells you that he or she really wants this to succeed.

■

High tolerance of ambiguity: he or she needs to be able to work effectively across the organization, without formal line or rank authority. He or she needs to be able, especially in the investigative stages, to deal with the many potentially conflicting needs and signals as the project hunts for a way towards a solution.

■

Excellent coalition- and team-building skills: people are at the heart of projects, both as team members and stakeholders. If they cannot be engaged and influenced, the project is unlikely to succeed. The poorer the project manager is at this, the more work you will need to put in, especially on coalition building.

■

Client orientation: this means the project manager needs to understand the expectations and differing success criteria of the various stakeholders, especially you, as Project Sponsor. It is your project and your business problem or opportunity which is being addressed. Can you work with the person? Do you believe that they will best serve your interests?

Poor reasons Poor reasons for selecting a project manager, if taken in isolation, include: ■

Availability: the worst reason to appoint a person is simply that he or she is available. Why is he or she available? What aptitude does he or she have? This tends to happen in organizations with a low level of maturity in project management as ‘project staff’ are often not seen as part of the normal work of the organization and having them do ‘something’ rather than ‘nothing’ is seen as important.

■

Technical skill: this can be useful on a project, but is not essential. The project manager can draw on technical experts as part of the core team. The danger when the project manager is also the expert is that he or she will drive his or her own agenda and area of interest to the exclusion of other areas. For example, a good

69


systems programmer may ignore the roll-out, training and usability of a new system as he or she is more interested in the technical architectures and features. ■

Toughness: the ‘macho’ project manager closely supervises every aspect of the project, piling demand on demand (or else!). This is the way to demoralize a team. Add to this the fact that many of the team may be working part-time with other managers, and it may be a fast way of losing the very people who are vital to a successful outcome. Yes, a project manager needs to be emotionally tough, but this should not translate into bullying.

■

Age: an old project manager is not necessarily a better project manager. Maturity in project management comes from exposure to a wide range of different situations and projects. Managing a single project over five years is quite different from managing ten projects lasting six months. Length of time alone is not an indicator of experience.

PROJECT TEAM AND ORGANIZATION The project team Project teams are: ■

short term, being established only for the duration of the project;

■

cross-functional, to provide the necessary skill mix;

■

frequently part-time, with team members fulfilling line and project tasks.

Bearing this in mind, it is essential, from the very start, that you agree the senior project roles (for example Project Manager and Project Board membership) with the individuals concerned and their line manager (if appropriate). You should ensure that the Project Manager does the same with the project team members. As many of the team members are likely to be assigned part-time to the project, it is essential that their line managers’ commitment is obtained. The line managers may also have a quality-assurance role to undertake. If so, the Project Manager must agree this with them and, if necessary, confirm and agree a role description, defining the team members’ accountabilities. Even if these descriptions are never referred to again, the act of creating them with the individual and agreeing them will clarify that person’s role and ensure that there are fewer misunderstandings. The key members’ roles should be summarized in the initial and full business case documents. Fostering team spirit is the responsibility of all the team, led by the Project Manager. The sooner the team can settle down to work together in an environment of openness and trust, the better it will be for the project. Project set-up is the ideal time to do this and you should attend the start-up meeting. Even

70


if you, as Project Sponsor, know what the project is about, sparing the time for the Project Manager and team to understand this for themselves will lead to greater commitment and better results. Listen not only to what they say, but also to how they say it. You need to be sure that you, the Project Manager and the team are working to the same objectives and priorities.

Project administration Projects require administrative organization to make sure that routine matters run smoothly, leaving the maximum time for concentrating on the big issues and work content for the project. Your Project Manager should set this up as a matter of course. Projects can generate a considerable volume of information, correspondence and reports, most of which needs to be accessible and some of which needs to be archived (for example for audit purposes). It is essential that the Project Manager sets up the filing needs for the project as soon as practical and that he or she makes sure that all team members and support staff understand what is required and available. The format or media for storing such documentation can vary from paper-based to a full web-based ‘group-ware’ platform.

Progress reporting As Project Sponsor, you should expect to be kept up-to-date on what is happening on your project. This is usually by receipt of a progress report, which may be formal or informal. Do not assume that this will happen. Agree the recipients, frequency and content with your Project Manager. If your organization has a standard for progress reports, follow it and do not waste time insisting on your own ideas and format. Nothing depresses a project manager more than having to churn out essentially the same material in different forms to feed personal preferences! (If you consider your company’s standard to be inadequate, work with the owner of the standard to improve it.) Typically, you should expect a progress report to include the following: 1

Business Objectives – A reminder of the business needs the project will satisfy (i.e. why you are doing the project). It is good to ensure that the Project Manager, team and stakeholders are always aware of it.

2

Progress Summary and Outlook – This should briefly describe the progress of the project in terms of both achievements to date and expected future performance. For any significant schedule slippage or cost variance expect to see the reason, impact and corrective action being taken.

3

Financials – A summary of the project finances in terms of spend to date and total expected spend compared to that planned.

71


4

Milestones – A list of the major milestones. These should at least be the gate milestones as defined in Chapter 3. For each milestone, expect to see the original and current baseline date and the forecast date or actual date achieved. There should also be milestones for any additional formal review points.

5

Key Issues – This should describe the key issues which have been escalated beyond the project manager for resolution. For each, the project manager should describe the nature and impact of the issue and state the action being taken to resolve it and who is accountable.

6

Key Risks and Opportunities – This should summarize the high risks and major opportunities which have arisen. For each, the project manager should give the nature and impact of the risk or opportunity and action being taken to manage the risk or opportunity and who is accountable.

7

Changes – All outstanding changes which are beyond the project manager’s authority to authorize should be listed. For each, expect to see the reason for the change, the likely impact of the change and who is accountable for authorizing the change.

8

Attachments – It may be convenient to attach or cross-refer (say on a web site), for detailed reference: for example cost report; progress bar chart; issues log.

If progress reports are to be effective, they should: ■

be honest and open, without undermining confidence;

■

focus on key issues;

■

balance good and bad news;

■

acknowledge the achievements of the team.

Your reaction to progress reports is crucial in maintaining this. Be tough on the problems and not on the people. If you ‘shoot the messenger’ for bringing bad news, don’t expect to have the truth told to you again. Your main aim should be to promote an environment where there are no surprises and in which issues can be worked through in a positive way. Also, remember that you may hold information which is vital for the team to know if they are to carry out their duties effectively. Often this will relate to the general business and political environment. Make sure that you share such information with them and make it clear how you want it to be used.

Change control Once you have authorized the project, its scope, cost, benefits and timescale are baselined and should be used as the basis to monitor progress. Under certain circumstances it is, however, desirable and/or unavoidable to change these

72


baselines. Who authorizes such changes very much depends on the impact. It is, therefore, essential that the extent of the authority you have given to the Project Manager or Project Board is defined. Chapter 10 on change management describes this more fully.

Review points The project framework comprises a staged approach to projects with the ‘gates’ defining the key points when you will undertake a formal project review. However, the time lapse in some stages can be very long, particularly in the Develop and Test Stage. It is, therefore, essential that a sufficient number of additional review points are built into the plan for you to check that: ■

the project still meets a real business need and is achievable;

■

the quality of the deliverables is adequate;

■

the plans are in place;

■

the project organization is working.

As a guide, a project should have a formal review every three months or when a major commitment to a supplier or customer is to be made. The occurrence of such reviews should be formally documented and planned as they are essential in managing the risks on a company-wide basis. Reviews are often seen to take up valuable time and hamper progress on the project. However, it is in your interest, as Project Sponsor, that such reviews are planned for and take place.

Project organization checklist Use the checklist given below to confirm that your Project Manager is organized. ❏ Have progress reporting formats been defined and agreed? ❏ Have recipients of progress reporting been identified and engaged? ❏ Has a system for capturing and managing risks and opportunities been set up? ❏ Has a system for capturing and managing issues been set up? ❏ Has a system for recording possible and actual changes been set up?

PROJECT DEFINITION AND PLANNING Project Definition Checklist Use the checklist given overleaf to review any projects in progress.

73


Criteria ❏ Has a project definition been written, reviewed by the stakeholders and approved by you, as the Project Sponsor? ❏ Do the scope and objectives of the project meet the needs of the business? The project scope must comprise everything needed to ensure that the benefits can be realized. There should be no assumptions that ‘others’ are providing a key part. If other projects are providing deliverables (interdependencies), this must be stated explicitly and not assumed. ❏ Have the benefits been fully assessed and quantified wherever possible? ❏ Do the benefits match the needs? ❏ Have all the key risks been identified and categorized? ❏ Has a comprehensive and satisfactory work breakdown been developed? ❏ Does the work breakdown reflect the deliverables to be produced? ❏ Are all key logical relationships between projects and activities clear? ❏ Has the plan been developed to minimize or offset the risks? The only way a project can be delivered is by its deliverables. For each deliverable check: ❏ Are the project deliverables listed? Are they relevant and feasible both to produce and to implement? ❏ Have quality criteria been established? ❏ Is it clear who is accountable for preparing each deliverable? ❏ Is it clear who will review the deliverable prior to signing off acceptance of each deliverable? ❏ Is it clear who will sign off each deliverable? ❏ Has sufficient time been allowed for reviewing/amending each deliverable? Note where there are gaps in the answers – be honest. You will fool no one but yourself in the long term. Ensure that the Project Manager works to fill the gaps identified in the list above. ■

If you don’t know why you are doing the project, consider terminating it.

■

If you don’t know what is being delivered, regard your costs and timescales as unstable and your risks high.

■

If you don’t know when it will be done, ensure that more investigations are carried out until you do know.

■

If you don’t know how the project will be approached, regard the risk as high and ensure that the project manager investigates further.

74


The project plan When starting a new project, remind the Project Manager and team to look at any previous projects. There may be lessons learned from those projects which could be useful and influential on the current project. A good plan will be more like a map than a route listing. If you follow a map and come across an obstruction, you can spot alternative ways around that obstruction. If you follow a route list and come across a blockage, you have no idea what the options are for moving on. A project plan enables control by: ■

defining the scope – specifying the activities which need to be performed to complete the project scope and the target dates for their completion;

■

assigning accountability – identifying an owner for each activity who will be accountable for its completion;

■

monitoring progress – providing the baseline against which progress will be measured.

The following should be defined by inclusion in the project plan: ■

stages – these represent the natural high-level break points in the project life cycle (for example initial investigation, detailed investigation, develop and test, trial, release);

■

work packages – these represent the clusters of work within each stage, usually focused on a key deliverable;

■

activities – these are the individual components of work within the work packages that must be undertaken to complete the project. Each activity should be defined in terms of its start and end dates and the name of the individual accountable for its completion;

■

milestones – these are the significant events (often representing the start of a stage) which should be used to monitor progress at a summary level;

■

deliverables – each of the key deliverables defined in the project definition should be shown in the plan. Use milestones to represent their completion;

■

reviews – include reviews at key points throughout the project when progress and performance will be critically evaluated;

■

interdependencies – define all inputs from (and outputs to) other projects. These should include all those defined in the project definition.

From these, the resource needs and cost can be derived. Rarely can a project be planned in full at the very start, but it should always be possible to plan the next stage in detail, with an outline plan for the remaining stages. Therefore, do not expect project plans to be fully detailed from the start; always regard them relative to the stage they have reached in the project framework.

75


Project schedule plans are most conveniently presented as bar charts, an example of which is given in Chapter 9 (see Fig. 9.1).

ENGAGING YOUR STAKEHOLDERS Stakeholder influence mapping Stakeholder influence mapping is a simple but effective technique you can use to identify your stakeholders and start deciding on the nature of any engagement you need to make (see Fig. 6.1). The same technique can be used by the Project Manager. Fig. 6.1

A typical stakeholder influence map

I -CFO Finance

D? CEO

?

I ++ SVP HR

Dave I ++ Consultant

I -VP Production

ME I -Head of Distribution

I ++ VP Customer Services

C? Employees D ?? Account Director

1

I -Outsource IT company

Brainstorm who the stakeholders are. Write each name on a self-stick note and stick the notes onto a whiteboard or flip chart. Stakeholders may be individuals or groups.

2

Group the stakeholders into clusters based on similar need or impact from the project. Rationalize the stakeholder list if possible. Don’t worry if you can’t.

3

Define the role of each stakeholder. Stakeholder roles are defined as: ■

Decision maker (D) – this stakeholder is required to make a decision regarding the project;

■

Influencer (I) – this stakeholder has influence over the project and/or over the decision makers;

76


■

Player (P) – this stakeholder is required to play a part in the project, perhaps providing resources, facilities or review time;

■

Consent (C) – the consent of this stakeholder is required if the project is to be a success (for example computer system users, customers).

Take each stakeholder cluster in turn and, using one flip chart per stakeholder, answer the following questions to determine what this person’s or group’s stake is in the project. ■

Are they directly affected by it? If so, how?

■

Are they indirectly affected by it? If so, how?

■

Are they needed to make any decisions? (D)

■

Are they needed to play a part in the project? (P)

■

Do they have control over any resources, facilities or capabilities required by the project? (C)

■

Are they unaffected, but do they still have the power to affect it should they choose to do so? (I)

■

Are they positive, neutral or negative about the project? How will this be manifest?

4

Write ‘ME’ in a bubble in the centre of a whiteboard. Write the names of those stakeholders you have direct access to around ‘ME’ and join them to ‘ME’ with a line. Use a single line for a weak link and a double line for a strong link. Define what role they play (D, I, P or C). Use or , or 0, to indicate if they are positive, negative or neutral to the project. Use ? if you don’t know. This map indicates the stakeholders you have direct access to.

5

Write the names of the remainder of the stakeholders in boxes around the edges of the whiteboard. Use , , 0 to indicate if they are positive, negative or neutral to the project. Use ? if you don’t know.

6

Write on the whiteboard the names of others you have access to but who also have access to one or more of the stakeholders.

7

Work with the stakeholder diagram to determine a plan of action to address the key people required for the project to be a success. You need all the Ds, Ps and Cs covered. Use the positive Is to influence people on your behalf. Do not ignore the ?s; find out their views and then act accordingly.

Stakeholder engagement You now have a ‘stakeholder influence diagram’. You can use this to decide how best to enrol a particular stakeholder. You may do it yourself,

OR

it may be more

effective to have others do it on your behalf. You should:

77


■

identify those individuals or groups negative to the project and seek, at least, to make them neutral. Use the information you have gathered to determine an effective way of exerting influence (see Chapter 4) based on the situation. Also investigate who may be engaged to undertake influencing on your behalf. Is there a person with a strong relationship to the target who is positive about the project?

■

identify those who are essential to the success of the project and whose attitude is unknown. Work to identify what their views are. Again, use others to determine this if appropriate.

■

identify those who are positive about the project. Keep them engaged and use their influence to engage others. The bigger your guiding coalition, the more likely you are to succeed.

Success is in the eye of the beholder You will have your views as to what ‘success’ will look like for the project. You should have made this as clear as possible in the Proposal and later, in more detail, in the Business Case. However, the more far-reaching and complex the change a project seeks to create, the more likely it is that people will have differing views. You cannot assume even that those who are positive about the project have an identical agenda to you. It may be that the project takes them nearer to completing an alternative agenda. This may lead to senior executives giving different signals to their employees. For example, in business process reengineering it is often stated that the aim is not to reduce headcount as corporate growth will absorb any efficiencies through volume growth. (This may be a naïve assumption!) A finance executive may support such an initiative because he or she sees this as a direct lead to reducing headcount and hence costs. If such conflicting signals ripple through the organization, the whole project could be threatened: people rarely work enthusiastically towards their own redundancy. Another point is that no matter what the commercial success is: ■

Sales may see success in terms of revenue growth and sales commission.

■

Operations may see success based on ease of use of the systems and processes.

■

Customer services may see success in light of an absence of fault reports and complaints.

■

A CEO may see success in terms of meeting a deadline promised to the board or shareholders over and above service quality, cost saving or revenue generation.

In defining a project, it is essential that you know what the perceptions are of each executive involved, so if trade-offs are needed, say time against cost, you can make your decisions in the best interests of the company as a whole rather than from an individual perspective.

78


SUMMARY ■

Projects should be formally initiated to ensure that they get off to a good start. The investigative stages are vital to overall performance, and taking short cuts may endanger the success of the project.

■

Understand the driving business need before starting the project. Make sure that the Project Manager and team understand it.

■

The objectives, scope and boundaries for the project should be defined in a business case which becomes the central reference for the project.

■

Ensure that your needs are reflected in the planning and approach for the project.

■

Stakeholders are crucial to success. They can be great movers for change and steadfast blockers. Identify and harness your stakeholders’ influence, using your network to engage and win over those who are hostile to the project.

79

7 Running a project in stages

■

Proposal

■

Initial Investigation Gate Checklist

■

Initial Investigation Stage

■

Detailed Investigation Gate checklist

■

Detailed Investigation Stage

87

■

Development Gate checklist

89

■

Develop and Test Stage

■

Trial Gate checklist

■

Trial Stage

■

Ready for Service Gate checklist

■

Release Stage

■

Project completion checklist

97

■

Post-Implementation Review

98

■

Checklist at Post-Implementation Review

■

Summary

83 84

85 86

91

92

93 94

95

99

99

81


PROPOSAL Overview The Proposal is the document which describes the business need (i.e. it focuses on why you want a project) and, if known, what you want to do. You should document it formally and discuss it with potential key stakeholders prior to starting the Initial Investigation Stage of the project. The Proposal document is used as the key control deliverable at the Initial Investigation Gate. This gate, just prior to the Initial Investigation Stage, is the first decision point when resources are committed to working on the project and is the point when the potential project is first formally recognized. This gate is also unique as it is the only one in the project life cycle which does not require a detailed plan for undertaking the work which follows. It is important for you to document the Proposal as: ■

it acts as the brief for the future Project Manager, without which he or she will not have a clue about what he or she is expected to do;

■

writing the Proposal down serves to clarify your own thinking and ensure clear communication of your intentions;

■

if you can’t be bothered to write it down, why should you expect anyone to work on it?

Key deliverable The Proposal is a short document (1–5 pages) which outlines the business need the project will meet, what it is intended to produce (if known), its benefits and how it fits with current strategy. If apparent, the likely impact on the organization (market, technology and operational), broad estimates of benefits and cost, and required time to completion are also included. The document does not need to contain any detail other than the business need; anything else is a bonus. If time is spent fleshing out the Proposal, it is in effect jumping ahead and starting the investigative work. A Proposal may ask far more questions than it answers. If additional information is available, either add it to the Appendix or cross-refer to any supporting documentation.

Focus on This is the starting point and only one thing should be certain – the project is aligned to strategy and meets a recognized need or opportunity. A Project Manager and team do not yet exist. If you do not identify the business need adequately, it is highly likely that the project will not be able to meet that need. Also check that

83


there are no other projects already under way which are addressing the same need. You are focusing on why you need a project.

What can go wrong? ■

Simply, you or the person who initiated the proposal hasn’t a clear idea of what they wish to achieve while pretending that they do! If you do not have this clear, ensure that work in the Initial Investigation Stage concentrates on defining the objective. Don’t let money and resources be wasted on ill-conceived objectives.

■

The business objectives of the project do not match the needs of the business.

■

Starting the initial investigation before the project has begun. A Proposal can be very sparse or quite detailed, but whatever it contains must already be known. If you insist on too much detail in your Proposal, you will force the creation of an ‘invisible project’ which no one can sign up to.

INITIAL INVESTIGATION GATE CHECKLIST Key control document: Proposal Before approving the start of the Initial Investigation Stage, you should ensure that your Proposal reflects the business need and your intentions and is in line with the company’s strategic direction and priorities.

Questions to ask yourself and/or your boss: Business need and strategic fit ■

Does the Proposal fits the organization’s strategy?

■

Is the opportunity attractive (size, share, cost saving, contribution, etc.) relative to alternative proposals?

■

Is the Proposal likely to be acceptable to the customers, users and other stakeholder groups?

■

Do any competitors have capabilities similar to this? If so, will the result of this Proposal provide us with any competitive advantage?

■

Have you provided detailed terms of reference for the Initial Investigation Stage to ensure that the Project Manager focuses on the key issues as you see them?

Accountabilities ■

As Project Sponsor, are you clear who you are accountable to for this undertaking? Have you agreed this with him or her?

■

84

Have you identified a project manager for the Initial Investigation Stage?


Questions to ask the key stakeholders: Resources Can resources be committed to the initial investigation?

Operational and technical ■

Is the organization likely to be able to develop or acquire the required capabilities to support your Proposal, if they don’t yet exist?

■

Is it technically feasible with current technology?

■

Has or can the organization acquire the operational capability to support it?

INITIAL INVESTIGATION STAGE Overview The goal of the Initial Investigation Stage is for the Project Manager to assemble the project team and examine the Proposal, as quickly as possible (say, within one to six weeks), identifying possible solutions and approaches. They need to determine if the intended project is likely to be viable in financial, operational, technical and customer terms. You will need to: ■

ensure that a preliminary assessment has been done;

■

check for overlap, synergy or conflict with other projects in progress or capabilities in use;

■

ensure that the scope, approach and plan for the remaining stages of the project have been planned and defined.

As the investigative stages of the project are the most influential, you are likely to need to be involved in many of the decisions and discussions which will steer the project team in a preferred direction. Throughout this stage expect to be asked your opinion on ranges of options and possibilities. While you may leave the Project Manager and team to derive and investigate these, you need to be making the decisions.

Key deliverables The Initial Business Case document contains the business rationale for the project. It is the document which outlines why you need the project, what options you intend to have checked out, how it will be done and who is needed to make it happen. It also answers, in outline, the question ‘how much?’ and hence is used to authorize the 85


funding for at least the next stage of the project. The Initial Business Case does not provide a full analysis, but only sufficient to enable you to decide if it is worth while continuing the project. (The full Business Case will provide the definitive appraisal for the project and will be produced at the end of the next stage.)

Focus on You will need to ensure that the Project Manager has engaged the right team and that they understand the business need and any constraints there are around creating a solution. Be prepared to modify the statement of the business need if this adds greater clarity and understanding. The focus here should be on constructive testing of assumptions and trawling for a wide range of diverse solutions. Focus on those potential solutions which are likely to meet the needs soonest with maximum benefits.


The project team take too narrow a view of the scope of the project. The classic example is of the ‘IT project’ which contains nothing else and can therefore realize no benefit. In every project look for the systems, the culture, the processes and structures and accountabilities (see Fig. 1.1).

■

Insufficient creative thinking is applied to the possible solutions. Consider them all, no matter how ‘off the wall’, and then choose the best three for detailed investigation in the next stage.

■

Spurious accuracy is placed on time and cost estimates. At this point it is better to think in ranges and not absolutes. Absolute values are erroneous and may only pander to senior-management insecurity.

DETAILED INVESTIGATION GATE CHECKLIST Key control document: Initial Business Case At this gate you should check the project against the organization’s business plans and reconfirm its strategic fit, its priority and whether it is likely to be viable in commercial, technical and operational terms. If you can tick off all these, you may approve the start of the Detailed Investigation Stage.


Is it clear which business unit(s) or function(s) strategy and plan the project supports? Does it fit the strategy?

86


■

Is there a real business need, and is the opportunity attractive compared to others which may consume the same resources?

■

Are the risks acceptable, and is a management plan in place to deal with any high risks?

■

Are the initial business case and investment appraisal acceptable?

■

Have you identified a project manager? Have you met him or her to agree on the approach to be taken, stakeholders to be engaged and how key risks should be managed?

Questions to ask your Project Manager: Deliverables ■

Is there a detailed schedule, resource and cost plan for the Detailed Investigation Stage?

■

Is there an outline schedule, resource and cost plan for the full project which takes into account the known risks and constraints?

■

Have all the relevant business units and functions been involved in creating and reviewing the deliverables?

■

Do the proposed deliverables represent value for money?

Resources ■

Do you have the ‘right team’ identified to undertake the Detailed Investigation Stage?

Operational and technical ■

On existing knowledge, is it technically feasible with current technology, or is there a possible technical development path to provide the capability or service?

■

Does the organization currently have the operational capability to support it? If not, is it likely that this can be put in place within the current/proposed process architecture?

DETAILED INVESTIGATION STAGE Overview During the Detailed Investigation Stage the Project Manager and team will identify and define their recommendation for the optimum solution and commercial proposition. 87


You will need to ensure that: ■

possible options are evaluated and identify your preferred solution;

■

the preferred solution will meet the defined needs;

■

process, technical and operational requirements are defined, where appropriate;

■

the concept is researched with the target users and/or customers;

■

any legal or regulatory issues have been checked;

■

possible suppliers and partners have been evaluated.

The next gate, for which this stage prepares you, is critical as it is the last point at which you can stop the project before substantial financial commitments are made.

Key deliverables The Business Case is the key control document at the next gate and contains the business rationale. It is the document on which you make the decision to continue with the project and build in costs and benefits to the business plan. The document is ‘live’, building on the Initial Business Case, and is under strict version control for the remainder of the project. The Output Definition is the fundamental source book describing the output of the project in terms of process, organization, systems, technology and culture. It is the document which integrates all the individual system, process and platform requirements. It also specifies how they will work together. The document will continue to develop as the project proceeds and will be handed over to the manager(s) of any operational parts once the project is completed. The project plan is an appendix to the Business Case and includes the detailed schedule, resource and cost plans for the Develop and Test Stage with the remaining stages in summary. The Feasibility Report is an aid for you to decide which solution to adopt. It includes the recommendation for which option should be adopted as the solution (including processes), and compares it against alternative solutions. The Test Plan documents the tests required to verify performance of any outputs from the project, both in isolation and working as a complete system.

Focus on The focus here is on deciding the overall approach, checking that it meets the needs and ensuring that key stakeholders are engaged and supportive (or at least not hostile). During this stage you will decide the approach to be taken which will set the direction for the remainder of the project and be reflected in a realistic plan

88


which takes account of known risks. Once this is decided, the scope for improving the performance of the project is very small. You are looking at what to do and when to do it.


The proposed change, while technically and operationally feasible, is not viable in the prevailing political environment.

■

The Feasibility Stage is either omitted or rushed with only one solution really being taken seriously in the often lame hope that the project will be quicker. Creative solutions often take less time. In some cases creative may mean phasing the delivery rather than meeting all the needs in one hit.

■

The necessary stakeholders are ignored, forgotten or simply missed. If you need a person or group to ensure benefit realization, you must have engaged them by the end of this stage – but the earlier the better.

■

The project plan is just a vague idea of what might possibly happen, containing little in the way of activities and deliverables. Without a decent plan, how can anyone have any confidence in what will happen?

■

The plan ignores the risks. All risks should be mitigated in one way or another, with no high risks remaining. Sensitivity and scenario analyses are perfect tools for assessing the possible outcomes – use them!

■

No time is built into the plan for decision making or review. Done properly, such activities add value.

■

Contingency for known risks is ‘removed’ from the plan to make it look more attractive or to ‘keep tight control’. Risk is risk, and pretending that it isn’t there is naïve.

■

The Trial Stage is left out in order to increase time to delivery (to RFS). All this usually does is deliver an inadequate and costly solution quicker. Always assume that you need a trial and then (if you can) prove that you do not.

Note, of all the ‘things that can go wrong’, this stage has the most influence as it is the stage when you decide what you are going to do. Everything which follows is reliant on the decisions and choices made here.

DEVELOPMENT GATE CHECKLIST Key control document: Business Case At this gate you should evaluate the project approach recommended by the Project Manager the proposed functionality and features of the solution including business processes, systems and organization/roles.

89


You should be now be very familiar with the project and the views of the key stakeholders, having engaged them personally. This is your Business Case, and you are ultimately accountable for the revenues and costs contained within it. If all the points below are covered, you can approve the start of development work.


Is it still clear which business unit(s) or function(s) strategy and plan the project supports? Does it still fit the strategy?

■

Is the Business Case ready to be built into the overall business plan?

■

Have the key sensitivities and scenarios for the recommended option been checked, and are they acceptable?

■

Have you engaged a project manager? Have you met him or her to agree the approach to be taken, stakeholders to be engaged and how key risks should be managed?

Questions to ask your Project Manager: Project plan ■

Are the project plans full and complete, producing deliverables at ‘the right time’ for the business?

■

Is there a detailed schedule, resource and cost plan for the develop and test stage?

■

Is there an outline schedule, resource and cost plan for the full project?

■

Are there sufficient review points in the plan to maintain confidence that the project will not move off course, for example planned at no more than three months apart?

■

Is it clear when major contractual commitments are to be made, and is there a review point planned prior to these?

■

Has the project been designed to eliminate known high risks? Is a trial stage required to mitigate risk?

Resources ■

Are there resources to undertake the Develop and Test Stage?

■

Have formal resource commitments been made by the relevant line managers?

Operational and technical

90

■

Is it technically feasible with current technology?

■

Does the organization have the operational capability to support it?


Deliverables ■

Have the development concepts (for example marketing) been researched and tested on target segments and has the need been reaffirmed?

■

Is the Output Definition complete?

■

Is it clear how the output will be tested or trialled?

DEVELOP AND TEST STAGE Overview The Develop and Test Stage is when the bulk of the costs relating to the project are spent. It comprises the outstanding detailed design, development, creation and build of the chosen solution and its supporting systems, manuals, business processes and training. It concludes with a full test in a controlled environment. During this stage, you will need to make the decision to start the Trial Stage. This decision can be taken prior to completion of the full work scope for this stage, as only activities required for the trial need be completed.

Key deliverables The Ready for Trial Review Report is the key control document confirming that all deliverables, resources and prerequisites across all functions required for starting the trial are in place. The Test Results confirm that any testing has been completed in accordance with the test plans and acceptance criteria, prior to the ready for trial review. Any outstanding issues are noted. The project plan: the schedule, resource and cost plan for the Trial Stage should be fully detailed with the remainder of the project in outline. It will include the Trial Plan, which documents the plan, conditions, environment, participants, tests, criteria and results required for the pre-launch trial.

Focus on Your main direction setting has been completed, and it is now up to the Project Manager to deliver the solution. Focus here is on ensuring that delivery is as expected, in terms of both time and quality. You need to ensure that the original business need is still valid, especially when issues arise which result in a change to the project. In such cases focus only on those things which will either preserve increase benefit realization or bring it forward.

91



There is a post-authorization lull when the project has key staff changes and a new team focused on delivery rather than planning may emerge. They need to be focused, energized and bonded as well as introduced to the project – many of them will not have been present in the often heated discussions which defined the solution. Unless they understand this fully, there is a danger that they will want to start to redesign it as they go along.

■

In the dash for delivery the overall business objective is forgotten and the need vanishes or changes without anyone noticing.

■

The plan is abandoned and the project lurches forward on a day-by-day basis. In addition to this, the risks identified in the investigative stages are overlooked and forgotten. Look for yellowing and out-of-date project plans and progress reports pinned to walls.

■

Deliverables start arriving late and contingency time is squeezed. Eventually slippage of RFS is inevitable, but this is not reported as there is blind hope that it will all come right in the end. It seldom does.

■

Testing and stakeholder engagement is dropped as pressure comes on delivery, almost regardless of quality.

■

Stakeholders are ignored or forgotten

■

There is scope creep. New features are added and added and added until the project is delayed for what may on their own be good ideas, but not at the cost of delivering nothing. Perfection is the enemy of the good! This is discussed more fully in Chapter 10.

TRIAL GATE CHECKLIST Key control document: Ready for Trial Review Report This gate comprises the check point prior to the undertaking of any trials with ‘real’ users and, perhaps, customers. You should be confident that the trial has been planned fully, addresses those areas which require more detailed checking and represents a good balance on risks.

Questions to ask yourself and/or your boss: Business need and strategic fit

92

■

Is the project still a good business proposition?

■

Is the project still correctly reflected in the overall business plan?

■

Have all high risks been eliminated?


Questions to ask the Project Manager: Project plan ■

Is the project plan up to date, full and complete?

■

Is there a detailed schedule, resource and cost plan for the Trial Stage?

■

Is there an outline plan for the remainder of the project?

■

Do we have sufficient resources to undertake the trial?

For the trial ■

Have the tests been finished and the results accepted?

■

Has the trial plan been prepared?

■

Have checklists been prepared for the customers and users?

■

Have customers/users been identified and trial agreements drafted?

■

Have the business processes been finalized?

■

Are all relevant functions and units ready for the trial?

■

Is the communications material ready?

■

Are trial results monitoring systems in place?

■

Have the trial acceptance criteria been agreed?

■

Are time and resources built into the plan to undertake modifications to any deliverables, should they be needed?

TRIAL STAGE Overview During this stage, the partially proven solution is checked in the operational environment with live users and/or customers. The purpose is to validate that: ■

the solution is acceptable to the users and customers;

■

all the capabilities work in a live environment, including the business processes, supporting systems and infrastructure;

■

the business objective is likely to be met and benefits realized.

Key deliverables The Ready for Service (RFS) Review Report is a short report to confirm that all deliverables and prerequisite activities required before starting the Release Stage have been completed. This is the key control document for the next gate.

93


The Trial Results is a summary document which confirms the trials have been completed in accordance with the plan and acceptance criteria and that the developed solution is now ready to move to the Release Stage. Any outstanding issues are also noted. The project plan: the schedule, resource and cost plan for the Release Stage should be fully detailed.

Focus on Delivery is mostly over and you need to ensure that the solution is likely to meet the need in customer and operational terms. Focus on the reactions of those who are engaged in the trials, ensuring that critical feedback is acted on. If critical feedback is not acted on, it will threaten the success of the project. You should be focusing on reducing or neutralizing outstanding opposition. Your most important decision comes at the end of this stage – should the solution be put into practice? Focus here is on the state of readiness of the organization and how it will receive the solution. A poor decision at this point threatens the entire investment.


The trial is started prematurely ‘to maintain the dates’ and the press notice the problems which ensue, damaging your organization’s reputation.

■

No time or methodology is planned to correct any errors discovered in the trial.

■

The trial is curtailed as it started late and the team is still under pressure to deliver on time. Look at the risks this will raise!

■

Insufficient notice is given to trialists and they are not available when needed.

READY FOR SERVICE GATE CHECKLIST Key control document: Ready for Service Review Report This gate represents one of your biggest decisions. Until now everything on the project has been internal or at least contained (such as the trial). If the project is terminated now, the costs will have been for nothing … but that is not what counts. What matters is your deciding whether it is still in the best interests of the company to release the new order and start reaping the rewards the project was set up for in the first place. Moving ahead when the circumstances are not right or the work is incomplete may severely damage the organization and its standing with customers, employees and shareholders. It could also be career limiting for you!

94



Is the project still a good business proposition?

■

Have all high and medium risks been eliminated from the project?

Questions to ask your key stakeholders: Ready for Service (RFS) ■

Have the right stakeholders been engaged and consulted concerning the RFS decision?

■

Are you absolutely sure, beyond reasonable doubt, that it will work? (Your reputation and that of your organization may be at stake!)

■

Have process designs across the organization (and to third parties if needed) been accepted, and is all training completed?

■

Have the operational parts of the business and any suppliers confirmed that they are ready to start using and maintaining the new capabilities?

■

Are benefits/results/operational monitoring processes and systems in place?

■

Have the costs and benefits been reforecast against the business plan?

Questions to ask your Project Manager: Project plan ■

Is the project plan updated, full and complete?

■

Is the launch/release date(s) defined?

■

Is there a detailed schedule, resource and cost plan for the release stage?

■

Do we have the resources to undertake the release stage?

RELEASE STAGE Overview This is the stage when ‘the rubber hits the road’ and you unleash your ‘new order’ on the world and start to realize the benefits your project was set up to create. It involves: ■

the releasing of the validated solution into its operational environment;

95


■

the start of all operational support;

■

the handover of the solution from the Project Manager to the process owners, functions and business units for ongoing operation and assurance.

In addition, work is carried out post release to ensure that the environments left by the project are ‘clean’, for example that old data are removed from computer systems. It finishes with a project closure review, when the project is formally shut down. The review should include a ‘lessons learned’ session. What worked well on the project? What didn’t? Were all the controls effective and useful? What would you use again? What would you do differently next time? Closure is discussed in more detail in Chapter 8.

Key deliverable The Project Closure Report contains the notes of solution handover and project closure, including ‘lessons learned’ from the project in terms of how the processes, organization, systems and team worked (i.e. the efficiency of the project). Terms of reference for the Post-Implementation Review are also included.

Focus on The project deliverables should now be completed, but that does not mean that they are being put to beneficial use. During this stage make sure that the handover of the solutions and capabilities to the operational domain and those with ongoing accountabilities is smooth and complete. Do not expect perfection, but do expect there to be management actions in place to deal with any problems rapidly. Until everything is handed over, the buck stops with you.


Look for signs of corners being cut, capabilities not being properly sorted, processes not working adequately, accountabilities being confused.

■

Users do not accept the solution (a bit late for this to be found out now and a damning indictment of the effectiveness of the stakeholder engagement so far).

■

The project closure is not done and funds are diverted to ‘pet initiatives’ or propping up other overspending projects.

■

The lessons aren’t learned and the same mistakes are made again and again on future projects.

■

96

No one thanks and rewards the Project Manager and team for a job well done.


PROJECT COMPLETION CHECKLIST Key control document: Project Closure Report The solution is now in full operation and it is time to close the project formally. You must be satisfied that everything planned was done. Don’t fall victim to ‘scope creep syndrome’, in which new feature after new feature is added before the team is dispersed. Don’t let anyone off the hook until the work is completed. All too often this part of the project is rushed as attention has moved on to new things. However, losing focus will adversely impact benefits realization.


Has the business forecast been updated to take into account the benefits arising from your project?

■

Have you decided who will monitor the benefits and how?

■

Have review points and metrics for measuring the benefits been put in place?

■

Have all suppliers been paid?

■

Has the project account been closed so that no more costs can be incurred?

Post-Implementation Review (PIR) ■

Have you agreed the need for, timing and terms of reference for the PIR?

■

Have you appointed a ‘Review Manager’ for the PIR, if not undertaking the role yourself?

Questions to ask your Project Manager: Risks and issues ■

Have all issues been resolved or handed over to a named person in the operational environment or another project?

■

Has ownership of each outstanding risk been accepted by a named person in the line or in another project?

Team/stakeholders ■

Have all who need to know about the closure of the project been identified?

■

Have team appraisals relating to the project been completed?

■

Have you acknowledged those who deserve special thanks and recognition?

97


Lessons learned ■

Have all lessons learned been recorded and communicated to the relevant process and documentation owners?

POST-IMPLEMENTATION REVIEW Overview You should carry out a Post-Implementation Review after sufficient time has elapsed for the benefits of the project and the operation of the outputs to be assessable. The review cannot cover every aspect, but it should establish whether: ■

the predicted benefits were realized or are on track to be realized;

■

the most effective operational systems, processes and structures were designed;

■

the solution really met the business needs, both for users and customers.

As you are the one who wanted the benefits and for whom the project was undertaken, it is in your interest to initiate the review. This review should result in action plans for improvement where necessary and hence help in the achievement of the benefits. For major projects this review may be carried out by an ‘audit’ function, but in all cases it is better (although not essential) if it is conducted by someone independent of the project team. To be effective, the review must not be used as a ‘witch hunt.’ If you use it in this way, you’ll never have the truth presented to you again!

Key deliverable The Post-Implementation Review (PIR) Report assesses the success of the project against predefined conditions of satisfaction given in the Business Case. It assesses how effective the project was in meeting its business objectives and how well the outputs are operating in practice and includes recommendations for improvements.

Focus on Your focus here is on confirming that the benefits are being realized and the solutions operating to expectations. Look for any deviations and ensure that corrective action is put in place. Confirm that the original business need has in fact been fulfilled.

98



This review is often not done either because interest has waned and the world has moved on or because it is felt that the outcome of the review will be embarrassing. If we are not ‘big enough’ to learn from mistakes, we are probably not fit to lead major change.

■

The wrong people are engaged in the review and it concentrates on ‘how the project went’ rather than whether the benefits were realized and whether the solution worked effectively.

CHECKLIST AT POST-IMPLEMENTATION REVIEW Key control document: Post-Implementation Review Report

Questions to ask yourself and/or your boss: Business need ■

Are the benefits being realized as expected?

Operational aspects ■

Are all aspects of the solution working as envisaged?

Action ■

Has a corrective action plan been put in place to address any shortfall in expected benefits?

■

Has a corrective action plan been put in place to address any shortfall in operational aspects?

■

Have all lessons learned been recorded and communicated to the relevant stakeholders?

SUMMARY ■

The staged project framework enables you to direct projects which are benefitdriven, are user-focused, take risk into account, allow parallel working, build in quality and draw on resources from across the organization. See Fig. 7.1.

99


■

Stages are periods of time during which the work happens. Stage names vary from company to company and method to method, but all involve investigative stages and build/development stages.

■

Gates are milestones, used as check points to verify that the project is still required, its priority relative to other projects, the plans for the remainder of the project and whether a decision to continue is in the best interests of the company. Gates are entry points to stages.

■

Each gate has defined criteria which must be met before the next stage is started. The Project Sponsor is the key decision maker at the gates.

■

Your focus and attention will change as the project moves through its life cycle.

Fig. 7.1

100

The staged project framework

Stage

Proposal

Initial Detailed Develop Investigation Investigation and Stage Stage Test Stage

Trial Stage

Release Stage

PIR

Key control deliverable

Proposal

Initial Business Case

Business Case

Ready for Trial Review Report

Ready for Service Report

Project Closure Report

PIR

Attention

High

High

Medium

Low

High

High

High

Focus

Why?

How?

What and when?

Delivery

Risks

Acceptability

Benefit realization

Key interactions

Stakeholders

Stakeholders and project team

Stakeholders and project team

Project team

Stakeholders Stakeholders Stakeholders

8 Closure – being confident that you have reached the start!

■

Why closure?

■

The closure report

■

Formal closure review and approval

■

Closure actions

■

Summary

103 103 104

106

106

101

Closure

WHY CLOSURE? Closure is the formal ‘end point’ of a project, either because it is complete or because it has been terminated. Termination may occur because the project is no longer viable or because the risks associated with it have become unacceptably high. The objective of project closure is to ensure that: ■

a project is closed down in a controlled and organized way;

■

all accountabilities relating to it have been discharged or handed over to the line or to another project.

The closure review should: ■

review the efficiency of the project in terms of meeting the original time, cost, scope and resource targets;

■

confirm the benefits have been built into the business forecast;

■

record and communicate any lessons which can be beneficial to future projects.

As far as you, as the Project Sponsor, are concerned, either the project has been completed and you can now expect to benefit from it,

OR

the project has been

terminated. In the latter case, this may be because the original business need no longer exists, but if it does, you will have to take action to address the unresolved business need which initiated the project in the first place. There are three key steps to closing a project: 1

when the Project Manager drafts the closure report;

2

review and approve: when you formally close the project;

3

action: when the Project Manager undertakes the final closure activities.

THE CLOSURE REPORT It is your accountability, as Project Sponsor, to approve the closure of a project. However, if a project is to be closed part way through (terminated) and other projects are affected (the project definition will define any inter-project dependencies), you may need to: ■

agree it with the Project Sponsor(s) of the affected project(s) or

■

seek a decision from a higher authority (if any).

If you are the sponsor for all the affected projects, clearly this is a decision you will take yourself. When a project is to be closed, you should expect the Project Manager to:

103


■

check the status and completeness of the business case (including the project definition), the change and issues logs, the most recent progress report and any papers referring to early cancellation of the project;

■

prepare a draft project closure report with the team, including agreeing with you the terms of reference for the Post-Implementation Review (PIR).

The purpose of the closure report is to record accurately the reason for closure and any outstanding accountabilities which need to be handed over. It also documents any lessons learned regarding how the project was conducted and the efficacy of the supporting processes. The project closure report should include the following sections: 1

Business Objectives;

2

Closure Statement;

3

Benefits Measurement;

4

Outstanding Issues and Deliverables;

5

Project Efficiency;

6

Lessons Learned;

7

Acknowledgements;

8

An appendix giving the terms of reference for a post-implementation review (if required).

FORMAL CLOSURE REVIEW AND APPROVAL The Project Manager should agree with you the procedures for closing the project formally. This will normally be a meeting, chaired by you and at which you formally approve the closure. You will need to discuss the list of attendees with the Project Manager so invitations can be sent out in plenty of time. The invitees will be core members of the project team, key suppliers or customers and the key impacted stakeholders. By drawing the group together, you will have an opportunity to: ■

assign accountabilities for outstanding issues;

■

ensure that feedback reflects the differing viewpoints of those involved;

■

acknowledge the team and celebrate.

The quality and sharing of feedback is always greater when done in a group than when conducted in isolation. You may also want to consider using a facilitator to run the feedback parts of the agenda as this frees you and the Project Manager up to act as participants. A suggested agenda for a closure meeting is given overleaf. The draft project closure report, which should be circulated prior to the meeting, provides the briefing for the 104

Closure

attendees. This will be amended on the basis of the discussions and feedback received at the meeting and reissued to you for authorization after the meeting.

Project closure meeting agenda 1

Deliverables Confirm that all deliverables have been approved and accepted by the business.

2

Outstanding Issues Review outstanding issues; for each issue, obtain agreement from a named person in the line or in another project that he or she will ‘own’ the issue and its resolution.

3

Benefits and Business Plan Confirm that the benefits have already been built into the business plan or are due to be included in the next forecast. Accountability for the monitoring of benefits should be agreed together with a timetable of defined review points.

4

Post-Implementation Review If a PIR is required, the terms of reference should be agreed together with a timetable and named participants. The accountability for the review must be agreed.

5

Acknowledgements Acknowledge all contributions to the project.

6

Formal Closure Assuming all the preceding business has been conducted, the Project Manager and Project Sponsor should ‘sign off’ closure of the project.

7

Lessons Learned What worked well on the project? What did not? Were all the controls effective and useful? What would we use again? What would we do differently next time? Suggested attendees: ■

Project Sponsor (chair);

■

Project Manager;

■

Facilitator;

■

Project Board members;

■

Key team members;

■

Functional line/process managers accountable for signing off key deliverables;

■

Functional line/process managers who will accept accountability for outstanding issues;

■

Project Manager from any related projects who will accept accountability for any outstanding issues. 105


Small projects If the project is small or if you do not believe that a meeting will add value, formal closure should be agreed by you after a review of the closure report by the relevant individuals.

Large projects It may be advisable to hold two meetings for large projects; the first to cover items 1–6 of the agenda shown on the preceding page and the second to cover item 7. This is particularly of value when it is known that the project can contribute greatly to the company’s corporate learning.

CLOSURE ACTIONS Following approval to close the project from the Project Sponsor, the Project Manager should: ■

finalize the project closure report;

■

prepare a communication, enclosing the approved project closure report to the Project Sponsor, project team and stakeholders, confirming the decision to close the project;

■

feed back any suggested process improvements to the relevant project offices and/or process support group.

What should happen to the lessons? Collecting the lessons learned from each project and focusing on them at project closure will ensure that those involved in the project are less likely to fall into the same traps twice. It will not, however, ensure no one else does! If your company as whole is to benefit, you need to be able to make these lessons more widely available, for example by asking those managers present to share them with their teams at the next opportunity. In large companies this can be problematic, as the volume of information can be daunting. Intranet capabilities are invaluable in this respect.

SUMMARY

106

■

Closure is the Project Sponsor’s decision.

■

Check interdependent projects before terminating yours.

■

Make project closure explicit.

Closure

■

Communicate closure to the stakeholders.

■

Learn the lessons and share them.

Closure checklist 1

Deliverables ■

Have all project deliverables been approved and handed over to ongoing ‘owners’?

■

2

Has accountability for outstanding deliverables been agreed?

Issues ■

Have all issues been resolved?

■

Has ownership of each outstanding issue been accepted by a

NAMED

person in the line or in another project? 3

Business Forecast ■

Have the functions and business units updated their plans to take into account the operational resources, costs and benefits relating to the project?

4

5

■

Has the Business Forecast been updated or will it be?

■

Has a person accepted accountability for monitoring the benefits?

■

Have review points for measuring the benefits been defined?

Post-Implementation Review (PIR) ■

Has a decision been made to have a PIR?

■

Have the timing and terms of reference for the PIR been agreed?

■

Has it been agreed who is accountable for ensuring that the PIR takes place?

Team and stakeholders ■

Have all who need to know about the closure of the project been informed?

6

■

Have all team members been reassigned to other activities?

■

Have project team appraisals relating to the project been completed?

■

Have those who deserve special acknowledgement been acknowledged?

Project documentation ■

Has all documentation pertaining to this project been filed, archived and referenced?

7

Facilities ■

Have all project facilities (desks, computers, office space, etc.) been released?

■

Have all facilities reserved for the project outputs or contracts raised been cancelled?

107


8

Project accounting and other systems ■

Has the project account been closed so that no further expenditure can be attributed to the project?

■

Have other corporate or functional project-tracking systems and registers been updated?

108

Part three Managing schedule, costs and risks

■

9

Schedule, cost and scope of planning

■

10 Risk, issues and change – your key indicators

111 127

109

9 Schedule, cost and scope planning

■

Fundamentals

■

The project schedule

■

Summary and detailed schedule plan

■

Critical chain

■

Inter-project dependencies

■

Project finances

■

Authorization of funds

■

Financial reporting

■

Monitoring progress

■

Summary

113 113 114

117 118

119 122

123 124

125

111


FUNDAMENTALS Time, cost and scope are intimately related (see Fig. 2.2). The development of a defined set of deliverables will take a given amount of time, consume certain resources and cost a certain amount of money. If the scope is increased, unless more resources are applied, it will take longer and cost more. Because of this intimate relationship, project plans should be built using a structure which integrates cost, time and scope. The decomposition of a project into smaller packages of work is called a ‘work breakdown’ and is a fundamental tool in project planning which enables a Project Manager to plan at the most appropriate level of detail under the prevailing circumstances. From this principle, provided the Project Manager manages the schedule effectively, as given in this briefing, the matching financial and scope management aspects will follow. In fact, there is no need for a separate process to look after scope planning: it is integrated as a matter of principle.

THE PROJECT SCHEDULE You will find that the management of the project schedule is one of the most fundamental of project management techniques. So much so that many people (incorrectly) think that schedule management is project management. At a simple level, the schedule tells you how long the project or any part of the project will take. In addition to giving dates, a well-produced project schedule also tells you: ■

who is accountable for every aspect of the project;

■

the approach being undertaken;

■

the major deliverables from the project;

■

the timing of key review points.

The schedule is also the basis on which cost and resource plans are constructed. However, unlike costs and resources, which are seen by only a few people observing a project, key dates are very visible. A well-publicized delivery date for a project, when missed, is very hard to hide. While ‘time’ may not be the most important aspect for you on some of your projects, an observer may develop his or her own perception of ‘success’ or ‘failure’ purely from the performance of your project against the publicized target dates. The ability to build and manage the schedule plan is one of the essential skills all project managers should have. Planning is far too important to delegate to junior team members, especially in the early stages of the project when the overall strategy and approach is being developed. The plan sets the course for the remainder of the project. Once agreed and set (at the Development Gate) it is very difficult to change 113

Part Three: Managing Schedule, Costs and Risks

or improve on. All the decisions which have the most leverage on time, costs and benefits will have already been made. Done effectively, the project plan will benefit you by providing: ■

a baseline against which to measure progress (without a plan, words such as ‘early’ or ‘late’ have no meaning);

■

a common understanding of the approach being taken to achieve your objectives;

■

a breakdown of the project workload into manageable pieces (work packages) based on the deliverables/outputs wherever possible;

■

a clear way of showing interdependencies between activities and work packages within the project and to/from other external projects;

■

a listing of accountabilities for different activities and work packages.

All projects are undertaken within an environment of risk. Good planning is done in the full knowledge of those risks.

SUMMARY AND DETAILED SCHEDULE PLAN The schedule plan can be considered on two levels: ■

summary – of most interest to you, as the Project Sponsor;

■

detail – of most interest to the Project Manager and team.

The former is used to map out the entire project, while the latter is used to show the detail for the current stage. For work packages done by others (for example by a contractor), the person or group doing the work will prepare the detail. However, your Project Manager needs to be satisfied that the plan is workable and includes sufficient check points for him or her to monitor their progress. Developing a schedule plan is an evolutionary process which starts with a statement of key objectives, deliverables and scope, followed by the preparation of a summary plan. From this your Project Manager should be able to estimate: ■

the resources required;

■

the cost of the project.

Before you agree to start working on any stage of the project, you should ensure that the Project Manager has prepared appropriate detailed plans. The criteria for all the entry gates in the staged framework from the Detailed Investigation Gate onwards include a detailed plan as a prerequisite. The attributes of a good schedule plan are shown in Fig. 9.1.

114

Plan project, finalize Initial Business Case

2.5

Register start of stage and assemble team

Finalize design and specification

6.2

DEVELOP AND TEST STAGE

6

6.1

Business Case Gate

Submit Business Case for authorization

4.7

5

Define operational impact

Define development/Service Definition

4.4

4.6

Evaluate Feasibility

4.3

4.5

Undertake feasibility study and prepare Feasibility Report

4.2

Indentation and logical numbering Define chosen solution shows the levels of the WBS easily

Engage team

DETAILED INVESTIGATION STAGE

4

4.1


3

F. Player

H. Woodcock

B. Hives

F. Player

F. Player

F. Player

M. Lance

Accountability

29 Apr. 2003

20 Apr. 2000

23 Apr. 2003

20 Apr. 2003

13 Apr. 2003

7 Apr. 2003

5 Apr. 2003

12 Mar. 2003

8 Mar. 2003

8 Mar. 2003

8 Mar. 2000

1 Mar. 2003

22 Feb. 2003

19 Feb. 2003

8 Feb. 2003

1 Feb. 2003

26 Jan. 2003

26 Jan. 2003

20 Jan. 2003

Start

29 Apr. 2003 Accountability: a single name at every level 30 Apr. 2003 in the WBS. No gaps.

F. Planyer

M. Lance

F. Player

K. Coral

S. Smith

S. Smith

H. Woodcock

J. Jones

F. Player

F. Player

Describe activities using active verbs!

Evaluate the Investigation

2.4

Submit Initial Business Case

Undertake the Initial Investigation

2.3

2.6

Engage the project team and plan the initial Investigation

2.2

INITIAL INVESTIGATION STAGE

2

Register start of stage and set up project controls


1

2.1

Description

A typical schedule plan

No.

Fig. 9.1

14.02

27 May 2003

30 Apr. 2003

20 Aug. 2003

20 Apr. 2003

29 Apr. 2003

23 Apr. 2003

20 Apr. 2003

13 Apr. 2003

7 Apr. 2003

March 28.02

14.03

21.03

April 28.03

18.04

25.04

The date scale is essential

11.04

02.05

May

Milestones should be distinctive

Business Case

Development/Service Definition

Delay likely due to resource shortage

Feasibility Report

This activity has started and will finish late!

04.04

Being able to write notes is useful

Dependencies between activities can be shown

07.03

The baseline tells you when the activity should have happened

21.02

Completed milestones and activities

29 Apr. 2003

8 Mar. 2000

8 Mar. 2003

1 Mar. 2003

22 Feb. 2003

19 Feb. 2003

8 Feb. 2003

1 Feb. 2003

8 Mar. 2003

20 Jan. 2003

Finish


Typical schedule reports Schedule reports come in two basic styles: ■

tabulated;

■

bar chart (as Fig. 9.1).

Tabulations typically comprise a list of the key gates, milestones and deliverables with the baseline date and either achieved or forecast date for comparison. In addition, they can show the position in the work breakdown and the person accountable for each milestone. They are simple lists and as such are not good for deducing any underlying problems or issues. Bar charts, on the other hand, are good formats for all-round reporting and analysis. However, to the uninitiated, they can be confusing and difficult to read. So it is good practice if the Project Manager uses consistent formats and styles when using these as a reporting tool.

Tracking progress Tracking progress towards delivery is essential. If the Project Manager doesn’t do this, you simply won’t know when you are going to arrive or even if you will arrive. You need to understand and agree the progress-tracking method used by your Project Manager. There are many ways to measure progress, the commonest being: ■

assessing percentage complete;

■

assessing the remaining duration for an activity;

■

estimating the date when a task will be completed.

Many people use the ‘percentage complete’ method. However, this method has potential dangers if an objective estimate of ‘percentage complete’ cannot be determined (such as measuring hours worked); it is not unusual to find an activity is 90 per cent complete for 90 per cent of its duration! A simpler method is to estimate the date when a task will be completed. An activity is either: ■

completed (i.e. 100 per cent complete);

■

not started (i.e. 0 per cent complete);

■

or started but not complete.

Activities which are started but not finished are assumed to be 0 per cent complete, but a current best estimate of the expected finish date is made. Expect the schedule to be updated at least monthly, but for faster-moving projects, weekly or fortnightly would be more appropriate. This update cycle should tie in with the regular progress reporting on the project as it is the most

116


concise method of showing what has been achieved and what is to happen next. The Project Manager should use summary reports for reporting to you and other key stakeholders, while detailed reports should be used for reporting within the project team.

CRITICAL CHAIN Despite decades of project management experience, backed up by ever more sophisticated technology, projects still deliver late. We have seen that a project schedule is basically the sum of the estimates (often guesses!) of the durations of those activities on the critical path. The project approach is evaluated using network planning, and estimates are made for how long each activity will take bearing in mind the resources needed. It’s all very logical. From here on, human behaviour takes over. Somewhere in the schedule some ‘padding’ will have been introduced into each activity which will increase the duration of the project and protect the Project Manager and team from ‘delivering late’. The challenge for you is not to remove the padding, but rather to make sure it exists to cover legitimate risks and is placed in the schedule where it can be of most benefit. In his book Critical Chain, Eli Goldratt proposes a solution to this. Rather than being added to each activity, he proposes that padding is added in a single lump towards the end of the project (see Fig. 9.2). In practical terms he says: ■

cut the duration of each activity as estimated by the team in half;

■

add, towards the end of the project, a safety time equal to half the sum of the safety times you trimmed. This is called a ‘buffer’.

In this way, the padding can be placed in a position where it really counts, towards the end of the project (prior to the Ready for Service Gate), where it can be used. Note, however, that this technique requires a very different approach from both you and the Project Manager if it is to be effective. You: ■

need to ensure that you have an experienced and well-trained Project Manager, who is familiar and comfortable with this approach;

■

should not hold the Project Manager to any intermediate milestone dates – you cannot expect everything to be on time or to be early;

■

need to agree the few key milestones which must be met and which therefore need protecting from slippage;

■

need to monitor the size of the ‘buffer’, rather than intermediate milestones, to predict the likelihood of delivering late.

117


Fig. 9.2

Putting the padding where it counts – towards the end

Activity 1 Activity 2

Safety built into each activity ‘just in case’

Activity 3 Activity 4

time

Activity 1 Activity 2 Activity 3

Safety placed at the end of the project, where it counts

Activity 4 Safety buffer

time

The key question to ask In any event, whether the Project Manager is using a critical path or critical chain approach you should ask him or her to tell you where contingency time has been built in and ask him or her whether this is in the most effective place.

INTER-PROJECT DEPENDENCIES Many projects require deliverables from other projects as a prerequisite to completion. For example, a software project may require another project to deliver a particular hardware configuration before it can be tested. It is very important to ensure that the scope of each project is well defined, particularly when different departments in a company are involved. If the full scope of each project is not clear, then accountability for delivery becomes vague and this will threaten project success. It will often be found that senior and line management who are not intimately involved in a project, or series of projects, will have different perceptions of the scope of a project and may even view a package within a project as a ‘project’ in its own right.

118


The breakdown of a project into discrete work packages related to specific deliverables is essential if such confusion is to be avoided. The plan for a project should only show those activities and deliverables for which the Project Manager is accountable. Activities done by others in other projects should not be shown in detail. Such linkages should, however, be recorded, for example by using a down arrow symbol in a bar chart on the date when the deliverable is due to be completed and is ready for use by the receiving project. Watch these special milestones carefully as interdependencies are frequently a source of risk, delay and confusion. If your project is one which has interdependencies with other projects, you should include the other Project Sponsor(s) in your stakeholder list and come to an understanding on the relative priorities and needs of the respective projects. It may be that your project is fundamentally higher in priority, but if you rely on a deliverable from a lower-priority project you need to be certain that senior management directives do not slow that one down (say, through moving resources to higher-priority areas) and have an adverse impact on your project.

PROJECT FINANCES After managing time, management of the finances is the most important and fundamental aspect of project management. Without a good schedule plan it is impossible to have a reliable financial plan. However, while the schedule is the most visible aspect of a project to outsiders, cost is often the most visible to insiders, such as the finance team – sometimes it is the only aspect they see or want to see! At a simple level, a financial plan will tell you: ■

what each stage and work package in the project costs;

■

who is accountable for those costs;

■

about the financial benefits deriving from the project;

■

about the financial commitments made;

■

about cash flow;

■

about financial authorization given.

In addition, some companies also derive the net effect of the project on their balance sheet and profit and loss account. Just as the a schedule plan is used as the baseline for measuring progress in terms of ‘time’, the financial plan is the basis for measuring costs and financial benefits. Many of the other principles already explained on schedule management are also applicable to the management of finances. Schedule and cost plans should share the same work breakdown structure. By doing this you ensure that: ■

accountability for both schedule and cost resides with the same person;

119


■

there is no overlap and hence double counting of costs;

■

there is no ‘gap’, i.e. missing costs.

In practice, the financial plan is likely to be developed to a lesser level of granularity (work breakdown) than the schedule plan. The financial plan, like the schedule plan, is developed in summary for the full project and in detail for the next stage. There is little point in developing an ‘accurate’ and detailed financial plan on the back of an unstable schedule plan. No matter to what level of granularity you take the calculations, they will be fundamentally inaccurate. You should see that the level of accuracy and confidence is taken forward with the schedule and related costs matching. The costs are influenced by the following, which must be taken into account when the plan is drawn up: ■

the scope of the project;

■

the approach taken to the project;

■

the timescale to complete the project and its component parts;

■

the risks associated with the project.

Financial management controls Financial management of a project comprises: ■

estimating the costs and benefits (preparing the financial plan);

■

obtaining authorization to spend funds;

■

recording actual and committed costs;

■

forecasting future costs and cash flow;

■

reporting.

Tracking progress towards the objectives is essential. If it isn’t done, you simply won’t know how much your project will cost. The cost estimates should be based on the work scope and schedule plan defined in the project definition, using the same work breakdown structure as the schedule plan and estimated to the same level of accuracy. An estimate should be made up of: ■

the cost of using your organization’s own employees (internal labour);

■

the cost of external purchases made as a result of the project.

The overall cost plan should be built up from three elements: ■

120

the base estimate;


■

the scope reserve;

■

contingency.

The base estimate is the total costs for all the activities identified, including the cost of the organization’s employees’ time and all external purchases. The scope reserve is an estimate of what else experience and common sense indicate needs to be done, but has not yet been explicitly identified. This can be very large: for example, the scope reserve required in software-based projects can be as high as 50 per cent of the base estimate. Normally, you would delegate the authority to use ‘scope reserve’ to your Project Manager, who should use formal change management to move funds from ‘scope reserve’ to ‘base estimate.’ Contingency is included in the estimate to take account of identified risks. It is not there to compensate for poor estimating. If a risk does not occur, the money put aside as contingency should not be spent. For this reason, the authorization for spending contingency is best left to you, the Project Sponsor. Again, formal change management should be used to move the costs from ‘contingency’ to ‘base estimate.’ The proportion of the estimate divided between the above will alter as the project moves through its life cycle stages. You should expect a higher proportion of scope reserve and contingency in the earlier stages than in the later stages. Figure 9.3 shows that in the earlier stages you should expect the bulk of the cost to be ‘soft’; the next stage should be a ‘hard’ estimate. ■

A soft estimate is one in which a low level of confidence can be placed.

■

A hard estimate is one in which you have high confidence.

Fig. 9.3

Estimating accuracy – the further away the stage, the softer the estimate

Detailed Initial Investigation Investigation

Develop and Test

Trial

Release

Soft

None

None

None

None


ACTUAL

Hard

Soft

Soft

Soft

Development Gate

ACTUAL

ACTUAL

Hard

Hard

Hard

Trial Gate

ACTUAL

ACTUAL

ACTUAL

Hard

Hard

Ready for Service Gate

ACTUAL

ACTUAL

ACTUAL

ACTUAL

Hard


Regardless of whether the estimates are soft or hard it is important you know the assumptions, constraints or qualifications used in deriving the estimate.

121


Notice that no mention is made of the financial or fiscal year. Projects rarely respect such artificial boundaries. When a project is planned it should be planned for its whole life cycle, and not just that which falls within the current financial year. True, cash flow may need to be managed to ensure that any budget constraints are not breached. However, if a project is forecast on a monthly basis, any fiscal cuts can be deduced.

AUTHORIZATION OF FUNDS Corporate attitude to financial authorization Every organization has rules prescribing who has the authority to spend money. If you are a subsidiary company, such rules may be imposed on you by your parent company. Public agencies may be working to rules set by a government department. These processes can be onerous and time consuming if not matched to the project process you are using. More forward-thinking organizations ensure that the timing of financial authorization, as laid out in their finance processes, match the gates and review points in their project framework. There is little point in allocating money to a project only to stop it almost immediately on the basis of non-financial factors. Authorization of a project should include not only finances, but also resources, timing, scope, benefits and quality. This area of corporate governance is probably where corporate management and culture can have the greatest impact on project management. A mature projectmanagement oriented organization will ensure that there is a single authorization process, covering all needs, which takes a balanced approach to decision making. More immature organizations probably focus mostly on finances. This tends to make the project authorization process seem more like a complex ‘purchase order’ system where the aim is merely to obtain money, rather than take a value-added, business-led decision. Such organizations are recognizable as the decision points are seen as hurdles to leap and are often treated with lip-service. Whatever the attitude and state of maturity in your organization, you need to be clear, as Project Sponsor, what authority you have to allocate funds to a project and under what circumstances you will need to go to others for such funding decisions. Where possible, you should consider the funding question, together with the other aspects.

A staged approach to authorization Each of the gates in the project framework offers the opportunity for you, the Project Sponsor, to allocate more funds to the project. You should allocate a limited

122


amount of money at the very start of the project (Initial Investigation Gate) to investigate the proposal so an informed decision to proceed can be made later at the Detailed Investigation Gate. Subsequently, further funds can be allocated on a stage-by-stage basis until the project is completed. For long stages it may be prudent for you to hold back full authorization and introduce intermediate review points. Such points may conveniently be prior to major commitments such as letting a contract. The project framework will work for whichever way you choose to arrange fund authorization. The key is to ensure that such authorization processes are consistent with the principles of the project framework and concentrate only on substantive issues.

Investment appraisal Authorization of funds is usually based on some form of investment appraisal. This briefing will not go into this in any detail as there are many books which deal with the plethora of methods which can be used. While each company will have its preferred approach, the following key points should be considered: ■

Investment appraisal should be based on cash flow.

■

Discounted cash-flow techniques are the most favoured.

■

Use least cost development (lowest net present value, NPV) if you must do the project.

■

Use internal rate of return for other projects.

■

Concentrate on substantive elements only. If a figure is wrong and has no significant impact on the appraisal don’t waste time having it changed.

■

Use sensitivity and scenario analyses liberally – they give you more feel for the project than spurious accuracy in estimates (see Chapter 10).

Finally … ■

Do not consider financial criteria as sacrosanct. Many projects are worth doing for non-financial reasons because they support your basic strategic direction.

■

Some things can’t be reduced to financial terms. Just because you can’t count them doesn’t mean that they don’t count!

FINANCIAL REPORTING The future is more important than the past. Any money you have already spent is lost and cannot be recovered (sunk costs). For this reason you must be concerned not only with what has actually been spent, but also with the forecast of what is

123


yet to be spent. The important figure to concentrate on is ‘what the project will have cost when it is completed’. To arrive at this figure, simply add any costs incurred to date to any costs yet to be incurred. The forecast is simply an estimate of what figures are going to appear on the project account during any particular period. So forecasts must: ■

use the same costing methods as actuals are measured;

■

be forecast on at least a stage-by-stage basis;

■

be timed to match the actuals (most organizations have a monthly cut-off).

By means of their accounting and operational systems, companies collect a considerable volume of data. Unless these data are converted into meaningful information, they are useless. Any reports produced by your Project Manager or finance support must be aimed at providing useful information which will act as a prompt for your action. As the reports seek to promote action, they should be: ■

timely;

■

as accurate as possible within those time constraints;

■

forward-looking.

A typical financial report tells you, in financial terms: ■

what has been spent to date;

■

the expected outcome for the project;

■

the impact on the current financial year;

■

the cost of work yet to be done.

MONITORING PROGRESS Focus mostly on the future Do not concentrate only on what has been completed. Look at what is coming up next. Consider, from your experience to date, whether the timescales, costs and resources allocated are adequate; if they aren’t, corrective action is needed now. Anticipating problems is good practice and provides more time to find solutions. If problems are ignored they don’t go away: they grow. Keep in mind that your main focus is to reach the RFS Gate, the trigger point when benefits can start to flow. You do not need to see every activity completed on time and to budget. Every duration and cost in the plan is basically a guess. Some will be good, some will be appalling and others will be the unfortunate victims of ‘Murphy’s Law’. Too much concentration on the wrong detail will divert attention from the real

124


issues … but no ‘rule book’ or process can tell you what the real issues are; this is a matter for your judgement.

Look for signs of planning distress Sometimes, you will find when monitoring against the plan that you have difficulty assessing progress. This often happens because the work is, in fact, being undertaken in a different way from that planned. In most cases this is not a problem if the key milestones, dates, and interdependencies are not affected. It can be symptomatic of ‘micro-planning’, i.e. the Project Manager planning at too detailed a level. At other times, it is simply because the plan has not been fully thought through. In which case you should ask the Project Manager to revisit it to reflect the actual work to be done (using the change management guidelines, of course). Changes of this nature often occur frequently in the early part of a project as a result of uncertainty. The plan should become stabilized quite soon if the Project Manager and team have applied themselves to it. You may also find that a particular work package is unstable. This could indicate either that the manager in question has not planned it properly and is not in control, or that it is inherently risky. Both reasons may need your intervention. In addition to reviewing the plans, look at the risk and issues logs (see Chapter 10). These, together with the plans, provide you with a richer picture of status: ■

Are the issues being managed or ignored?

■

Does the ongoing plan take risks into account?

■

Are the issues real ‘show-stoppers’?

■

Are the risks acceptable?

SUMMARY ■

You do not need to see a detailed plan for the entire project from the very start. Plan in summary for the full project and in detail for the next stage. As each stage is completed, the reliability of the plan for the remaining stages increases.

■

Look at the plan with respect to risk. Especially consider risks to benefits realization. Is there sufficient cost and schedule contingency to cover known risks? Is this contingency placed at the points in the plan where it can have most effect?

■

Once the plan is agreed, baseline it. Without a baseline, words like ‘early’, ‘late’ and ‘overspent’ have no meaning.

■

Look out for any interdependencies with other projects – they can be risky. Ensure that the respective Project Sponsors are on your list of engaged stakeholders.

125


■

Are you clear on what formal authority you have to commit your organization to spending money?

■

Keep your eye on the future. Ensure that schedule, benefits and costs are forecast regularly.

■

Use the Project Manager’s progress reports to monitor the project but do not rely solely on them. Make your own enquiries, paying attention not only to what people say, but also to how they say it. Look for hard evidence.

■

126

Always look at the project in its business context.

10 Risk, issues and change – your key indicators

■

Risks, opportunities, issues and change

■

Considering the possible risks and opportunities

■

Issues management – what has gone wrong

■

Managing changes to the project

■

Summary

129 130

136

138

141

127


RISKS, OPPORTUNITIES, ISSUES AND CHANGE Risk is any potential threat or occurrence which may prevent you from achieving your defined business objectives. It may affect timescale, cost, quality or benefits. All projects are exposed to risk in some form, but the extent of this will vary considerably. Opportunity is the possibility that your project may go better than you planned. Issues management is the process for recording and handling any event or problem which either threatens the success of a project or represents an opportunity to be exploited. Change, in the context of a project, is any modification to the benefit, scope, time or cost targets. There can only be a ‘change’ if there is a previously approved standard or ‘baseline’. Such a baseline is provided in the project definition (included in the initial and full Business Case). Figure 10.1 shows how risk, opportunities, issues and change relate to each other; a risk will become an issue if the event occurs. Issues can be resolved either within the scope of the project as currently defined or via a change to the project. An opportunity is similar to a risk but has a potentially beneficial impact rather than a negative one. Like risk, an opportunity will become an issue if the event occurs and requires management action from you. Fig. 10.1

Risk, opportunities, issues and change

Risk

What might happen

Opportunity

It doesn’t happen

It happens

Unexpected events

Issues

It doesn’t happen

What has happened Solve

Change

What needs changing to keep the project viable

129


CONSIDERING THE POSSIBLE RISKS AND OPPORTUNITIES The purpose of risk and opportunity management is to ensure that: ■

risks and opportunities on projects are identified and evaluated in a consistent way;

■

recognized risks to the project’s success are addressed and significant opportunities are exploited without undue delay.

You cannot use risk management to eliminate risk altogether, but by careful planning, it may enable you to avoid it in some instances or minimize the disruption in the event of its happening in others. But what if a new opportunity comes about which will further your business objectives better than planned? You have two options: ■

you can keep to the original plan as something quite unexpected may still go wrong and eat into the time and money you’ve saved;

■

you can build the new-found opportunity into the project and ‘mine it’ for all it’s worth.

Traditionally, the former approach is the more prudent, but that does not mean that it always makes more business sense. As the Project Sponsor, you will need to determine the extent to which you should be involved in risk identification and management. This very much depends on the nature of the project and experience of the team. In most cases, project teams are very good at identifying what can go wrong in terms of preparation of project deliverables; however, they are often not so good at identifying possible risks to benefits realization and downstream operation. This is where you should be able to add value and direct the project in such a way that the business objectives are not compromised.

Addressing risk and opportunities at the start of the project Risk should first be addressed by you when you draft the Proposal. By setting out what you perceive as the risks, you will be steering the Project Manager towards solutions which take these into account. You can also ensure that the pattern is set for business risks to be considered. The Project Manager should start identifying risks while the project is being set up during the Initial Investigation Stage. Risk is an important section within the project definition; when you, as the Project Sponsor, approve a project you should do so in full knowledge of the stated risks, accepting the consequences should things go wrong. You are the primary risk-taker.

130


The steps to be taken in risk identification and evaluation are: ■

Brainstorm all the risks that may potentially jeopardize the success of the project.

■

Review each risk in turn and assess the likelihood of the risk occurring and the severity of the impact on the business objectives should it occur.

■

Use a risk matrix, such as the one in Fig. 10.2, to determine the ‘risk category’ (high, medium or low). – For high risks, consider ways of reducing the impact or prepare a contingency plan. – For medium risks, prepare a contingency plan. – For low risks, take no immediate action but continue to monitor them – they may become more significant.

Fig. 10.2

Risk matrix Likelihood of event occurring

Severity of impact

Unlikely < 15%

Fairly likely

Very likely

Almost > 85% certain

1 Minor impact on project schedule or cost. No impact on benefits

Low

Low

Medium

Medium

2 Major impact on project schedule or cost. Minor impact on benefits

Medium

Medium

Medium

High

3 Major impact on project schedule or cost. Major impact on benefits

Medium

Medium

High

High

Taking active steps to reduce the possible effects of risks is not indicative of pessimism, but a positive indication of good project management. Many options exist for addressing risk, including: Prevention: where countermeasures are put in place either to stop the threat or problem from occurring or to prevent it having any impact. Reduction: where the actions either reduce the likelihood of the risk occurring or limit the impact on the project to acceptable levels. Transference: which is a specialist form of risk reduction where the impact of the risk is transferred to a third party such as a contractor or insurance company. Contingency: where actions are planned or organized which will come into force as and when the risk occurs.

131


Acceptance: where you decide to go ahead and accept the possibility that the risk might occur and you are willing to accept the consequences. Consider suggesting to your Project Manager that he or she: ■

brings risky activities forward in the schedule to reduce the impact on the project outcome if they are delayed;

■

modifies the project requirement to reduce aspects with inherently high risk, for example new leading-edge technologies;

■

includes appropriate time and cost contingencies;

■

uses prototypes and pilots to test the viability of new approaches.

A project should not usually contain any high risks by the time it reaches the Development Gate. If it does, the project plan should be reconsidered to lower the overall risk by using an alternative approach or by introducing ways of reducing the likely impact. A convenient way of recording risk is in the form of a ‘log’ as shown in Fig. 10.3. Fig. 10.3 Ref. No.

A typical risk and opportunity log

Description of risk or opportunity

Date raised

Probability Severity Category of impact

Management action Action

by

1

There is a risk that the delivery of the ZM Unit will be late.

3 Mar. Fairly likely 2004

Minor

Low

Monitor J. Marsh through site visit and weekly phone calls to the supplier.

2

There is a risk that resources currently working on the customer processes will be withdrawn to help remove the backlog on deliveries.

8 May 2004

Major

High

Source K. Philips agency staff to train up on deliveries, thereby allowing the skilled process designers to remain on the project.

Very likely

Handling opportunities is similar: ■

For major opportunities, consider amending your baseline plan to build the opportunity in from the start.

132


■

For medium opportunities, prepare an outline contingency plan you could use should it happen.

■

For minor opportunities, take no immediate action; stay with your current plan.

There are many possible options for you to exploit opportunities. Examples include: ■

modifying the project timescale so it is possible to bring the release date, and hence benefits, forward should a risky aspect of the project proceed without undue problems;

■

using time and money saved to incorporate outputs which originally had to be discarded (but make sure that these really add benefit rather than are ‘nice to have’).

Monitoring once the project is in progress You need to ensure that your Project Manager is monitoring and tracking risks and opportunities, using techniques similar to those described below. It is not unusual to find that projects are derailed by known risks, simply because the Project Manager did not pay them sufficient attention. Once the project has started, the Project Manager should: ■

maintain a log of the risks and opportunities similar to the example given in Fig. 10.3;

■

regularly monitor them with the team and reassess the likelihood of their occurrence and seriousness of impact;

■

log, categorize and report new risks and opportunities together with the action being taken to deal with them;

■

report new high risks to you in the regular project progress report (see Chapter 6). And highlight potential significant opportunities.

During the course of a project, either of the following can happen: 1

A risk or opportunity ‘event’ occurs – this should be noted in the ‘action’ column and a corresponding entry made on the issues log.

2

A risk or opportunity event is passed, i.e. the project proceeds and the event does not occur. The category should be recorded as ‘none.’

In both cases, the log entry is ‘closed’ to show that the event no longer requires management attention.

133


Sponsor actions on the risk and opportunity log ■

Review the risk and opportunity log regularly. Is the sum total of risk acceptable to you?

■

Ensure that each ‘risk’ fits the sentence ‘There is a risk on this project that xyz will happen, caused by abc specific event. The impact of this will be def on the business objectives.’

■

Has each risk been properly categorized?

■

Look at the management plan for each risk: does it address the causes? Does it outline a recovery plan?

More sophisticated risk-evaluation techniques The basic approach to risk described above can be used by any person on any project. It requires no special tools, technical or statistical knowledge. In many cases it is the most powerful and effective approach, relying on the creativity and common sense of the team. Nevertheless, there are occasions when other tools and techniques are very valuable for supplementing intuitive analyses. These include sensitivity and scenario analysis and probabilistic modelling (Monte Carlo analysis).

Sensitivity and scenario analysis So far we have looked at risk as black and white. Either it happens or it doesn’t. In practice, however there may be a range of outcomes with impacts ranging from the disastrously negative to the unbelievably positive. You can identify such items easily; these are your assumptions. All assumptions are risks and should be treated as such. Examples are market rates, customer usage, plant efficiency, inflation, customer demand, cost forecasts and timing. Sensitivity analysis is used to review the impact on the project of the possible range of values for each assumption made. Using this, you will be able to see which assumptions are substantive to the case and need to be addressed further. The steps are: ■

identify the assumptions;

■

decide on a range of possible values for each assumption;

■

rework the financial calculations (business model), using these values to see the effect on project viability of variations on that particular assumption;

■

identify those assumptions which have most impact, log them as risks and decide on your response to these risks.

134


Scenario analysis takes sensitivity analysis a step further by looking at alternative futures. A scenario comprises a set of compatible assumptions chosen from the risk and sensitivity analysis which describe the future. This often requires a model to be built so the different assumptions can be used consistently. For example, fewer customers lead not only to less revenue, but also to less cost of sales; but fixed costs may remain the same. Three scenarios should be investigated: ■

optimistic;

■

most likely;

■

pessimistic.

Thus for a pessimistic scenario you assume a late project completion date with a cost overrun with slower customer take-up and usage with more severe downward price pressures than anticipated. This can be tabulated as shown in Fig. 10.4. Fig. 10.4

Scenario analysis

PARAMETER

Pessimistic

Most likely

Optimistic

Timing of RFS

2 months late

On time

2 weeks early

IT cost

£450k

£340k

£320k

Customer take-up

+5%

+12%

+15%

Usage

35 minutes/day

50 minutes/day

65 minutes/day

Tariff erosion

–15% annual

–5% annual

–5% annual

IRR %

–6%

40%

87%

NPV (£k)

–1767

2990

3875

Payback

No payback

3 years

2 years

As for sensitivity analysis, the aim is to provide you and other decision makers with an objective view of the possible consequences of continuing the project, thus enabling you to balance the possible opportunities (up-side) with the associated risks (down-side). This technique can be used as early as the Initial Investigation Stage when cost or revenue estimates may be very unclear. Using this technique, you can look at the outcomes resulting from a series of assumptions for the unknown variables. In this way, a good appreciation of the dynamics of the business proposition and hence its risks can be put together. In some cases, this type of analysis may be used instead of more laborious, detailed cost estimating.

135


ISSUES MANAGEMENT – WHAT HAS GONE WRONG When an issue is identified You should expect a large number of issues to be raised at the start of the project or at the start of a new stage within the project. These will be mainly from people seeking confirmation that aspects of the project they are concerned with have been covered. The Project Manager should deal with most issues, but there will be some which need your attention. Issues are a rich source of feedback on stakeholder concerns as well as a check on completeness of the project plan and effectiveness of the project management. Examples of issues are: Problem issues: ■

the late delivery of a critical deliverable;

■

a reported lack of confidence by users;

■

a lack of resources to carry out the work;

Opportunity issues: ■

a contract negotiation is concluded early;

■

a breakthrough on a new technology cuts months off the development time.

Make sure that your Project Manager records issues, even if he or she has no time to address them or cannot find a person to manage the resolution (see Fig. 10.5). Just making them visible is sometimes enough to start resolving them. Also many issues cannot be resolved on their own simply because they do not reach the core problem; they are merely symptoms of a bigger, core problem. Look out for these. Once other ‘symptoms’ appear as issues it is possible to start making connections which can help identify the core problem. It may be that such connections are only visible from your perspective and not apparent to the Project Manager. The power of the issues log is related to its accessibility. If it is kept secret, no one will know what the problems are and hence will not be able to help. This openness does, however, carry its own risks. If seen by an uninformed stakeholder, an issues log can look like a very negative and damning document for the project. You should, therefore, be very careful to monitor how your Project Manager writes up the issues and how they are circulated or communicated. Make sure that the Project Manager is not being ‘personal’ but rather concentrates on problems: the old saying ‘be tough on the problem, not on the people’ is very pertinent.

136


Fig. 10.5

A typical issues log

Ref. Description of Date No. issue raised 1

Raised by (name)

Issue owner

W. Lorimer

C. Collin

21 April 2004

2

Analyze weaknesses in competitor’s product and ensure that ours covers those: use weak points in advanced PR for our better product.

Main assembly 16 N. Colbourne W. Hoyle plant has been Mar. badly damaged 2004 by fire and will not be available for trial production.

31 April 2004

1

Source alternative manufacturing plant (possibly Thailand) for trial. Establish team to ensure that trial can be located to new site.

A competitor has released an almost identical product almost three months before our due date.

14 Mar. 2004

Resolution Priority Comment: date progress; resolution

What shall we do? 2

How can the trial proceed. Priority 1: 2: 3: 4:

Critical – needs escalation Major impact – can be handled by team Medium impact Minor impact

Sponsor actions on the issues log ■

Review the issues log regularly. Don’t just rely on your regular progress report.

■

Ensure that each issue is phrased as a question; this is more powerful in helping to focus on a solution.

■

Has an appropriate person been assigned as owner? Are there any issues you could or should own yourself?

■

Have they been correctly categorized? Are the Priority 1 issues (show-stoppers) really that important?

■

Look for symptoms and connections between issues. Is there a hidden core problem which needs deeper investigation?

■

If the resolution of the issue requires a project ‘change’, look for a crossreference to the change log in the resolution column.

137


MANAGING CHANGES TO THE PROJECT Changes are an inevitable fact of project life. Seldom does a project go exactly to plan. Unless changes are managed effectively the project team will soon lose sight of the objectives and scope and thereafter lose total control of the project. Managing change does not mean preventing change, but allowing only beneficial changes to be adopted and included in the project. Change may result from a number of sources: ■

changes in business needs/requirements driven by you or other stakeholders, often resulting from changes in the business environment (for example, economics, social factors, competitor action);

■

problems or opportunities which occur during the course of the project;

■

modifications or enhancements identified by the project team (beware of these as some may be based less on business need and more on ‘gold plating’!);

■

faults detected by the project team or users (these must be addressed).

‘Scope creep’ is a phenomenon in which a project overruns its agreed timescale and budget because of many extra (often minor) ‘requirements’ being added in an uncontrolled manner. For this reason it is often more effective to bundle a number of small changes together and assess them as a whole, choosing to implement only those which will further the business objectives of the project. Always consider the option of delaying the addition of a major change until after the project is completed, introducing it in a second-phase project. Remember that the primary aim of a project is to fulfil a stated business need. As long as this need is satisfied, fine tuning, enhancing or embellishing the outputs for its own sake, is a potential waste of resources and time. Inevitably, a time will come when an issue will arise on a project which cannot be resolved while the project is still kept viable. Either a time window will be missed or costs will be so high that even a marginal cost analysis leads to the conclusion that it is not worth continuing. In these cases, the impact assessment will result in a recommendation for you to terminate the project. Look out for these, as all too often, the project team will be the last people to ‘admit defeat’ and flag up such an option. You, as Project Sponsor, are accountable for ensuring that the business objective is met, and that may mean cutting your losses by terminating the project and then finding an alternative means. Termination should be treated as a success, as there is little point in continuing with a project which is fundamentally flawed and not viable in business terms.

138


The change management process Because of the potential for changes to reduce projects to chaos, insist that your Project Manager agrees with you a formal approach to assessing and authorizing change right from the start (see Fig. 10.6). Such a process is as follows: ■

The Project Manager notes the proposed change in a change log.

■

The impact of the change on the project and any interdependent projects is assessed by the appropriate people.

■

If it is within the Project Manager’s authority, he or she rejects or accepts the change proposal.

■

If it is outside the Project Manager’s authority, he or she refers the decision (with a recommendation) to you.

Possible decisions are that the change proposal is: ■

accepted for immediate implementation;

■

accepted, subject to certain conditions being met;

■

accepted, but implementation is deferred to a later stage;

■

rejected.

Once the decision has been made, the Project Manager should: ■

obtain further financial authorization (if needed);

■

record the outcome in the change log.

If the change was accepted: ■

implement the change;

■

update the project documentation;

■

inform all interested parties about the change;

■

inform the originator of the outcome and, if the change is rejected, give the reason for the decision.

Accountabilities for change decisions All proposed changes need to be reviewed and their impact assessed before they are implemented or rejected. A project may have several levels for the review and authorization of changes, depending on how serious or far-reaching the change will be. Table 10.1 suggests such levels.

139


Fig. 10.6

The change management process

Modifications

Faults

Environment

Record potential change in change log

Review change need and assess impact Rework

Yes, but…

Is change accepted?

No

Yes Record in change log Update project documentation Implement change Inform interested parties

Record decision in change log Inform interested parties

Notice the first two levels of authority lie within the project itself as the impacts do not affect other projects. Once other projects are affected, it is necessary to have the change reviewed and authorized, balancing the conflicting needs of different projects and project sponsors. The impact levels should be defined and agreed when the project is authorized. This should be documented in the initial or full Business Case.

140


Table 10.1 Project change approval levels Impact of change No impact on overall schedule, cost or benefits Allocation of scope reserve

Approval required by Project Manager (record in change log)

Minor impact – change affecting schedule or costs which can be accommodated without affecting other projects and are within the authority (tolerance) delegated to the Project Sponsor, including allocation of contingency.

Project Sponsor (use change request form and record in change log)

Major impact – change affecting scope, objectives, benefits, schedule or costs which cannot be accommodated within the authority (tolerance) delegated to the Project Sponsor or which affect other projects

Project Review Group (use change request form and record in change log) In some cases a Business Programme Board may have delegated authority which would normally be at Project Review Group level

SUMMARY ■

Risk management starts with you, before the project even begins. It is probably the most influential of all project controls with respect to impact on project success.

■

Identify risks and decide on management action. Work to reduce the impact of high risks or to sidestep them. Allow appropriate contingencies for time and cost or bring risky activities forward and pilot any new capabilities early. Look at the risk log regularly.

■

Ensure all issues are captured as they arise and that they are circulated widely in pursuit of a solution. Never ‘sit on a problem’; it only worsens with time, moving from important to urgent. Review the issues log frequently to gain a view on the status of a project.

■

Use the full experience and skills of the team and other experts to resolve the tricky issues.

■

Change is inevitable, but progress isn’t. Ensure that you approve only beneficial changes, avoiding the temptation to ‘just add one more feature’.

■

Ensure that the Project Manager has a simple, clear process for change. Review the change log regularly and look out for scope creep.

141

Appendices

■

A

Glossary

■

B

Further reading

■

C

Roles and accountabilities

■

D

Health check

145 153 155

159

143

Appendix A

Glossary Accountability

What you can count on a person doing. That person and only that person can be called to account if something he or she has accountability for is not done.

Activity

Individual components of work that must be undertaken to complete the stages of the project. Each activity should be defined in terms of its start and end dates and the name of the person accountable for its completion.

Authorization

The decision which triggers the allocation of funding and resources needed to carry on the project.

Bar chart

Graphical representation of activities within a project over time. Each activity’s duration is shown as a bar, the ends of which correspond to the start and end dates. A bar chart is also known as a Gantt chart.

Baseline

The original project plan used to track progress against during a project. The baseline plan includes start and finish dates of activities and budget costs. The baseline cost is often called a budget or cost plan.

Benefits

Quantified increases in revenue, decreases in costs, reductions in working capital and/or increase in performance which occur directly as a result of a project.

Business Case

A document providing the justification for undertaking (or for continuing) a project, defining the financial and other benefits which the project is expected to deliver together with the schedule and other constraints within which the project is to operate.

Capabilities

Building blocks of systems, process and competence which are combined with other capabilities to provide an operational capability.

Change management

The formal process through which changes to the project plan are introduced and approved. 145

Appendix A

Changes are recorded on a change log. (Do not confuse with the management of change.) Closure

Formal ‘end point’ of a project either because it is completed or because it has been terminated early. Closure is formally documented in a closure report.

Contingency plan

Plan of action to minimize or negate the adverse effects of a risk should it occur.

Cost Plan

Document detailing items of cost associated with a project, in categories (work packages) relating to the schedule plan. See also budget and baseline.

Critical chain

The critical chain of a single project is the sequence of dependent events that prevents the project from being completed in a shorter interval, given finite resources.

Critical path

The path through a series of activities, taking into account dependencies, in which late completion of activities will have an impact on the project end date, or delay a key milestone.

Deliverable

Output produced by the project, for example a report, system or product. Each key deliverable should be defined in the project definition section of the initial or full Business Case document and represented by a milestone on the project plan.

Dependency

A constraint on the sequence and timing of activities in a project. Activities may be dependent on other activities within the same project (internal dependency) or on activities/deliverables from other projects (interdependency).

Detailed plan

Developed throughout the project, breaking down the forthcoming stage into manageable work packages and activities.

Detailed Investigation Stage

The second stage within the staged project framework when a detailed study is undertaken to evaluate a number of possible project options and to recommend a particular course of action.

Duration

The amount of time required to complete an activity. It is calculated as the finish date less the start date.

146

Appendix A

Escalation

To increase the awareness and ownership of a problem or issue to a level in the company where the required resources, expertise and/or authority can be applied in order to resolve that issue.

Gate

The check point, preceding each stage, at which all new information converges.

Idea

A possibility for a new or enhanced capability, system, service or product. This is written up as a proposal.

Impact assessment

A study undertaken to determine the effect of an issue on the project. An impact assessment is required as part of change management.

Interdependency

If Project B requires a deliverable from Project A in order to achieve its objective, project B is dependent on project A. There is dependency when a deliverable is passed from one project to another.

Issue

A circumstance (event, lack of knowledge, etc.) that has occurred and which will jeopardize the success of a project. Issues are recorded on an issues log. Issues can sometimes be resolved within the project as defined, or a change may be required to accommodate them.

Key control deliverables

Documents on which decisions are made that relate to gates in the project life cycle. They comprise: Proposal, Initial Business Case, Business Case, Ready for Service Review Report, Closure Report, Post-Implementation Review Report (see Fig. 3.1).

Life cycle

A sequence of defined stages over the full duration of a project, i.e. initial investigation, detailed investigation, develop and test, trial, release.

Management of change

A name often used to describe the process of transforming an organization from one state to another. Not to be confused with change management, which is a technique used on projects to ensure that alterations to the project time, scope, benefits and cost are introduced in a regularized way.

147

Appendix A

Milestone

A major event (often representing the start of a stage) which is used to monitor progress at a summary level. Milestones are activities of zero duration.

Network chart

A diagram which shows dependencies between project activities. Activities are represented as boxes or nodes and the activity relationship is shown by arrows connecting the nodes. Often called a PERT chart.

Opportunity

The opposite of a risk. An opportunity is a possibility of enhancing the project benefits. Opportunities are recorded on an opportunity log.

Pilot

A pilot is the ultimate form of testing a new development and its implementation plan prior to committing to the full release. It is undertaken using a sample of potential customers and users. This would normally take place in the Trial Stage, although it may, in some cases, be treated as a limited release.

Portfolio

A grouping or bundle of projects which are collected together for management convenience: for example, the collection of projects sponsored by an individual is his or her sponsorship portfolio.

Post-Implementation

A review, three to six months after the end of the

Review (PIR)

project, to assess whether the expected benefits and performance measures are being achieved. This checks the effectiveness of a project as opposed to its efficiency, which is reviewed as part of project closure.

Programme

A tightly coupled and tightly aligned grouping of projects

Progress report

Regular report from the Project Manager to the Project

Sponsor

and

other

stakeholders

summarizing the progress of a project including key events, milestones not achieved and issues. Project

A project, in a business environment, is: ■

a finite piece of work (i.e. it has a beginning and an end);

148

Appendix A

■

undertaken within defined cost and time constraints;

■

Project Board

directed at achieving a stated business benefit.

Body established to monitor the project and to assist the Project Sponsor in directing the project. Sometimes called a Steering Group.

Project buffer

The project buffer protects the project end date from variability in the duration of the activities in the critical chain. For a single project the size of the buffer depends on the number and duration of the critical chain activities and on the degree of risk associated with each.

Project definition

A section within the initial and full Business Case which defines a project, i.e. what will be done, how it will be delivered and what business need the project supports.

Project manager

Person accountable to the Project Sponsor for managing a project on a day-to-day basis, from start to finish, to ensure successful implementation within agreed cost, schedule and quality targets.

Project plan

The supporting detail to the project definition which details the schedule, resource and costs for the project. It can be in outline or detail.

Project sponsor

The person who sees a commercial possibility in an idea, is the primary risk-taker and the one who agrees to take ownership of the proposal. Once a project is authorized, the Project Sponsor is accountable for the realization of the benefits to the business.

Proposal

A short document prepared, by the originator, for the Initial Investigation Gate review, which outlines the proposed project, its fit with current strategy and, if known, the impact on the organization, broad estimates of benefits and cost, and expected time to completion.

Ready for Service (RFS)

The milestone prior to the Release Stage, by when all prerequisite project work, testing and trials have been completed and full operational support is in place.

149

Appendix A

Release

Generic term used to denote when an output from a project is put into service, for example when a product can be used by a customer under standard terms and conditions (i.e. launched), a system can start to be used, a new process is operational. It must not be confused with Ready for Service, which is the point when all capabilities are ready to use but have not yet been put to use.

Release Stage

The final stage in the staged project framework, during which the final output is launched and put into service.

Responsibility

What a person is or feels responsible for. It assumes that he or she has a commitment, beyond his or her own accountabilities, to act responsibly to ensure that the project objectives are met. See also accountability.

Review

A process used as a check point at which a deliverable or the project in full can be evaluated against its business objectives. Gates are special review points. Reviewers are contributors to a decision and do not actually make the decisions. Decision makers may draw on the collective ‘wisdom’ of the reviewers, but ultimately the choice is theirs. The role of the reviewers is to ensure that decision makers make informed choices.

Risk

Potential occurrences or threats that would jeopardize the success of a project. Risks are continually assessed and recorded on a risk log.

Single-point accountability

The concept that any activity or work package at any level in the work breakdown structure has only one named person accountable for it.

Sponsor

See project sponsor

Stage

A natural high-level breakpoint in the project life cycle (for example initial investigation, detailed investigation, develop and test, trial and release).

Stakeholder

Any person, or group, who has an interest in the project. Typically some support it, some are neutral and others are antagonists.

150

Appendix A

Termination

The premature closure of a project due to an issue which cannot be addressed or because the risks have become too high.

Theory of constraints

The theory expounded by Eli Goldratt which led to the development of critical chain schedule management.

Trial Stage

A trial of a capability in the same environment as the customer or user will use it. This is done as part of the trial. Often called a beta trial under special trial agreements or a pilot.

White space

Unassigned resources which are available to work on future projects. White space is required at short notice for initial investigations and at medium notice to resource future projects after the Detailed Investigation Gate. Without white space, companies are unable to change themselves without taking resources

from

previously

authorized

and

committed work. Work Breakdown Structure

A structured hierarchy of work packages.

(WBS) Work package

Generic term used to describe a grouping of activities, stages, etc. each of which has a defined scope, timescale, cost and a single person accountable for it. A work package is related to a deliverable or group of deliverables.

151

Appendix B

Further reading THE PROJECT WORKOUT The Project Workout describes not only how individual projects should be directed and managed but also how an organization can manage any number of projects. Written by the same author as this briefing and sharing the same key messages and principles, The Project Workout provides the ideal companion. For use either by the Project Manager or senior executive charged with making sense of the wide range of projects organizations have to undertake or for those who are charged with the task of introducing business-led project management into their organization. The Project Workout is fast becoming the text of choice for many companies, consultants and business schools. It is available in French, Russian, Indian subcontinent and Chinese editions. Further details are on the author’s web site: projectworkout.com

153

Appendix C

Roles and accountabilities THE PROJECT SPONSOR’S ACCOUNTABILITIES The Project Sponsor is the business advocate and is accountable to [insert name here] for directing a project to ensure that the conditions of satisfaction for the project are achieved (indicative of realization of the benefits) and the project is viable at all times. He or she is the owner of the Business Case and the primary risk-taker. This is an active role and includes ensuring that the project always makes sound business sense, involving all parts of the organization which benefit (using a Project Board if appropriate), engaging stakeholders, approving key deliverables, giving direction as and when required and making decisions or recommendations at key points in the project’s life. There is only one sponsor for each project, who may appoint a Champion to act on his or her behalf on some of the day-to-day matters noted below. The Sponsor will:

Business management ■

ensure that the project remains a viable business proposition, owning the Business Case and validating it against external events and progress;

■

ensure that the solution adequately represents the needs of customers and users and meets the business objectives;

■

keep the Project Manager briefed on external events which have an impact on the project;

■

chair the Project Board (if one is required);

■

ensure that the corporate management is kept apprised of progress;

■

ensure the appointment of the Project Manager and facilitate the appointment and retention of core team members.

Evaluation and approval ■

authorize project decisions, if within the remit laid down by corporate management; if outside the remit, make recommendations to the appropriate decision-making authority;

■

ensure that project reviews are planned and take place at predefined milestones;

■

ensure that the post-implementation review is carried out to show that business objectives have been (or are likely to be) achieved.

155

Appendix C

Project control ■

monitor progress against the plan (schedule, cost, resource);

■

monitor business risks and keep the Project Manager appraised of any relevant aspects;

■

facilitate the resolution of project issues that are outside the control of the Project Manager;

■

provide ad hoc advice and direction to the Project Manager.

Delivery ■

ensure that the delivered solution matches the needs of the business;

■

sign off key project deliverables, including RFS and project closure.

Purchasing ■

monitor supplier and contract payments.

Quality ■

ensure that quality requirements are being met and reviews are being conducted by the appropriate people.

THE PROJECT BOARD’S ACCOUNTABILITIES The Project Board is an optional body which is usually required for projects which span a number of functional boundaries and/or where the benefits are directed to more than one market segment or business unit. The Project Board is appointed by and usually chaired by the Project Sponsor. It is responsible for supporting the Project Sponsor in ensuring that the benefits from the project are realized. It has accountability and authority for the project within the remit set by corporate management. The role of the Project Board is: ■

to support the role of the Project Sponsor;

■

to monitor the project progress and ensure that the interests of the whole company are best served;

■

to provide a forum for taking strategic, cross-functional decisions, removing obstacles, resolving issues and reviewing and approving changes.

156

Appendix C

THE PROJECT MANAGER’S ACCOUNTABILITIES The Project Manager is accountable to the Project Sponsor and has single-point accountability for defining and creating a business solution which will ensure realization of the required benefits and meet the business objectives stated in the Business Case. He or she will run the project on a day-to-day basis in accordance with the Project Framework, using a team of project and team managers drawn from across all necessary functions as defined in the Business Case. The Project Manager may set up a Project Support Office to help with project administration. The Project Manager will:

Business management ■

define the approach to the project and its segmentation into work packages;

■

define the project organization structure;

■

direct and motivate the project team;

■

forecast likely business benefits;

■

liaise with the Project Sponsor to ensure the overall integrity of the project.

Evaluation and approval ■

manage the preparation and approval for all key control documents (for example the Business Case, RFS Review, etc.);

■

manage reviews as defined in the plan or as requested by the Project Sponsor.

Project control ■

prepare the project definition and detailed plan;

■

monitor and manage the progress against the plan;

■

initiate work packages to be undertaken by team members;

■

initiate corrective action where necessary;

■

monitor and manage risks and opportunities;

■

manage the resolution and/or escalation of project issues;

■

manage the scope of the project and control changes;

■

keep stakeholders informed through regular progress reporting;

■

manage interdependencies between the projects within and outside the project;

■

maintain project-level controls covering plans, risks, issues, change and reporting;

■

manage the timely closure of the project.

157

Appendix C

Delivery ■

define the accountabilities, work scope and targets for each team member;

■

deliver the project deliverables on time and to budget.

Purchasing ■

ensure that any supply agreements are set up, managed and closed and goods or services supplied as specified.

Quality ■

agree technical and quality strategy with appropriate managers in the company;

■

set up and maintain project document, quality and configuration management;

■

ensure that the deliverables are of the required defined quality.

THE PROJECT SUPPORT OFFICE The need for project support is driven by the needs of the individual project. Specific accountabilities may include the following administrative tasks: ■

administering change control;

■

setting up and maintaining project files;

■

establishing document control;

■

collecting of actuals data and forecasts to update plans;

■

administering quality reviews;

■

setting up and maintaining configuration management;

■

assisting with compiling reports;

■

managing contract resources;

■

managing communications.

In addition, it may be a source of advice for:

158

■

specialist knowledge (for example risk, value management);

■

specialist tools and techniques (for example planning tools, risk analysis);

■

standards.

Appendix D

Health check Use this tool to verify that the key factors for the project are in place. It is good practice to undertake this at every gate review and whenever you undertake a formal project review, during any stage of the project.

159

Tasks are well managed

Roles understood

Appropriate expertise available within team

Project is understood: capability to implement

Method of individual performance evaluation understood

Individual accountabilities written, understood and agreed

Adequate training available and timetabled within scope and schedule

Slack time and transferrable/flexible resource

Contingency plans

The project fully costed and budgeted

Financial and commercial value estimates made

Clear benefit and Return On Investment

Measures of success identified: measurement processes planned

Adequate funding available

Expertise

Technology works and is fully supported

Personnel needs understood and specified

Justifiable case

Technology available

Detailed project budget

Resources

Notes

Sufficient manpower

2

Detailed plan for project completion

Project Plan

Top-level support

Clear specification

Expertise

Justifiable case

Ownership

Resources

Project Plan

Individual risks (scores from –2 to +2)

Risk/health check score: (Total)

1

Project health-check analysis

Project number/name: Project Manager:

Fig. AD.1

Aims and objectives presented to stakeholders

Adequate documentation of project and operational needs

I am enthusiastic about the chances of success of this project

Project goals meet corporate goals and standards

Objectives clear to all stakeholders and team

Clear specification

Stakeholders understand in-scope requirements

Project limitations understood

Conditions of satisfaction agreed

Stakeholder ownership of actions

Stakeholders have opportunity for early input

Ownership

Total health check risk –14 to –7 Impossible –6 to 0 High risk 1 to 7 Medium risk 8 to 14 Low risk

Strongly disagree or don’t know Disagree Neutral Agree Strongly agree

Scoring rules –4 –2 0 2 4

The Project Sponsor is fully committed to the project’s success

I am confident that I can call upon management help where necessary

Terms of reference, authority and responsibility levels agreed

Management responsive to flexible resource requirements

Project Sponsor shares accountability with project team

Top-level support

1 Compete the questions in each of the seven ‘boxes’, using the scoring rules on the left. Note: ‘Don’t know’ = –4! 2 Divide each score by 10 and transfer the scores to the Risk/health check score on the top left. 3 Add the individual scores, placing the total in the ‘Total’ box, 1. 4 Use the Total health check risk table on the left to determine the level of risk for your project and write this in box 2. 5 Use the ‘Notes’ box to note the weak parts (those less than zero).

INSTRUCTIONS

Role Of The Executive Project Sponsor

International Construction and the Role of Project Management

Executive

Executive

Executive

Executive

Executive

Project Management Professional (PMP) Role Delineation Study

Executive

Executive

Executive

The Nature of Executive Work

The Role of Variables

The Politics of Executive Privilege

Role of Honour (Role of Honor)

Role of Honour (Role of Honor)

Jean Sandwich, The Sponsor, and I

The Sponsor: Notes on a Modern Potentate

Deadly Connections: States that Sponsor Terrorism

The Role of the Non-Executive Director in the Small to Medium Sized Business

The Role of the Weird

The Sinkiang Executive

The Executive Assistant

The Effective Executive

The Sinkiang Executive

The Angst-Ridden Executive

The Sinkiang Executive

The Sinkiang Executive

The Sinkiang Executive

Executive Positions

Executive Orders

Role Of The Executive Project Sponsor

International Construction and the Role of Project Management

Executive

Executive

Executive

Executive

Executive

Project Management Professional (PMP) Role Delineation Study

Executive

Executive

Executive

The Nature of Executive Work

The Role of Variables

The Politics of Executive Privilege

Role of Honour (Role of Honor)

Role of Honour (Role of Honor)

Jean Sandwich, The Sponsor, and I

The Sponsor: Notes on a Modern Potentate

Deadly Connections: States that Sponsor Terrorism

The Role of the Non-Executive Director in the Small to Medium Sized Business

The Role of the Weird

The Sinkiang Executive

The Executive Assistant

The Effective Executive

The Sinkiang Executive

The Angst-Ridden Executive

The Sinkiang Executive

The Sinkiang Executive

The Sinkiang Executive

Executive Positions

Executive Orders

Recommend Documents