Making Sense of Project Realities

Citation preview

Making Sense of Project Realities

This page intentionally left blank

Making Sense of Project Realities Theory, Practice and the Pursuit of Performance

CHARLES SMITH

© Charles Smith 2007 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 the prior permission of the publisher. Published by Gower Publishing Limited Gower House Croft Road Aldershot Hampshire GU11 3HR England Ashgate Publishing Company Suite 420 101 Cherry Street Burlington, VT 05401-4405 USA Charles Smith has asserted his moral right under the Copyright, Designs and Patents Act, 1988, to be identified as the author of this work. British Library Cataloguing in Publication Data Smith, Charles Making sense of project realities : theory, practice and the pursuit of performance 1. Project management I. Title 658.4’04 ISBN-13: 9780566087295 Library of Congress Cataloging-in-Publication Data

Smith, Charles, 1947– Making sense of project realities : theory, practice and the pursuit of performance / by Charles Smith. p. cm. Includes bibliographical references and index. ISBN 978-0-566-08729-5 1. Project management. I. Title. HD69.P75S57 2007 658.4'04--dc22 2006034252

Printed and bound in Great Britain by TJ International Ltd, Padstow, Cornwall.

Contents List of Figures List of Tables Acknowledgements

vii ix xi

Chapter 1

Projects: the opportunities and shortfalls

1

Chapter 2

Making sense of projects

7

Chapter 3

Projects and complexity

15

Chapter 4

Tribalism and rituals

25

Chapter 5

The tyranny of projects

37

Chapter 6

Managing multiple projects

45

Chapter 7

Fraudulent projects

57

Chapter 8

The language of projects

67

Chapter 9

Creating project sense

75

Chapter 10

Personal engagement

93

Chapter 11

Delivering value

103

Chapter 12

Business transformation

113

Chapter 13

Dealing with uncertainty

131

Chapter 14

Quests for value and accountability

145

Chapter 15

ProjectCra


153

Chapter 16

The business of project management

165

Vocabulary Bibliographic notes Index

179 181 187

This page intentionally left blank

List of Figures Figure 7.1

Social interactions – a fraudulent research project

63

Figure 11.1

Spider diagram – delivering diverse interests

104

Figure 11.2

Spider diagram – delivering a school project

109

Figure 12.1

Example benefits map – reducing town centre crime

122

Figure 12.2

Complete benefits map – saving lives

123

Figure 12.3

Value-chain argument – saving lives

124

Figure 12.4

Component of management plan – saving lives

126

Figure 12.5

Benefits matrix – saving lives

127

Figure 14.1

The twin quests of projects

146

Figure 16.1

The business of project management

169

This page intentionally left blank

List of Tables Table 4.1

The tribes of DivCo

29

Table 4.2

Foremost tribes of the project world

33

Table 8.1

Vectors of project diversity

72

Table 9.1

Peripety table – a pensions project

87

Table 10.1

Diverse project identities

94

Table 12.1

Diverse business transformations

118

Table 12.2

Transactional change and journey of change

119

Table 13.1

Project risk register

133

Table 15.1

ProjectCra
for all

154

Table 15.2

ProjectCra
for project directors

156

Table 15.3

ProjectCra
for strategists

157

Table 15.4

ProjectCra
for project shapers – general

158

Table 15.5

ProjectCra
for project shapers – transformation agents

159

Table 15.6

ProjectCra
for project deliverers

160

Table 15.7

ProjectCra
for the priesthood

161

Table 15.8

ProjectCra
for opponents of projects

161

This page intentionally left blank

Acknowledgements This book could not possibly have been wrien without a large body of work carried out by others, and without the contribution and support of many people. A prime influence has been the work of the EPSRC-funded research network Rethinking Project Management. Many of the ideas I present emerged from the discussions of this network, and I am therefore heavily indebted to the academics and practitioners who participated. Foremost among these is Mark Winter, the Principal Investigator for the network. Mark engaged me to work as network coordinator, and he established the network mode of working that has been so fruitful. Together we worked to develop the discussions of the network, producing a series of ‘sense-making papers’ which subsequently provided the storehouse of ideas which then supplied this book (and other publications). Two other groups must share some responsibility for the events that led to this book. First, the Making Projects Critical series of workshops, organised by Damian Hodgson and Svetlana Cicmil, have been an important forum for many of the arguments that have influenced this book. In fact it was Damian and Svetlana who originally encouraged me, a mere project manager, to present a paper at their workshop, and to air, in an academic environment, (and subsequently publish) my interpretations of my own project experiences. Second, Helen Jones’s York-based Northern Personal Construct Psychology Research Group have been a source of encouragement throughout. This friendly and flexible group have, at one extreme, challenged me on fundamental issues concerning the nature of life, work and projects and, at the other extreme, helped me deal with the personal demands that emanate from finding out what it means to be an author. Within the book I have used many project stories and examples, gleaned from the network and elsewhere. While the texts of all stories in this book have been wrien by me, they are derived entirely from real experiences, which I have amended and relocated (and sometimes even regendered) to support my arguments. Those whose project experiences have found their mangled way

xii

MAKING SENSE OF PROJECT REALITIES

into my text deserve special thanks and unreserved apologies. They include: Kevin Baker, Mark Baptist, Paul Collard, Jane Grant, David Hancock, Norman Haste, Chris Ivory, Alan Murray, Colin Saunders, Peter Southcombe, Pauline Stewart-Long and Tony Teague. There are others who have preferred to remain anonymous, and yet others who must remain anonymous for reasons that will become apparent. These people, named and unnamed, volunteers and conscripts, are the suppliers of my basic raw material, and without them there would be no book. To these I must add those other project people with whom I have worked and discussed project issues over the years. Among many I must give prominence to Brian Burne and John Mills for their perpetual willingness to engage in argument about projects. Among those supporting me at Gower, I must particularly acknowledge Jonathan Norman, for his sympathetic encouragement throughout, and also for his ruthless wielding of his red pen over my initial dra
s. Special thanks are also due to Neil Morrison for his help with the diagrams. Finally I must thank my wife Helen. The writing of a book places enormous demands on those who, for beer or for worse, must live with the writer. Having overcome her initial astonishment that I should be engaged in such a project she has given her full support, and has been supremely tolerant of the long periods of total silence and the disruption to normal life that have ensued. Charles Smith

CHAPTER 1

Projects: The Opportunities and Shortfalls THE DEVELOPMENT OF PROJECT WORKING This book is for people who work in the world of projects. Its aim is to provide insights and understandings that will support their ability to act effectively in that world. There are many people, in a wide variety of roles, whose lives are touched for beer or for worse by projects. There are some for whom the performance of projects is central to their working lives: strategists who hope to see their policies and plans turn into reality through the medium of projects, investors who, personally or through their organizations, put up the money that funds projects, and project managers and an array of others who have responsibilities for seeing that projects are delivered. There are others whose roles are supportive: providing training and development, running the professional bodies, researching new methods and practices, and advising organizations and individuals. The ideas put forward will, I hope, be of value to them all. Over the last few decades (since the 1980s) the growth of the project mode of working has been phenomenal. Some fields, such as construction and engineering, are traditional territory, and it can be argued that for this type of work the concept of the project has been in use for several centuries, or even millennia. However, even in these domains there has been a step change in recent years in the recognition given to the discipline and methods of project management, which have now taken up a central position. There are many of us who can remember a time when the engineering disciplines themselves managed major construction projects. People who were explicitly called ‘project manager’, if they existed at all, had a supporting role preparing plans of instruction and perhaps looking a
er contractual relationships with clients. This culture has now changed radically. The project management discipline – and within it the individualistic heroic project manager – now takes overall responsibility, as a maer of routine, for the delivery of such projects. The field of information technology (IT) systems development has broad similarities with engineering in its concern with the delivery of technology

2

MAKING SENSE OF PROJECT REALITIES

– the transformation of technical concepts into socially useful products. The rapid expansion of the project management discipline within this field has therefore been unsurprising. In practice, however, IT development is o
en intrinsically tied up with organizational change, and so it makes lile sense to apply tight project controls to technical developments alone, in isolation from organizational developments. The logical response to this problem has been a further expansion in the scope of the project management discipline to apply it to the organizational and human aspects associated with the introduction of new technology, and it has now become normal management practice to plan and implement organization change and business transformation through the medium of projects. Such has been its success that there are now many large organizations, including major corporations and government departments, for which project management and its companion programme management are the only means through which policy is implemented. There are numerous organizations in which it is claimed that all work is a project, or in which (perhaps more accurately stated) the only means by which funding is formally authorized is through the processes of project approval. If it isn’t a project, then it has no authority or budget. In this idealized world, the strategists – company executives, government ministers or senior civil servants – formulate policies and strategies and then pass these to the project management fraternity, with their legions of project managers, who are to ensure delivery. Under this simple division of labour tasks as diverse as the provision of health services, the reorganization of emergency services, the delivery of aid to developing countries and the provision of accommodation for the homeless have been brought into the project domain, their territory conquered and assimilated into the ever-growing project management empire.

PROJECT MANAGEMENT KNOWLEDGE This remarkable expansion has been accompanied by the emergence of strong and influential institutions. In the UK and the USA, two major organizations – the Association for Project Management and the Project Management Institute respectively – have emerged, claiming to act as custodians of project management as a profession, providing an ideology, an intellectual framework and a home for project managers. These enterprising organizations formulate and codify knowledge and practices, set out the criteria and qualifications for different grades of membership, and act as gatekeepers, controlling entry and exit and awarding certificates to those who meet their standards. Their

P R O J E C T S : T H E O P P O RT U N I T I E S A N D S H O RT FA L L S

3

membership is large, numbered in hundreds of thousands, and increasing rapidly, reflecting not only the expanding scope of the discipline but also the rising status of those who practise it. Project managers see themselves as an elite group; they are, a
er all, the people who are responsible for ‘geing things done’. ‘Project manager’ has become a role to which large numbers of people aspire – a high-value career path, a means to a first-rate reputation and a vital step up the ladder towards the top of the tree. Project management qualifications are valued both in their own right, or as an essential addition to a more traditional profession in engineering, IT, or social services, or virtually any other field. The independent associations are not alone in the quest to create a new profession. Major corporations and government departments are also actively seing and promoting their own standard practices, appointing Directors of Project Management and encouraging their staff to learn the methodologies and gain qualifications. Through these means they drive forward the growth of project forms of working in their own organizations. The discipline has thus established itself at the centre of organizational life, in many respects emulating the major science-based professions such as engineering or medicine. The object of its special expertise – the project – has been identified, our knowledge of this object and how it must be handled has been extensively systematized and wrien into codes of standard practice, and individuals who are expert in the application of this knowledge are granted entry to the privileged profession (or refused it) on the basis of their level of understanding of this knowledge. The overall case that is made for project management is very simple and very powerful. The project mode of organizing has been shown, both historically and currently, to be the best way to deliver the aims and strategies of organizations. The basic practices and skills of project management have been defined and applied across government and business, and within many technical and organizational disciplines. We have developed, and continue to develop, a group of people who have passed through the gateway into the professional enclosure, expert in the discipline’s practices, who apply their skills to the benefit of business success, and we have established independent associations, which act as custodians, holding the profession’s knowledge, promoting its benefits, and training and regulating its practitioners. And yet all is not well. This simple picture of success is open to serious challenge.

4

MAKING SENSE OF PROJECT REALITIES

THE CHARGES AGAINST PROJECTS The charges – the critical flaws – are as follows.

PERFORMANCE DEFICIT First, it can be argued that the growth of engineering and medicine in the eighteenth and nineteenth centuries supported major advances in society: in the case of engineering, the building of national infrastructures and machinery that had been inconceivable or impossible in the days before the profession produced them, or, in the case of medicine, the achievement of dramatic improvements in public health. Can the same be said for the emergence of the project management profession? Are major projects now completed to time and cost? Are government strategies more successfully implemented? Are new technologies sloing smoothly into reorganized businesses and government departments? Unfortunately not! It is difficult to say what we are doing beer as a result of this surge in project management. The world appears to be continuing much as before. There are successes, but also widespread failures. In the 1820s George Stephenson completed the Manchester to Liverpool railway late and 45 per cent overspent against budget. Today, lile has changed. Major public sector projects regularly overspend, o
en by 30 per cent or more (and sometimes by a factor of more than ten), or do not deliver their promised benefits. Major investments are initiated based on untried technology which later turns out not to be sound. New IT systems are developed at great expense, but then rejected by their intended users as unusable. It seems that projects, as human endeavours, are inherently unpredictable and flawed both in their execution and in their outcome, and modern project management has not, as yet, done much to change this. The response to this charge from the mainstream establishment – project management experts, consultants, project directors and others – has been to demand more of the same. If management controls are ineffective, then we need to strengthen our resolve and apply more controls. If the uncertainties in our plans are overwhelming, then they must be listed on a schedule and managed. If the project managers are failing, they must be removed from their posts and replaced by new blood – people who are properly trained, and who can be beer trusted to follow the approved rituals.

P R O J E C T S : T H E O P P O RT U N I T I E S A N D S H O RT FA L L S

5

This response has proved to be largely futile. It should itself be recognized as part of the problematic culture of project management. If we hold to a philosophy of strength, order and control, then any shortfall in achievement will be interpreted as a failing in that strength. Perhaps it is time to look for a way out of this rut, and ask whether there are alternatives. This first charge, the performance deficit, is well recognized. It is raised regularly in the media, in parliament, and between treasury officials and investors. These people, in joining in the hue and cry, add their voices to the demand for stronger project management.

ALIENATION The second charge, however, has less visibility. It concerns alienation. For every commied believer in the value of projects, there are others who are non-believers. By non-believers, I do not mean the outright rebels – those who oppose or resist, on principle, any communal or business activity or initiative. I am thinking of the disaffected: those who ask, quite regularly, ‘Why should this be a project?’ and don’t get an answer that satisfies them, those who believe they are doing a useful and productive job and find that the imposition on to their work of the concept of a ‘project’, with all its associated aributes, is irrelevant, distracting or even disruptive; and those consultants in wider fields of management who ask themselves whether an organization would perform beer if it adopted the project model for strategic delivery, and find the answer is a resounding ‘no’. Their complaint is that projects are not the only way to turn ideas and strategies into reality, and are o
en not the best approach, so why do the project profession and its allies in government and business seek to impose this model on everything? The consequence is that in all organizations that purport to be project-based there remains a large community of people who are alienated from this policy – critically detached. To them project management is something imposed from outside, merely one, perhaps, of the many management initiatives that have been inflicted on them with numbing regularity. Rather than take up a partisan position, arguing for or against project management, we should explore this question more thoroughly, in less blackand-white terms, and ask what the appropriate territorial frontiers of the project kingdom might be. Are there perhaps alternative and more flexible formulations that might be more pragmatically useful to different people in diverse circumstances?

6

MAKING SENSE OF PROJECT REALITIES

THEORY–PRACTICE DISCONNECTION The third charge to be laid against mainstream thinking in project management is that of theory–practice disconnection. At an event organized by a project management organization the presenters spoke enthusiastically about the training they could provide, discussing the tools and techniques they covered and the qualification levels that participants in their training could achieve. During the interval, a project manager of the older generation commented on the high quality of the presentations. However, he then looked into the distance and added: ‘but of course none of this bears any relation to anything I ever did’. This is a crucial allegation. It appears that the tools and techniques – the things they teach on project management courses – are only rather loosely related to the things that experienced expert practitioners actually do. This dislocation is not just a challenge to those who practise the cra
s of project management. It is a challenge to those who would write books on the subject. There is a vital need to identify and make visible the capabilities that people actually employ on projects.

A WAY FORWARD This brief overview of the state of ‘project-world’ is, of course, very much an aerial view – a snapshot from a helicopter hovering at a safe altitude above the real world. On this otherwise pleasant landscape, with its aura of optimism and promise, our criticisms – performance deficit, alienation and theory–practice disconnection – are major disfigurements. It is tempting, from this height, to look for a solution to these problems – a new theory, the final piece of technique we need to banish the flaws from the face of the earth. The history of projects shows us, however, that this is not a realistic hope. My purpose is to help those on the ground who are struggling to find their way forward. These two perspectives, the aerial and the grounded, are both needed. I shall argue throughout that if individuals are to enhance their capabilities and effectiveness, then they must raise their eyes and look beyond the immediate surroundings – the prescribed, procedural, mechanistic trappings of mainstream project practices. To move on it is necessary to enhance our understanding of the wider context in which projects are created and performed. It is the illumination of this complex terrain – foggy, messy and ambiguous, and beset by conflict, intrigue, doubt and ignorance – that is our goal.

CHAPTER TWO

Making Sense of Projects STORIES AND THEORIES Most available guidance about projects and their management can be broadly categorized as emanating either from practitioners or from theoreticians. The practitioners have done the job and wish to pass on the benefits of their experience, but the more general value of this experience – its transferability to different situations – may o
en be hampered by a lack of theoretical backing. The theoreticians have analysed the subject and wish to pass on the expert principles, frameworks and techniques they have devised, but their ideas can become ends in themselves, detached from the realities of everyday project life. The thinking that informs this book is grounded on a combination of both expert views of the field, investigating the issues that lie behind real projects and their management and exploring the ideas and theories that can illuminate them. Our aim is to seek out the sense that can be made of projects, based on understandings of how they are experienced and handled by practitioners in the field. A major recent contribution to this mode of investigation has come from the ‘Rethinking Project Management’ research network. Rethinking Project Management The work of the research network Rethinking Project Management has made important contributions to our understanding of projects. This network, which was based in the UK and operated over a two-year period between 2004 and 2006, brought together leading academics and senior members of the project management profession from the UK and around the world. The aim of the network was to generate new thinking about project management practice. The agenda of the research network was set by its members, covering the major topics and issues that they considered critical to the performance of projects. In typical sessions, presenters from private companies or government departments would give a brief overview of the content of their work – perhaps a project or an organization change programme – and then describe frankly and in detail what they actually did and what really happened. Speakers might spend a few minutes explaining what their company does and how in principle it operates, but then

8

MAKING SENSE OF PROJECT REALITIES

speak at length about their everyday life on projects: who they deal with, the phone calls, the meetings, the politics and the problems. Or they might briefly describe the projects they run, and then treat the meeting to insights into how they manoeuvred to protect these projects from interference from outside parties. This is most definitely not the kind of material you can read in the manuals. The academics and practitioners at these meetings would then interrogate the stories, involving the speakers in the discussions. They may ask fundamental questions: ‘Why was this a project?’. They may ask about alternative perspectives on the story. When the speaker talks heroically about ‘how I put things in order’ they might ask about what was happening beforehand: ‘Who was creating the disorder, and why?’ The aim of these interactions was to expose and explain the events of these projects within the organizational world in which they take place. These explanations could then support the development of generalized concepts and ways of thinking that will enable us to gain a better understanding of projects, and the roles people play in them. Because of the immediacy of the argument, this approach is a superior route to better understanding than the standard academic path of research and report. The debate takes place between people of different views who are discussing the real world and its interpretation, rather than defending their various theoretical positions. Consequently the arguments are grounded on the experiences of people in the field, and expressed in the terms they use to describe and explain those experiences. The events of the network took place in a context of ongoing investigations and conversations concerning the perils and problems of projects. The members of the network brought to it their existing practice, research and educational interests, relating emerging ideas to current discussions in the wider management literature. The interrogation of the practice stories was therefore largely informed by this management and organizational theorizing, testing preferred theories against the practitioner’s stories, and testing the stories against theories.

Many of the themes and ideas presented in this book originate in the thinking emerging from this research network. However, I have extended many of the arguments based on these continuing discussions and on my own experience and thus not everything presented here can be traced back to the network conclusions. Reflecting the fact that the content and ideas have arisen entirely from real stories of project life, I shall make extensive use of stories. A number of these originate from the stories presented to the Rethinking Project Management network, but many others originate from my own project life. The examples I use are most definitely ‘real’ in the sense that either I have experienced every incident presented here myself, or it has been related in my presence, in public

MAKING SENSE OF PROJECTS

9

or in private. However, my approach has been to make changes fairly freely – amending the narrative, merging stories, relocating them – to render them anonymous, to make their relevance more general, and to concentrate the subject maer to bring out the issues that I have chosen to emphasize. To a large extent, therefore, this book presents the ‘sense’ that I believe can be made of projects in general, extracted, ordered, interpreted and shaped from the material of real project stories.

THE CHALLENGE TO THE MAINSTREAM This process of sense-making has led to understandings about the reality of projects as practised that challenge current mainstream thinking. By mainstream thinking I mean those concepts presented in the textbooks, manuals and procedures of standard practices. I include within this mainstream thinking those documents that define a project: its business case, the project brief and the specified requirements. I include the procedures that control and approve a project through its initiation and the different stages of its life cycle. I include the plans that implement the requirements: the definition of intermediate outputs, the work to be done separated into tasks, the estimates and the resource allocation. I also include the management of delivery: the negotiated commitments, the monitoring of expenditure, and practices to manage risk. All these and similar activities are gathered under the term ‘mainstream’. They are characterized by being embodied in the artefacts of projects – the standard documents defined in the standard manuals that implement the standard processes. The mainstream philosophy is extremely simple. If we wish to get from an existing state, A, to a new state, B, then surely our best strategy is to define B and the tasks that will get us there, and then carry out those tasks. The essentials of project management are the acts of planning and of doing: lining up the jobs to be done and then making them happen. It makes no logical sense to make counter-proposals – to suggest that it is beer not to plan or that we should make plans and then not carry them out. I am not suggesting that the methods are, in themselves, in any way wrong. My challenge is rather to the notion that these methods are realistic descriptions of what people actually do. Humans, and groups of humans, rarely travel from A to B without arguing about the state defined by A, without disputing and changing their minds about the location of B and whether B

10

MAKING SENSE OF PROJECT REALITIES

is where they are really going, and without taking in diversions by way of C, D and E on the way. To make our way forward we have to negotiate our route, and not only with those who will accompany us. We must also contend with the plans of those who actually intend to get to Z, or to stay at A. The mainstream methods of project management are a set of mechanistic artefacts – rules, standards, typical documents, control systems – that relate to a way of working that is in fact hypothetical. I will not devote much space in this book to descriptions of the mainstream techniques themselves. They are obvious and simple, and extensively covered in textbooks, manuals and procedures. The questions I will put forward relate not to the methods but to their application. If current mainstream methods do not deal with the things that are important in projects, then when are they of value and when should we ignore them? Can they be used more pragmatically? Does it help to characterize work as ‘projects’, and if so, when? How are projects created, and why, and what is the effect of their creation? Are there beer ways of describing projects that would give us the capability to act more effectively?

INTRODUCING PROJECTCRAFT Although they challenge mainstream thinking, the ideas I am puing forward are not in fact ‘new’. They have emerged from the stories and thinking of experienced practitioners, and so are well known by many, although perhaps o
en only implicitly. We need to seek out such thinking and make it explicit, to bring it forward from being the privileged possession of the few and make it available to provide insights and ideas for the benefit of all practitioners. There is a parallel here with the concept of the ‘Reflective Practitioner’. This is concerned with how people at work reflect on the situations in which they find themselves, understand the relevance of the practices they employ and consider the alternative possibilities for action. I wish to develop here a specifically ‘project’ version of this concept, which will encapsulate the reflective-practitioner capabilities of all manner of people concerned with projects and their management. In principle then there are two levels of knowledge being applied in this field. The first level is mechanistic: knowledge about the contents of the toolkit of mainstream project methods and the simple operational functions of the tools we can find in it. This knowledge is sanctioned by the authoritative bodies of the profession. Those who practise the profession need to possess

MAKING SENSE OF PROJECTS

11

it, but that is not sufficient. This level of knowledge cannot act as a solution to the problems of project management, any more than a plumber’s bag filled with pliers, wrenches, spanners and a blowtorch is, on its own, a solution to a malfunctioning plumbing system. The second level concerns knowledge about how we are to navigate our way through the messy world of real projects: what being ‘effective’ entails, and what we need to know about projects to be effective, when we should use the tools in our toolkit, and when we should throw it away and find ourselves a new set of tools. We are concerned here with this second level – of understanding, of thinking and of knowing how to act. We are concerned with the wily, shrewd skills (the nous or the savvy), the know-how of a capable project performer. This second level is diverse, and difficult to pin down. It arises not from prescription or official sanction, but from reflection by the individual on their experience. The second level is crucial to the success and even to the survival of practitioners. Many projects go astray, and unfortunately the jobs and careers of many project managers and others go downhill with them, o
en quite rapidly. The projects profession is hazardous. An argument that ‘I have done my duty and followed the procedures’ rarely has much leverage in a discipline where failure is inevitably followed by the search for culprits and scapegoats. With beer understanding of the dynamics and pitfalls, your projects will perform beer, and you will have the advantage of being more aware, astute and politically agile than your associates – and hence less likely to be standing in the line of fire when the moment of truth arrives. It is therefore an important continuing strand within this book to discover, extract and set out the capabilities of those who practise projects, for which I am coining the term ProjectCra
. I will highlight them whenever they arise in the discussion, so they can later be collected together into a coherent ProjectCra
summary.

SPEAKING ABOUT PROJECTS Another important strand of the book concerns the question of language. While Eskimos may possess an extensive vocabulary that enables them to talk fluently about any type of snow, those dealing with projects appear to be saddled with a vocabulary that is sadly inadequate for their needs. I shall exemplify this with our first story.

12

MAKING SENSE OF PROJECT REALITIES

LANGUAGE AND TRANSFORMATION The Narrator: Fiona, the Regional Coordinator for a public service change programme Her Story We all know that the public service we perform is desperately in need of reform, but until now the efforts put into that reform have been disparate, spasmodic and ineffective. However, over the past year there’s been an enormous change in atmosphere, with government demands for a systematic programme to drive change across the country. The biggest problem is the wide range of parties who need to get involved: government and non-government bodies, the different professions, pressure groups and unions – everyone has an opinion on what we should be doing, and no two opinions are the same. I’ve been appointed as one of the regional coordinators, and I can state, quite confidently, that for the first time ever we have identified a set of projects that we can all sign on to that will take us forward. We’ve not yet started any projects, but I’m confident that this is the route forward. A key factor in our ability to create this programme has been our adoption of the Prince2 Standard.1 It isn’t the content of the Standard itself that has been critical. We can change that, and we have done. What is most important is that the adoption of a Standard has brought us a common language. There isn’t a great 1

Prince2 ©.

deal of trust between some of the parties to this programme. To overcome that we try to make everything transparent, and for that to happen the common language is critical. Without that language all is chaos. We try to talk to each other, but we’re all talking about different things and there’s no meeting of minds. The language of the Standard was a useful starting point but we’ve had to extend and refine it quite considerably. We now have our own definition for what a project is, and we have terms for all manner of different project types. For example there are the easy ones, the no-brainers, and the ones we have to believe in for political reasons even though we know they will have to be changed. We have also given titles to a lot of roles, and to the various categories of stakeholders. We have terms for the political moves of the unions and others, and we even have coded names for the people on the steering committee who we know have been put there by the Secretary of State to spy on us. When people come on board, the first thing they have to do is learn the language. And then once they’ve learned it they will contribute to it – new words, new concepts – it’s always changing because there’s always something new that we need to express.

The most important issue highlighted by this story is the fact that the language of projects as set out in standard literature is not adequate for use in the real world. To improve our performance of projects we first need to improve our language of projects. Because of this poverty of language people engaged in projects will invent their own vocabulary of definitions and conceptual terms. The development of such a vocabulary is of great benefit. To generate trust, different groups

MAKING SENSE OF PROJECTS

13

of people need to understand each other’s aims and needs, and for this they need shared terminology – a mutual language of projects. This language, the local vocabulary, will be all the more effective by being encouraged and made explicit, so that newcomers can more readily learn the language and contribute to whatever the endeavours may be to which the vocabulary applies. The importance of local vocabulary is such that we will note the development of this vocabulary as a component of ProjectCra. The field of projects as a whole would benefit from an enhanced generic vocabulary, which could improve the subject’s comprehensibility to the outside world, aid the induction of new practitioners, and support the development of local vocabulary. There are many existing terms that are misleading (including the most fundamental – project management) and many significant issues surrounding projects that are simply not covered by the existing vocabulary. Therefore throughout my text I will introduce, define and redefine words that relate to and describe projects, and include these in a vocabulary summary. Having raised the question of definitions, I will first clarify the meaning of the term ‘projects’ as my subject of interest, so that we may differentiate projects from all the other activities that go on in organizations. The standard definitions are wrien in terms of mainstream thinking about plans and tasks, and so must be discarded if we are to advance from this position. We need broader ideas of what constitutes a project. The concepts of purposeful collective endeavours are central. A project is also somehow separate, having boundaries that divide work that is project from work that is non-project. However, the essence of a project is, I believe, its overall trajectory, which concerns the invention and realization of something new. At the end of a project, something has been created that makes the world different. Our collective efforts have lead to transformation, and we can compare the post-project world with the pre-project world, and observe the differences.

This page intentionally left blank

CHAPTER THREE

Projects and Complexity ON THE EDGE OF CHAOS To develop alternative ways of thinking about projects in organizations, we must first set out a more fundamental description of the reality of the life of work in organizations – the basic terrain across which we hope to find our way. When we ask people about the raw realities of their working lives their responses are invariably flavoured by expressions of complexity, uncertainty, ambiguity and confusion. Even those who lead a fairly structured life, perhaps feeding the demands of some robotic production system, are at the same time conscious of potential unanticipated disruptions, which may at any moment intrude on the stable ordered structure they know. For most people, therefore, working life is characterized by the struggle between order and disorder – an existence perpetually on the edge of chaos. Complexity is present in many forms. For individuals, complexity manifests itself firstly in terms of their daily experience. The Things I Do This is one project manager’s list of the things she might handle during the course of a day: A letter arrives from the client with a new requirement. Can it be done? The answer is probably yes, but it will invalidate half of what we have already done. My boss telephones. The head of another department has contacted him to complain that I have ignored one of their experts. I’m not listening to advice. The reason is that their expert has misunderstood the project, but it’s impossible to tell him. Someone in the team has a brilliant new idea that will transform the project. It sounds good so we ought to consider it, but it will cause big changes. I am passed a letter from head office requiring a new form of monthly report. It includes all sorts of data we can’t possibly produce, and other items that will put the project in an unreasonable light.

16

MAKING SENSE OF PROJECT REALITIES

Someone mentions a meeting next week to discuss our strategy for dealing with my client. I haven’t been invited. Why not? Someone in the IT team, who has a critical job to do on my project, has handed in his resignation to go to a rival. Can he be persuaded to stay? If he goes, how will we get the job done? The administration manager drops by and casually mentions that our office is to be relocated to another part of the building. It will disrupt us at a crucial time. The client telephones me about the letter received this morning. Will we ignore it? They have had second thoughts – a slight change of plan. They will send another letter tomorrow. This is just a sample of what can come my way on a single day. All these things affect the project and my ability to manage it, so I have to handle them as they arrive. If we are still on course when evening comes, then it’s been a good day.

Most people, especially those engaged on projects, find they are subject to a stream of unpredictable and oen unexplained events. While it is normal practice to aempt to lay out plans for the hours or days ahead, intentions are invariably blown off course by frequent unplanned interruptions, which must be experienced, interpreted and understood before they can be dealt with; then incorporated into a revised forward plan, postponed or ignored, and hence brought within the realm of control and order. Individuals also have, every day, significant and varied ‘personal’ work to perform. Personal work will include maintaining a position and reputation, defending against criticism, gaining inclusion in a group or at an event, or establishing their role in the organization – as manager, subordinate, colleague, or rival. Many roles (that of Project Manager is an obvious example) also put demands on the holders to maintain ‘face’ – to establish and protect their reputation for being right. This type of personal ‘reputation work’ is also highly unpredictable, but must be performed whenever the demand arises, taking priority over recognized work tasks. For these personal endeavours, and for the daily negotiations concerning all manner of work maers, relationships are central. But relationships are themselves uncertain, ambiguous, and subject to sudden change, and so they too require continuous aention to keep them live and productive. There is thus complexity on top of complexity – a stream of uncertain events to be handled through our oen insecure relationships.

PROJECTS AND COMPLEXITY

17

All these complexities – the stream of work events, the personal endeavours, the reputation work, the relationships, and more – frame the lives of individuals at work. They are experienced as taxing, as time-consuming, and as emotionally demanding. The only available defence strategy is to aempt to create order.

ORGANIZATIONAL COMPLEXITY The complexity of work is also evident at a macroscopic level, in terms of the interactions between different organizations and parties and their diverse interests and agenda. This constitutes organizational complexity.

MEGA COMPLEXITY The Narrator: Howard, the Projects Director of a Major Construction Company His Story I’m not arguing that projects have ever been easy, because they certainly haven’t, but I’m acutely aware that they get ever more complex and difficult. This is apparent with many of the major projects we’re working on now: airports, railway upgrades, sports facilities. There was a time when we were given a specification, we had the resources and knowledge to get on with it, and we just did it. Now everything is changing, and our projects are getting very complex. The first level concerns the technical things. Not only is technology getting more sophisticated but you also find that everything now interacts. Anything we do has a direct effect on other facilities being built alongside, and vice versa. You only need to dig a hole in the ground and someone is affected. Furthermore, our projects no longer stand alone. They are intertwined with all manner of other projects. While working on the railway we have to take account of the stations and the train operators. Our work on the sports stadium has to take account of the infrastructure including the transport systems.

However, these matters are minor in comparison with the social issues we have to handle. First, at the requirements level, we don’t just build a structure; we have to respond to the expectations of the people who will use it, and to understand and allow for the ‘whole experience’ of the user. We might, with some difficulty, set up a focus group to advise us on these matters, but then we will find that the client has been challenged by another pressure group we hadn’t known existed, and the client has decided we have to take account of them. Then the politicians will also suddenly weigh in, demanding that we recognize another late requirement or a policy change, and telling us we must follow some project management standard of their choosing. Yes, we’ve been doing project management for 50 years, but they will still demand we comply with something new and, frankly, irrelevant. On top of that we have our own homegrown complexity. Twenty years ago we did everything in-house – we had our own designers, our own labour force, everything. Now we’re part of a multinational, and we’ve outsourced all our design work and labour force, so

18

MAKING SENSE OF PROJECT REALITIES

we have to manage all these interactions between all these parties. When I pause and think about it, it’s very frightening. We only need a few things to go wrong – an over-commitment, a technical interaction we hadn’t spotted,

a problem with a contractor – and we could have a major disaster on our hands. Some companies have dropped out of the business because their backers won’t take the risk. How can we handle it all?

On hearing a statement such as Howard’s it may be tempting to dismiss it as something particular to his area, to assume that this is the sort of problem that afflicts those working on massive construction projects but unlikely to concern the rest of us. However I could quote similar descriptions from projects in health service management, in financial administration and in many other areas – projects that require daily dealings with a diverse array of interacting problems: technical, IT systems, personal, social, operational, political, skills and training, financial, etc, etc. The trap in front of us is that we might consider the opposite possibility, the delusion that there may somewhere be projects that are simple. There are none. Projects are human social endeavours, and are therefore always complex, ambiguous and uncertain: at the granular level of individuals and their personal actions and interactions, at the intermediate level of group and inter-group behaviours, and at the social–political level of organizations and their competing interests. The tangible objects that make up projects – the outputs, the specifications, the plans – might appear, to a particular observer at a particular time, to be straightforward, but they exist within the context of this complex social world and are at all times subject to it.

IN SEARCH OF ORDER In the workplace, we cannot tolerate these levels of confusion. We need to find pragmatic ways to act, to ‘handle it all’. One option is, of course, to aempt to shut the world out, and some people may, some of the time, find islands of isolation and security where they can act independently and have certainty. For the most part, however, we need to make sense of the ambiguity and uncertainty and to generate some semblance of order. Complexity that appears to be structured, and hence controllable, is preferable to chaos. There are, in the literature, advanced theories about complexity, both in the world in general and as applied to organizational life. However, they are primarily directed towards those in our metaphorical helicopter. They

PROJECTS AND COMPLEXITY

19

provide an excellent means through which the world below can be examined and understood from a safe height, generating erudite explanations of what is going on. The test of a good theory, however, is its pragmatic value to those struggling on the ground, and theories of complexity do not meet this criterion. In organizations the basic complexities I have described are constrained by the structure imposed on them through many forms of institutional order, which limit and control the extent to which chaos can prevail. These forms of order include the organization structures, the accepted ideologies and rules that govern behaviour, shared understandings about the political and commercial worlds in which the organization operates, and accepted rules and practices (how we do things). People are assigned to departments and groups and identify their own interests with those of their group. These facets of organizations all serve to generate order, and with that order come those other essentials for effective collective work: commitments, trust and the possibilities for cooperative action. However all these forms of organization and order are artifices, superimposed on an underlying bed of complex human behaviours that continue unabated. As the inhabitants of organizations we generate sufficient order to create an illusion of control and lile more, striving to make sense of the stream of complexity. This conclusion has important consequences for our understanding of projects.

PROJECTS – DO THEY HELP? What is the significance of projects in this argument? In production-orientated organizations the production process itself provides a basis for much of the shaping and thinking of the organization and how it works, that essential constancy around which people can understand their working lives and plan their actions. The process may be modified or retuned, but the fact of production continues as a structuring force. In organizations without that continuity of the production machine, something else is needed to provide essential order. The philosophy of projects responds to this need in abundance: clarity of aims, direction of energy, coherence of efforts, criteria for success. For those who are managers, the project model provides legitimacy for their plans and criteria for success that can be used to enhance their reputation (if achieved) or assign blame to others (if not). It provides a whole system to command action, to prevent

20

MAKING SENSE OF PROJECT REALITIES

or at least restrict disorganized working, and to evaluate performance and judge the worth of their colleagues and subordinates. Projects are immensely powerful. For those of us who are not managers, the project model has some disadvantages in that it makes us subject to its inherent power structure – its imposition of demands, with the threat of punishment for those who fail to live up to those demands. For this reason it is sometimes held up for criticism as a mechanism of the corporate ‘prison’ – a powerful instrument of control and a destroyer of individual freedom and initiative. As a counter to that criticism, the model also has significant aractions. If we are prepared to buy in to a project we have gained an immediate and comforting antidote to the complexity that we wish to avoid. Here is a strategy for avoiding chaos. We have been told what we must deliver; we have been given a plan. If we choose to believe this is viable we then have order and certainty. If it turns out the plan is not viable, we have a scapegoat (a gullible project manager), who can doubtless be induced to give us a new plan, and a new certainty. All parties, then, can find good reason to buy in to the aractions of projects and the project-based organization, but the concept is at the same time perhaps not as firm as we would like to believe. There is an anecdote (perhaps apocryphal) about an experienced manager who had spent much of his working life as a director of production in a manufacturing company. In late career he was promoted to the role of project director at a new manufacturing facility. Initially he was pleased to be given this high-status position, but he soon found he was completely beaten; he could not do the job. His problem was this. As a production director he had, on most days, walked into the factory and checked up on how ‘production’ was going. This was straightforward, because he could see it. There was a production line, which moved, there were people operating machines, which assembled the products, and there was a waste bin for scrap, which he inspected at every opportunity because its contents showed him what had gone wrong. He dealt, all the time, with tangible objects. At any time, on any day, he could see and touch the production for which he was the director. As project director, however, he had none of this. There was only one form of evidence available for his inspection – pieces of paper. Their contents might or might not have some connection with how well the project was proceeding.

PROJECTS AND COMPLEXITY

21

The moral of this anecdote is that a project is not real. It is a story constructed by humans for a particular purpose. The bits of paper, the things we can see, give the illusion that it is real, but it is still an illusion. The project artefacts are an idealized representation of the highly complex interactions that the project is aempting to shape. So the question we must ask about any project – its story, its artefacts – is whether or not it is a useful story. Do the things we produce to act out this thing called a project help us perform our work in an effective manner, or are they a distraction? In a sense a project is a map – an idealized incomplete representation of a complex terrain. Like a map it is critical to our understanding of that terrain, pointing us towards our route forward. The sense of order and direction generated by the creation of a project can be used to great advantage. If we have a project business case approved by senior managers, that gives us authority to spend money and employ other resources on our project. If we have a project plan, negotiated and agreed, that gives legitimacy to our strategy, and gives us the power to compel others to act in accordance with that plan. But to gain these benefits we must make our project appear real, and so we must work hard at the bits of paper that form the project. Without these documents there is no project. They give the project its legitimacy as a map. With a legitimate project we can gain commitment and trust, turn collaborative work into something coherent, and give it momentum – the drumbeat to which we can all march forward, all in step.

MODELS AND THEORIES A project, then, can be a useful map, but there are many types of map: motorway maps, footpath maps, vegetation maps, geological maps, weather maps. Maps have different scales: they may be rich in local detail, or they may show our location in the wider world. Each has its purpose. The map that is based on mainstream project management has its uses, but it is flawed. It is inaccurate, its projection of reality is distorted, and the order it promises is an illusion. There are other possible maps we could draw, and some of these might be beer representations, or they may be complementary, providing another perspective on our possible course of action. If we return now to Howard and his final rhetorical question – ‘how can we handle it all?’ – we can hear his answer.

22

MAKING SENSE OF PROJECT REALITIES

MEGA COMPLEXITY  SOME ANSWERS Howard’s Story (continued) How do we handle it? Well it’s difficult, but it’s our job. This is what our fee is for. There isn’t one single answer. We have lots of them. Basically our answers come in two categories. The first category concerns sets of values and rules: the core values that inform our decisions, and the pragmatic principles that we’ve learned over the years. They are specific to our sort of work, and tell us what makes for a good project and what doesn’t, such as how we relate to clients or how we deal with contractors. We do our best to follow them, but sometimes circumstances intervene and we have to

go along with something else. Then we know things will go wrong, but at least we are prepared. In the second category are our theories and models. For example in this business we are beset with horrendously complex problems, where every party has a different point of view. We classify these according to how messy they are, and how politically intractable they are, and then have standard approaches we use to set them down and deal with them to get the end we need. It’s about creating a systematic approach to dealing with the problems you meet regularly.

Howard’s answer, then, is a set of theories of good practice, about values and principles, heuristic models, systematic approaches, creating typologies for different problems and having routine procedures for decisions. These are his company’s ways of navigating through their project-based business – their sketches of the topography of their local domain, with the best paths marked out clearly, to be followed whenever possible. At the level of the company or organization, the creation and sharing of such theories is an important capability, so we will add this to our ProjectCra inventory. While the development of local theories is important, there are also two more general perspectives that are used, implicitly but regularly, by practitioners to explain what happens on projects. These concern social interaction and value creation. These two frameworks for thinking about projects are evident, in the background, in many of the explanations given by practitioners when speaking about their projects. (Howard’s story is a good example.) These two perspectives can provide valuable insights into the workings of projects, and will therefore have a major role in the remainder of this book, acting as alternative maps for finding our way through the complexity of projects, replacing or supplementing the rather imperfect map that is constituted by the mainstream mechanistic tools and techniques.

PROJECTS AND COMPLEXITY

23

In thinking about projects as social interactions, we will move away from conceiving each project as being some objective entity ‘out there’, to have operations performed on it as if it were being delivered by a mechanized production process, and recognize instead that projects emerge from interactions between different social groups, and are framed by their agenda and the interplay of politics and power. This way of thinking about projects will be presented in the next chapter, and will inform our subsequent examination of topics such as the expansion of project modes of working, and how organizations handle strategies and projects. In thinking about projects in terms of value creation, we will move away from conceptualizing them as being there to deliver some hard and tangible product, and endeavour instead to understand the things that have been created at the end of the project trajectory – the forms of value that our diverse social groups hope to see realized through projects. This way of thinking will be presented in Chapter 11, and will inform our subsequent examination of later topics including business transformation and the handling of uncertainty. In summary, to handle complexity in our daily working lives we need to construct forms of order: models and theories that make sense of our predicament, point the way forward, and keep us on the right side of chaos. Project management offers such order, but it is flawed and partial. Two further general perspectives, social interaction and value creation, are inherent in project explanations given by practitioners. They provide useful alternative ways of thinking about projects, and will be used to inform the arguments to be presented in the remainder of this book.

This page intentionally left blank

CHAPTER FOUR

Tribalism and Rituals PUTTING SOCIAL MATTERS FIRST Mainstream ideas about projects bear a strong resemblance to a production line. A project is identified, and has a project manager assigned to it. They must then supervise the progression of this object, the project, along the production line, operating the machines provided to ensure its successful deliverance, perfectly formed, at the end of the line. We should recognize that the standard project management model is not entirely mechanistic, and does in fact pay lip service to the existence of a surrounding social world having potential to influence the project. The wellestablished techniques of stakeholder management require the project manager to find out and consider the interests these external parties may have in the project. The project can then be steered carefully through the hazards they pose. There is, however, an implication that these external parties are essentially a problem. They are treated as a hazard, having the potential to disrupt what would otherwise be an untainted perfect project, and so they must somehow to be ‘managed’ so that its faultless progression towards its ideal conclusion may continue unperturbed. There is an alternative way to understand this relationship between projects and their social context, which is to put social maers first and to consider projects as being instigated, formed and delivered as manifestations of social interactions. To follow such an approach we need to develop some concepts we can use to describe the social world of projects. To this end we shall consider a case study.

A TRIBAL PROJECT The Narrator: Robert, an itinerant Project Manager His Story My arrival in the Pensions Office of DivCo was quite a shock – to all parties. My background is in engineering and construction and that is where I picked up my understanding of projects. At the Pensions Office a lot of the project

basics seemed to be much the same: work breakdown, specifications and plans, dealing with IT suppliers, budgets and expenditure – all very familiar. The people, however, and their preoccupations, were quite different from my old colleagues, like a different species.

26

MAKING SENSE OF PROJECT REALITIES

Essentially the job was to change how the office worked by introducing a new IT system. There was a new database to be designed and set up, data to be transferred from the old system to the new, and pensions administration software to be purchased and configured. This would allow the operation to be handled with fewer than half the existing staff, with better turn-round, better access to information and enormous cost savings. There was a twenty-strong project team already there when I arrived. Half of them were IT and database specialists, and the others were pensions administrators. They had been seconded into the project team from the main office, given a budget of around £6m, and told to get on with it. The only string attached was an insistence, from Head Office, that they would take on a professional project manager for the duration, and that the project would be subject to a formal review by an independent review team before the main contract was signed: hence my appointment. There were two managers, Colin and Lisa, running the show, from IT and administration respectively. They had already set out their plans and identified their software supplier, and were ready to go. Their aim, approved by the office executive, was to deliver a top-class administration system that the company could be proud of, and they knew exactly how they were going to do it. They talked convincingly about the new culture they were bringing to the office. My role, as they told me on my first day, was to ‘do whatever it is that project managers do’: prepare some formal plans, check the contract with the main software supplier, write progress reports. And, of course, get the project approved in the independent review – a formality in their eyes, since they knew it was well conceived and planned. So I set off to do as I was asked. They had

hired me and so I was, after all, their servant. There were, however, some problems on my mind. The first was just the scale of the ambition. I was confident the £6m was enough, but there was an awful lot of work to be done, within a tight timescale and with people who hadn’t done that sort of work before. My second concern was the executive. At first sight they seemed to be distant – suspiciously distant. They had even located the project team in a separate building, well out of the way, and were adamant that they had delegated the whole job to the three of us. Colin and Lisa were flattered by this separation, because they thought it demonstrated that the executive had confidence in them. It made me quite nervous. Furthermore, despite this separation between the executive and the project, Keith (the Chief Executive) had dived in a few weeks after my arrival and demanded a change of supplier. We had already checked out the new supplier and it wasn’t a big deal to us, but it seemed to matter a lot to him. Third, of course, I knew that my doubts about feasibility would make it difficult for us to get through the independent review. I knew the reviewers personally. Together we were all part of the DivCo project management community. In the past I had been in independent review teams for some of their projects, and I had been involved in writing the review procedures that were now in the project management manuals. Something had to shift if we were to get the necessary approval. I decided to bridge the gap and get closer to the executive, and especially to Keith and to his deputy Belinda, who was also the Director of Administration. I soon realized they didn’t really have confidence in the project, or in the ability of Colin and Lisa to deliver it. Their only serious topic of conversation was an impending sale of a large part of DivCo and the need to pass on a big part of the pension fund with that sale. They talked only of the company’s

TRIBALISM AND RITUALS

liabilities, and the need to divest these at the time of the sale. None of this had been mentioned in our project brief; it was treated as a separate issue. But the planned date for the financial transaction was very close to our project go-live date, and the supplier to whom we were switching had, it transpired, delivered a very similar system to the company now negotiating to buy the chunk of DivCo. I formed an alliance with Belinda, and together we brought this big finance agenda to the foreground. Keith became concerned that the project as planned couldn’t be delivered, and might jeopardize the sell-off agenda. He promoted me, putting me on the executive committee, and in charge of Colin and Lisa. Belinda and I took control and refocused the project on supporting the divestment. We visited the supplier together, where we struck out swathes of the project scope, optimizing the new system to deal with the financial transactions. The administration software, which had been so important to support the project’s original aim of providing a top-class administration system, was massively cut back. With it we also dispensed, in passing, with the motivation of Lisa and the administration staff in the project team. Lisa was devastated. She had originally been put in charge of the project. She had designed it, planned it and then sold it in this form to her administration colleagues. She had brought me into the project, but now I had betrayed her, conspiring with Belinda to undermine her and decimate her plans. She left the company soon afterwards. Although the shift had been painful it now felt like the right project, and we moved on. We set up a proper steering group,

27

including the executive, took the project successfully through the independent review, placed the software order with the supplier and, with the announcement of the DivCo sale, brought the purchaser’s representative on to the steering group. We also relocated the project team back into the main building. The project team continued working in a professional manner, but without the same level of dedication. They never forgave me for what I had done to their top-class pensions administration project. In retrospect I sometimes wonder whether I could have just kept my head down and done the job as specified. I know plenty of project managers who would have done just that. We might have bluffed our way through the independent review and would have ended up with one more underperforming IT project, but would that have mattered? To that question I believe the answer is yes. First, by pushing through a dodgy project I would have done myself no favours with the project management community. They wouldn’t have trusted me again, or have engaged me again as a reviewer of other projects. Second, and crucially, the vultures – Belinda and her friends on the executive – were already circling overhead. As soon as they smelt failure they would have pounced. There was never a benign option – a route we could follow where everyone got what they wanted, and where nobody got hurt. So in the end I’m sure it was right to go with the most powerful agenda and realign the project to support the big finance manoeuvres. It was always going to happen, so it was best to get on with it. It’s better to swoop with the vultures than to cower with the dead meat.

It is indeed! But if we are to dare to take such decisions then we need a sound basic model of the social world – a model we can use to analyse these situations so we can be reasonably sure the moves we make are the right ones.

28

MAKING SENSE OF PROJECT REALITIES

TRIBAL ANALYSIS The building blocks of such a model are apparent from Robert’s example. There are a number of social groups in evidence, which we shall call practice groups. The primary characteristic of a practice group is that it has a field of expert knowledge. For each group there is a topic – a zone of work – where the group claims particular expertise and responsibility and has the power to make decisions. In any organization we can define these practice groups by the substance of their interest – what they deal in, and the set of practices they employ. In most organizations there are a number of classic groups, well recognized and easily identified, such as accountants, lawyers, engineers – the groups commonly recognized as professions. However, this is only a limited subset of the groups we can identify. There may be others, perhaps less clearly labelled, who are also highly influential in the running of the organization. These are the tribes of the organizational world, each tribe having its identification marks and its set of artefacts and rituals – the ideas and behaviours that set its members apart from the other tribes. To understand social interactions in projects, therefore, our first requirement is that we must be able to identify these practice groups – the tribes – in any project situation. If we consider the DivCo pensions office, there are three local groups we can identify immediately. The first two are concerned with the core substance of the business of the office – the management of pensions. The fact that there are two of them – that the office is performing two related but separate functions – is crucial to the story. The first group comprises the administrators. They are looking aer the interests of the individual pension scheme members, their savings and their individual entitlements. The second group are the financiers, whose primary interest is the handling of DivCo finances, its assets and its liabilities. In this story there is also a third local practice group comprising the IT and database specialists – experts in a technical service that supports the primary functions of the office. Into this three-tribe social environment, an interloper has been injected in the form of Robert, our narrator. He is a member of a remote and mysterious tribe – the DivCo project management community. He brings their special rituals and artefacts (the project manuals) into the story. As a starting point for our analysis of the story we can thus simply list these tribes in terms of their zone of interest and their ritual practices:

TRIBALISM AND RITUALS

Table 4.1

29

The tribes of DivCo Group

Zone of Interest and Control

Practices

1

Administrators

Individual scheme members and pensioners, and their entitlements

Administration rules

2

Financiers

Corporate assets and liabilities

Valuations and trading: acquisitions, mergers, divestments

3

IT and data

Databases, data, security

Database design and data manipulation, IT systems

4

Project managers

Projects – viability and delivery

Project shaping and authorization. Techniques of project delivery

We will note firstly that these groups existed before there was ever a project, and they will continue to exist irrespective of whether the project goes ahead, and whatever its form. It is a characteristic of such groups that their field of interest is fairly stable, and their ideas are slow-moving. The business may change, and projects may come and go, but these groups tend to continue. They are part of the fabric of the organization and do not change direction lightly. The project, when it appears, is a supplement to their existing strategy – something they need to pursue to advance their aims. The various practice groups interact in a system of power relationships. Each group seeks to pursue its own interests, jockeying for position with the other groups as best they can. In our example, the Financiers, who hold the purse strings, have sanctioned the Administrators to perform a project, enticing them in this direction by reflecting, initially, the Administrators’ own vision of a superior administration system. Under instruction from the Financiers’ cohorts in head office, the Administrators have hired a project manager, Robert, from the appropriate tribe. They treat him and his tribe as servants, defining for them the subordinate role their project manager must play. The Financiers, however, have a different view of the project manager, whom they see as an agent – a potential ally whose central power can be used to advance their own interests and, when the moment arises, reshape the project to something that beer suits them. In this contest Robert, we will note, has been playing for both sides. He has started out in a servile ‘whatever you want’ mode on behalf of the Administrators, but has at the same time used his position as a member of the DivCo project management community to bypass their rule

30

MAKING SENSE OF PROJECT REALITIES

and form an alliance with the more powerful group, the Financiers, and engage with them in reshaping the project. Within these groups, individuals act as tribe members. It is this membership that gives them their authority. Robert, for example, may like to think he is an engineer, but his ability to act is granted to him by virtue of his membership of the project management tribe. It is his membership of that community that brought him to the pensions office and it is as a member of that community that he speaks and acts. Individuals become members of their tribe through a learning process, usually quite extended, in which they become indoctrinated in the recognized practices, learning the specialist techniques and also learning what is permissible and what is not. To gain admission, there is a language to be learned. Each tribe has its ways of talking about its zone of interest. The Financiers’ agenda in our example is discussed and promoted using the language of corporate finance, and those who wish to join in, to discuss or challenge that agenda cannot do so unless they first learn to speak that language. To summarize, our basic element of analysis will be the practice group – or tribe. Such a group can be characterized as having its zone of expert knowledge, its standard rules and practices (rituals), the artefacts it uses to apply these, and its language. Practice groups have a relatively stable long-term existence. They interact through a set of power relationships. Individuals become members of a group through learning its practices, thereby becoming accepted as members. Having established this social element as our unit of analysis, what then is the function of a project?

TRIBES AND PROJECTS The first thing we must note about projects and project teams is that they do not comply with our definition of a practice group. While practice groups are stable, project teams are temporary and unstable. The members of the team may hold some temporary allegiance to the team, but they remain essentially members of their own tribe. In our example, Colin and Lisa have made a pretence that they are the leaders of a project group. They have produced a plan, and had it approved by their executive. Does this give them status as project managers? In this example it does not, because the executive are simultaneously undermining that status, introducing an external

TRIBALISM AND RITUALS

31

project manager and then manoeuvring to reshape the project over their heads. Their position as managers of the project is temporary and fragile. The project comes into existence by emerging from the social context. Its birth is a transient response to the short-term agenda of the more stable practice groups. In DivCo the Administrators had a vision of a perfect administration system, and the Financiers had a vision of a world where major corporate transactions can be made easy. These visions had a degree of overlap reflected in the original project scope. A deal was arrived at whereby the Financiers pretended to support the Administrators’ agenda and the Administrators got on with their project, funded by the Financiers. This deal ran, but only for that short time span until the Financiers realized there was a beer and safer option. A new deal, the reshaped project, was then formed. The Administrators did not like it, but had to lump it and accept the project that was defined by the Financiers’ agenda. Projects thus do not exist in their own right, but are brought into existence as subservient to other agenda. A situation arises where the aims of a number of parties can be advanced by the creation of a project, and so it happens – a project is conceived and is born. This process, the set of social interactions between different practice groups which in combination demand the creation of a project, we call projectification. For those parties who wish to create projects, the existence of a permanent expert practice group, the project management tribe, is a vital resource. The politics of organizations are notoriously unstable, and an agreement today may fall apart tomorrow. Projects, however, involve a substantial commitment to spend money and employ resources. The creation of a project brings with it a need for a period of stability, having sufficient clarity of purpose to take sizeable steps forward on the project path. The introduction of the expert project manager as somebody who can set out a plan, ensure that it is sound (or at least appears to be so) and pronounce on its viability is crucial. The project may emerge from the dynamics between a number of competing factions, but to establish it as viable, legitimate and reasonably stable, these factions need to call on the services of an expert. It is not my purpose, at this point, to discuss whether this process is effective – or to discuss why it is oen so patently not effective. That will be addressed in later chapters. My aim now is merely to note the fact of this social process: the interaction between practice groups leads to the demand for a projectification to happen, and to give the new project its necessary legitimacy an expert

32

MAKING SENSE OF PROJECT REALITIES

project manager must appear and have the authority to ‘bless’ the project. The leading tribes of the organization need a project management profession, and professional project managers appear in response to this need. This process is superficially quite simple, but its implications are significant. Project management is a resource called upon by practice groups to promote their own aims. Project managers and their tribe are therefore not acting as independent agents, but are the hired servants, the lackeys, of these groups, and must follow the lead dictated by their masters, moulding the project to fit the prescribed agenda. The problem of course is that their potential masters are numerous and diverse, and the relationships between them are unstable. The project management resource is therefore highly politicized. There is no neutral set of project requirements to be sought out and set down. Project managers may sometimes act out this apolitical line and pretend, as Robert did in the early stages, to ‘just do as I was asked’, but such a decision – to support and make legitimate the agenda of one party in preference to that of another – is itself political. These are critical maers for the astute project manager. Robert optimistically stated his desire to ‘swoop with the vultures rather than cower with the dead meat’, but if we get this wrong we may find ourselves hopelessly trying to swoop when we are part of the dead meat, or cowering with the chickens. The project practitioner is a partisan player in the power struggles of the organization. Experienced project shapers go to great lengths to shake out the requirements – to flush out the parties lurking in the bushes and to bring them into the foreground. Through these efforts complex and diverse interests become open and transparent. This is the only way to ensure that we can understand what is going on and spawn the optimum project – one that has the potential for a dynamic and successful life.

SOME STANDARD TRIBES Those are the principles of a social interaction model of projects, but we can also make some generalizations, and name the tribes usually involved in the practice of projects. Table 4.2 presents a very simple categorization of the types of tribe we may meet in an organization where projects are practised. We will use and refer back to these categories through the course of this book, to examine particular actions and cases.

TRIBALISM AND RITUALS

Table 4.2

33

Foremost tribes of the project world

Category of Tribe

Who Are They?

What Are Their Characteristics?

Project directors

The group seeking to impose project working within an organization.

Driving a central agenda of accountability and control, promoting management by projects as a way of life.

Strategists

Agents of central policy makers, using projects to deliver a strategy.

Concerned with creating projects, while preventing peripheral and non-essential activities. May act as the formal project ‘sponsor’.

Project shapers

The project designers, negotiating and setting the agenda of individual projects.

May be an explicit tribal group, but is often an ad hoc group negotiating between interested parties. Some project managers see involvement in this function as central to their role. Others deny any interest in the subject.

Project deliverers

The group who take responsibility for delivering a project (or part of a project).

Individual project managers will belong to this tribe as a long-term home, while acting on behalf of a temporary team for a specific project.

Priesthood

The groups who act as custodians of project management knowledge.

The group that sets the standards. They include in-house expert practice groups, independent standards organizations, associations that claim to be professional bodies and universities.

TRIBAL MEMBERS In seing out a model of projects based on social interactions there is a danger that I may be accused of ignoring the importance of individuals, eliminating their actions from the equation. This is not the case. If we consider the actions of individuals in terms of their roles as members of a tribe, this does not prevent us from also considering the relationship between each individual and his or her tribe, or questions about individual decisions, individual capabilities and individual career paths. Particular people may believe themselves, quite reasonably, to have their own interests, or to be members of several tribal groups. These issues are very important, and will be addressed throughout the book. At this stage my claim is, however, that the influence people have on projects arises by virtue of their positions as tribal members, and that our global understanding of what is going on within projects is therefore pursued most pragmatically by viewing them through the lens of a social model.

34

MAKING SENSE OF PROJECT REALITIES

On this basis, all actions in a project environment will be looked at in terms of the tribes of the perpetrators, and how they speak and behave as members of those tribes. If we look back at the examples presented by our narrators so far we can already make sense of their contributions in this way. Our first speaker, in Chapter 2, was Fiona. She presented herself as part of a public service delivery team. She also demonstrated and employed considerable knowledge of the approaches and techniques of programme management. However, her overall role is clearly that of a strategist. She is a member of a governmental group with a highly focused agenda, which is to transform the delivery of the service. The artefacts of programme and project management are part of her armoury. Our second speaker, in Chapter 3, was Howard. He spoke of the complexity of the construction projects in which he was involved. The principles he espoused were, again, those of project management. His primary interest, however, is that of a senior manager in a contracting organization. His aim, in talking of complexity, is to formulate a way of thinking about projects that will enable his organization to control the messy situations in which projects are delivered. He represents the executive of a corporation whose aims include the protection of their corporate profitability. The application of project management principles is an essential element of their strategy. He is thus a project director, and speaks as one. Our third speaker, in this chapter, was Robert, a project manager. His position is slightly more complex in that it appears to embody two different conceptions of his role. The local managers believe they have employed him by virtue of his membership of a tribe that is expert in project delivery, which they understand in a fairly limited form. He also considers himself part of the project priesthood of his company, a party to the custodianship of good project management. This particular priesthood has a predisposition to participate actively in projects, and has an understanding of the practice of project management that includes acting as a project shaper, which he does. This interpretation of the example stories in terms of the social roles of the storytellers highlights two final points about the social interaction perspective on projects. The first is that the examples provided in this book, and indeed any project stories we may hear, are not impersonal stories of objective events. They are storytelling performances that emanate from a particular position: that of the tribal role in the social interactions that frame the project. The social interactions we wish to understand may oen be an explicit part of the stories

TRIBALISM AND RITUALS

35

being told, but they are, additionally, implicit in the telling of the story. The telling itself displays and sustains the partisan interests of the teller. The second point of interest is that all of the stories include explanation of how the tools and techniques of programme and project management have been used; all our speakers are to some extent exponents of the practice of projects. However, this expertise does not mean that they are all members of one singular all-embracing practice group – the project management profession. Within the world of projects there are many different practice groups for whom the tools and techniques of projects are of value. The total set of project techniques exists for all groups to select those ideas and tools of relevance to them, and to adapt and absorb these into their practice as needed. Our concept of ProjectCra – the capabilities required of those who seek to be proficient in the practice of projects – must therefore embrace a number of different dimensions: ProjectCra for strategists, for project shapers, and so on.

MAKING SENSE OF PROJECTS – THE SOCIAL INTERACTION PERSPECTIVE In this chapter I have set down the basic principles of a social interaction model of projects. The framework presented constitutes a significant shi in how we think about projects. In mainstream thinking a project is characterized as being like a production line in which the project is treated as an objective entity, to be processed by rational beings aligned to a single purpose – the achievement of the defined project end points. The social interaction perspective departs from this model, viewing projects themselves as the product of collusions, spawned and delivered out of the intercourse between diverse tribes – groups with diverse interests. A corollary to this shi in perspective is that we must also re-examine the conventional view of stakeholder management. This view takes the project as being the central concern, and requires the project manager to identify stakeholders and manage their impact. With our new perspective we recognize that there is invariably a set of interested parties who are actually dominant, superordinate to the project, and holding the power to determine what the project will be. The project manager, whether as shaper or deliverer, will follow their agenda.

36

MAKING SENSE OF PROJECT REALITIES

The adoption of a social interaction perspective has significant implications for our understanding of ProjectCra. First, we must recognize that ProjectCra is multifaceted. We are not discussing the skill set of a single form of expert, or even of two forms of expert (for example the project manager and the programme manager).The diverse groups of parties involved in the prosecution of projects have diverse interests, and require a range of different abilities to pursue their varied objectives. Second, and despite this diversity, there is a fundamental capability essential for all those who work in the project environment. That capability concerns the ability to understand the social context in which projects are taking place, to manoeuvre within this context and exploit it, to create projects that are viable. To do this we must be able to identify the influential parties, to flush out and recognize their interests and agendas (whether overt or hidden) and to take account of their power to determine how the project will unfold. Without this ability we will invariably fall flat on our faces, backing the losing sides in conflicts, and associating ourselves with projects that are doomed to fail. Fundamental to this understanding is the ability to recognize and evaluate our own position and options. We are all partisan players and must choose our allegiance and strategy with care. Specifically, project managers play a role that is oen subservient to the agenda of others. Whoever wishes to take on the title of project manager must also be able to answer the simple question: whose project manager are you? The social interaction perspective is not put forward as the only way to view projects. There are other models, ideas and guidance that are also very important. There is no intent that this perspective should replace mainstream project management thinking. The aim is rather to extend our thinking in more pragmatic directions, for which the social interaction perspective is the foundation stone – underpinning much of the thinking put forward in this book. In the next three chapters we will use this standpoint to examine two issues that are critical in current projects: the rapid growth of projects as a mode of management (and whether that is a good thing), and the proliferation, in all sectors, of projects that fail.

CHAPTER FIVE

The Tyranny of Projects PROJECTIFICATION – THE DRIVE TO PROJECT WORKING The conventional explanation for the proliferation of projects as a mode of working is simple: projects are considered to be the optimum working mode for the delivery of non-routine work. Projects are also, as we have noted, largely welcomed, creating structure and order: a clear map of the otherwise complex and chaotic terrain of the workplace. It follows that projects are good, and so more are beer. As organizations seek to become more competitive, the expansion of the project domain – the projectification of work – is both inevitable and desirable. If we consider this growth from a social perspective, different questions arise: why should it happen, and why now? Project management is not a recent invention, so explanations for its growth based solely on its merits as a management science are not sufficient. We should expect to find contemporary reasons for the phenomenon: forces of projectification arising in the wider social and political changes of our time. We can then ask some critical questions about projects. Primarily we can compare the scope of work brought into the project domain by the social forces of projectification with the scope of work for which the project is a useful and efficient mode of working. Project management, like any science or theory, has its range of convenience – the zone in which its application is pragmatic and beneficial. Are projects, as now practised in a broad band of business areas, entirely within their range of convenience? We can also ask what the wider consequences might be of making work a ‘project’: the advantages, and to whom, and the limitations and disadvantages? To consider these questions we will take an example of strong projectification: a case in which systematic project management has been imposed on a difficult situation.

38

MAKING SENSE OF PROJECT REALITIES

A NOVEL COOPERATIVE VENTURE The Narrator: Matthew, a new Project Manager His Story When I was asked to take over the project, it had been going for about a year out of its two-year programme. I had never done any project management, and was hoping for a senior management appointment, but this job was thrust upon me. I knew I had to do it right so I took it as a challenge. According to the project specification we were working to the Prince2 standard, so I got my head down and swotted that up in the few weeks before I started. It all seemed fairly obvious. The job was basically about setting up a pilot IT facility that would enable different people in various agencies across the country to share information. When I got into it I was quite taken aback by the state of things. A number of local agencies around the country had come on board to take part in the trial, and two software suppliers had been identified, but otherwise it was chaos. There was no business case, no single clear vision of what we were doing, and no specification of the software requirements. As a result the pilot agencies were going their own ways, inventing their own ideas of how it would work. There was no way this uncoordinated activity could lead to a meaningful trial that could be completed by the date that had been promised to the minister. I was frightened that I wouldn’t be able to pull it together, but there was no way to back out, so I set some very simple priorities: to agree the content of the project and to try to do something useful. I hammered out a project scope with the agencies and suppliers – something properly defined that we could reasonably hope to achieve in the time allowed – and set up some proper project control

mechanisms: budgets, milestones, reporting arrangements, a risk log, monthly reviews. The fact that we were working to a recognized standard was immensely valuable. It gave me authority to bring all the parties into line. It was hard work and a close-run thing, but in the end we made it. We had a demonstration system up and running, and a report on the minister’s desk with only days to spare. I recognize now that there are things I should have done differently. We probably didn’t get the users involved soon enough, and my contacts with the project sponsor were erratic, and so we didn’t get clear principles laid down. Overall, however, I’m very proud of what was achieved. I took a situation that was close to disaster and knocked some order into it to create a creditable and ultimately successful project. I’ve shown what project management can achieve in a difficult situation, and shown that I can do it. Actually, having said all this, I realize I have probably been unfair to my predecessor. I’ve given the impression he had left everything in a mess and I sorted it out, and that isn’t the whole story. In fact he was an incredibly creative man. He was the person with the imagination and foresight to conceive the whole idea. Then he made it happen. He sold his idea to the minister, and he co-opted the agencies around the country. When I took over these people were already overwhelmingly committed to the success of the project. He only left the project because he retired. If it wasn’t for his passion and drive there would never have been a project for me to take on.

THE TYRANNY OF PROJECTS

39

In this story there are several social groupings in evidence, engaged in seing up the project. At the centre is a government ministry. They have a general agenda to introduce enhanced IT facilities that will improve the sharing of information in distributed agencies. Their demand is for a project that will deliver a tangible benefit in a defined timescale. The outcome must be something that can be shown as evidence of progress. They are, aer all, accountable to the electorate for this service. Out in the country there are a set of agencies and soware suppliers with varied responsibilities who have agreed to join in, perhaps because their participation will enhance their reputation. There is thus a simple client–supplier relationship, a demand and a response, in principle a sound basis for action, but initially rather unfocused. This social context is apparently not sufficient in itself to make a project happen. Within this situation, two individuals have taken decisive action. Our speaker, Mahew, has a strong agenda to build his identity and reputation as a project manager in the heroic style. He takes on all the artefacts that the role demands and leads the agencies in an exercise to convert the chaos into cohesion and order, to shape the project, and, as a loyal political servant, to deliver the prize – a completed project – to his political master. He also mentions, as an aerthought, a rather different sort of hero, his predecessor, an imaginative innovator who could generate original ideas, sell them to others and create a programme of work to put them into practice. The creation of the project thus depended on both the social context and the volition of key individuals. Similar social forces can be seen at work in more general programmes to adopt the project mode of management. The United Nations Development Programme (UNDP), for example, has introduced a standardized system for project management across all parts of their international organization. Speaking at a seminar in London in 2005, a representative of UNDP gave their reasons for this initiative as being ‘to persuade foreign governments to take the project seriously’. In the previous example we saw individuals undertaking project actions to promote their individual credibility as project experts. In this second example, there is a similar endeavour, but it is to promote the collective credibility of their organization – to use the adoption of project management standards as a demonstration that their multifarious multinational enterprises are fiing recipients of funding from donor nations. As a third example we will consider a highly innovative but less than successful case. A report on the Central Artery Project in Boston, USA

40

MAKING SENSE OF PROJECT REALITIES

(Professional Engineering, 11 May 2005, under the title ‘Mega-muddle’) relates the mishaps on a project to construct a super-highway through tunnels under the centre of the city (the ‘Big Dig’). The project has suffered major problems in the form of leaks of water into the tunnels, leading to cost and programme over-runs.

MEGA MUDDLE The Narrator: Stephen, a Congressional Representative His Perspective Many of the problems of the Big Dig can be attributed to inadequate planning and project management. If taxpayers took

a hit because of the design failure, then they should be reimbursed. We want to ensure that the responsible parties are held accountable for their actions.

In this post-hoc comment on an unsuccessful project we can perceive the value that the existence of a project has for the congressional representative. Diverse parties in the supply chain must be made accountable to higher authority. The solution to the problem is beer project management. In the construction industry the project mode of working was adopted long ago, but here, in response to similar forces, we can see changes in the form that projects take. There have been substantial structural changes. In the past the contracting companies were large, had a diverse range of expert capabilities within their organizations, and employed substantial trained labour forces. Now, with the freeing of competitive markets, we see projects being handled by small management companies who deliver their projects through a complex multi-tiered supply chain. In the old organizations project management was predominantly an operational exercise – work breakdown structures, plans, critical paths, progress tracking – performed as a service by project administrators. In the new form of organization project management has become primarily concerned with the supply chain: the mechanisms for transferring accountability to successive layers of diverse subcontractors. With the augmentation of the supply chain, the responsibility for competence has also been devolved. Instead of training the workforce, the project must seek to control competence through chains of requirements and specifications. The project has thus become the chosen mode for controlling work using anonymous and possibly mediocre people.

THE TYRANNY OF PROJECTS

41

THE FORCES OF PROJECTIFICATION In all these examples, the force driving the creation of projects is the demand for accountability. The context that frames the growth of project working is one where services to the public and private sectors are being procured through a web of increasingly fragmented providers. If work has been devolved and outsourced through multilayered chains of responsibility, how then can government ministers, civil servants or industry executives act out their accountability to their stakeholders: parliament, the electorate, the treasury, the banks, the shareholders? The answer, of course, is to strive for control through structured organizing – project management. This is the context that is driving the creation of projects, and it follows that the style that project management takes will also reflect that context. Peripheral fragmentation and central accountability together demand project management in a form that makes those working at the periphery accountable for the delivery of the agenda set by the centre. The centrifugal force of the free market, throwing the execution of work outwards to outlying providers, must be countered by the centripetal force of projects, pulling the agendas of these diverse people back inwards to comply with the objectives of those in power. That context in itself is not sufficient to create actual projects, only permiing the possibility of a project and the possible forms it might take. The production of actual projects also depends on the wilful action of individuals. These are the people who seize the opportunities, simultaneously creating themselves in whatever is their chosen mould: strategists, sponsors, innovators, shapers, heroes, or strong project controllers.

PROJECT HAZARDS These powerful forces are driving the creation of projects, and oen with great benefit to all concerned. However, in our examples we have also seen clear instances in which the practice of projects, at least in its conventional form – with defined deliverables and tasks – is being applied beyond its useful range of convenience. In our first example, the cooperative IT venture, Mahew our narrator responded to the minister’s demand for a system to be up and running by a target date. He formed a well-defined and controlled project and in doing so made his own reputation as a strong project manager, but at what cost? The distributed agencies and soware suppliers were prevented from exercising further initiative, and the creative production of ideas was stopped. The project requirements were

42

MAKING SENSE OF PROJECT REALITIES

fixed and then delivered, but with lile assurance that the new system would be acceptable to users, or support the government sponsor’s strategy. In the example of the Boston Central Artery Project, the Big Dig, the project went ahead, but unfortunately those who delivered it are to be punished for performing work that did not fit the model – hardly an encouragement for the next innovative venture. If work is forced improperly into a project form then creativity and flexibility are constrained. The creation of controlled projects can damage enterprise and initiative. We must beware projectification! There are, of course, moments when precise delivery to a specification, cost and timescale is the right course. However if we set up such a project too soon, when continuing creativity is needed, this will lead to the wrong project being formed – one that cannot be delivered, or one that fails to deliver the benefits that could be had through a more flexible mode of working. Timing is crucial. We must therefore beware premature projectification! These warnings, of course, apply to the application of the conventional form of projects. It is reasonable to argue, as we shall in later chapters, that this form is not the only possibility, and that the style of the project and its management should be chosen to suit the situation. If we wish a project to be creative, or to be continually flexible, responding to the demands of the day, then we may perhaps be able to set up our project to achieve that. Whatever our good intentions, however, the hazards of projectification remain unchanged. The forces that combine to demand the creation of projects also demand them in a form in which they act as vehicles for strong central control. When we should be engaged in seeking out new and varied design ideas, those with the power to authorize our plans ask for clear and tangible products. When we should be looking for innovative solutions in uncertain situations, powerful clients threaten to impose punitive penalties on any failure to meet specified requirements, and impel us to seek safe options. If we move forward daringly but disruptions then force us to change course, the media demand to know ‘who is to blame?’ and look for heads to roll. The imperatives of the political world perpetually drive well-meaning project sponsors and project managers into the trap of seing up the wrong project, and at the wrong time.

PROJECTIFICATION – THE CRAFT These issues have important implications for ProjectCra skills. We might observe, in our first example, that while Mahew swoed up the Prince2

THE TYRANNY OF PROJECTS

43

standard for project management in ‘the few weeks’ before he started his new job, it took him several months to grasp how he should have been dealing with the government sponsor. Knowledge of the mechanisms of the standard can be acquired quickly, and may be learned in private, in isolation from the real project. On the other hand a sound understanding of how to handle the social interactions surrounding a new project takes time to acquire, and requires the learner to engage with other people and deal with real events. These skills are relevant to all those who may be party to the seing up of a project, and particularly to those individuals who are the agents for the making of a project, forging and shaping it. These people must be able to read the social environment, to understand what is possible, and then to exercise a considerable act of will to make it happen. They must be aware of the linkage between their personal interests and the project they establish – that the project is a reflection of their own ambition, within their social group, framed by the social context that is encouraging its formation. Different people, in different positions, with different agenda, will form different versions of the project. A major problem is that if we are people in pivotal positions – the formers and shapers of projects – we are acting under social pressures that actually encourage us to create poor projects. The world of projects is rife with opportunities for us as individuals to advance our self-promotion by giving life to projects that are improperly conceived and prematurely born. The overriding drive – the projectification of work – is not merely towards projects everywhere, but towards bad projects everywhere. No wonder we are engulfed by failing projects. We have shown up the nature of the problem, and advised all participants to beware, but what can we do? The answers to this question oen lie in the ways that projects are handled in organizations, and this is the subject of the next chapter.

This page intentionally left blank

CHAPTER SIX

Managing Multiple Projects The main reason why projects turn out badly is that they were conceived badly; their chances of success were never high. In this chapter I will therefore examine critically the approaches that organizations use to control how their projects are initiated. If the conventional concerns of project management are generally with doing projects ‘right’, my interest here is in the more fundamental question of how organizations aempt to ensure they do the ‘right projects’. This topic is obviously of major interest, and a number of approaches are well established. In this chapter I will summarize these, examining their purpose and effectiveness. We will discuss the topic primarily from a managerialist viewpoint, listening to the voices of conscientious managers to hear their concerns and how they address them. While their practices may vary, they are pursuing one broad aim: to protect their organizations – companies, departments, services – from the risk that they will set up projects that will subsequently fail to deliver their intended outcome. We shall find that despite their best endeavours, the bad projects get through. There are many variations in practice, which I have covered in three broad categories of organization style. In the first, which I have called distributed projects, the projects are formed and executed in the scaered regions of the organization, but are subject to central corporate control. In the second style, which I have called strategic power, projects are devised by the corporate centre as a means to implement a central strategy. In the third style the whole function of the organization is concerned with the delivery of projects, and so I have called it the projects-are-our-business form. These are not exclusive options (some companies do all three) but merely a categorization of the purposes that drive the efforts of executive management teams to control projects.

DISTRIBUTED PROJECTS Large organizations, in public and private sectors, have many divisions and departments, each with their own responsibilities and agenda. For reasons already noted, there has been a marked trend for executives at the centre of the

46

MAKING SENSE OF PROJECT REALITIES

organization to demand that project working is adopted within these distributed territories. Initially this demand may take the form of a simple edict, to the effect that all work (or all of some forms of work) must henceforth be managed as projects. This is invariably ineffective; to make sure the edict is implemented the central executive must also introduce some supporting management initiatives. These are necessary not only to ensure that all fiefdoms comply with the edict, but also to protect their organization against bad projects and their consequences: wasted resources, lost profits, lost reputation and possible bankruptcy. The standard measures taken to protect against these risks deal with three areas: the development of staff competence, the introduction of standards and the imposition of controls. These are employed in a variety of mixes by different organizations. Initiatives to improve competence and introduce standards will involve training and development programmes and the mandating of procedures. These need no special explanation here (although we will in due course query their effectiveness). Controls are usually applied in the form of a stage-gate (or life-cycle management) system. The operation of this type of procedure is of critical importance and so, for the benefit of those who are not familiar with such practices, I summarize the principles below. Stages and Gates Any project is presumed to progress through a defined set of sequential stages. The passage of the project from one stage into the next is referred to as a gate. Different business sectors tend to have their own definitions of the stages that apply to them, which may also vary depending on the particular focus of an organization’s business. For example, government departments and industries whose primary interest is in procurement will emphasize the stages concerned with conceptual thinking, leading up to contract placement. Suppliers, on the other hand, will emphasize contract agreement and the stages of their delivery process, validation and handover. As a principle, the transition from one stage to the next will coincide with those moments when a commitment is to be made to invest. Some organizations operate what is effectively a single gate at the moment of financial commitment – the placing or acceptance of a contract. Procedures are put in place to vet the passage of projects through each gate, from one stage to the next. These require reviewers to examine the project, looking backward at the previous stage to confirm it has been satisfactorily completed, and forward to the next stage to confirm the project has a viable plan. This process gives senior managers and executives a mechanism through which they can choose to grant or to refuse the authorization for projects to proceed at each stage, and hence control their commitments and risks. The whole process is often referred to as life-cycle management, and the gates as stagegates.

M A N A G I N G M U LT I P L E P R O J E C T S

47

Here is a high-profile example of the process in action.

PASSING THROUGH THE GATES The Narrator: Tony, a Procurement Director His Story My organization as a whole is a major user of military equipment. In the past we have had a very bad reputation for projects that have overspent or have failed to deliver the equipment we need, so we’ve been doing everything we can to put that right. We now put all large projects through a stage-gate process, run by my department. We’re completely committed to this process and convinced it’s the only way forward. However there are still some big problems. The first problem is optimism: our people are very enthusiastic and full of selfbelief, so potential problems and risks, particularly areas where the technology might not work, get overlooked or minimized. Second, there are issues of integration. We have diverse needs so when a project comes up for approval it’s not enough to assess that project; you have to look at linked projects across the whole business. Third, there is the political interference. Sometimes we get told to go ahead even though we aren’t really in a fit state to do so. If there’s an international collaboration agreement, the scope of the work is set by that agreement, whatever we think it ought to be. Sometimes the political pressure is so great that we have to approve the project through the gate review even though it’s not in a fit state,

and then later try to rectify it, forking out more money in the process, or killing it off. Quite often we may get it right at the main gate but then later events and decisions conspire to send our plans off course. Conditions we imposed to authorize the go-ahead may get rewritten or ignored as the job proceeds. Our performance is improving but overall it’s still woeful because of these rogue projects that get through. We have to keep going because there’s no better alternative. An important aspect is to address the whole life cycle and not only the main gate. The earlier gates, where we approve the strategy and confirm the business case, are also very important. In the early stages we need to make sure we invest in work to understand the technology – to ‘taste’ the later stages before we make the irrevocable investment decision. We also need to continue the review process through the later project stages, revisiting earlier decisions. Most importantly we need to be stricter, imposing our will more strongly, at the main gate. We must get it right at this step, even if it takes years, which it sometimes does. And obviously, in all these areas, we have to work hard developing the competence of our staff so that these ways of working get ingrained in the thinking of the organization.

Tony is speaking here with the voice of a corporate controller. He is the agent of an executive group who are struggling with problems that seriously threaten their reputation, and his role is to prevent the rogue projects. It may appear that his process is failing to meet this aim – that the rogues are continuing to escape – but he has no alternative. His sole purpose is control, and this system, designed for control, is the only one he has. However much he may optimize the process and

48

MAKING SENSE OF PROJECT REALITIES

the capabilities of his staff, it is unlikely that his additional controls will deal with the main problems, because these are political, embedded in the organizational context in which he lives. We can also hear hints that his efforts to hold back the rogues are also provoking the opposite effect; stage-gate constipation may be preventing the timely emergence of sound non-rogue projects. To provide a contrast with Tony’s control-driven example, we will consider a brief example that focuses on people and standards.

PROJECT EXCELLENCE The Narrator: Heather, an External Consultant Her Story The role I have been given is to bring project management excellence into the company. Senior management are very much focused on their primary responsibility, which is strategic planning and policy. It is then the job of the various departments to implement the policies and plans. However the senior managers have become very concerned that delivery has not been what it should be, and that sound policies are being subverted by faulty implementation, and so they have introduced a project management initiative to put that right. Consultants were brought in, and they did a lot of work on setting the standards to be followed and providing training courses, but the take-up was very patchy. Some department managers had even instructed their staff not to read the standards in case they led to over-complication and slowed them down. The essential shift I introduced was to bring the department managers into the equation. We made it clear that project management wasn’t just something imposed from

outside, and that they were responsible for how it was implemented in their own area, tailoring the standards to suit if needed. We also brought in structured responsibilities. Department managers must now perform the gate reviews for smaller projects, reviewing and challenging what their people are doing. Larger and critical projects are reviewed by senior management but the department managers must present their projects at the review. This means that the training can now be pointed directly at supporting people’s management responsibilities. Project management is now something they use, rather than a theoretical model imposed from outside. Even so the change is quite a jolt to the culture. In the past these managers have had an antipathy to such a hands-on approach to management. They prefer to give an instruction and only get involved after it has gone wrong, and they aren’t used to having their own plans challenged by their senior managers. The switch to the discipline of life-cycle management is a difficult adjustment for them to make.

The approach in this example appears to contain a more balanced mix of management actions: standards, capabilities and structured controls. Heather’s voice is essentially one of development. Her aim is to develop the capability of staff and managers at all levels to fulfil their project roles. However we must note that the standards and the training alone were not enough. The inherent

M A N A G I N G M U LT I P L E P R O J E C T S

49

value of project management as a management technique was not itself a sufficient cause for the discipline to be taken up; in fact it was resisted. The driving force was the demand for accountability: that the department managers should become responsible for the success of the policies devised by the senior managers. When managers found they had to answer for their projects to higher authority then the ability to apply effective project controls became an imperative, overcoming even the most entrenched laissez-faire culture. We have seen in these examples why it is that organizations with distributed projects introduce structured management and standards. They are driven by their needs to protect themselves from poor rogue projects that will drag down their performance and reputation. We have also seen that the standard approach, and particularly the stage-gate system for life-cycle management, is a necessary part of this structure, but that there are continuing issues about its effectiveness. The bad projects still get through, and good projects turn bad aer the approval process is completed. In most cases there is also an absence of any feedback loop, which in any other application of process management would be considered to be an essential feature. Projects pass through the controlling gates and out into free space. There is no motive or will to reflect, to learn how beer to set up or review the next similar project. The system is amnesiac: the mistakes of one department, of one year, are doomed to be repeated in other departments, or even in the same department in the next year. The main problem, as recognized by Tony above, concerns integration. A project may be in gestation in department A for some time, developing its strategy, perhaps with significant investment of effort and with a strong emotional aachment, before it is formally reviewed by central management at a main gate. At that point an interaction with an embryo project in department B may become apparent; they may overlap or be incompatible, or the sum of the two may not be sufficient to cover the needs of the strategy of the organization as a whole. At this stage negotiations are unlikely to be easy, and the projects get late adjustments, oen poorly thought-out. Changes are made to distort department A’s project so it may look compatible. It might be argued that department A should have consulted with department B. However their factional interests may militate against full consulatation, being best served if they consult only as necessary to defend their own project. The stage-gate controls on distributed projects therefore only manage what is presented to them, which will be the projects emerging from the silos of the individual departments. If the aim is to deliver a central organization strategy, something stronger and more coherent is needed.

50

MAKING SENSE OF PROJECT REALITIES

STRATEGIC POWER In the cases so far, the initiative has come from the peripheral parts of the organization, warranting control by the senior managers at the centre. If the organization executive are themselves driving a programme of change, it is unlikely to be achieved in this mode. The initiative must come from the centre.

DRIVING RADICAL CHANGE The Narrator: Thomas, a Transformation Manager (now retired) His Story I was recruited by the BigBank to drive a major programme to transform the way their businesses operated. They had a new CEO who was determined to make a difference. The changes had been promoted by the previous CEO, over a period of several years, and were well recognized, so our first thoughts were to identify the projects already in hand and check how they were going. The results were amazing. We found over 300 projects in hand, of which only 30 had been delivered in the past year. They ranged from the trivial to major investments that appeared to go on for several years without clear end points. They had all been vetted in the sense that business cases had been produced and submitted to the executive for approval, but as a collection they made no sense. If you summed all the claimed savings we would soon be running the bank on zero expenditure. The figures were clearly nonsense. We were spending a large proportion of our turnover on these projects and yet could not get an honest view of the potential benefits or of the progress to date. Despite the expenditure levels some critical projects were underresourced. Others had little relevance to the intended transformation and were clearly the pet projects of individual mangers. Others were being duplicated and run competitively by separate divisions.

The solution was quite simple. We withdrew funding from all projects other than those approved personally by the CEO. The criterion for continuing a project was that it had to be viable (time, cost, delivery) and directly contributing to our strategy. We identified a programme director in each division and brought them into a coordination team that assessed each decision and made recommendations to the CEO, who then wielded his executive axe. We cancelled 75 per cent of the projects and redeployed our resources to the others. For the projects on longer timescales we divided them into manageable chunks that could be closely monitored. We ran this for two years and made enormous strides, successfully enhancing our services by bringing in major changes that had been snagged for years, and we started some new radical initiatives that were equally important. The end was very sudden. The CEO moved on and a new high-performing CEO was poached from a rival bank. I took the opportunity to have an early meeting with him so I could explain what we were doing, and show him how advanced we were in BigBank in our philosophy of programme and project management. But he couldn’t understand it. ‘I’ll tell you my management philosophy’, he said, ‘it’s JFDI, just do it! I appoint the best people with the best

M A N A G I N G M U LT I P L E P R O J E C T S

ideas and I expect them to get on with it.’ He couldn’t fathom why someone like me should be employed at all, outside the formal hierarchy of the organization but presuming to exert control over his managers, restricting their freedom to take the initiative. He obviously thought I was an interfering busybody. Within days the programme directors in the divisions had been reassigned to ‘useful work’. My role, which I had thought was

51

fundamental to company success, had evaporated into thin air. Most of the projects continued. We had done the necessary shake-out and those remaining were basically sound and had their own momentum. I don’t know whether they were completed successfully; I didn’t hang around to find out.

Thomas is here speaking as the agent of a powerful CEO, an executive with a mission. His agenda is that of a strategist, to get a grip on all work connected to the transformation of the company, hammer it into a coherent shape and drive it to a successful end. Perhaps one of his most striking powers is his authority to act over the heads of the division managers, and to close down anything perceived as non-essential, so that all resources are assigned to work that contributes directly to his vision of the transformation. This is an example of programme management in a strong centralized form. The projects exist only because they are components of the programme of work that will deliver the strategy. A key feature is the systematic evaluation of all projects against the chosen criteria. In this example the criteria concern viability against the traditional project aims of meeting requirements for time, cost and delivery, together with a test of relevance to the corporate strategy. Other criteria are oen employed in this evaluation process; for example, desirability, feasibility, risk levels, resource demands, market value, etc. There is no single answer; the criteria to be applied must depend on the strategy. This picture is in contradiction to the mainstream explanation of the development of programme management, in which organizations are presumed to become expert in the management of projects before they move on, as their capability improves, to the more advanced capability that is programme management. In fact it is the programme to deliver the strategy that is formed first: project management then follows as a supporting discipline, and in a form that sustains the programme. We can find many examples of business transformation programmes where the required projects are conceived before there are any people available with the capability to manage them. Those given the responsibility will then find out and absorb the necessary tools and techniques, introducing project management in its subservient role in the service of strategic management.

52

MAKING SENSE OF PROJECT REALITIES

The final dramatic events of Thomas’s story also warrant our aention. In mainstream thinking, the introduction of programme management is invariably presented as being progress, and organizations adopting such methods are considered to be displaying additional ‘maturity’. Here we have seen that this ‘progress’ may in fact be very fragile, and that it can evaporate at a moment’s notice. Thomas’s second CEO may possibly see progress in the abandonment of programme management. For him, maturity means trusting his creative initiativetaking managers, liberating them from unnecessary central management controls. We have now considered two ways in which organizations handle multiple projects. In principle an organization may run both these forms at the same time: distributed projects that address the aims of peripheral managers, together with strategic projects that are critical to the organization as a whole. In both these styles, the organization has a continuing main operational business. The role of the projects is to create some change in how these operations are performed. There are however some organizations in which the projects themselves are the main function, and these need a different approach.

PROJECTS ARE OUR BUSINESS An excellent example of a type of business run through the medium of projects is the development of new drugs in the pharmaceutical industry.

KEEPING AHEAD OF THE MARKET The Narrator: Stephanie, a Portfolio Manager Her Story Our work in PharmaCo R&D division is to develop new medical products. At any time we might have a portfolio of 60 to 80 projects in hand, at any stage from the initial market assessment to the final piloting of the product. Our resources for this development are limited, and we are therefore perpetually making decisions on priorities, and specifically on whether particular projects should be dropped. The decision process is very complex, taking account of market conditions, likely time to market, commercial

valuation, likely spend to completion, and risks that the project may not deliver a viable product to the market. We also have to take account of the likely returns on our investment, for example the length of time we may be able to successfully exploit the product in the market, and whether our competitors are likely to be ahead of us or behind. We also try to maintain a balance of projects: high and low risk, short and long timescales. Decisions to terminate a project are common, and can take place at any stage, even when the drug is completing its final pilot testing.

M A N A G I N G M U LT I P L E P R O J E C T S

All these factors are very complex and dynamic, depending not only on the state of the project itself, but on changes in the market. We therefore run a highly structured evaluation process, with stages and gate assessments, and systematic risk calculations – for the project and for the market. We believe we have optimized this process over the years, but we still have problems, especially concerning the quality of our real-time information,

53

project slippage (for example the need to repeat studies) and changes in strategy. We also find that despite our intensively analytical approach we still have to take enormously important decisions – worth many millions of pounds – on a gut-feel basis. In the end it’s those decisions that differentiate us from our competitors and it’s what our senior managers are paid for. If they get these wrong they don’t last long. It’s still a very risky business.

The approach described in this story constitutes portfolio management, which concerns the systematic handling of the portfolio of projects that comprises the business, making decisions on priorities and the commitment of resources. The particular approach to information tracking and decisionmaking is highly specific to the industry and its context. Stephanie’s explanation of their activities is given with a voice from the world of businesses and their markets. Her concern is for the day-to-day business: the critical investment decisions that position the company in its market and determine whether it will be successful. In this sense this example is a departure from our previous examples. In those, there was some higherlevel demand from a powerful group whose agenda – to gain control, to drive change – demanded the introduction of a temporary set of actions in the form of projects. In this new example the business portfolio and the procedures to manage it constitute the actual business of the company. They have been put in place to look aer the performance of the whole enterprise in its market environment, and are a permanent and stable feature of its operation. Another feature of this industry, which clearly drives the need for the processes to be intensely structured and analytical, is its high level of business risk. Every day the senior managers take critical decisions which determine the future both of the company and of their own careers. One of the functions of the highly systematic mode of analysis is to replace personal decisions, subjective and highly anxiety-ridden, with decisions that are collectively owned and process-driven, effectively dehumanizing decisions that may be uncomfortable for an individual human. Despite this, those at the top of the game will still find that they sometimes must take daring gut-feel decisions, because it is these, rather than careful analytical plodding, that have the

54

MAKING SENSE OF PROJECT REALITIES

potential to take them beyond normal levels of performance and make them big winners. In portfolio management the details of the decision process will depend on the type of business. For example, in the UK nuclear industry structural changes have led to the establishment of government agencies and commercial suppliers whose function is the decommissioning of industrial sites that have radioactive contamination. The business of these organizations comprises the projects needed to restore the sites to a stable and safe condition. The project tracking system is again concerned with strategic priorities, resource allocation and with project costs, timescales and risks. Rather than being concerned with delivery to a commercial market, however, the projects are assessed in terms of their contribution to the desired end state – the restoration of the sites. Another difference in the nuclear industry case is that it is also dealing with a contractual interface. The strategy is devised, owned and managed by a central government agency, which then imposes it on distributed independent contractors. The management approach therefore takes on some characteristics of typical programme management (which is the terminology used in the industry), being formulated to measure and control (and sometimes punish) these contributors. Because portfolio management in an organization is an established and stable practice it brings with it an extensive local vocabulary. There are numerous types of projects, some generic to most examples: high-risk, lowrisk, low-hanging fruit, mission-critical, speculative, etc. There will also be local terminology. In the case of nuclear decommissioning, for example, there are oen high technical risks which may impose delays, with a consequential impact on the deployment of resources. We therefore find risk-reduction projects (for example technical investigations) that will endeavour to prevent such unplanned delays, and also flywheel projects: projects that are spinning and ready to go, to which people can be reassigned if the main project on which they are working is delayed.

MANAGEMENT OF PROJECTS – SUMMARY We have now completed our tour of the approaches adopted in organizations to handle their multiple projects, and seen that different approaches have different purposes: controlling risks in distributed projects, driving a coordinated strategy, or making decisions on priorities and resource

M A N A G I N G M U LT I P L E P R O J E C T S

55

commitments across the business. The common factor, the critical value that these techniques bring, is transparency. Decisions about projects – to continue, to approve, or to cancel – which would otherwise be personal, local and oen hidden, become collectively owned and open. Decisions may be supported by careful analysis or they may be based on subjective judgement, but they are part of a visible defined process. For many this collectivization of responsibility is valuable, replacing personal decisions, and their associated anxiety, with a process-based system of management. Others see this as a loss, imposing an array of requirements for bureaucratic controls and authorizations, restricting management creativity and personal initiative and responsibility. The practices reinforce the power of executives and strategists to impose their control, but in doing so they detract from the power of other managers to act independently. In mainstream project thinking, these different forms of management are presented as stages in the development of capability – a journey towards maturity. However, we can now see that this is an erroneous view. The adoption of techniques is determined by the nature of the organization and its business, and on the state of power relationships between executive teams and the distributed parts of the organization. There are important elements of ProjectCra in this area. As with all tools and techniques, the methods for the management of multiple projects can be picked up from a manual and learned and applied in a short time. A more significant ability concerns understanding the organization and its needs, and being able to recognise the types of management practices that will meet them. ProjectCra practitioners who are more socially aware will also recognize that the techniques deployed in organizations to oversee projects are determined by a pendulum of power, swinging between central control and peripheral independence. As this pendulum swings in the direction of centralized corporate power, astute project players will add their know-how to the forces driving its motion. As it swings back they will know to step out of the way, and move on to sell their professional wares in a more favourable environment. The main tangible benefit (or contribution to the forward swing of the pendulum) claimed for these management approaches is that they reduce the incidence of poor projects, but we have seen that they oen fail to do so. The most important question facing us therefore concerns how it is that rogue projects

56

MAKING SENSE OF PROJECT REALITIES

can subvert the best management practices, geing approval and investment and rolling onwards despite what are sometimes appalling inadequacies. This we shall now consider.

CHAPTER SEVEN

Fraudulent Projects ON THE ORIGINS OF DUBIOUS PROJECTS Despite strenuous management endeavours to prevent them, dubious projects still abound. Their continuing existence is detrimental to efficient working and to the delivery of intended outputs, and damaging to the reputations of the project mode of working and to those who practise it. The widespread belief that project management has ‘failed’ is sustained by the evidence of dubious projects. To investigate this phenomenon we shall look at some unhealthy examples, considering, in particular, the context of social interactions that breeds them.

FRAUDULENT PROJECTS Some projects are so blatantly out of step with reality that we must classify them as fraudulent. A fraud has occurred when something is not what it purports to be. If a piece of paper purports to be a banknote but is not, then it is fraudulent. If a project purports to be delivering an elephant but is in fact delivering a hippopotamus, then it is fraudulent. If a project purports to be delivering a sports stadium, on a particular date and at a particular cost, but cannot possibly do so, then it is fraudulent. Within this category of fraudulent projects I am not including projects that are plainly incompetent or insane, created out of ignorance or stupidity – they do not need any special explanation. Some frauds arise out of an act of collusion. If two or more parties deliberately conspire to mislead in order to gain advantage or to cheat others out of their rightful rewards, then that is collusion to commit fraud. Such frauds are a maer for the police, and are not my concern in this book. Frauds can arise, and do so, without the prelude of collusion. In the examples well-meaning honest and competent groups of people will, between them, create projects that are fraudulent.

58

MAKING SENSE OF PROJECT REALITIES

RESEARCH INTO ESTIMATING PRACTICES The Narrator: Joyce, a University Researcher Her Story We are a leading academic institution, performing research into the practice of project management. Our philosophy is to maintain strong links with industry and thereby ensure that our work is grounded in the real world and useful to practitioners. A couple of years ago we started out on a project to investigate estimating practices in a local industry. We had three industrial partners, who agreed to let us have access to their data and contribute to the development and testing of a tool that could be used to improve the accuracy of estimates. We made a proposal to a research council, based on the principle of this collaborative investigation, and they agreed to fund the project. Unfortunately, not far into the research programme, there were some changes in the partner organizations. One of the responsible managers moved on, and his replacement hadn’t the time to participate. Another partner’s company was involved in a merger, and this work was no longer of interest to them. The third was just never available to speak to us. Perhaps he never had any real intention of participating. I suppose you might expect these things to happen; these are live and dynamic organizations. All the same I think we were unlucky to lose all three partners. We had to decide what to do. In principle

we could have gone back to the research council and offered to close the project. However we had completed our initial data collection and had some information we could use. It seemed more prudent to maximize the value of this information by performing our own analysis to see whether we could reach any conclusions. Some observations emerged, so rather than lose them we went into publication. Obviously we didn’t have the industrial input we would have liked, and we didn’t produce the estimating tool originally planned, but our output is a valuable contribution to the theory of estimating, and has enhanced our reputation as a top-notch research team. The grant from the research council was therefore spent on funding our publications, rather than on developing the estimating tool, but when we delivered our final report the council seemed not to have a problem with the outcome. Our work had contributed to their targets, which were about levels of funding for research, and they had received a full report. The fact that we had departed from the proposal was of no concern. In fact I would go further and suggest that had we taken a different course, withdrawing from the project or attempting to renegotiate, we would have received no gratitude. Such action would more than likely have jeopardized our prospects of getting funds for future research.

According to our earlier definition this is a fraudulent project. It purports to be a collaborative project to develop an estimating tool for the benefit of industry. It is actually a project to collect and publish data for the benefit of the university, on whose behalf Joyce speaks. Initially it may have been otherwise; we will give Joyce the benefit of the doubt and believe her assertion that there really was a shared intention to complete the collaborative project.

FRAUDULENT PROJECTS

59

By the time the industrial partners have withdrawn, however, the fraud is established. It is important to my argument to note that within Joyce’s story there is no apparent victim of this fraud. Neither the research council nor the industrial partners have any complaint concerning the outcome. The real victim is in fact the taxpayer, whose contribution to the advancement of industrial capability has been diverted for the benefit of academia. The victim has no voice in this story. Some may consider this to be small fry. Here is a bigger fish.

BIG DEALS IN DEFENCE The Narrator: Roy, an Engineering Manager His Story I used to work for a big contractor in the defence industry. We believed we were world class in our particular area. Several years ago we bid for a project worth several billion pounds. We had been doing projects like this for years and from our in-house experience had a very good grasp on what it would cost. We avoided the temptation to bid low because we didn’t think we needed to; there was no credible alternative supplier. However the Ministry of Defence had instructions from the Treasury to bring in competition, and they found another bidder. This other company had little relevant experience but they put in an offer. While our proposal was based on doing everything in-house, making use of our established competence, theirs involved buying parts from untried suppliers all over the world and only doing the final assembly in this country. It wasn’t a credible plan, and so we were horrified when they were offered the contract; they had put in a price that was about 30 per cent lower than ours. We were facing enormous redundancies and devastation to the local community. Then

the politics kicked in, and after some manoeuvrings we were given another chance, but on the basis that we would accept a firm price 30 per cent below our original offer. Our Managing Director returned from the negotiations and called a big meeting. All the managers were there. I remember his words well. ‘This has been a difficult time for us,’ he said, ‘but we can pull through. I have put my faith in you managers by accepting a deal that will challenge us all, but I know you can do it. It’s now up to you to respond to my trust, and deliver the job at that price.’ We had a day of discussion groups, looking for ways it could be done. In the end, however, there was only one item on the table, and that was new technology. New IT systems, computer-aided design and concurrent engineering practices were going to take us to new levels of efficiency. If you asked anyone in the company whether they believed this argument they didn’t answer, but shook their heads: ‘We have to believe it. What else can we do?’ What surprised me most was the alacrity with which this was taken up. We have

60

MAKING SENSE OF PROJECT REALITIES

very rigid stage-gate procedures that require the CEO of the parent company to sign off the plan, which he did with scarcely a pause. The client nodded their approval and added a sub-project to implement the new technology, to our scope. I moved on soon afterwards, but not because of this project. I wasn’t surprised a few years later when it was announced that the project was overspent by 30 per cent.

‘Another defence project overspent and out of control’ proclaimed the newspapers. The explanation? It had ‘experienced unexpected problems in implementing the new IT systems’ for which the client accepted some culpability and was going to pay the extra. There was no alternative. Too much had already been invested, and cancellation would have been devastating for the local community. Well I never! What a disgrace! They should never have got away with it.

Whether or not we classify this as a fraud depends on whether we think there was any honest belief that the technology project could realize the cost savings claimed for it. On the evidence above there was no assessment of the savings that could be achieved. Nobody believed the plan was valid. The project was fraudulent. As before, there is no obvious collusion, and no incompetence. The interactions between the different parties have resulted in a fraudulent project. As before, all parties appear to be satisfied with the outcome, although some explanatory posturing is necessary to preserve their dignity. As before the taxpayer is the victim, and has no voice in the story.

PROJECTS ARE NOT THE ONLY AGENDA We discussed earlier the fact that projects do not come into existence of their own volition, but are responses to other more powerful agendas. It is not always the case that these agendas are compatible with good project management practice, and if not, the consequence will be that project practice becomes distorted. A typical scenario concerns the treatment of some ‘pet’ projects in the public sector, which I shall refer to as dog-day projects. Every dog has his day. Some ‘dog’ projects also have their day. Many managers have, in their desk drawer, a pet project they have devised. It is in their drawer and not the public arena because it is not wanted. However, some untoward event occurs and the politicians, having an urgent need to take action, demand a plan. Our manager opens the drawer and pulls out the pet project. Could it possibly be made to look like an answer to the new demand? If, with some minor revisions and a rewriting of the business case, it can be put forward, then the dog’s day has come. Whatever flaws had earlier made the project unviable are now amplified

FRAUDULENT PROJECTS

61

by the distortions made to fit the new need, but it will now be unstoppable. A dog-day project is born. Such projects invariably fail. For example, a civil service department may have a plan to produce a new database, which they believe may make their day-to-day operations easier. However, the risks are high, the technology is not advanced, the benefits are uncertain and they cannot get funding approval. However a new political commitment is then made, perhaps in the fight against crime or terrorism, and a way is found in which the database can appear to contribute to this commitment. All pressures will now conspire to approve the new database, which will now go ahead. The deficiencies in the technology and uncertainties in the benefits are as great as ever, if not more so, but concerns about these are unlikely to resist the political momentum now propelling the project forward.

THE TYRANNY OF ANNUAL BUDGETS For management teams in many organizations, especially in the public sector, the requirement to control annual budgets takes precedence over all other considerations. Usually this will be compatible with the aims of project management, both being concerned with bringing work to completion within allocated budgets. On the other hand if the budget is underspent then distortions may occur. Examples are very common, for instance the unnecessary road projects, built despite there being no good case for them in order to spend annual budget that would otherwise be lost. Sometimes this is not a major problem, equivalent to the flywheel projects – spinning and ready to go – that arose in our discussions of portfolio management. If the projects are themselves valid then so is the practice of bringing them forward into this year’s budget. More seriously, the budget-year agenda can lead to distortions in existing projects.

DON’T STOP NOW The Narrator: Robert, an itinerant Project Manager His Story I was engaged as a project manager, on contract, on a large industrial site. They had problems with obnoxious chemical waste which they had to move into new storage, and they needed to procure some new engineering plant and storage tanks to transfer the materials. On the day I

started, Gareth the Projects Director pulled me into his office and laid down the law. ‘We’ve overspent in the past because of not getting things right before placing contracts with the suppliers’, he said. ‘We’re now operating a strict stagegate review system, and I want everything in order when you come for the reviews. No excuses!’

62

MAKING SENSE OF PROJECT REALITIES

Early in March the work was approaching the main review, at which approval would be sought to place the external contract for design and supply of the new plant. I was determined to make sure there was nothing that could go wrong but I was worried about the materials specification for the pipework and tanks. I consulted a chemist friend, and I found that my worries were well founded. The materials for the plant weren’t compatible with the chemicals to be transported. It would have to be rethought. I reported the problem to Gareth, thinking he would be pleased the problem had been discovered before the money was committed. That was what he had asked for, but he wasn’t at all happy and the reason soon became

clear. Look at the date! The funds for the contract were in the budget for the current financial year. If the contract wasn’t placed before the end of the financial year the funding would be lost and would have to come out of next year’s budget, and that was already committed. ‘Get it through the review’, he told me, ‘no excuses!’ and being on contract I knew that if I didn’t follow his instructions I would be out. At the review I glossed over the problem. I knew the job would cost more this way, and take longer, and so did he. He didn’t seem to mind. The extra work would be discovered downstream and the additional costs could be covered by the site contingency fund. Everyone was happy, but I had picked up a black mark for trying to rock the boat.

These examples typify some of the more prevalent forms of dubious project. Their common aribute is their ability to circumvent the normal processes of project veing.

SOCIAL TRANSPARENCY Dubious projects such as I have described above are not unusual aberrations; they are very common. The traditional response is to demand that more aention should be paid to conforming to the norms of good project lifecycle management. Proper veing will prevent improper authorizations and so those responsible should be sent for training to impose their veing skills. This is flawed logic. The people who are being requested to conform to project norms are already conforming, but to the norms of the practice group to which they belong or which has hired them. These practice groups are powerful, and each project, ever subservient to this power, takes a form that responds to their agenda. The people who create frauds and other dubious projects are doing exactly what is expected of them. There is a significant step we could take to improve the practice. When discussing the standard methods used to control the initiation of projects we observed that the essence of these methods was transparency; decisions that would otherwise be personal, subjective and hidden now being openly

FRAUDULENT PROJECTS

Project

Main party agenda

63

Subsidiary party

Industrial partners

Taxpayers

Estimating tool

Academics research papers reputation

Declared project

Approve funds

Research Council fund allocation reports

FRAUD

Publish papers

Report

Actual project

Figure 7.1

Social interactions – a fraudulent research project

displayed for process-based collective evaluation. If we now recognize that it is the social interactions between different practice groups that create dubious projects, we may correct that effect by exposing these interactions, making them transparent in the decision-making process. A possible form of transparency would be a social interaction diagram. For example, in the case of the fraudulent research project it might look like Figure 7.1. On this diagram the main parties are those practice groups having the power to determine the nature of the project. I have also noted the long-term agenda that they pursue. The subsidiary parties are also identified, but to keep the diagram simple I have not included their interests since these do not have any impact on the outcome. The most important message displayed by this diagram is the fact that both versions of the project, initially declared and later fraudulent, are valid in the eyes of the main participants. Both versions advance their interests. The replacement of the non-fraudulent version by the fraudulent version

64

MAKING SENSE OF PROJECT REALITIES

was triggered by the withdrawal of the industrial partners, but the change is essentially a switch from one plausible vision of the future to another equally plausible vision. The main difference is that the first version supports the original decision to award the funding, whereas the second is concerned with outputs – papers and reports. The elements of this diagram have much in common with the information included in a conventional stakeholder analysis. However, it is more tightly focused on those maers that lead to the distortion of the project: the interests and dealings of the parties who form the project. This type of simple diagram could be produced for our other examples, and in principle is a useful analytical tool, but we must ask who would make use of such an analysis. It has the aura of an outsider view, a technique that could be used by our helicopter pilot to collect information about the terrain from his loy vantage point, but is it of value to those fighting their way through the hazards on the ground? In our examples, Robert, dealing with the chemical waste project, could see the threat but could take no evasive action. More especially Roy, whose story exposes the seing up a fraudulent large defence project, speaks to us from the comfortable distance of hindsight. He takes a moral stance now, but he was an active participant in the fraud at the time it was formed. Then and now his possibilities for action and speaking are constrained by his position of the moment: corporate manager then, freespeaking pundit now. Participants in fraudulent projects have good reason not to declare the actual version of the project. Those who would wish to map and expose the social interactions underlying dubious projects can only have an impact if they can align themselves with an identified victim and act as their agent. Typical victims might be government departments, public pressure groups or banks who are providing funds. However it is oen difficult to identify a tangible active party whose interest could be furthered by bringing it to the foreground and revealing the undeclared version of the project. In most dubious cases the main parties are content with the misshapen project they have created. It is the fact that the victims are subsidiary and voiceless that discourages analysis and hence makes it easier for the fraud or distortion to proceed. It seems to be inevitable that project practitioners, employed by the main project parties, will continue to fulfil their roles as project shapers, creating stories about the objectives of their projects, sometimes declared, but sometimes fraudulent.

FRAUDULENT PROJECTS

65

TOWARDS PRAGMATIC ACTION The picture so far has been painted in rather black and white terms, as though projects must be in one camp or the other: honest and open or fraudulent with undeclared objectives. However, potential projects cannot simply be divided into right or wrong, sound or dubious. The real project world is painted in varied shades of grey. Every project is pervaded by unknowns, and every project that starts out with the best and clearest of intentions is vulnerable to being reshaped by subsequent events into something different. If outside observers sometimes find that the outcome was not what they had expected they may well think they have been misled, or even defrauded. The role of those of us responsible for projects, versed in ProjectCra, is to create a plausible story of what the future might be, and how we might proceed towards it. This story may well be coloured by honest optimism, but we should not be penalized for striving for something new, difficult or uncertain. On the hill, in the mist, we may sometimes have to step forward confidently along a rocky path in the hope that it will take us out of the cloud and to a new summit. Sometimes the story that sells the project may stray beyond the grey of extreme optimism towards the black of deception and fraud. On the other hand many projects later recognized as a great success have contained some element of fraud at their inception. It is possible that the ugly project dismissed as a rogue and smothered at birth may have been our best hope. It is not good enough to take the moral high ground and declare oneself to be against dubious or fraudulent projects. Those who took part in our dubious stories might argue that the directions they took were the only pragmatic routes forward, and they may be well right. The conventional approaches to the control of projects i.e. life-cycle management and stage-gates, are deeply problematic in this respect. At the root of these problems is a management fraud, the world of the management of projects. Its systems and practices purport to control, and yet the rogue projects regularly circumvent that control. The only way forward is to disown this illusion of mechanistic control, and to cultivate beer awareness of the surrounding less tangible issues. If a high level of certainty is necessary, then veing systems must be enhanced, exposing the interests and interactions between all parties, and bringing those with vested interests actively into the decision process. If, on the other hand, we have a project that is taking us into unknown territory, but

66

MAKING SENSE OF PROJECT REALITIES

we live in an environment of strong control, then the most obvious strategy is to adopt a fraudulent position: to present our plans as definitive and make absolute promises of delivery. We should resist this temptation, and be explicit about and accept the unknowns, the diverse interests of different parties, the potential for shis in the scope of the project, and even the likelihood of failure. If a project is dubious, then instead of hiding its problems in a project fraud we can examine the nature of its dubiousness, consider the alternatives, and choose the most pragmatic option.

CHAPTER EIGHT

The Language of Projects The ways in which we think about projects are currently framed by the wellestablished language and terminology of the mainstream discipline of project management; defined in many books and guidance documents produced by the custodians (the priesthood) of project management knowledge and their allies. However, this terminology is too narrow and restrictive. As we have already seen, we need to be more flexible in our thinking about the forms that projects may possibly take – different models will suit different situations. In this chapter we will explore some projects that take us beyond the standard form, and look at the concepts and language we need to explain them.

THE MAINSTREAM LANGUAGE OF PROJECTS Much of the terminology used in the standard project management literature stems from the basic definitions of a ‘project’ and of ‘project management’. The following composite definition of a project, compiled from a variety of sources, incorporates the most common concepts: A project is a collective endeavour to accomplish a specific objective, through a set of well-defined tasks, by a specified date and within a specified budget. The absurdity of this definition is that no such entity ever existed. Humans do not behave like this. If endeavours are collective, then they involve several parties whose objectives will be diverse and not specific. No real task was ever well-defined, and every project involves a mass of chaotic activity that was never predefined, well or otherwise, in any task. And what of collective endeavours for which the completion date or budget is not clearly specified? Are they not projects? The concept embodied in this definition is idealized and entirely hypothetical. The addition of the term ‘management’ to form the core concept of ‘project management’ is equally problematic. It reinforces the idealized notion that each project somehow exists as a given objective entity, and that all we have to do is somehow ‘manage’ this object. The basic metaphor embodied in these definitions is that of the production line along which the project passes, having mechanistic operations performed on it, towards its ‘specific objective’.

68

MAKING SENSE OF PROJECT REALITIES

Why has so much effort been devoted to the generation of a definition for an entity that is fictive? In fact the concept as defined has important uses. There are times when we should use this Utopian vision as a statement of aspiration. I shall therefore coin the term ‘project-perfect’, and adapt the definition as follows: A project-perfect is a hypothetical concept that defines idealised ends and plans for a collective endeavour: a specific objective, a set of welldefined tasks, a target completion date and an authorized budget. Most of the other terms central to the standard glossary of projects flow from the mechanistic definition of a project. When we speak of the things associated with projects – a business case, a stage-gate, stakeholder management, a work breakdown, a Gan chart, a resource plan, a risk register, change control – we are participating in a culture that takes the production-line model as its starting point. All these terms represent artefacts produced as part of our endeavours to bring work activities under control by aligning them with the illusory projectperfect. If our aim is to improve our handling of projects by recognizing more diverse forms, then the existing terminology is deficient, both in terms of its nouns – defining projects and their associated artefacts; and in terms of its verbs – the things we can do to deal with them. Like an ill-fiing corset, these terms constrain and contort a project into an idealized and unnatural form.

PROJECTS IN THE COMMUNITY In order to develop some other possibilities for project language we must look for some other, contrasting, concepts of what a project might be. To this end we will consider two examples that take us, quite deliberately, to the other extreme, and into territories where projects are less constrained and more malleable.

CIVIC PROJECTS The Narrator: Charlotte, a Director of City Branding Her Story I used to work in arts administration, but for the past three years I’ve had a high profile job looking after civic projects in this city. In the past the city has had an image dominated by industrial decay, but recently we have made big strides towards

establishing ourselves as a good place to be – a city with an exciting future. If we can create the right ethos then that will act as a magnet, drawing in businesses and cultural organizations, and attracting ambitious and enterprising people to come and live here.

THE LANGUAGE OF PROJECTS

My role is to lead the development of projects that will create our new city branding. We are interested in iconic projects that will take us on the journey towards our new identity – projects that will epitomise our ideals and support a narrative of what we are, and where we are going. They might comprise all manner of possible ventures: buildings, sports facilities, sporting events, sculptures, or arts festivals and events. Mine is essentially an enabling job. I see myself as a searcher for acorns – seeking out the ideas that can germinate and grow into something big that will make a difference. We can’t prescribe what we want. We have to take ideas and proposals that we can find, and help people to develop them, shaping their plans into a project that will emerge and make a valuable contribution to the new city. Then we approach the city fathers to ask them to back the project, and the funding bodies – for arts, for sport, for regional development – to persuade them to throw their weight (and money) behind the project.

69

Our biggest risk is that a project that sounds really promising and attracts funds will then fail to live up to its rhetoric. You have to work constantly to ensure an outcome that is satisfactory for the city. For example we built a new sports stadium that we believed would attract a national event, but for reasons beyond our control that didn’t happen. We then had to look for different uses and alternative events to make the investment look worthwhile. We can’t tolerate a failure, because that would cause irretrievable damage to our image. If we are in difficulty we have to redefine what we mean by success. We renegotiate the project, redefining the deliverables and what we expect from them. Everything we support has to be seen in terms of how it is taking us onwards. It’s an interesting job because you are never quite sure how your plans will evolve – what ideas will come in through the door, and where they will eventually lead. That’s what makes it exciting.

SOCIAL PROJECTS The Narrator: Stewart, a Social Entrepreneur His Story I work for a large charitable organization in the voluntary sector. I deal in social projects. In terms of their basic hardware my projects are mainly about the recycling of equipment: taking items that are being discarded by consumers, or industrial plant coming to the end of its commercial life, and putting it to new use to help the needy, locally and overseas. For example, we have taken over some IT equipment being thrown out by a local bank, and used it to set up an IT centre at a hostel for the homeless,

and we have delivered used industrial refrigeration plant to a hospital in India. We have also taken part in some major waste recycling projects. Whatever the hardware might be, our overriding aims are social, and our focus is on our impact on people. We seek to build social capital, helping people in a variety of ways: relief of poverty, helping the disadvantaged, protecting the environment and providing employment experience for those who have difficulty finding jobs.

70

MAKING SENSE OF PROJECT REALITIES

These principles have a profound effect on our approach to project management. The projects need cooperation and support from many people: transport providers, people who do the refurbishment, owners, those receiving the goods and many others. Our policy is to be inclusive, bringing the disparate groups into partnership, and deliberately giving authority to disadvantaged groups of people who elsewhere would be disempowered. By involving this wide range of stakeholders we also prevent the more powerful stakeholders, such as the banks who provide the funding or the industrial companies who provide the goods, from taking control of the agenda.

We run the projects though a form of umbrella management. We set up partnerships, seek out novel approaches, look for resources and funding and generally unblock any day-to-day problems that arise. However we don’t dictate how things will be done. Strategies and plans emerge from the parties delivering the project, and we encourage them and help them along. Timescales tend to be open-ended. Our projects are dynamic, creative and flexible. You have to provide the space for these ideas to take root and come to fruition. A focus on project deadlines does not encourage creativity, generate social capital or build cohesion: in fact it does the opposite.

Each of our two speakers is the agent for a group of people following a powerful agenda, but one that is loosely defined. These groups have a need for projects as vehicles for progress, but their needs cannot be met within the principles of conventional project management. There is a stark contrast between these mainstream principles and the philosophies enshrined in our examples of community projects. Whereas the mainstream projects are concerned with planning and control to achieve a tightly specified end point, the community projects are organic, growing and developing in an unstructured way, to achieve aims that are unclear and negotiable.

VECTORS OF DIVERSITY It is tempting when faced with this contrast to declare an allegiance to one position or the other. There are some who will incorporate these examples into their political manifesto for a revolution in which the oppression of managerial power will be overthrown. There are others who will detect a flavour of anarchy in cases such as those I have presented, and assert that a more rigorous application of best-practice project management could have made the delivery more efficient, more timely, or more successful in meeting targets. Both of these parties will expect the rest of us to make our choice. ‘Are you with us or against us?’ Do you support project management, or do you support autonomy? Both positions can be defended, but rather than support one or the other, my aim is to bring the discussion of these possibilities into the language of

THE LANGUAGE OF PROJECTS

71

project management, so that practitioners can choose to take whichever line is the more pragmatic option in any particular circumstance. We may broadly categorize these two camps under the headings of the ‘control’ model and the ‘organic’ model, but there are in fact many associated dimensions along which projects can be seen to vary in their form. In Table 8.1 I have ordered these dimensions, or vectors, within a simple three-stage project life-cycle model: formation, implementation and assimilation. The control and organic models constitute two vastly different conceptions of what a project can be. In the former we use the project’s artefacts – its specifications and plans – to define what it is, and then aempt to control its outcome through the preset operations of the production line. In the laer we create a space defined by possibilities – of engagement, actions, outcomes – within which the project can take form and grow. A fundamental mistake in much conventional project management is the emphasis on constraining that which should really have space to grow. These endeavours will inevitably fail. There is a need to follow the project vectors towards the right-hand side, and to recognize and adopt the thinking embodied in the organic form. This recommendation must not be taken as a call for all project work to take on the organic form. The converse argument is also valid. A fundamental mistake in much non-project management is the emphasis on empowerment and providing a space for growth, when there is a clear need to nail down, organize and deliver something that is known and tangible. Our hope here is that those who would normally apply formal ‘control’ project management everywhere might be persuaded that there are moments when they should relax their grip and think in terms of the organic model, and also, conversely, that those who would normally steer clear of formal project methods may be persuaded that there are moments when tighter specification and control will be of immense value. In real project situations, of course, there is a continuous movement between the two opposing poles of the vectors. In Charloe’s story above, she is searching among a plethora of unclear ideas and proposals for suitable projects, however ill-defined they might be: a notional scope emerging from a context of diffuse power. In subsequent phases of these projects, however – the construction of a sculpture, the preparations for a public event – there may well be moments

72

MAKING SENSE OF PROJECT REALITIES

Table 8.1

Vectors of project diversity

The Control Model

The Organic Model

Project formation: its conception and birth. Integrating the strategy for the project with those of the organization and stakeholders. Expressing the project as a solution to known problems. Conceptual ideas and their potential application. Concentrated power. Power held by one or two parties, who make covert decisions and private deals.

Diffuse power. The formulation of the project is open to discussion and agreement with diverse parties. Decisions are made by broadly based partnerships, which make overt and transparent decisions.

Bounded scope. The content is fixed and well specified, having clearly defined limits.

Notional scope. The content is understood only in broad terms. It is open to challenge and can be influenced by outside parties (permeable).

Detailed strategy. The plans and the resources to be applied are fully defined.

Conceptual strategy. Plans exist only in broad conceptual terms.

Sequential. Each stage is finished before the next starts. The scope and form of the project are fixed before it is implemented.

Iterative. The project continues to be re-formed throughout implementation stage. The scope and strategy are subjected to serial reshaping, evolving in response to the changing external context and to the process of self-discovery within the project itself.

Implementation: structured work to deliver the outputs of the project and other outcomes that are direct consequences. High-stability scope. The boundaries of the project are fixed, unproblematic and not in dispute. The function of management is to prevent change.

Low-stability scope. The content of the project is contested and open to change. Its boundaries are permeable. The function of management is to encourage and facilitate change.

Centralised control. The autonomy of participant individuals and organizations is limited by a controlling management.

Distributed control. Participant individuals and organizations are semi-autonomous, empowered to act as they see fit under umbrella management.

Predefined plan. The tasks to be performed are pre-agreed (i.e. by some form of contract) with the controlling managers, who monitor progress and compliance with the plan.

Creative plan. Tasks are performed in accordance with the conceptual scope. The work performed is flexible, and evolves in response to changing needs.

Bounded resources. Groups of people, in specified disciplines, are given approval by management to work on the project, as and when their efforts are necessary for the delivery of the defined tasks.

Open resources. Groups participate on their own initiative as and when they believe they can contribute to the holistic needs of the project.

Structured relationships. Roles and responsibilities are defined formally in organization charts and job specifications.

Fluid relating. Responsibilities and relationships evolve in response to the demands of the work in hand.

Assimilation: the continuing impact of the project on the organization’s operational practices, and the consequences of the project for the wider world. Tangible output. The project ends with the production of specified goods or the completion of defined services. It is judged on its completion to the specification: time, cost and quality.

Social impact. The project makes continuing contributions to society: the development of social capital, benefits to the wider community, contributions to learning. The project is a source of new ideas and new projects.

THE LANGUAGE OF PROJECTS

73

when the need to control expenditure or meet deadlines will require an environment of high-stability scope, centralized control and a predefined plan. Similarly, Stewart the social entrepreneur may sing the praises of his openresources labour force, operating under distributed control in the shade of his umbrella management, but he will occasionally need to transform himself into Stewart the controller. Otherwise he will find that his diverse stakeholders are less than happy if he does not ensure that the transport vehicles and a sufficient number of people to move the refrigerators arrive on site on the same day. In following the journey that is a typical project we should expect to see a number of shis: between the organic and the controlled, between the creative and the precise, between the open and unlimited and the bounded, between a loosening and a tightening of management control. Rather than characterizing any project as being either organic or controlled we should instead see a project as a series of zones of control: project-perfect islands of rigour and clarity, set in the midst of a sea of creativity and ambiguity. Mainstream control-based project management methodology is only of value during our brief stays on such islands of certainty. We can only get to these islands if we also have the more flexible ways of thinking – the ProjectCra – to find our way from one island to the next. The concepts of the organic model are the most important elements of that wider thinking.

This page intentionally left blank

CHAPTER NINE

Creating Project Sense MAKING PROJECT SENSE We will now turn our aention to the actuality of project life: how people handle the experiences that projects thrust upon them. We are not concerned here with the normal productive elements of work: how people go about being designers, service providers, soware developers, construction workers, or whatever. Our interest is instead with the project environment and how it gets shaped. In mainstream thinking about projects this question is addressed through the components of a project plan. The plan is considered to show what people are expected to do. We can therefore examine their activities through that lens, assessing the extent to which their work complies with or departs from the plan. If we are sceptical about the quality of plans, we might also look into the planning activities at the front end of the project, and whether they produced a sound and viable plan. This approach, however, constrains our thinking within the bounds of the production-line model of projects. We define the processes performed by the project-perfect machine and then, like quality controllers, monitor its performance. Rather than follow that line of enquiry, our interest here is to look at how people deal with projects, and how, in consequence, a project develops through its life. In our consideration of these issues we will take a particular stance. We will discount any notion that people are somehow victims of the project, passively accepting what they are given by their managers and, like machine components, following (perhaps inadequately) the course of action defined for them. Our approach, instead, is to consider project players as sense-makers. This general concept of sense-making is a valuable general perspective on behaviour in organizations. Sense-making is a social process through which collectively people interpret the complex situations in which they find themselves and the events that impact on their working lives, to construct forms of sense: explanations of how things are. It is this constructed sense, the local shared understanding of what is going on, rather than the orders and practices laid down by managers, which underlies how individuals go about their work. In essence, then, we will consider people in projects as actors striving to cra their preferred versions of the reality of projects.

76

MAKING SENSE OF PROJECT REALITIES

The concept of the reflective practitioner, introduced in Chapter 2, is closely related, being concerned with how practitioners reflect on their situation as a basis for action. ProjectCra is effectively the project-specific equivalent of generalized reflective-practitioner capabilities. The collective version of sense, constructed and prevailing in a project situation, will inform the actions of ProjectCra practitioners. Conversely, a critical capability for those of us proficient in ProjectCra will be our ability to understand the processes of sensemaking in our local organization, and to make effective personal contributions to the making of project sense. This can be a demanding occupation.

PROJECTS WITH A DRUMBEAT The Narrator: Bernard, a Project Manager His Story I work for a large multinational manufacturing company with facilities in the UK and elsewhere. I call myself a project manager. My job isn’t like the book version, which is about project execution – administering projects that already exist. That’s not a very interesting job as far as I’m concerned; someone else can do it. My job is to make projects – to get them up and running in a highly complex environment. We do actually have a project management manual, but it’s only 20 pages long and hardly profound. I can’t say that I look at it very often, because it has little relevance to what I do. Not only is the company multinational but our products are multinational; different components are manufactured in different countries, and assembly could take place anywhere. So we have national management teams, we have functional management teams, we have product management teams, and we have customer management teams, looking after the interests of different client groups. We work through a matrix

system. Some people have two, three or four bosses. The need for a new project usually comes from the customer teams, who have identified that we need to make changes to a product to keep our clients happy. I then have to negotiate the project specification with everyone else. It has to be clear, meet the clients’ needs, and be agreed by all parties. It’s no use overriding disagreements because you must get everyone on board. If people are against some facet of the project, their opposition will sap the project energy and it won’t succeed. Once we’re into manufacturing we can’t afford to change course, so you have to do everything possible to get it right at the start. Then your projects will run through with everyone playing together: projects with a drumbeat. So how is that done? Basically you have to get people aligned. You can’t use hierarchical control, because the structure is so complex. Responsibilities are never clear, but you have to seek out those with influence, the supporters of the project and the potential blockers, and then talk to them. You have to find their boundaries – what they can do and what they cannot

C R E AT I N G P R O J E C T S E N S E

possibly do – and understand how these limit their possible actions. Decisions are always made by consensus; the project manager doesn’t actually make any. It’s all down to personal influence, and for that it’s your credibility that counts – not your job title or your place in the hierarchy. The whole process is very time-consuming because it needs a full personal interaction with every party. You can telephone people, but in my experience only about a quarter of agreements made by phone actually stick. Emails are no better. You really have to talk to people face-to-face, get to know them, look into their eyes to find out what is on their minds and understand their position, and that takes time and lots of effort. We have meetings galore; in some weeks my diary contains nothing but wallto-wall meetings. When you need to get agreement between several parties

77

there’s no other route. The meetings are large and chaotic, and can go on for hours or sometimes days. Most of those attending have other interfaces with other departments, or need to check their position with their bosses, or the clients, or with their technical experts. Even while the meetings continue they can be on their mobile phones or using their laptops to check their emails. Again, it’s not how the textbooks say you should hold meetings, but we treat it as normal and necessary. Otherwise there would be unfinished business: critical information would be missed, decisions wouldn’t hold. What I’m trying to emphasize is that the creation of a sound project is a very human process. You can follow procedures to the letter, and still end up with a project that’s doomed to fail. We actually do quite well on delivery, but it’s all down to the efforts we put in at the start.

Bernard speaks on behalf of a practice group who facilitate the front-end of projects. Their allegiance is to the organization as a whole and to its business success. Their function is to create product-development projects that will work, both for the overall business and also for the large number of parties who have a stake in them. However, while Bernard’s group are acting, as shapers, to create a project that makes sense in terms of its contribution to the overall commercial strategy of the business, each of the other parties is, at the same time, making sense of the embryo project in terms of its integration into their own local area of expert practice – how the project fits with the interests of their tribal domain. What is the source of Bernard’s power to decide what the project will be? He has no hierarchical power over those he seeks to influence. His power emanates only from his ability to negotiate something acceptable to all, from his expert knowledge of how to carry out negotiation in this territory: his knowledge of the people and their interests and motivations, what they can take and what they can’t, of the organization and its politics, of the normal daily course of events, meetings and phone calls, and of how he may generate and sustain the intensive interactions that are necessary to achieve his aims.

78

MAKING SENSE OF PROJECT REALITIES

This sense-making process that Bernard is driving is essential to the success of the business. A large number of parties must collectively find a coherent path. There is a high level of risk: investment of resources that may go to waste, clients who may be alienated. They therefore need a high level of belief that all parties are in agreement and can trust each other to support the project. The intensive discussions are essential to this end. They constitute a process that takes the organization from having what is initially an organic project, with diffuse power (with no direct hierarchical control) and a notional scope, and converts it into a controlled project, with a tightly bounded scope from which a predefined plan can be put together. Through this process they can create their island of clarity and commitment – a project with a drumbeat. This specific example of project sense-making may not be entirely typical, but it incorporates four characteristics that I believe are fundamental. First, project sense-making is social and partisan. Second, it is enactive, in that shared sense is achieved not through abstract ideas but through the creation of artefacts that are tangible (i.e. they can be inspected). Third, it is dynamic, ongoing and potentially unstable. Fourth, the making of project sense is driven by individuals, developing their personal identities as players in the world of projects. In the following sections we shall discuss these characteristics in turn.

SENSE IS – BASED ON GROUP POWER In Chapter 4 I introduced the principles of social interaction, a perspective through which we can view projects as the product of collusions between diverse practice groups with partisan interests. The power to shape the sense of a project rests with such groups, and the version of the project that emerges represents some form of resolution of the contest between their different interests. The energy and initiative of individuals such as Bernard, and others we have met in previous chapters, are critical to the formation of the project, but they can only act through the power they possess by virtue of their membership of their practice group. This power may reside in various parts of the organizations performing projects. Oen there is some form of concentrated power: Powerful single group. There may be a group who have the authority to define the project regardless of the views of others. In Chapter 4 we heard an example in pensions administration, where those responsible for the corporate finance agenda took control of the project scope and redefined it over the heads of

C R E AT I N G P R O J E C T S E N S E

79

the nominal managers of the project. In Chapter 7 we heard an example of a research project, where the university department had full autonomy to revise the project purpose to suit their own ends. Two-party deal. The project scope is commonly negotiated between a client sponsor and a supplier organization from whom the delivery of the project is commissioned. Together they can agree a contract that defines the project. Note that the sponsor may not be the ultimate user of whatever the project may deliver, and there may also be user groups that have a significant interest in the project. The two-party deal between the sponsor and delivery groups can be a powerful means of excluding the voices of users, or other interested parties, from the project agenda. Both of these forms have the power to defend their boundaries against unwanted external intervention. However, the power may also be diffuse: Multi-party alliance. We have heard two very contrasting examples of diffuse power. Stewart, the social entrepreneur in Chapter 8, opened up his projects to a wide alliance of participants, but controlled the project strategies within his own team. Earlier in this chapter, Bernard negotiated his projects among a large number of managers within the matrix organization. The project team itself may not comprise a viable power base. We observed in Chapter 4 that the project is called into existence by the powerful practice groups, and that the project itself is both temporary and subservient to the agenda bringing it into existence. However, for longer projects, such as large construction projects, there is oen a desire on the part of the project team to take control of the project agenda, first in hopes of increasing the stability of the project scope, and second because their semi-permanence enables them to establish themselves as a practice group in their own right – the expert practitioners on their particular project, secure from challenge from less expert external groups, whether customers, users or others. Less permanent project teams or partnerships oen aempt to control the project agenda, but without such a sound basis for their authority they are likely to fail. For example Robert’s project team on the pensions administration project in Chapter 4 aempted to define the project agenda in terms of a new administration system, but they were overwhelmed by the power of those pursuing a different agenda, that of corporate finance. Furthermore, we oen see project cooperative alliances and partnerships, set up with the best of

80

MAKING SENSE OF PROJECT REALITIES

intentions, later subverted by the concentrated power of the commercial agenda of one or two of the main parties to the alliance. Whatever the power structure that underpins the project scope, we, the skilled ProjectCra practitioners, must be able to analyse and understand the relevant parties and the relationships between them. We must be able to identify which parties can exert their authority to shape the project agenda, and which cannot. We must be able to understand the thrust of the primary project agenda, while also recognizing that the peripheral parties to this project have their own diverse purposes that may sometimes support the primary agenda and sometimes be in conflict with it. To achieve this capability we need to understand the agenda and power of all parties. This cross-group understanding will itself depend on our ability to cultivate strong face-to-face relationships with people in other groups, across demarcation lines, and oen into the territories of our competitors or enemies.

SENSE IS – ENACTED Because the definition of a project emerges from a complex human and social process, it is inherently lacking in stability. Any version of what the project purports to be will be challenged as different groups manoeuvre to promote their tribal interests. The project, as we observed when discussing complexity, is not real, but is an invention created to make sense of an otherwise chaotic world. It can be reinvented. To gain any stability of purpose, we must act to make the project appear real, and this is achieved through enactment. Essentially an enacted project is one that is visible. The vision of the future that is promised by the project can be seen, inspected and queried through the medium of the artefacts that have been created. If, to invoke the commonplace, ‘the facts speak for themselves’ then the best strategy to ensure our own view of the project holds sway is to create some incontrovertible facts that can speak on behalf of the project. We have already seen many examples of enactment. Three general forms are evident: Documents. Many of the project documents we produce in accordance with standard project procedures, such as specifications and plans, are forms of project enactment. Documents are, of course, easily rewrien, and so the version of reality they define is susceptible to challenge and change. We will enhance their legitimacy as best

C R E AT I N G P R O J E C T S E N S E

81

we can, for example through having them approved by senior management or through a stage-gate process, but the fact remains that they are mere paper (or data files). This represents a significant rethinking of the purpose of project documents. The mainstream view is that they are its plans, produced solely in the interest of good practice in management control. Yet this purpose is rarely borne out in practice: people do not usually follow plans. When we consider them instead as enactments, then our decisions on what documents to produce, and when to produce them, are fundamentally changed. The need for plans will be determined not by our need to instruct others or to follow laid-down procedures, but by our need to enact – to create artefacts. If we, as project managers, have agreed a delivery date with a group of people outside the project team and we are less than confident in their good faith, then we will update and publish our plans immediately. If we know and trust the other party, a handshake may be a beer confirmation of the agreement. In general, the less confident a project’s managers are in its agenda and its security, the more energetic they will be in the production of paper. While the conventional wisdom is that continuous updating of project documents, to keep them current, is sound practice, we can now take an alternative view: that such behaviour is evidence of vulnerability and a lack of confidence. Excessive generation of paperwork perhaps indicates that those in charge are insecure, aempting to stabilize positions that are inherently unsustainable. Hard product. A more concrete form of enactment, one that can speak clearly of the future promised by the project, is ‘hard’ product. Since for many projects the ultimate ‘hard’ product only appears towards their conclusion, we may find ourselves having to invent some early substitutes. Possibilities include prototypes, or the early delivery of small but key parts of the project. For engineering or construction projects it might be a scale model; for IT projects it might be the implementation of a database of a small part of the system; for an organization change project it might be a move to a new office, or the establishment of a new organization structure ahead of the implementation of new practices or soware. It might be argued that these items are intermediate deliverables, and would be produced as part of a logical mechanistic project plan, regardless of any concept of project enactment. My argument here

82

MAKING SENSE OF PROJECT REALITIES

is that this enactment can exceed that needed to support a purely logical plan, or may be produced on a much shorter timescale. The project could be done without the model or the prototype, but the enactment of such objects enhances the visibility of the project: securing its content, displaying its outcomes and creating a much needed drumbeat that could never be achieved through a mechanistic plan. Fast Enactment A works director in the motor industry recognized that his company was missing out on the market for convertibles. He went down to the production plant and asked the chief engineer when he could have a prototype for a new model. ‘If you authorize me a development budget’, said the engineer, ‘I could probably put an outline design together in a month or so, and then, depending on the time taken to get executive approval, we should be able to have a prototype ready in under a year.’ ‘You have misunderstood me,’ replied the director. ‘I want you take a vehicle off the line now and chop the top off.’ Why would the director want this? His prototype will probably be completely unsuitable. Yet his plan has two big advantages: the project to produce a convertible is established immediately, and it’s under his own control.

Referring back to our earlier discussion of the power of project teams, we can see now that the key factor is their ability to enact hard product. For a project team to exercise control of the direction of the project they must have the capability to define and design the key enactment products – the prototypes, the models, etc. – whatever their form. Leaders. Leaders are people who somehow exemplify the project vision. Their essence is that they can tell us, with authority, what the project must be. A person who acts as a project leader in this sense is normally expected to have suitable aributes: a position of hierarchical authority, a charismatic aura, an ability to make inspirational pronouncements in public, a profound understanding of the project. However these are not essential. Unprepossessing people can find that they have inadvertently become leaders. Leaders can find that views they have never expressed can become, on their authority, built into the project. The essence of being a leader in this form is that the position has been conferred on you by others. You

C R E AT I N G P R O J E C T S E N S E

83

become a leader not primarily because of your natural charisma, but because others believe you to be a leader. The ProjectCra practitioner will wish to ensure that an appropriate leader is in place to exemplify the project and its form – to act as its face to the world. There may be obvious candidates. Ideally there may be a recognized project sponsor who can perform this role, and who may indeed be the person who has hired the project manager. In the absence of such a person, those engaged on the project will seek out an alternative enacted leader. Sometimes the project manager may endeavour to play the role if that is compatible with his or her personal plans. ProjectCra practitioners will also exercise their skills to make good use of a project leader to support the version of project sense they wish to establish. Leading and Leaders For the purposes of the discussion I differentiate between ‘leading’ and being a ‘leader’. Much writing on organizations conflates these and other concepts under the general abstract concept of ‘leadership’, presented as an attribute possessed by leaders, and something we should all strive to acquire. I understand the two concepts separately as follows: Leading. A verb (participle). Something one can do. Those who take a prominent role in the activities I have described as sense-making can be understood to be doing ‘leading’. People who are good at shaping and enacting effective forms of project sense are good at leading. When pundits propose that everyone should be involved in leadership, this is a form of leading that anyone can attempt. Leading is an essential capability to be learned by anyone aspiring to be expert in ProjectCraft. Leader. A noun. Something one can be. A person who is a project leader is the ‘face’ of the project. To be a leader one has to be recognized as one by others. A person’s potential to be identified as a leader is primarily in the hands of others. The charismatic attributes commonly associated with leaders can aid this identification, and help the leader look the part. On the other hand, however, those who take pride in themselves as leaders should perhaps not forget that dead kings and stuffed animals have, on occasion, been effective leaders.

A variety of forms of enactment are therefore available to the project practitioner. In practice many people tend to be limited and compartmentalized in their approach to enactment, preferring one form or another, and they should perhaps be advised to expand and diversify their enactment repertoire. Those who devote their energy to producing accurate and carefully documented plans but li
le else may oen find a demoralizing absence of understanding of those plans among their colleagues, who may find them less than inspiring,

84

MAKING SENSE OF PROJECT REALITIES

and may even not read them very carefully. Visionary leaders may acquire great admiration and generate commitment, but then find themselves embarrassed and undermined by a deficient practice or an object that stands in contradiction to their position. To produce the coherent drumbeat of a successful project we must enact it in all these forms – audible and synchronized. Without being prescriptive we might consider that different forms of enactment may be appropriate in different phases of a project. While the project’s strategy is primarily conceptual and under discussion then a human leader can epitomise the project’s aim. During productive phases documented detailed plans and agreements can serve to maintain the chosen course. As the project approaches completion, visible hard product will focus efforts on a coherent outcome. All three forms can be considered as forms of leadership, applied successively through the course of a project: human leadership, document leadership and object leadership. These arguments are, of course, all directed towards the production of a project that is solid and secure – a project with a high-stability scope under centralized control. The aim of the central managers is to promote a single uniform understanding of the project. They will produce all manner of enactments – leaders, documents and objects – to discourage any visionary thinking in the peripheral parts of the organization. In enacting their project they are creating a rigid structure in the hope that ‘structure sticks’. In some contexts, however, fluidity may be preferable – a low-stability scope. In these situations the opposite advice applies. Over-enactment of the project will limit its possibilities. A casual comment dropped by an overzealous leader can be transformed into an immutable part of the project; plans and contracts signed off too soon can kill off essential flexibility; a too-early prototype can destroy the possibility of be
er options. In these circumstances documented plans, hard product and leaders are all part of the problem: we should avoid them.

SENSE IS – UNSTABLE AND DYNAMIC The sense prevailing at any time within a project is not stable. It responds to a changing world. However, change is not steady and continuous, the constant feature of organizational life. We cannot select a point on our project vector between high-stability and low-stability, and expect to proceed at our chosen rate of change.

C R E AT I N G P R O J E C T S E N S E

85

In practice, projects experience periods of relative stability, when those involved may successfully hold to a defined plan, interrupted by periods of instability, when significant shis in plan can be expected. This period of instability may be part of a deliberate strategy, an opening up of the project: a switch from a period of bounded scope to one of a notional scope in which the strategy is permeable to wider influences. More oen the sudden instability is unintended. While some managers may welcome change, there are more who will have change thrust upon them. A useful perspective on these dynamics is the dramatic concept of peripety. This term was used by Aristotle to denote a point in the plot of a play when the arrival of some new information transforms our understanding of what is happening on the stage. Peripety in Oedipus Rex Aristotle quotes the example of peripety in Sophocles’ play, Oedipus Rex. In this play the progress of the drama is transformed by the arrival of a messenger. Acting only with benevolent intentions he informs Oedipus the king that his parentage is not as he had previously thought. This news has a dramatic effect. Until this point the gist of the play has been to discover who had murdered Laius, the former king. From this point onwards the gist of the play becomes the quest to identify Oedipus’ parents. This quest sets events in motion towards the tragic conclusion. Oedipus discovers that the old man he killed in a skirmish was actually Laius, who was his own father, and that Laius’ widow Jocasta, who he married on becoming king, is his mother.

The significance of peripety is not merely that there has been some change in fortune, a twist in the plot, or an untoward event. Something has appeared which leads us to reframe fundamentally our understanding of all that has gone before. The changes are not only to the outcomes, but to the questions that frame our thinking and plans. Aristotle notes that the agent of peripety, the ‘recognition object’, may be a human messenger, but it may alternatively be an inanimate thing of the most trivial kind. The message is delivered without there necessarily being any intent on the part of the person or object delivering it. In development projects, peripety oen occurs at the moment when the purpose of the development work (the plot) becomes clear. While early work may be confused, with different parties searching for possible options and pursuing different ideas, later work becomes focused on the delivery of an agreed solution to an agreed problem, with a clear plan of how to get there. It is oen a prototype that acts as the recognition object, crystallizing a

86

MAKING SENSE OF PROJECT REALITIES

preferred option and exemplifying the direction of subsequent work towards completion. A similar effect can be seen in the city branding projects presented by Charlo
e in Chapter 8. In these the question of how to promote the city is suddenly transformed, by the arrival of an unexpected proposal, into a question of how to complete a defined artistic project: to put on a festival, to erect a sculpture, or whatever. Peripety is not confined to the later stages. In our example in Chapter 4 we saw a peripety take place at another key moment – when the decision to commit the investment was to be made. Before this moment, Robert’s project was conceived of as a pensions administration project, its question being: ‘How can we improve our administration?’ Aer the appearance of messengers from the office executive (prompted by their decision to commit funds to the project) the project was reconceived in terms of corporate finance, its question becoming ‘How can we set up the pensions fund for quick and efficient financial dealings?’ This is not, however, the only peripety that occurred on this project. More were to follow as the temperature rose when the project neared completion.

A TRIBAL PROJECT  COMING TO A HEAD The Narrator: Robert, an itinerant Project Manager His Story My project in the Pensions Office of DivCo was progressing reasonably well, following its early difficulties and change of plan. We had set up the new database and we had appointed the new administration team, the people who were to operate the new system. However there were some problems on the technical side: some of the data processing software was late, and we were having trouble with ‘dirty’ data when we started transferring the data from the old system to the new. None of this was unexpected – all recognized on the risk register – and we had a timescale contingency of around four months which was more than adequate to cope

with the problems. So the delay wasn’t a big problem, and Keith, the Chief Executive, was quite relaxed about it. But the atmosphere among the other directors changed. They started referring to ‘your project that’s late’ at executive meetings, and we weren’t getting the support we needed from the administration team. Keith and I tried to address this by introducing an organization change, transferring the responsibility for getting the new procedures running to the administration team. The stand-alone project team had had its day; it was time for the users to take centre stage. At the same time we completed the transfer of the data.

C R E AT I N G P R O J E C T S E N S E

The result was dramatic, but not what I had hoped. Belinda, the Administration Director, concocted a new plan through which the system would go live on the originally planned date, but without any of the software to perform the financial transactions. They would use the delivered database, but operate it manually. By this means they claimed that they had rescued my ‘failed’ project and could claim ‘success’. Keith overrode my objections and they set off on this new route. This was a disaster for my plans to complete the original scope. I had no resources; everyone was working on Belinda’s partial version of the project.

87

However they had only got as far as preparing their plans when the external auditors visited, and asked to audit the management of the project and its handover into live operation. We had always believed this audit would be done at the end of the financial year, after everything had settled down, but now, quite suddenly, it was imminent. The prospect was too frightening for the administrators, and so they put off the handover to live operation. Keith realized that the safer option was to wait for the full software, and that’s what we did. We satisfied the auditors, and went live two months late against the original programme, as I had predicted.

This project experienced peripety at least three times, each reframing event being heralded by a messenger and followed by intensive enactment of the new project reality. Table 9.1

Peripety table – a pensions project

Old question: How to …

Messenger(s) and recognition objects

New question: How to …

Enactment

Create the best administration system?

Corporate financial agenda. Review of investment decision.

Facilitate financial transactions?

New scope – excludes administration automation.

Facilitate financial transactions?

Announcement of new organization responsibilities. Database available, but late software delivery.

Go live as soon as possible and claim success?

Procedures for operating the office using the database and manual administration – no administration software.

Go live as soon as possible?

External auditor, with plan for imminent audit.

Make an orderly transition to live systems – to convince auditors?

Live use of software. Management and test records.

The messengers who initiate a peripety can take a variety of forms. Some are from outside the project, while others are internal, arising from objects produced by the project itself.

88

MAKING SENSE OF PROJECT REALITIES

What does this mean for practitioners? Is peripety merely something that happens to the project, or something we hope to avoid but which will afflict us from time to time, an unfortunate outcome from uncontrollable events? In fact, we can do be
er than succumb to this passive view. First, we must be aware that a recognition object – something incompatible with our current understanding – has appeared among us. In the theatre, of course, the dramatist can put the messenger in the centre of the stage to proclaim the significant news. In real life the situation may be less obvious. Once we have identified the messenger, we have an important decision to make. Will we welcome the message and encourage the change? There is no simple answer. There is a time to change course, and a time to persevere with our chosen route; a time to pause, raise our binoculars and scour the horizon for approaching messengers, and a time to plough onwards, focus on the work in hand, and shoot messengers on sight. As a general rule, the message that leads to a peripety appears at a significant project moment: the commitment to invest, initial deliveries, audit and handover. Experienced ProjectCra practitioners will, at these times, go out of their way to seek out such messages, believing it is be
er to receive them sooner rather than later when the disruption could be worse. In either case, we should move swily to enact the option we have chosen. If we have taken the message on board the project must then be reconstituted (and re-enacted) to establish the new version. In our example above, for example, Belinda’s a
empt to switch the direction of the project was not successful because she had failed to produce anything of substance before the next recognition object, the external auditor, appeared on the stage. Robert’s subsequent reclaim of the agenda, on the other hand, was sustainable because the audit became an immediate and prominent reality, which made his preferred final route to completion unchallengeable. In extreme instances of peripety we would also expect to review whether our human face of the project, the leader, can still fulfil his or her function. If we are se
ing off in a radically new direction, then perhaps we need to embody the new sense of the project in a new face – a new leader. The old leader may be too strongly associated with our old understanding of the project. A leader who is proficient in ProjectCra will recognize when this situation has arisen, understand that the position as leader is no longer tenable, and move on.

C R E AT I N G P R O J E C T S E N S E

89

Leaders less proficient in ProjectCra will need to be pushed. Astute project managers may see this as a good reason for not taking on the role of leader.

SENSE IS – DRIVEN BY IDENTITY CONSTRUCTION The three characteristics of project sense-making discussed so far – its origins in the power of social groups, its creation through project artefacts and its periodic instability – are social explanations of how project sense is formed. However, the driving force behind sense-making lies in the initiative of individuals. We observed in Chapter 5 that projectification – the drive to create projects – is dependent on the energy and decisive action of individuals. The same applies to the actual form that a project takes. In any project situation the individuals engaged in and around the project will be taking action to shape the project into a form that suits their personal interests and ambitions. Reputations are inextricably bound up in the outcomes of projects. Reputation, however, does not take some simple unitary form. Different people seek different forms of reputation, and not everyone wishes to be recognized as a project manager. Those who do may have widely different conceptions of what it means to be a successful project manager. In terms of ProjectCra, we practitioners need to be self-aware, fully conscious of what we ourselves are striving to be, and how that affects our aims for the projects on which we are engaged. This issue takes us away from our analysis of sense-making and into the realm of personal advice. I will therefore cover it separately in the next chapter. If we are to be effective in our dealings in this area, we must also be aware of the ambitions of others, and how they may intend to use the project to further these ambitions. This can only be achieved through relationships. If we look back at the example of Bernard, at the beginning of this chapter, we can see that he was only able to negotiate his ‘projects with a drumbeat’ by ge
ing to know people, face-to-face. His knowledge of the hierarchy, power and group interests was not enough. Many tracts about projects highlight the importance of ‘relationships’, but there is a danger that this ma
er can be treated too superficially, as though relationships are about being friends and ge
ing on with people. From a sense-making perspective a different emphasis emerges: the need to get so close to other players that we can look into their eyes and find out what they are about.

90

MAKING SENSE OF PROJECT REALITIES

CONCLUSIONS – PROJECT REALITY In Chapter 3, we considered the complexity of organizational life, and noted the role of projects and project management in forming clarity out of a life on the edge of chaos. But we also noted that conventional project management thinking is only one rather limited perspective we can use to make sense of that complexity. In this chapter we have taken the argument a step further. It is clear that during the course of a project, the documented plans that form the overt definition of the project are a very limited description of the actuality of life on that project. They present us with a picture devoid of social interactions, dynamics, dramatic turns or individual ambition. They ignore the sense-making that has shaped people’s collective understandings of what the project is about. A more pragmatic perspective can be found by considering these conventional plans not as the actual project itself, but as artefacts, created from time to time as part of the strategies of those engaged in the dynamic social processes that make sense of, and shape, the project. Furthermore, conventional plans are not the only artefacts available to skilled practitioners, who will have a far wider repertoire of enactment skills at their disposal to shape projects to suit their interests. Mainstream thinking on projects is also incompatible with the reality of projects described in this chapter in terms of its treatment of peripety. Despite the fact that most projects can be expected to experience several dramatic turns, the stage-gate approach to project governance demands that projects shall continue along the course defined and approved at each gate. In consequence, a project that should perhaps be undergoing a useful peripety may struggle blindly onwards, ignoring clamorous messages to change direction. Alternatively a project may succumb to peripetal pressure, take a unilateral turn that divorces it from its stage-gate approval, and so become a fraudulent project, out of alignment with the needs of the company executive and other stakeholders. The greatest deficiency in the mainstream model of projects is its treatment of people as automatons, engaged to perform the tasks assigned to them. The reflective practitioner is a more pragmatic model of human behaviour. Individuals on projects do not merely perform or misperform the tasks assigned to them. They perpetually scan a wide range of issues: their membership of groups, the struggles between different factions to assert their own version of the project, the dramatic changes of course and of fortune, and, perhaps above all, the personal ambitions of themselves and of others. These ma
ers are the currency of daily transactions in organizations, and we cannot understand the reality of projects without locating them in this world.

C R E AT I N G P R O J E C T S E N S E

91

The insights and guidance I have provided in this chapter are intended to help people, as reflective practitioners, to deal with this reality of projects in organizations. I hope that it may help people to create be
er projects, more compatible with their context, and more responsive to changes in that context. In a sense, however, this is a secondary aim, because I have now stated categorically that all project sense-making is driven by the personal ambitions of individuals. We will therefore now briefly turn our a
ention in that direction.

This page intentionally left blank

CHAPTER TEN

Personal Engagement The practice of projects is an intensely personal ma
er. Conventional project management thinking considers these personal aspects in terms of the progressive acquisition of capabilities. The practice of ProjectCra takes us beyond conventional thinking, but perhaps only taking us further in the same direction, adding reflective practitioner capabilities to the mechanistic knowledge and skills of conventional project management. There is, in this approach, a danger that we are treating ourselves as skilled robots, the sum of our humanity encapsulated in the sum of our knowledge of projects and our ability to perform. For real people working on real projects there are many different ways of experiencing projects, and of being project workers. Furthermore, many working people find they have difficulty being ‘project people’ at all in any meaningful sense. The question we need to address, therefore, concerns the manner of people’s engagement in projects. In the previous chapter I introduced the concept of identity construction as the primary form of this engagement. We will use this concept to explore how individuals experience and deal with projects.

IDENTITY When we discuss identity construction, we are concerned with how people wish to be seen, and how they go about ‘creating’ themselves so that they may be perceived by others in this desired form. In terms of personality it is useful to differentiate here between the ‘I’ – the person who is acting, and the ‘me’ – the part they are endeavouring to play. Identity is about the la
er. People’s identities are largely determined by the way in which they participate in social groups and in social practices. The way you behave displays, to others, what you are. For the purposes of this discussion we are specifically concerned with project identities – the identities people construct for themselves, and for others, as they go about their project business.

94

MAKING SENSE OF PROJECT REALITIES

PROJECT PEOPLE In Chapter 4 we identified some primary social groups – or tribes – concerned with the performance of projects: the project directors, seeking to impose project working within an organization; the strategists, using projects to achieve a strategic end; the project shapers, who negotiate and set the agenda of a project; the project deliverers, working to produce output; and the priesthood, acting as custodians of project management knowledge. These are very general categories. In practice, there is within each category a multiplicity of roles that people perform. The statement ‘I am a project manager’ is too general to define a person’s role or roles. To exemplify the diverse possible forms of identity, we will revisit a sample of our earlier speakers. Table 10.1

Diverse project identites

The Person

The Part He or She Played

Fiona (Chapter 2) the regional coordinator for a public service.

A programme manager, but in the manner of a facilitator, bringing people together to set up projects to deliver the strategy of her ministerial masters.

Robert (Chapter 4), the project manager at the pensions office.

A project manager (shaper and deliverer), but also an external consultant, a member of the company priesthood bringing project management to the management team.

Matthew (Chapter 5), the new project manager developing a new IT facility for government agencies.

An up-and-coming manager determined to show that he could deliver to order. To do so he also acted as a shaper, moulding the project into a form that he could be certain would be successful.

Thomas (Chapter 6), the transformation manager for a bank.

A programme manager and a ruthless strategist, acting on behalf of a powerful chief executive to approve or cancel company projects.

Joyce (Chapter 7), a university researcher.

Dedicated to the production of research papers, shaping and reshaping the project as necessary to protect her department’s aims.

Roy (Chapter 7), the engineering manager on a major (and fraudulent) defence contract.

The detached functional manager, looking after his tribal patch and observing, from a safe distance, the dubious manoeuvres of his senior managers

Stewart (Chapter 8), the social entrepreneur.

The social champion, strategist and shaper, doing good and being inclusive while at the same time taking political action to defend his plans from outside influence.

Of course this collection of people is not a representative cross-section of those who work on projects. I have granted them a voice in this book because

PERSONAL ENGAGEMENT

95

of their central project roles. There are others, many of whom have an antiproject story and construct for themselves identities that refute the validity of the project management model. We can see from the examples that a project role is not the totality of a person’s project identity. Identity also embraces how a person plays the role. Any actor may be engaged to play the leading role (or perhaps the jester), but each will present the role in their own particular way. I have assembled the summary statements above from the stories spoken by each person. I can do this because the forms of language used by these people, and the stories they tell, construct simultaneously both the sense they are making about the projects of which they speak and their own identities. Conversely, to be accepted as a player of a particular role, one must be able to speak the part convincingly, using the language and telling the stories appropriate to the role. For this reason the ability to learn a new local language is a critical skill for those who wish to reinvent themselves – to change their project identity. To be recognized as a project manager, one must talk like one. To be recognized as a corporate strategist, one must talk like one.

THE DYNAMICS OF IDENTITY In a project environment, all people will strive to ensure that projects take a form that supports the construction of their preferred identity. At the simplest level, if you wish to be recognized as a successful manager of the delivery of projects, you must ensure that the projects you are called upon to manage can be delivered successfully. Similar principles apply to other roles. The various parties to a project must negotiate their positions on that project – the nature of the project, and the terms of their involvement – to protect their identity. In the ideal world postulated in standard project management texts, this would be no problem: all parties would focus on making their projects successful. In the real project world not all parties have this objective, as we saw in many instances in our discussions of project fraud. To demonstrate their brilliance as the bringers of new business, marketing managers will negotiate contracts that cannot be delivered. To show their dynamism, civil servants will set off initiatives that are doomed to fail. In these situations, those who would be successful project managers must move with care. Among our performers above, we see that when Mahew was called upon to manage a project to develop a pilot IT facility he went to great

96

MAKING SENSE OF PROJECT REALITIES

lengths to renegotiate the scope of the project and the part that he was to play. Not everyone has this flexibility. Project managers, especially those responsible for delivery, oen find that the die has been cast before they are involved. Those who wish to maintain a strong reputation for success must avoid rogue projects. Fortunately for the purveyors of rogue projects there are usually other would-be managers who pursue an identity of a ‘company worker’ style, which they support by taking on whatever job they are asked to do. As well as negotiating our own identity, we join in the negotiation of the identities of others. When Robert joined the pensions department (his story in Chapter 4) the office managers told him quite clearly their expectations of a project manager: to prepare some plans, check the contract, write progress reports. This subservient depiction of his role was not merely a reflection of their ignorance. It was part of their strategy to protect their version of the project, and their own roles as its senior shapers, from interference. Robert refuted this identity, but not by contradicting the local managers. Instead he aligned himself with the executive team, remoulding the project to support their financial agenda, and in this way also promoting his own preferred identity as a senior consultant. By this move he also repositioned the office managers as subservient to himself. The term negotiation should not be taken as implying that there is a considered, rational discussion between mature and well-meaning equals. This is rarely the case. Negotiations can be directly competitive.

A BAD TIME FOR A HOLIDAY The Narrator: James, an Engineering Project Manager His Story The client had asked our company to prepare an outline design for some process plant for drying their chemical waste. It was quite a simple project, but in some ways quite novel, so I had gone out of my way to get Bill, our best designer, as my chief engineer. The work was well advanced, so it seemed a safe enough time to take a short break. After all, I hadn’t had a holiday in years. I sent out an email explaining the arrangements while I was away. Bill would be in charge.

The day before I went Murray the business manager called me into his office. He was in a very friendly mood, asking where we were going, so I knew he had some plan in hand. He waited until I was leaving the office and then let drop that he had asked Caroline, a newly qualified project manager, to hold the fort while I was away. I knew she was very ambitious and would want to make her mark. I tried to persuade him that it wasn’t necessary, but the arrangement had been made. ‘Don’t worry about it, she’ll just keep it ticking over’, he said. ‘Go and have a good time. You deserve it.’ I was furious – I knew it would go wrong.

PERSONAL ENGAGEMENT

When I got back from holiday I called a team meeting and asked how it was going. At first nobody wanted to tell me, but then it came out. My fears had been well founded. Caroline had discovered a mention in the client’s brief that they might, at some time in the distant future, wish to make the plant transportable, so it could be moved around and used at different sites. She had gone to the client’s engineer and persuaded him that we could make the plant transportable, and then returned to the office and made out that I had missed a crucial requirement. As a consequence they had fundamentally changed the design and we were now three weeks behind the programme. I was livid. I got Bill on his own, and asked him to his face whether there had been a transportability requirement. He

97

replied that Caroline had been in charge so he had to go along with it. Now Bill may be a good designer and an honest worker, but he has no head for politics. I couldn’t let her get away with it. Over the next three days I pulled together all the evidence into a dossier – the original brief, the correspondence, everything. I took short statements from the engineers on the job. I sent my dossier to the senior managers and demanded their support. How could I continue in my job if I didn’t have their complete trust? They had no alternative but to back me and accept that I had been in the right and that Caroline had deliberately misled the client just to make herself look good and me look bad. She won’t try that move on me again.

This lile drama is not very wholesome, and leaves an unpleasant taste, but it is fairly typical of how people behave. It is very easy, from the comfort of our armchairs, to criticize every one of the players. Even honest Bill, it appears, has used his distaste for office politics to avoid facing up to an obvious issue when it arose. If there was evidence that James could use for his dossier, why had Bill not shown it to Caroline at the time of her manoeuvre? In turning our aention from personal criticism to analysis, we must note that the story as told belongs to James. Senior managers may have been less than pleased with this contest, and may have objected to the time deployed on the compilation of the dossier, but the purpose of James’s story is to let us know the sense that he has constructed about the events. The outcome is, from his perspective, a success. He has been subjected to a personal aack, but has emerged with his identity as a fault-free trustworthy manager intact. He could not contemplate turning the other cheek. His whole working life is bound up in his reputation for being a sound project manager. We must also acknowledge the intensity of his pain. Dealing with the slur on his reputation is not just one more job to be added to the long list of tasks that he, as project manager, is supposed to do. Until the issue of his credibility is resolved it takes over his whole life. Personal defensive work must always take precedence over his other job, the completion of the project.

98

MAKING SENSE OF PROJECT REALITIES

It is difficult to have sympathy for Caroline, but we must remember that her own version of events will doubtless have a different slant. Newly promoted project managers do indeed have to make their mark. (We have seen them do so in earlier chapters, but were then perhaps less interested in the impact of their efforts on others.) In principle Caroline has followed a good strategy. She has created a peripety using the transportability requirement as its recognition object, and the client has been persuaded to act as messenger. Furthermore she has instantly enacted the new version of the project, incorporating the transportability requirement into the design before James’s return. The version of the project that proceeds towards completion is the one she devised. Despite the disruption caused, she has sustained her identity as a radical new manager who can make things happen. On the other hand the ill-will generated by these events is unlikely to help her prospects in the short-term. Perhaps, with the benefit of this experience, she will execute the move more adroitly next time the opportunity arises. Another highly competitive area is the bale zone between the forces for and against the supremacy of project managers. Here is a typical comment on project managers from an IT soware developer. I suppose they’re a necessary evil. They can keep the clients in order, and sometimes prevent them from making unnecessary changes to the specification. What I object to is the way they keep demanding plans and information. It makes absolutely no difference to the job. I have to keep explaining what we’re doing to them, but it’s just a waste of time because they contribute nothing. The negotiation here is difficult. The project manager feels obliged to take sufficient managerial action to fulfil his role, while the developer wishes to establish a project position in which she is unhindered by the project manager’s intrusions. There is no simple answer to this contest. They may try to negotiate a position along our project vector of controlling management – umbrella management. The position may vary between different project phases, or remain in permanent dispute throughout the project, a frequent occurrence if neither party can sacrifice their need to appear to be in control.

PERSONAL STRATEGIES There is a general lesson here for our understanding of ProjectCra. We have, in previous chapters, dealt with our need, as expert reflective practitioners of projects, to be able to ‘read’ the nature of projects in our organizations, and to act accordingly. If we now recognize projects as highly personal affairs, then we

PERSONAL ENGAGEMENT

99

must extend our reading skills to include the domain of project identities. This applies first to ourselves: to be able to recognize the possibilities for roles we might play and how we might play them. It applies secondly to our dealings with others: to be able understand the identities that others are seeking to construct for themselves, and to take this into account in our project negotiations. We must also recognize that for many players in project roles the maintenance of their reputation is a core emotional issue. Identities cannot be shrugged off, like discarding an old overcoat, and replaced by something new. There are also more specific issues concerning the merits of particular personal strategies. We have seen in our examples two broad forms of strategy that individuals adopt. The first of these is the ‘honest worker’. This form of identity can be adopted in any project role: the diligent engineer or soware developer, the straightforward project manager or administrator, or the executive or government mandarin commied to the aims of the organization. The second strategy is the ‘player’ position. This is a more Machiavellian approach to organizational life, in which we try to see things for what they really are, and use them to promote our own interests. The fundamental distinction is that people in the first category believe they exist as honest workers to support the organization and its projects, while those in the second category believe the organization and its projects exist to support themselves as players. Both strategies have their advantages and disadvantages. For organizations, honest workers are a useful resource; few would survive without them. However, frauds and other rogue projects ride on the shoulders of honest workers, who are willing to take on the impossible and are fated to take the blame when they fail. We might reasonably be somewhat sceptical. Perhaps to put oneself forward as the honest worker is itself a subtle political gambit, through which ‘honest Bills’ pose in an innocent apolitical stance to avoid having to deal with difficult issues. We might also note that some of the most politicized people in the world use the explanation of ‘just geing on with my job’ to divert aention from their manoeuvres (although generally with lile conviction). My personal preference is to adopt a player approach. To be a player, in its soer form, means I am aware of the wider issues and of my own ambitions. I can support good projects because they will generally benefit us all, and I will encourage honest workers because without them all will fail. To my personal advantage, I am not limited to one option, losing out when it proves to be poor. I can see when the ground begins to move, and jump to somewhere safer before

100

MAKING SENSE OF PROJECT REALITIES

I fall. When my reputation is threatened I am unlikely to lash out, unless I have calculated that by lashing out I will restore my position. Alternatively I can have my escape route ready. More negatively, of course, as a player I may be seen by others to be lacking in conviction. If a project starts to wobble I may well jump rather than aempt to stabilize it. People will put their trust in an honest worker, rather than in me. In its harder form, being a player would take me into the realm of the jungle fighter, where only the fiest survive. Such people can be dangerously disruptive. The difference between these two strategies is most apparent in cloudy political situations. A common example is the power vacuum, when a newly appointed project manager finds that nobody is willing to talk about the project scope. The honest worker will follow the standard book advice and continue valiantly to try to ‘find out what the requirements are’. The player, in contrast, will wish to see through the fog and find out what is going on: why those with power are holding off, and whether there are hidden agendas that have already condemned the project to failure.

THE OLIGARCHY For those of you wishing to get to the top of the tree, there is another question to be addressed. What is the best job to be in to further your ambition? The position of project manager is oen heralded as a stepping stone to the higher strata. However, when performed in honest worker mode the role rarely takes its owner beyond the next project. Some jobs go well, others go less well, and your position in the pecking order will advance or retreat accordingly. If you are pursuing ambitions you must raise your sights beyond this immediate vicinity. In larger organizations there is usually a loosely structured oligarchy – the group of people who concern themselves with the organization’s strategic direction. Membership of this group is not confined to those with formal senior management positions. The oligarchy constitutes, in effect, a practice group whose subject of interest is the organization and its welfare. Promotions to senior management positions will usually come from this group. In project-based organizations, ambitious project managers will wish to join the oligarchy. To this end they must, as well as performing their project management duties, engage with issues of strategy, speaking the local language of the oligarchy. For example, if we re-examine James’s story above, we can see that his response to the threat to his credibility was to defend his local rather

PERSONAL ENGAGEMENT

101

limited territory as a sound project manager. This response may secure his ground, but it will not take him forward. As an alternative he could, perhaps, have put forward a more ambitious response, framing his defence in terms of the overall interests of the organization and its relationships with its clients. Through this he would claim his membership of the oligarchy and his potential for a more senior position.

CONCLUSIONS: TOIL AND PAIN In summary, projects present us with many personal difficulties, and we who practise them must work hard to negotiate for, compete for, establish, maintain and advance our positions. There are many pitfalls, some painful. Our ability to avoid them will, as ever, be improved through a beer understanding of what is going on in the lives of ourselves and of others as we perform on the project stage. The hazards of personal decisions are exacerbated by the inherent uncertainty of all projects. We are perpetually under the spotlight, and always at personal risk simply because things may not turn out as we hoped. Project personnel are always in the front line when the blame mongers of the world move into the aack. I shall return to this question in Chapter 13, when I will examine the handling of uncertainty.

This page intentionally left blank

CHAPTER ELEVEN

Delivering Value A FOCUS ON VALUE In raising the problems of organizational complexity in Chapter 3, I identified two perspectives that provide valuable insights into the performance of projects. The first of these, concerning social interactions, has been central to much of our discussion. The second, concerning value creation, has also had a significant role in our arguments, but so far in a less explicit manner. We have described diverse and interacting social groups as having interests and as pursuing agenda, without being too specific about what these might comprise. In this chapter we will look more closely at the connection between the performance of projects and the creation of value. In mainstream thinking a project is considered primarily in terms of its tangible deliverables, specified at the start as requirements, and visible at the finish as the project’s output. The scope of these deliverables is treated as static in the sense that if the project is perfectly executed, then the final output will be a realization of the original specification. The end reflects the beginning. This is the project form encouraged by the forces of projectification, having a rhetoric of promise and delivery. The project has been reduced to something that is tangible, static and testable. Its managers can be held accountable for the delivery of its promises, to be rewarded or punished accordingly. Recently more aention has been given to conceiving projects as vehicles for creating value, acknowledging that a project does not begin and end with the specification and delivery of goods. The purpose of any project, it is argued, is to deliver value to a set of stakeholders. The management of projects can therefore be improved by a greater focus on these ‘real’ aims – the value sought by the stakeholders – rather than on the production of hardware to time, cost and quality. We can perhaps also encourage further improvement in performance if we measure the success of each project in terms of its delivery of this value, and reward the participants – organizations and individuals – on that basis. A consequence of this line of argument has been a proliferation of performance metrics – measurements of parameters that are considered to represent the value to be delivered by the project – which are then embedded, for beer or

104

MAKING SENSE OF PROJECT REALITIES

for worse, into the contracts that determine the profits of companies and the bonuses of individuals. For any real project, however, the objectives of the interested parties are diverse. It is very unlikely that we will find a single agreed version of what the project’s real aims might be. Ideally we might hope to see the aims of each stakeholder somehow reflected in a single agreed project specification, such that when the project is completed it will deliver output that creates the desired value for each and every stakeholder. This principle can be expressed as a spider diagram, as in Figure 11.1. The actuality of real projects, however, is rarely so straightforward. The different aims may not be compatible, and some may not be known explicitly. The project manager, who is generally encouraged to analyse and respond to these stakeholder interests, will have a partisan sponsor whose will may have to be imposed on the other parties. There is therefore no simple all-embracing answer in the form of an impartially derived project specification that will suit everyone. These messy demands for disparate forms of value can be a threat to the clarity and stability of the project. The conventional approach therefore aempts to detach the delivery phase of the project from these influences. Managers are encouraged to address the diversity of aims by performing a stakeholder analysis, preferably as a once-and-for-all exercise to be completed before the project begins. A stable set of requirements, together with metrics to measure

Party 1 Agenda

Party 2 Agenda

Value

Value

Aims Demands

Aims Demands

The project and its attributes Value

Party 4 Agenda

Figure 11.1

Value Aims Demands

Aims Demands

Party 3 Agenda

Spider diagram – delivering diverse interests

D E L I V E R I N G VA L U E

105

their delivery, can be specified, and the project can then set off on its projectperfect course, unperturbed by the distraction of competing external demands. We shall see that there are good reasons why this approach is unlikely to succeed.

THE VALUE CHAIN In practice the completion of any project will lead to a chain of consequences, which can usefully be considered at three levels.

1.

The output level. The standard project deliverables: tangible products, which can be inspected.

2.

The outcome level. The project will have been conceived as the solution to a problem. We should therefore expect that the completion of the project will provide us with a new facility – the ability to do something we could not do beforehand. The output and outcome of a project are closely linked in that for a well-formulated project we would expect the former to lead directly and instantaneously to the laer. However, not all projects are well formulated.

3.

The impact level. The project will have an effect on people’s lives, and will continue to do so aer the formal managed phases have been completed. Ideally we might expect this impact to take the form of the benefits that were claimed for the project when it was set up. However it is more than likely that there will be intended benefits that never become realized, and impacts that come to pass even though they were never intended.

We will clarify these levels with some examples: Taking first the UK Millennium Dome; during its course this project was managed at the output level, its primary aims being to construct a novel building and fill it with exhibits. The outcome was an exhibition facility – the possibility of a day out for millions of people. In terms of its impacts, a variety of claims were made for benefits that would accrue from the project: the educational experience of the visitors, the statement about the nation at the turn of the millennium, and the contribution to the regeneration of parts of London. Other major public projects can be considered at an equivalent three levels. For the London bid for the Olympic Games, for example, these are: the building of sports grounds and transportation systems, the

106

MAKING SENSE OF PROJECT REALITIES

facility to stage the Games themselves, longer term aims to improve sporting opportunities for young people and, once again, to promote urban regeneration. In a different field, consider a local cinema project to establish an Internet site through which visitors to the site can view the forward programme of films, and make bookings. The output of this project is the web site and its functionality. The outcome is the facility for individuals to choose and purchase seats. For the public the impact would be the benefits arising from the enhanced service: be
er access to choice of films and seats, ease of booking, avoidance of queues. For the cinema the impact would be higher levels of a
endance and the reduction in demand at the box office. The recognition of this value chain leads us to question the identity of the project. Is a project simply concerned with the delivery of specified goods, or is it something more extended? There are good reasons for either answer, and no simple rules that define how much of the value chain should be within the managed project. We will need to consider this question on its merits for each project.

PROJECTS DELIVERING VALUE The shi in focus towards value creation has an inherent logic, but it is not without problems. Richard wishes to make a complaint.

A BAD DEAL The Narrator: Richard, in the Construction business His Story I’m the owner of a construction company. We’ve been building for the city council for over 30 years, and have always been good at our projects, but I also understand the changes that are going on. The days are gone when we could win a job at a supposedly firm price and then charge for every change to the specification. We have to find ways of getting closer to the customer. A few years ago we bid to build a new school and we were very pleased to win the job, because it took us into new styles of management. In line with new thinking

the contract covered us for costs, but our profits depended on performance. We had to work cooperatively with the education authority to ensure that the buildings and their fittings would provide a first-rate environment for education. The school was also part of a plan to bring life to what had been a deprived area. Performance, on which our profits would be based, was defined in terms of these aims: the takeup of places at the school over the first two years following its opening. The cooperative working went very well, and we did all we could to support the

D E L I V E R I N G VA L U E

107

educational experts. We worked closely with them to introduce lots of features that made this a first-rate school.

performance assessment date arrived the school was only half full, and our profits went out of the window.

Commercially, however, it was a disaster. Parallel schemes to build roads and improve transport provisions were delayed, and a nearby school was refurbished, sucking away potential pupils. When the

I felt we had been cheated. We had fulfilled our side of the bargain, and bent over backwards to adopt the new practices, but we didn’t get our reward. How does this make sense?

The answer is that it probably does not make sense, but that conclusion is tied up with a number of other implications arising from the focus on value.

SOCIAL IMPACT While outputs and outcomes may be thought of in terms of objects and what we can do with those objects, impacts are entirely social. In our discussion of project diversity in Chapter 8, we included a vector contrasting projects that produce tangible outputs with those that lead to social impacts. Whatever their primary concern, all projects contain both components. The most hard-nosed projects lead to social impacts, whether intended or not. The most socially minded projects to drive a nebulous change in culture will have no impact whatsoever unless they first deliver tangible outputs that can induce that change. The fact that impacts are social takes them outside project control. The impacts are not a simple consequence of the outcomes of the project, but are also influenced by the much wider web of interacting human endeavours in which the project takes place. The benefits we intend will be jeopardized and distorted by the confounding effects of other people’s projects. The fundamental myth of management, the linkage between cause and effect – between management action and its consequences – is decidedly weaker when applied to social impacts. Even in the case of a social project (such as that described in Chapter 8) whose primary purpose is the development of social capital, the managers have an open specification (a notional scope) as far as the social ends are concerned. The main work content concerns the handling of hardware. The managers then shape the form of this work to generate social capital, in whatever form, as opportunities arise. Such projects are only a possibility because they stand outside the mainstream rhetoric of promise and delivery.

108

MAKING SENSE OF PROJECT REALITIES

LOCATION IN CONTEXT The traditional project specification, limited to tangible outputs, is aractive because it creates a clearly defined zone of responsibility for the project team. In doing so, however, it divorces the project from its environment. The focus on value puts the project back into its context. Instead of dealing with one element of a solution in isolation, we are dealing simultaneously with a problem and its solution. This can vastly improve the good sense of a project. It may be possible to conceive a project to build a Millennium Dome, but that project makes no sense whatever unless it is managed in conjunction with the transport systems, ticketing systems and everything else necessary to produce a viable exhibition facility.

THE EVER-PRESENT CUSTOMER The traditional project specification serves to disconnect the project from its customer. Having handed over the specification, the customer has no role to play until called upon to accept the completed product. This, the absent-client model, is incompatible with the new focus on value. Desired value – as outcome or impact – cannot be delivered unless the customer is present, since it is value in the eyes of the customer that is driving the direction of the project. To focus on value we must therefore re-engage the customer into the project. We can see both faces of this engagement question in the school building example. Rather than deliver a mere school, Richard our contractor is required to provide an educational facility, and to this end has a close interactive relationship with the local authority and educational experts who represent his customers. However his contract also makes him accountable for school aendance – which is dependent on the decisions of parents and pupils. This end-point customer cannot pragmatically be brought into the realm of the project (there is no group with whom its managers can have a meaningful interaction). Consequently in this respect success and failure are outside the project’s control. In Figure 11.2 there is a link missing. The stakeholders’ aims and demands are not routed into the project; they have the option to seek the value they desire elsewhere.

THE VALUE CHAIN – MAKING THE CASE The value chain is an important rhetorical tool for making the case for a project. For example: ‘If we build this school, then we will have an improved educational facility, which will transform the educational ethos of the town.’

D E L I V E R I N G VA L U E

Education authority Teaching facility

Contractor Profits and reputation

Value Aims Demands

109

Value Aims Demands

The school and its attributes

Demands

Value

Aims Demands

Teaching community Teaching facility

Figure 11.2

Other projects (schools)

Value

Value?

Parents and Pupils Preferred schools

Spider diagram – delivering a school project

‘If we build the Millennium Dome we will have an exciting exhibition centre that will capture the spirit of our age, and it will lead to the regeneration of this deprived area.’ A well structured business case links all three levels of value – output, outcome and impacts. We use these arguments to gain social legitimacy: acceptance of our project by its sponsors and by the society in which we live.

THE VALUE CHAIN – PERFORMANCE CRITERIA It is not reasonable to use the full value chain, leading to downstream social impacts, as a basis on which to judge, reward or penalize projects and their managers. As we have noted, the project runs its course in a messy social world, and the managers generally have limited control of the impacts. Some benefits will, we hope, be realized, but others may not. If we choose to pursue the managerialist aractions of holding managers accountable for results, then we must set criteria for performance and reward in terms of tangible outputs and outcomes. If we choose to focus on social impacts rather than tangible outputs and outcomes, then we must forego holding managers accountable.

110

MAKING SENSE OF PROJECT REALITIES

VALUE OVERLOAD While the claiming of consequential benefits is a necessary preliminary to any project, this can become the route to the creation of another form of fraudulent project. A perfectly feasible project might be proposed, but to establish its business case, or to raise its political profile, additional benefits are claimed. To get political backing, public sector projects are co-opted to support a wide range of government aims. This leads to value overload. The project scope is amended to add new outputs and outcomes to address these new aims, and the result is a project that is no longer feasible. This hazard is especially serious for IT projects. All evidence shows that the most successful IT projects are those based on a simple concept: a sound solution to a simple problem. In terms of the value chain these projects produce an output (so
ware) that enables an outcome (a capability to perform a new function). The focus on value can distort this picture. Additional features are added to the specification to address the gamut of social benefits that have been claimed, and the simple concept is lost. A previously viable project very quickly becomes impossible.

DELIVERY OF VALUE – CONCLUSIONS The focus on value is a direction in project thinking that can bring significant rewards. For a project to be considered effective, its delivery of tangible goods is not sufficient. The project must be conceived in terms of its delivery of value, and its execution must engage with the social world it serves. However this thinking also brings with it a number of hazards. The critical question for managers concerns the definition of a project: whether it is delivering goods (output), creating new facilities (outcome) or seeking social ends (impact). Those of us who are project managers need to be clear about what it is we are managing. There is no single answer to this question, but some general principles can be found by referring back to the definition of a project in Chapter 2. The key concepts of a project are: a purposeful collective endeavour; being separate (having boundaries that divide work that is project from work that is non-project); and the overall trajectory – the invention and realization of something that makes the world different. The focus on value encourages us to emphasize the final element of this definition, and to consider projects in terms of how they change the world.

D E L I V E R I N G VA L U E

111

However we must not lose sight of the first two elements. For a project to make sense, and be amenable to being managed, it must be possible to conceive it as separate from the wider work environment. We must also be able to identify a collective group who are responsible for the project and have it within their grasp to deliver it. For most projects we can expect to form some type of coalition – the project team, sponsors and users of the new facility – who can reasonably take collective responsibility for delivering output and its immediate outcomes. In some cases it may not be feasible to form such a coalition, and we will have to revert to the classic project scope, defined in terms of hardware. ProjectCra
practitioners will, as project shapers, embrace the principles of the focus on value. However they will also, as managers of project delivery, make sure that their project is not overloaded with requirements for the benefit of all parties, to the point at which it becomes impossible to execute. They will also resist aempts to hold their project accountable for social ends beyond their control. It is not always the case that social ends are beyond the remit of the project. A project form that departs from this general principle is that of business transformation, where the sponsors have a deliberate intent to change working practices – a social impact within the limited territory of their own organization. Business transformation projects therefore encompass a complex mix of tangible hardware deliverables, enhanced capabilities, and visionary hope for the future. We shall discuss how these elements can be handled in the next chapter.

This page intentionally left blank

CHAPTER TWELVE

Business Transformation MANAGEMENT OF CHANGE IN ORGANIZATIONS Business organizations are o
en compelled to change. Driven by the need to improve performance, to compete and to survive in a changing world, they restructure themselves, redesign their operational processes and take on board the latest advances in technology. A variety of approaches have emerged to guide managers through the hazards of organizational change. These take one of two general forms – the incremental and the radical. Incremental approaches seek to improve performance in modest steps within a set of basic operating principles that remain unchanged: they include Total Quality Management and continuous improvement initiatives. Radical approaches seek to rethink basic operating principles: they include business process re-engineering and sweeping plans for downsizing or outsourcing parts of the business. For the purposes of these discussions I shall lump all forms under the heading of business transformation. Despite the proliferation of techniques, business change has been perpetually fraught with difficulty. There is much cynicism among staff, managers and the outside world, many believing that change has always failed its promise, and will continue to do so. This is evidenced by the enduring popularity of the following quote (usually aributed to Petronius but, in fact, a fake): We trained hard … but it seemed that every time we were beginning to form up into teams we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization. There is good reason to be sceptical. Major reorganizations and massive investments have failed to deliver their promises. New IT systems, introduced as the foundation for a transformation in working practices, o
en fail to provide the functions expected of them, or are found to be unusable by those who were intended to operate them. Senior managers, however, cannot throw up their hands and admit that planned changes are unlikely to work. Shareholders and governments demand

114

MAKING SENSE OF PROJECT REALITIES

change, and managers are paid to deliver it, so have lile choice other than to make the aempt. A common response to this problem has been to inject a dose of project management into this ailing patient. The argument put forward is that if managers are not being successful in their aempts to introduce new technology and change, a probable cause is inadequate planning, organization and control. The discipline of project management, which embodies these virtues, can be brought in to cure the malady. In terms of the value chain introduced in the previous chapter, the case for introducing project management to this field is simple: sound project management practices (the output) will give the business the ability to introduce new processes and technology effectively (the outcome), which will enable the organization to respond to its external threats (the beneficial impact). In this chapter we will examine this logic. How can project management best be applied to business transformation? What is the relationship between project management and the other techniques of business change? Can project management really deliver the value claimed for it, or is it merely creating an illusion of control? In dealing with these questions, I am seeking to support hard-pressed managers as they face up to difficult issues, trapped between the insistent demands of their masters and the harsh realities of organizational life.

THE NATURE OF BUSINESS TRANSFORMATION We will set the scene by considering an example of IT-driven change.

FOOD TO SUPERMARKETS: BUSINESS PROJECT OR IT PROJECT? The Narrator: Christopher, a Director His Story Our company produces food and delivers it to retailers across the UK. We have a good brand name, and have been very successful. However with that success the nature of the business has changed in that we have ever-increasing sales to the large supermarkets. These customers have strong views on how their suppliers should operate. They expect us to

respond quickly to changes in demand, keeping the shelves stocked, and they expect to deal with their supplier through a single representative. Until recently we were delivering from fifteen different factories, each with their own processes and management systems. We had no option but to get our business into line. If we didn’t transform ourselves quickly we would lose our best customers.

B U S I N E SS T R A N S F O R M AT I O N

Our basic strategy was to buy in an enterprise IT system. I worked with the executive team to list the benefits we were seeking and set out our needs: better integration and collaboration, improved efficiency by rationalizing the organization, a single customer interface, and improved planning and distribution. The IT system was a well-known product. We brought in an expert consultant and instructed him to configure it to meet our needs. It was all fairly standard – nothing revolutionary. Our programme of work was driven by the changes we needed to make to our business processes, so I set up and ran an expert project team, separate from the dayto-day businesses, who worked with the consultant. We phased the programme, doing the simple things first – financials and purchasing – and then moving on to planning, sales and distribution. Our aim was to implement something that would work for the business, so we deliberately kept the lead away from the IT department, who only did tasks when we asked them. This meant that the project was run by people who were committed to and understood the transformation we were seeking, and could set up new systems that would facilitate that change. The initial outcomes weren’t good. The businesses were slow to take up the new working practices. The systems took more effort to operate than we had hoped, and when things went wrong they were inflexible. If a problem arose people didn’t discuss it with the project team; they just found ways to work round it. A

115

number of turf wars broke out over who was responsible for what. Some people continued as before, working outside the system. One business even started to develop its own version of the purchasing system. At this point it became apparent the project team was no longer the right form of management, so we disbanded it and set up a new implementation team. This new team co-opted managers from the businesses, and had a remit to deal with the problems and find ways to harvest the benefits we needed to satisfy our customers. The new team set out the principles for how the system should be used, what it covered and what it didn’t, set performance targets, and managed the changes that were needed to the IT system to make it better suited to the business. They supervised teams at the local level who were working on the details of the new practices. It took some months to iron these things out. In retrospect I’m not sure it could have been done differently. The IT element of the project was actually very well carried out. There hadn’t been anything seriously wrong, and the later modifications were only minor. Our expectations for the implementation had perhaps been over-ambitious, but it wasn’t possible to address this in the early stages. We needed to have the system in place and then to go through the subsequent disputes and conflicts before we could work out how best to use it. It isn’t credible to believe we could have designed the application in detail and planned all this from the start.

The most notable feature of this ‘project’ is that it is staged, and that each stage has a different form of ownership. While Christopher is present throughout as sponsor, representing the executive and their vision of the new company, the management initiative moves between different groups. Initially there is a design group (the executive and the consultant), then an independent

116

MAKING SENSE OF PROJECT REALITIES

IT project team, then a cross-business implementation team. At this final stage there are also local user teams dealing with practices in the business. Each team takes what has been done by the previous owners and reinterprets it, creating their own sense of what they are doing. When the IT element of the project has produced the so
ware (its output), the functions that people will perform with the so
ware (the outcomes) remain negotiable. Each user group examines the system and make its own decisions as to what it means to them and how it affects their own practices. Inevitably this leads to the turf wars, the disputes over who does what. This competitive making of project sense is not a regreable misfortune that has afflicted the project; it is a productive part of the process of assimilation for the new so
ware, and is an essential activity in the quest for the business benefits. The initial project team has the wherewithal – power, knowledge and resources – to deliver an IT system. This was based on well-established so
ware, and was not a problem. In contrast, the outcomes (the possible new practices) and the impacts (the delivery of the business benefits) are not under their direct control. The business transformation, the whole purpose of the project, is not within their grasp. These downstream consequences are in the hands of the local managers, who have their own agenda. Their business practice concerns the day-to-day delivery of products to clients. When a ‘message’ appears from the central team – a new policy, a new IT system, or whatever – their valid response is to evaluate and negotiate its relevance to their existing practice. Their implementation of the new system is therefore slow, distorted from the executive’s original concept, and partial in its implementation. The initial project team perform a conventional project management role, following a standard life cycle: seing the requirements, designing the system, planning the work and organizing the delivery of the new IT system. The later management group, the implementation team, have a completely different role. They are there to guide the continuing transformation. They work with a range of user groups, exposing disputes and facilitating resolution, coordinating work at corporate and local levels. The standard tools of project management have lile to offer this second role. The standard life cycle is not an adequate description of the complex iterative flow of work over long timescales. In fact the methodologies relevant to this group are more akin to those of a continuous improvement initiative than to those of a managed project. The techniques needed by managers to support working people as they collaborate to improve their practices are profoundly different from the planning, organization and

B U S I N E SS T R A N S F O R M AT I O N

117

control techniques brought to bear on business transformation by conventional project management. Because a transformation project has at least two stages in the hands of different parties, it is not possible for the early stage of the project to plan and deliver something that is considered ‘right’ by the managers of the later stages. Iterative work is inevitable. IT-based projects are especially prone to this effect. The Trouble with IT Projects Any business transformation project goes through a sequential transfer of ownership. The people who can design and deliver the tangible outputs are not the same people as those who will realize the downstream business benefits. In non-IT projects, managers can smooth this transfer by bringing representatives of users into the initial project team, helping them to design a product that they know can work. In even the simplest of IT projects, however, the relationship between the new concept and its effect on operations is obscure. The end users are unlikely to be able to envisage, at the early stages, the impact the project will eventually have on their working practices. It is therefore never possible to specify the project in detail, or to plan the job through to completion. The best strategy is to design and build a minimum system – the key features of which provide a basic solution to the problem – using an independent project team. Responsibility for the system is then handed to the users. When they attempt to use the new system they will discover its shortcomings. They can then adapt and optimize it. Iterative reworking is inevitable. The alternative approach, advocated by mainstream project management, is to attempt to get the system specification as near right as possible at the start and then prepare a detailed plan. To ensure the system is acceptable to users they are brought in at this early stage. This is likely to result in more deficiencies and contradictions being built into the system. This approach also carries the risk of value overload: too many features and complications becoming built in, deforming a project that is attractive and viable into one of gruesome and unworkable complexity.

PRINCIPLES OF BUSINESS TRANSFORMATION To ensure that the principles we establish for business transformation are truly general, we must also look briefly at three further examples – projects that are not driven by information systems. These are:

1.

‘Job Done!’

2.

‘New Office, New Culture’

3.

‘Saving Lives’

118

MAKING SENSE OF PROJECT REALITIES

Job Done! The Speedy Transport Company runs a large fleet of vehicles. In the 1980s the company followed the prevailing fashion and outsourced all their maintenance work. Since then, despite the best of intentions, they have been plagued by scheduling difficulties and shortfalls against safety standards. They decide that the only option is now to bring the maintenance back in house. They engage Jason, an interim manager, to manage the change project. Jason sets up a small project office under his own control. Avoiding any consultation with those affected, they buy in an off-the-shelf scheduling package, appoint a new maintenance manager and close the contracts with the external maintenance companies. ‘Job done!’ says Jason. ‘I’ve been on courses about involving people and holistic approaches to transformation but I find it’s completely unnecessary. If you deliver the goods, the people catch up.’

New Office, New Culture The Government Department of Spending is operating from a large London office which is decaying and expensive to maintain. Plans are developed for a new building, but when the bids come in the prices are well over the budget. How can it be justified? The organization has a bad reputation for working in silos. Nobody knows what anyone else is doing. The case is made that if the new building could create an open office environment, that would lead to improved cooperation between work groups and hence to efficiency savings. The building design is changed to reflect this hope. The annual savings are estimated and found to be sufficient to justify the project, which goes ahead. In parallel with the construction work, Efficiency Teams are established to seek new ways of working. When the building is opened, the savings are not immediately realized, but the possibility of savings is evident. Each manager is given a 10 per cent year-on-year savings target, on which their annual bonus depends. Now it’s up to them.

Saving Lives The Northcounty Ambulance Service is among the worst performers in the country, regularly failing to meet its targets for getting to emergency calls. Additional money is made available, and Cameron is appointed as CEO to sort it out. He is highly expert in ambulance operations, and soon develops a comprehensive plan. It includes a large number of projects: a new control centre, new crew rota systems, redistribution of ambulances across the county to match demand, closure of stations, introduction of statistical process control to analyse and improve the response cycle, and many more.

B U S I N E SS T R A N S F O R M AT I O N

119

The projects must be coordinated, so Cameron takes on a programme manager to run it. However the plan is essentially Cameron’s, and he presents it with enthusiasm to all parties. He obviously knows what he is doing, and the management team fall in behind him. This is a long journey. Improvements are needed now to save lives, but it may be several years before all performance targets are met.

SUMMARY OF TRANSFORMATION PRINCIPLES We now have four examples of business transformation, as shown in Table 12.1. Table 12.1

Diverse business transformations

Name

Nature

Benefits

When?

Food to supermarkets

A project to transform how the organization works

Align the company with expectations of customers

Driven to conclusion

Job done!

Re-engineering of processes

Effective maintenance

Now

New office, new culture

A new working environment

Changed culture and efficiency savings

It’s up to the managers

Saving lives

Multi-project improvement programme

Performance in responding to ambulance calls

A long journey

These examples are diverse, but all can be interpreted in terms of two interlocking forms of process: transactional change and journey of change. Their respective features are listed in Table 12.2 Table 12.2

Transactional change and journey of change

Transactional change

Journey of change

Accomplished through the plans and actions of managers

Flows onwards as a consequence of transactional change

Having tangible deliverables (i.e. that can be inspected)

Driven by need to realize benefits or create social impact

Planned

Organic, developing as it proceeds

On a defined project timescale of limited duration.

Long-term and continuing

Managed by an individual or team external to the organization undergoing change

Managed by distributed parties – the people whose work is changing

Amenable to conventional project management methods

Demands a holistic approach: coordination and facilitation, continuous improvement

120

MAKING SENSE OF PROJECT REALITIES

Business transformations may be incremental or radical, but whatever their basic form, transformation projects will comprise both transactional and journey-of-change components. The project concerning food to supermarkets is essentially radical and is initially managed in a transactional manner, but it then becomes a longer journey of change. Jason’s claim of ‘Job done!’ for Speedy Transport is only true of his initial transactional actions. There is a journey of change ahead for the managers of his new organization who must now make his radical changes work. The new office for the government department is itself a transactional entity, but it is the initiation for culture change that is a journey as yet unplanned. The Northcounty Ambulance Service is undergoing a long journey to improve performance, but the necessary first steps consist of a number of tightly managed transactional changes. In these cases there is no single answer to the question: what is the project? For example in the supermarket food example we can envisage two different approaches. There is a weak project available, in which the project comprises the new information systems, more than likely delivered by the IT department. The subsequent journey of change will then be taken up by the managers of the business units, referring back to the IT department if changes are needed to the IT systems. The stronger project, however, is that adopted by our speaker, Christopher. The project is conceived as embracing the whole trajectory of the change in the organization. This version of the project takes us beyond the bounds of the standard mechanistic definition of a project, but it conforms to our broader definition in Chapter 2. There is a collective group (the executive) driving the organization to a well-defined new state. The act of defining the project in these terms is a powerful management statement. It proclaims the senior management intent, and creates the possibility of a coherent strategy across the organization. This is not an IT project but a business transformation. In the transport example, on the other hand, Jason appears at first sight to have adopted the weak version of the project, delivering the tangible outputs but washing his hands of responsibility for the subsequent social impact. Nonetheless this might be a good strategy. It may well be that his actions have already administered sufficient shock to the system – a force majeure – such that the intended consequences must necessarily follow without being the subject of an executive project. The plan for the new office contains a similar hope, that it may constitute a force majeure for culture change, but this is perhaps more open to doubt. The

B U S I N E SS T R A N S F O R M AT I O N

121

managers who have been handed the downstream responsibility do not have a strong pointer to the direction in which they are expected to travel.

PROJECT OR BUSINESS IMPROVEMENT? In these three examples the discipline of project management has claimed supremacy: the project is the primary executive vehicle for transformation. However the skills of ProjectCra must now also take us beyond the conventional frontiers of project management to colonize the methods of continuous improvement, such as target seing and performance management, priority seing, process analysis and Statistical Process Control (SPC), etc: all the techniques familiar to those of us who have engaged with Total Quality Management, Business Excellence, Six-Sigma, and all the other initiatives that inhabit this adjacent but foreign land. In the Northcounty Ambulance Service the roles are reversed. The ruling mode of action is business improvement. The projects, which are largely transactional, take a subordinate role. The managers of this transformation, proficient in process improvement, should perhaps look across the frontier and acquire some of the mechanistic skills of project management.

The Middle Manager Resistance Movement Many initiatives to transform organisations lose momentum when new working practices are to be implemented. This is usually attributed to resistance to change. Middle managers are often accused of being particularly prone to this fault. It is argued that any change threatens the identity of individuals (see Chapter 10), and middle managers, who have made a personal investment in their management position, are most affected. Overcoming middle management resistance is therefore critical to successful change. This explanation may well have some validity. It has an obvious popularity among senior managers whose grandiose but impractical plans have failed. The discussions of this chapter have revealed a companion explanation. For any transformation the basic executive action – to buy in an enterprise information system, to build a new office, to cancel outsourcing contracts – is essentially transactional. It can be done decisively and quickly by an individual or a small group of people. However the delivery of benefits – making the new systems work, finding new working practices - falls to middle management, and is a journey of change. This journey is diffuse and must be negotiated with other parties. It will be affected by other unplanned events. It may sometimes be impossible to do as the executive expected. Resistance is not the only reason why change takes time.

122

MAKING SENSE OF PROJECT REALITIES

MANAGING BENEFITS Many business transformations are maers of great complexity. Projects that are inherently quite simple in terms of their technical deliverables may be intended to produce varied benefits to multiple stakeholders. A
empts to drive a transformation which is straightforward conceptually may involve an array of projects, each with its own output, which it is hoped will, in total, lead to a valued social change. In these situations it is not good enough to hope that the tangible products from the project or projects – the transactional changes – will create a force majeure sufficient to drive the benefits through to fruition. Their delivery will need active a
ention. The work to coordinate this delivery is referred to as benefits realization management. The management techniques of business improvement make an important contribution to benefits realization, but must be focused on the work to be completed to ensure that the executive’s aims are achieved. This is usually addressed through benefits mapping. The standard approach to benefits mapping is to create a diagram of boxes and arrows representing chains of cause and effect, with a time line running from le to right as shown in Figure 12.1. This very simple example demonstrates the principles of a benefits map, which shows the sequence of events that we hope will take us from conventional project outputs (street lighting and CCTV), through project outcomes (the capability to make arrests), to hoped-for social impacts (reduced criminal presence and crime). If I am the sponsor of the project to improve street lighting, this diagram shows how my project will contribute to the fight to reduce town centre crime, and the ma
ers that must be addressed to ensure the intended impacts are achieved. For business transformations, the diagrams will have many boxes. For the ‘Saving lives’ programme, our third business transformation example, Cameron, the Northcounty Ambulance Service CEO, could explain how his plans will work by a diagram such as that in Figure 12.2. His is a complex Install CCTV Improved capability to arrest Improve street lighting

Reduced crime

Increase penalties

Figure 12.1

Reduced criminal presence

Example benefits map – reducing town centre crime

1 Supply and demand

Activity review

Demand analysis

Fewer stations

Deployment system

Community perceptions

Deployment plan Efficiency gains

Roster system

Deploy

Recruit

2 Staff resource

Value for money

Available staff

Alternative responders Skills analysis Review alternative resources

3 Fleet resource

Fleet maintenance system

Faster response times Saved lives

Deploy staff Triage (no-send) system

Deployed ambulance and crew

Available fleet Faster return to available

Call cycle process model

4 Call and response process

Stage-time standards Reduced cycle time

SPC & improvement systems

Stage-time continuous improvement

New Call Centre

Faster arrival on scene

Gazetteering system

Repeat demand analysis

5 Culture and improvement

Figure 12.2

Develop culture Develop responsibilities

Complete benefits map – saving lives

Continuous improvement

Improved working lives

124

MAKING SENSE OF PROJECT REALITIES

diagram and it has been reduced and distorted (losing some le to right passage of time) to present it in full on one page of a book. Typically managers and their consultants will wish to display their diagrams on the office wall. These can be impressive, operating in a similar mode to a detailed project programme, demonstrating to the world that they know where they are going, and that they are in control. But beyond this claim, what is their pragmatic worth? There are two main answers to this question: the value-chain argument, and the management plan.

DISPLAYING THE VALUE CHAIN The value-chain argument for a transformation programme links the outcomes of the projects to the social benefits that may follow, and is encapsulated in the final right-hand boxes of the full diagram, as shown in Figure 12.3.

Key:

Deliverable Operational outcome Social benefit

Community perceptions

Fewer ambulance stations Efficiency gains

Value for money

Better deployment of resources (ambulance & crew)

Faster response times Saved lives

Faster return to available Faster arrival on scene Response process improvement

Figure 12.3

Value-chain argument – saving lives

Improved working lives

B U S I N E SS T R A N S F O R M AT I O N

125

From the complex benefits map, a simple value chain has been extracted to display the essence of the benefits argument: that a limited set of tangible outputs will lead to operational improvements, and hence to the desired social ends. The presentation of the diagram in this more limited form also exposes its highly partisan nature. This is not some absolute objective map. It is an executive map. It is Cameron’s personal explanation as chief executive, of what he is doing and why. It is directed towards those who fund the ambulance service, its purpose to claim their support. As ever with this portion of the value chain, the linkage of cause and effect is not strong. For example it may be statistically true that faster response times will save lives, but the achievement of this end in practice depends on many factors, some within the team’s control but others dependent on the impact of unknown forces and events. Success will be judged on the achievement of operational outcomes – the provision of resources, the time taken to respond to emergencies – rather than on saved lives or whether the service provides value for money. Other parties may have different perceptions of the value chain. Local communities may feel that the closure of ambulance stations is a backward step, and ambulance crews may not agree that the redeployment of resources is an ‘improvement’ to their working lives. This map, however, is Cameron’s. If others wish to join in the debate, and make their own cases for other projects or other social benefits, they must draw their own value-chain maps. If they do so they will find that the executive map is very powerful, and difficult to challenge. It takes the high moral ground – of saved lives and saved money – and ties these ends to a management strategy. The ends justify the strategy, and the strategy promises the ends. In Chapter 9 we noted how a project plan is used to enact a particular version of a project, making it appear to be the only possibility. Here we see the same effect, but applied to a transformation programme. The executive’s version of what the transformation will be is validated as the only possibility through its enactment in the delivery plans.

MAPPING THE MANAGEMENT PLAN The second purpose of a benefits map is as a management tool. For this we can subdivide the map. In this example there are several separate delivery plans in place (numbered 1 to 5, with headings, in Figure 12.2). The second of these, concerning staff resources, might look like Figure 12.4.

126

MAKING SENSE OF PROJECT REALITIES

Management action

Project External negotiation

Operational outcome Recruit additional staff

Develop new roster system

Deploy new system

Perform skills analysis

Train and Deploy staff

Available staff

Recruit and organize alternative responders

Develop guidelines for alternative resources

Develop fleet maintenance system

Figure 12.4

Better deployment of resources (ambulance and crew)

Set up triage (no-send) system

Improved fleet availability

Component of management plan – saving lives

This map plots the packages of work that will take us to our destination and contains a mixture of items. There are conventional projects, delivering particular goods or capabilities, enabling the group to perform tasks not previously possible. There are also other transactional actions (that can in no meaningful sense be termed projects), operational management requirements and negotiating points – agreements to be made with other parties, who may themselves be on extended journeys of change in organizations beyond Cameron’s territorial limits. Of critical importance are the operational outcomes. These give focus to the sub-projects, so that managers can concentrate on these and not on every potential downstream selling point for the transformation, which could divert their gaze away from the immediately possible and into the hazy distance. This map is, like a project plan, a dangerous entity. It takes a complex interactive situation and presents it as a step-by-step path, treating as the actual

B U S I N E SS T R A N S F O R M AT I O N

127

reality a particular simplification of what may happen. It creates an illusion that a journey of change can be travelled by taking a path of simple transactional steps. It embraces intangible theories about what other parties may or may not do, and shows an excessive faith in nebulous assumptions of cause and effect. It appears as a static plan in a shiing world, vulnerable to changes in aims, failed negotiations, and discovered messages that may lead the transformation to a peripety – a switch to a completely different understanding of the path to completion. A map such as this appears as a promise from the chief executive: ‘Follow me along this route and we will get our benefits.’ This is a dangerous promise to make.

PLANS AND BENEFITS – SIMPLIFIED MAPPING The dubious basis of a map such as this is a serious concern, but the primary function it performs, to point at what we must address to realize the benefits of the transformation, remains important. The technique is dubious because it appropriates the most mechanistic of project management methods – the detailed step-by-step task schedule – and aempts to make use of it to take us across a terrain where it is even less appropriate. There are simpler alternatives that do not fall into this trap. These are standard methods of process improvement, which we have already noted is a more relevant discipline than project management in this area.

Improved working lives

Value for money

Save lives

▼

Impacts

An alternative map for the case under discussion might comprise a simple matrix as in Figure 12.5.

Sub-programmes ▼ Supply & Demand

Plan to meet demand

Deployment plan

Deployment plan

Staff Resource

Available staff levels

Effective resource usage

Deployment plan

Fleet Resource

Available fleet

Effective resource usage

Improved equipment

Call & Response process

Process analysis. Time to arrive at scene. Cycle time.

Efficient use of resources

Continuous Improvement

Figure 12.5

Benefits matrix – saving lives

All Issues

128

MAKING SENSE OF PROJECT REALITIES

While avoiding the faults of the detailed cause-and-effect maps, this simplified matrix shows the principles of the transformation plan: its intended impacts, its sub-programmes and the tangible deliverables needed from the sub-programmes to achieve success.

MANAGING BENEFITS – SUMMARY There are some important tasks to be performed by managers to ensure that the intended benefits of business transformation projects can be realized. However, as with projects themselves, there is a danger that we can become over-mechanistic in our thinking, believing unrealistic details of cause-andeffect diagrams and deluding ourselves that we are in control of the impacts. This danger is encapsulated in the terminology and many of the ideas of benefits realization management: most social benefits cannot be managed in this way. Despite these warnings I have departed from a principle stated in Chapter 2, that I would not generally concern myself with techniques. I have done this because the issue in hand, the delivery of complex and diverse benefits, is a crucial one. The recognition that projects, including those aimed at business transformation, are concerned with the production of value rather than the delivery of goods, is central to new thinking about projects and is not addressed in traditional methods. We must have some systematic ways to air these issues. Obscurity in this area is oen dangerous the source of frauds, disconnections between plans and hoped for benefits, or over-dependency on unreliable outside parties. Our plans may stray from the realistic into the realm of wishful thinking, but even so it is beer to make them explicit and visible, so we may have the necessary arguments early in the process of change. A plan of any form creates a narrative of where we are going, and if a business transformation is to have clear direction this narrative is essential. The essence of ProjectCra in this domain is the ability to find the appropriate mode through which the business transformation project can be presented to the wider world. There may be occasions when a complex benefits map, covering the office walls, has its uses, but I suspect there are not many. More oen we need a succinct presentation, something simple that will instantly display our purpose and how we propose to proceed, highlight the deliverables from our subprojects, and help us track the critical maers to be addressed.

B U S I N E SS T R A N S F O R M AT I O N

129

BUSINESS TRANSFORMATION AND PROJECT MANAGEMENT At the start of this chapter I put forward some simple questions about the role of project management in business transformation. Our discussions suggest the following answers. In any business transformation there are elements of the change that can be considered as transactional. They have tangible deliverables, and are under the control of a concisely defined group of people. They are amenable (in so far as anything is) to the conventional planning and monitoring techniques of project management. In any transformation there are also stages that are journeys of change. These elements are characterized by distributed management ownership, iteration and the impossibility of through-planning, and are not amenable to standard project management approaches. Here methods traditional to continuous improvement initiatives are more relevant. However, despite the methodological incompatibilities, an overall programme of business transformation, including its continuing journeys of change, can be given additional authority and focus if it is conceived of as a single executive-driven project. A critical topic in the management of business transformation is the need to focus efforts on the realization of the intended benefits. The project management discipline has put forward techniques of detailed benefits mapping to deal with these issues. These serve two important functions: to create a narrative of explanation for how the benefits are to be realized, and to direct efforts to critical areas of work. However, these methods are too much akin to standard project management methods for these socially complex situations, being overmechanistic and creating a dangerous illusion that benefits can be realized through a set of managed transactional steps. Managers may well find that other approaches – partial maps or benefits charts – may be simpler and more helpful.

This page intentionally left blank

CHAPTER THIRTEEN

Dealing with Uncertainty INTO THE UNKNOWN Projects are foggy, messy and ambiguous. We stride along on the edge of chaos, creating stories of order and sense that can guide us forwards. As we move on we are threatened by obstacles looming out of the murk and treacherous ground conditions, casting doubts on our chosen direction and pu
ing us off our stride. To handle these dangers we have, in our toolkit, the techniques of project risk management. If we list the hazards ahead and set out our plans for handling them, then we can make sense of them and bring them within our domain of project order. In this chapter I will briefly introduce these techniques, and then ask questions of them. How is risk management applied in practice, and what can it really do for us? What other resources do we have at our disposal? The origins of project risk management lie in the concepts and methods devised for the control of deviation. We have a plan, and in a perfect world we would follow that plan. In this less than perfect world our plan is threatened by untoward events that may compel us to deviate, but we can systematically review our plan and identify these threats. We can assign a probability to the occurrence of each threatening event, assess its consequences, and then plan our remedial actions: the things we must do to control deviation and keep to our original plan.

THE RISK REGISTER These principles are implemented through the standard risk management tool of the risk register (or risk log), which lists the items we have identified as a threat to our performance, and states the actions we must take to deal with them. The typical contents are as listed below. Actions might reduce the likelihood that the risk event will happen, or might mitigate it so that its consequences can be tolerated. The register is also used to inform project decisions: whether to proceed, choice of strategy, timing of stages, etc.

132

MAKING SENSE OF PROJECT REALITIES

Typical Contents of a Risk Register

• • • • • • • • • • • • • • • •

Risk identification number Risk type Risk owner Date identified Date entry last updated Description of risk (untoward event) Probability Cost impact Timescale impact Performance impact Overall risk level (probability x impact) Possible response actions Chosen action Target date for action Action owner/custodian (if this differs from the risk owner) Closure date

Notes: The risk owner is the person responsible for handling the risk Probability is the likelihood that the risk event will occur, impact is the effect it may have on the performance of the project. Probability and impact may be treated quantitatively (percentage likelihood of occurrence, weeks delay, extra cost, etc.). Alternatively they may be treated qualitatively (high, medium, low).

Table 13.1 shows an abbreviated example from Robert’s project, which was introduced in Chapter 4. The project concerns the procurement and configuration of a soware package for administering pensions, and the downsizing and reorganization of the administration team. This register was compiled early in the project. The actual risk register contained several hundred items and included more explicit analysis of impacts (on time, cost and performance) before and aer mitigation. This limited set of risks has been selected to provide examples for the discussions that follow. I have also chosen to present the register here as a single unstructured list. In normal good practice the items would be categorized and ordered: by type (for

D E A L I N G W I T H U N C E RTA I N T Y

Table 13.1

133

Project risk register

Identifier

Owner

Description

Probability

Overall risk

Action

R1

Project team

Data errors (will affect ability to migrate records to the new system)

High

Medium

Allow time for corrections and rework

R2

Software supplier

Supplier cannot allocate sufficient resources

High

Medium

Recruit. Allow time in programme

R3

Project team

Interface software for new data not suitable for purpose

Medium

High

Carry out early assessment

R4

Project team

Preparation of calculation specifications takes much longer then estimated

High

Medium

Track progress closely from an early stage

R5

Project team

Administrators will not accept new system

Medium

High

Involve new administration team in system design

R6

Executive

Office executive withdraws support for the project

Low

High

Will have to accept any new strategy

R7

Executive

Head Office withdraws project approval

Low

High

Will have to accept any new strategy

R8

Project team

Project late delivering specifications to software suppliers

High

Medium

Accept lateness or reduce system scope

example technical or commercial), by work breakdown, or by the project phase to which they apply. The techniques employed for project risk management originate in the probabilistic analysis of processes and data, and have precedents in the management of safety and statistical process control (SPC) for manufacturing. The techniques were devised for dealing with known risks.

134

MAKING SENSE OF PROJECT REALITIES

In our example register, item R1 is a known risk. The soware suppliers know from their previous experience that old databases of pensions information are likely to contain many omissions and errors, and these can compromise the operation of the administration soware they are supplying. The discovery of these errors will delay the project. With this quantified knowledge Robert can make a decision on how to proceed, based on a rational analysis of probabilities. He might commission early work to check and clean up the data, or he might allow a contingency in the project programme to deal with errors as they appear. We can make this type of logical decision about known risks because we have good information about past experience of the problem. Despite the threat posed by these risks we can predict how they will affect the outcome of the project. A similar example is the risk due to bad weather during a construction project. We can identify the weather conditions – high winds, low temperature – that would stop construction, and use available statistics to calculate how many days of work are likely to be lost because of bad weather. The crucial characteristic of known risks is that we have relevant data. We know their likely impact. The science of risk management is founded on data. Unfortunately in the world of difficult projects known risks comprise only a small fraction of the threat to project performance. Strictly speaking the techniques are not applicable to most of the problems experienced in real projects. Nonetheless we project managers routinely apply these methods to all manner of hazards when we have no relevant data. We plan our projects in the dark, making numerous unwarranted and dubious assumptions in the face of ambiguities and uncertainties that exist by virtue of our plain ignorance about what we are doing: ma
ers that are invisible to us. How can we pretend to know what the outcome will be? If we list our uncertainties on a risk register and assign to them arbitrary guesses about their probability and possible impact we are no nearer to knowing what will happen. Risk management is a technique designed to help us deal with the known, the benign, the predictable. Is it reasonable to apply it to the unknown, the malignant, the unpredictable? To consider these questions, we must differentiate between risks and uncertainties. Risks are the deviations we know about and can predict. Uncertainties concern the things we do not know. For the purposes of our discussion I am also differentiating between two types of project uncertainties: task uncertainties and social uncertainties.

D E A L I N G W I T H U N C E RTA I N T Y

135

TASK UNCERTAINTIES When se
ing out a project plan as a set of tasks we are oen in a state of ignorance and must make assumptions. In our example register items R2 and R3 come into this category. Robert cannot know, at this early stage, whether the supplier will have sufficient resources or whether some off-the-shelf soware will be suitable for its intended purpose. The question of estimates (item R4) is also crucial. If Robert’s team have never before produced any calculation specifications and do not know what problems may arise, then it is highly likely that their estimates of the effort required will be too low. This characteristic of estimates for poorly understood tasks is well documented, and is referred to as estimating bias. Because these are uncertainties – unknowns – we cannot predict the project outcome. We may add contingencies and margins into our plans, but we cannot tell whether these will be adequate. However it is still useful to apply the logic of the risk register to track and manage these items. Many project-competent organizations take control of these ma
ers at an executive level. Since Robert’s organization does not do this we shall take a temporary diversion to another example.

GOVERNANCE OF UNCERTAINTY AND COMPLEXITY The Narrator: William, a Company Director His Story We are involved in many construction projects, which are getting increasingly complex. We used to just build things, and could predict our costs and timescales reasonably well. As we moved into new areas we found we were frequently making losses that we couldn’t afford. We carried out a thorough review, and found that we were often committing ourselves to carry out work and meet targets in complex and uncertain situations. We were already running a stage-gate system to approve projects. What we did was to realign that system to make the review of uncertainties, and uncertainty reduction, its primary function. At each stage review each project manager presents the project to a committee of

the company executive. Uncertainties must be declared, and we make sure that everything possible has been done to remove uncertainty before we will approve the next stage. If there are open issues in the specification we insist they are firmed down. If we don’t know that a particular feature of the design will work then we insist on design studies and tests. For cost estimates we insist that there is data-backed evidence to back them up, and if there isn’t we only approve preliminary work so that evidence can be collected. If we’ve done all we can and the project stills looks doubtful, then we will want to stand back, ask whether we’re following the right strategy, ask for a change in our contract terms, or even back out.

136

MAKING SENSE OF PROJECT REALITIES

It’s now a matter of principle. We never proceed without going through this review at each project stage. Sometimes

we don’t start as quickly as our clients would wish, but in the end I’m sure it pays.

This is a strongly managed company, in which the directors are fearful of the commercial risks that can come about due to project uncertainties. Rather than a
empt to estimate the unknown, William and his co-directors use a process of staged uncertainty reduction to do all they can to manage and eliminate it. They have also recognized that pressing forward is not the only option. Risk management should not be used simply to find ways to prevent deviation from the plan. It should also help us pause and reflect: to seek alternative plans that are more certain to lead to a favourable outcome. This might include renegotiating the meaning of success if there is no viable strategy to achieve success under the current definition. These observations on the handling of uncertainties can also be extended to the handling of project issues. While in the case of an uncertainty we have a planned task, but are unsure of our ability to carry it out, for an issue we are uncertain about what our plan might be: the packaging of work, the choice of a product or supplier, a design strategy. In all these examples we know what we are trying to do but have to deal with unknowns that may prevent our success. These are known unknowns, in the sense that we can list them by trawling systematically through every assumption we have made in compiling our plans. The risk register is a useful management tool to track and coordinate the actions we take to deal with the known unknowns so that we may maximize our chances of success. However, in using this tool we must beware of the temptations of quantification. Some people may add probabilities to the items on their register, and calculate contingencies to cover additional costs, programme delays or performance shortfalls. The astute ProjectCra practitioner will be aware that the implied certainty created by these figures is a dangerous illusion. On our project journey, task uncertainties are akin to roadworks, cracks in the path or unsignposted junctions. If we carry the right equipment and have a good map and a compass we will find a way forward or round the hazard, and will reach our destination, or somewhere like it, in due course.

D E A L I N G W I T H U N C E RTA I N T Y

137

SOCIAL UNCERTAINTIES Our discussion of risks and uncertainties has so far conformed to the production line model of mainstream project thinking. The project has been treated as an objective entity, to be processed towards its defined project-perfect end points. The threats to its progress can be analysed and addressed by competent managers, whose sole interest is to intervene to assist the production machine. We have argued however that projects can be more pragmatically considered as the products of social interactions, concerned primarily with the creation of value. Projects are the product of collusions, spawned and delivered out of the intercourse between competing tribes – groups seeking to achieve diverse forms of value from the project. These considerations raise additional uncertainties, oen unknown (in that we have no systematic way to list them) and with the potential to have a major impact on the overall conception of a project. It is not merely the performance of tasks that is under threat. The project’s objectives, its organization and its basic strategy are all vulnerable. We may perhaps be undertaking the wrong journey. Social uncertainties take many forms, a number of which have been discussed in earlier chapters. Examples are: Unknown agenda. Different parties have their own agendas, perhaps hidden, and they strive to create versions of the project to support their interests. We do not necessarily know what people want from the project, and how they may interfere to achieve their ends. In the case of fraudulent projects, the ‘real’ intent is deliberately obscured, and the overlooking of uncertainties is a deliberate strategy. Furthermore, estimating bias, far from being an inadvertent outcome of our ignorance, may be a deliberate policy. Emergent strategy. For business transformation projects we have seen that we should expect a journey of change to emerge in response to the production of tangible outputs. The interested parties react to the project as it proceeds and generate their own plans. We cannot therefore plan the route to completion; it is emergent. In our example risk register, item R5 reflects the fact that the managers cannot know how the pensions administrators will deal with the new system until they have actually come face to face with it. Divergent strategy. Even for the simplest of projects, groups we have brought in to perform a part of the project work cannot be relied on to do as we expect. They may choose to reinterpret the project

138

MAKING SENSE OF PROJECT REALITIES

aims and diverge from the main project policy to follow their own separate path if this suits their own needs. Peripety. The project strategy can be rapidly diverted by the appearance of a message or object that invalidates our current understanding of its purpose. Conventionally, decisions are thought to be the prerogative of humans, but in practice objects can act as the agent of change, introducing an unexpected new reality into our project arena. Continuing contest. The project has arisen out of a negotiation, but the parties to that negotiation will subsequently change their positions. The balance of power may change. Parties who took a peripheral interest in the early stages may suddenly find they have influence, and decide to exercise that influence to divert the project. Unstable group. In any project plan we identify groups of people and set down their expected contributions, but we may be mistaken in assuming that a group has a stable identity. For established practice groups (see the discussion in Chapter 4) we may expect some continuity of purpose, but other groups, including project and executive teams, may be transient and unstable. Our example risk register includes an item (R6) raising the possibility that the executive may withdraw support from the project. In the event the executive later showed themselves to be fragmented, torn apart by personal conflict, all protecting their own positions and having no coherent collective stance. New brooms. Unstable groups are particularly vulnerable to new brooms: newly appointed individuals (for example project manager or chief executive) who wish to make their mark. Any new manager will wish to shape the project to align it with his or her ambitions, and is unlikely to be content to keep the current specification. This is especially significant if the new manager is seeking to establish a reputation as a radical person – someone who can make things happen. The project will provide such people with an opportunity to demonstrate their capabilities. These are typical examples of social uncertainties that could have serious impacts. Experienced practitioners will doubtless be able to add many more, because they are ubiquitous throughout the project world. They arise from the human and social context of projects, inherently uncertain and unstable.

D E A L I N G W I T H U N C E RTA I N T Y

139

Most projects will be vulnerable to several of these influences. Unfortunately their effects are not merely additive. They will interact with feedback loops, one untoward event leading to another. A shortfall in project delivery will change the a
itudes of the interested parties, which itself will have a further knock-on effect on project delivery. Many projects experience a cycle of escalation due to these feedback loops. It is exacerbated by conventional management practice, which a
empts to control risk. When a project gets into difficulty the pressures on the project’s managers, who are being held accountable for meeting the original deadlines, demand the production of remedial plans to put the project back on course. These remedial plans are inevitably even more laden with uncertainty. (If they were as sound as the original plans they would have been adopted from the start.) A common form of dubious remedial plan is the late injection into a project of additional resources. Additional people will oen divert the existing team from their work, demand extensive training and introduce new and conflicting interpretations of the project aims and plans. They oen come with an expensive agenda of their own – to make large financial gains out of the project’s difficulties. The remedial plans inevitably increase the likelihood of further disruptive events, oen leading to exponential growth in costs, and massive overruns. A strong management team should react to unexpected difficulties as in William’s example above. They should pause, take stock, and act to reduce uncertainty before proceeding onwards. In practice, however, company executives in this situation usually find themselves dominated by an agenda of control and correction, and will not back the rational strategy of staged uncertainty reduction. Holding to the existing plan is rarely the best course, but nonetheless most management teams a
empt to follow it.

WHAT CAN A PROJECT MANAGER DO? These uncertainties pose great problems for all practitioners and for project managers especially. What are we to do? In principle there are three broad strategies: the innocent, the protectionist and the ProjectCra player.

THE INNOCENT The simplest option is to follow conventional practice. The project manager will seek out the requirements, plan the project and list known risks and

140

MAKING SENSE OF PROJECT REALITIES

uncertainties on the risk register, complying with standard procedures. When the project goes badly wrong, as it oen will, the manager will use honest worker rhetoric: ‘I did what I was asked and complied with the rules.’ However there are disadvantages to this strategy. If you are a wellintentioned manager this is not the best that you can do for the project, and in the long run it will not be a career-enhancing style. You should also note that every fraudulent project, with its hidden agenda and disguised uncertainties, depends for its continuation on having an innocent to act as its project manager – someone who will not rock the boat by exposing the fraud. Taking this role does li
le to enhance your reputation.

THE PROTECTIONIST A project manager can protect his or her reputation by taking a more careful approach. The basic strategy is to act as a refusnik, declining to take on any project unless all issues have been resolved and it is uncertainty-free. In support the manager can cite the conventional definition of a project, with its requirement for defined objectives and well-defined tasks, and claim ‘It isn’t a project, so I won’t take it on.’ This approach has important advantages for the organization, encouraging (if not blackmailing) the sponsors and senior managers towards the good practice of staged uncertainty reduction. This purist policy is devised to protect us project managers from the worst of uncertainties. Task uncertainties are eliminated before we deign to touch them. Social uncertainties are removed from our project scope since the requirements define the project. If there is a socially driven change of strategy, we will treat it as an externally imposed change, and wait, once more, until any new uncertainties are removed before restarting. Our aim is full blame avoidance. We will make no commitments unless we are certain we can keep to them, with the possible exception of some unavoidable known risks. Our risk register will include nothing but these known risks, declared to protect our position. While having obvious benefits, this strategy has considerable difficulties. First, strictly speaking it is impossible. It implies that everyone on the project will know exactly what they have to do. We must be careful how hard we press our demands for this ideal state because we will never get there. We may find that our senior managers and sponsors are not wholly appreciative, considering us to be unduly difficult. There is a danger that we will be le on the sidelines, predicting doom, while they appoint someone with a less purist approach – an

D E A L I N G W I T H U N C E RTA I N T Y

141

innocent – to take over our job. We can then but hope that we will be asked to take on the rescue role when the inevitable overruns occur.

THE PROJECTCRAFT PLAYER We can perhaps adopt some of the principles of the protectionist while being more pragmatic. Our aims will be to protect our position, while giving more positive support to our organization. We will employ our ProjectCra skills to the full, in order to be as aware as possible of all manner of uncertainties, and to handle them to our best advantage. The final paragraphs below consider what these pragmatic skills might be.

PRAGMATIC UNCERTAINTY SKILLS Of primary importance is uncertainty spoing. Unless we see the dangers coming we cannot deal with them. Standard approaches are useful. Of these, probably the weakest is to ask others to inform you of risks and uncertainties. Handing over this responsibility to a risk manager is also to be avoided. Both these lines of action deliver your future into the hands of others. The main line of enquiry should be to seek out and challenge assumptions. We can systematically review task plans to identify assumptions. For social uncertainties it is useful to ask similar questions about each relevant group. What have we assumed about the nature, stability, power and interests of this group and its individual members? How confident are we of these assumptions? Could there be a serious impact if we are wrong? Workshops and meetings are a good forum for uncertainty spoing, because we can observe and query the various factional and partial presentations of risks and uncertainties. In Chapter 9 we heard an example of the intensive work needed to establish a sound project reality. As well as holding numerous large meetings, the practitioner (Bernard, Projects with Drumbeat) also found that talking face to face was a crucial (although time-consuming) activity, necessary to ‘get to know them, look into their eyes to find out what is on their minds’. Through these means we must spot the potential frauds, and shake the tree to find out what is not secure. The risk register is a management tool, but it also has political implications. Some of the social uncertainties we identify cannot usefully be included. We have no project strategy for them, just our private plans for how we will respond. In the example there is no obvious purpose to the inclusion of two

142

MAKING SENSE OF PROJECT REALITIES

items (R6 and R7) which merely appear to highlight a lack of confidence on Robert’s part in his local and head office executive teams. It probably does not help to pre-warn them of these doubts. Some items may be included only to smooth relations. The inclusion of item R8, highlighting the problems that will arise from late specifications, is unlikely to make any difference in practice, but may have been added to protect the so
ware supplier’s commercial position. The risk register is a political document, and we ProjectCra
practitioners will use it as such. The impending arrival of a peripety (Chapter 9) will be included in our uncertainty management strategy. We must spot these messengers as they approach, and know which option will prevail – to press ahead with our existing plan or to divert to a new plan. When the strategy is inevitably going to change, then we ProjectCra
experts, a
er expressing suitable regrets to placate those who would rather continue as before, will be in the vanguard, encouraging and leading the switch to the newly emergent strategy. We will not be caught holding on, forlornly, to an unworkable strategy. We will assess and judge the likely impacts of uncertainties. An item (R5) in the example raises the concern that the administrators may not be happy with the delivered so
ware system, but Robert may consider that this does not really maer. If other teams have used the same so
ware and it carries a strong force majeur they will have no option but to use it, so their opinion is irrelevant. Nonetheless Robert might include the item on the register to show his concern, but it needs no mitigation plan. We have continued to see, throughout our examples, the ubiquitous forces of projectification. Project managers are perpetually under pressure to promise that their project is under control, and give commitments on completion dates or upper limits on expenditure. If they submit and give such commitments they are almost invariably wrong. On the other hand it is very difficult to aend a meeting with senior managers or sponsors and tell them ‘I don’t know whether we’ll succeed’. I know because I have tried it. They will look around for a more positive manager to replace you. A beer option is to follow a good faith line of explanation. ‘I am proceeding in good faith on the assumption that … will work. If it turns out that it doesn’t, then the project may be late on delivery.’ A similar line of argument will be appropriate if we embark on a speculative project or phase of a project. Examples would be investment in a development project with a low chance of success, or the adoption of a course of action in

D E A L I N G W I T H U N C E RTA I N T Y

143

the face of strong opposition in a difficult political situation. In both cases we would explain our high-risk position, but not quantify it. When the inevitable happens, and our project suffers a severe problem, we will usually take the hit; we have been unlucky. For reasons I have already aired we will, on principle, object to the introduction of remedial plans. If our organization is determined to ignore our good advice and act in this way then our priority is to expose and publicize the new uncertainties the revised plan will bring. The event that has caused our problem may well bring with it a learning experience: new knowledge that we can feed back into a review of our current plans. We will also consider whether the event could be used as a narrative that might lead to the reshaping of project aims. In particular we might argue for a redefinition of success to make the favourable outcome of the project less uncertain in future. These strategies apply to those who continue their role through the duration of the project. In practice, managers come and go, and those who arrive late have distinct advantages. We can adopt a rescuer role, seek out the existing deficiencies and uncertainties, and make the most of them, demanding additional budget and resources to deal with the mess. There is of course a converse side to this argument. Regardless of our ProjectCra
skills in dealing with uncertainties, there will be times when the chaos overwhelms us, and untoward events will inflict a degree of damage to our project that others consider unacceptable. When this happens those others may well react by finding fault with our performance as project manager, and call for our early departure. We may defend ourselves against this possibility by performing our own personal risk management, identifying potential hazards, preparing for them and if possible identifying a viable mitigation strategy. If there is no viable strategy we shall have to concentrate on preparing our explanations. Ultimately our most important mitigation plan will be in the form of our own escape plan. The whole edifice of project risk management can be treated as an element of our strategy to protect our personal risk, the reputation work we must perform to maintain our position. Narratives about uncertainty are part of our resources to manage the expectations and disappointments of those with whom we deal. If we claim all is well but it transpires that it isn’t, then we are likely to pay the price. If we exaggerate difficulties, we lose our credibility. Communication about the unknown is a crucial area of project skill, for the sake of our projects and, more importantly, for the sake of our own survival.

This page intentionally left blank

CHAPTER FOURTEEN

Quests for Value and Accountability While mainstream project management considers projects in terms of their deliverables, plans and controls, the examples we have examined have displayed three significant traits that distinguish them sharply from the project-perfect ideal.

1.

The world of work that project management aempts to structure is highly complex, in terms of our personal experience of work, and the technical and social issues we have to face.

2.

The performance of projects is a social activity, in which projects, and their successes and problems, emerge from the interactions between different social groups.

3.

Projects are driven by the need to create diverse forms of value for different groups, rather than simply being concerned with the delivery of tangible products.

Much of the discussion of this book has been concerned with understanding how practitioners deal with these issues, and the consequences of their chosen approaches. The possibilities for action have themselves proved to be complex, but we can develop a broad picture by seeing these possibilities as emanating from two general themes: two ‘quests’ that underlie the concepts of projects and their methods. The first is the Quest for Accountability. Our society expects that individuals and organizations will be held accountable for meeting their commitments. Institutions – governmental, voluntary and commercial – are structured to extract such commitments and to monitor their realization. This quest lies behind the ever-expanding scope of projects as a mode of working. The critics of these institutions contribute to this quest, seeking to judge and find culprits (‘Who is to blame?’) in the same terms. For this alliance of institutions and critics, projects are vehicles for the delivery of promises, and their purpose is the creation of order and control. The second is the Quest for Value. Managers and others are engaged in a continuous search to find ways forward for their organizations. They endeavour

146

MAKING SENSE OF PROJECT REALITIES

to make sense of their situation and then organize themselves to achieve their valued ends. One option (of many) at their disposal is to structure their work as projects. Within this narrative projects are a vehicle for creating value in whatever form it is perceived. In a simple world these two quests might be compatible and mutually supportive. However, when faced with the significant traits of real projects – complexity, social interactions, diverse value creation – they lead to different forms of managing, and have markedly different influences on how projects develop. These differences are summarized in Figure 14.1, and discussed in the following paragraphs.

THE QUEST FOR ACCOUNTABILITY AND ITS CONSEQUENCES The Quest for Accountability sets an agenda of compliance. While work may be undertaken by various distributed groups it is subject to centripetal control, tying it back to comply with the demands of those at the centre so they may achieve the promised ends. This need for control demands, in turn, the creation of high levels of order. Projects are seen to succeed or fail, judged on their ordered implementation and on whether they deliver their promises. The principles and instruments of mainstream project management are designed to deliver accountability. We expand the domain of projects to bring DRIVERS The quest for accountability

The quest for value

ACTIONS Control model Projectification, staged approvals, task-output toolkit, remedial action to control deviation.

Pragmatic organising Sensemaking, negotiation, social scanning, dealing with power, pragmatic handling of uncertainty, mixed modes of managing (control and organic).

PHENOMENA TRAITS OF PROJECT REALITY Complexity Social interactions Diverse value creation

Dubious projects: impossible scopes, frauds Overspends and escalations Pessimistic, inhibited creativity Alienation and resistance

Creative tension

Figure 14.1

The twin quests of projects

Permeable to social context, transparent dealings Dynamic: emergent strategy, reshaping, peripety Varied project modes: creative, taskdriven, extended journeys Optimistic, creative

Q U E S T S F O R VA L U E A N D A C C O U N TA B I L I T Y

147

all non-operational work within its control. We then subject each project to the staged approvals of life-cycle management, with the intention that any potential project that cannot comply with the standards of controllability is prevented from coming into existence. By this means we will only be held accountable for projects that are compliant. Project work is kept under tight control by employing the standard toolkit techniques for handling tasks and outputs, assigning defined packages of work to the various parties and holding each of them, in turn, accountable for the completion of the work in their scope. These methods conform to the control model of projects (Chapter 8). They are designed to create the illusion of order, the project-perfect, maintaining the pretence that those to be held accountable for delivery are in control of the work in hand. The possibility of deviations from plan is handled through systematic risk management, quantifying such deviations and bringing them back into the ordered domain. The interaction between the Quest for Accountability, with its idealized form of management, and the harsh realities of project life has been an important thread of discussion throughout this book. We have seen numerous examples demonstrating that the agenda of accountability and control fails with alarming regularity against its own criteria. As social groups manoeuvre to shape projects to suit their own ends they conspire to create all manner of dubious project forms (Chapter 7). Common examples include value overload (Chapter 11), where so many commitments are made to gain project approval that it becomes impossible to complete, and fraud (Chapter 7), where the main participants disguise the fact that it is not possible to complete the defined project. Skilled organizational players can therefore achieve their own local tribal aims, but they do so by subverting the control and accountability of the project. Projects are complex human and social endeavours (Chapter 3). All plans are necessarily partial and distorted presentations of the work that will actually be carried out, which is inherently unpredictable, and always likely to deviate from the plans, exceeding allo
ed timescales and budgets. When a project deviates from its plan the accountability narrative demands that its managers must avoid the project being classified as a failure, and therefore must take remedial measures to bring it back into order (Chapter 13). These remedial plans exacerbate the uncertainties

148

MAKING SENSE OF PROJECT REALITIES

of the project, and have the opposite effect from that intended, oen leading to exponential growth in costs, and in massive overruns. If the stage-gate approval system (Chapter 6) had been applied rigorously throughout history the human race would be very much poorer. There would be no pyramids, cathedrals, railways, aeroplanes, or any other technological advances. The system discourages the creative and innovative in favour of the predictable. The philosophy of accountability is inherently pessimistic, discouraging us from se
ing out on any journey unless the end is already in sight. Human progress is achieved despite the practices of project management, not through them. In a
empting to impose centripetal control over distributed work, project managers oen impose layers of management that are not compatible with the actual work to be performed. There is a continuous conflict between those who would impose project management control and those on whom it is imposed, whose work would oen thrive be
er under different management forms (Chapter 8). The laer are alienated from projects, and resist them. If le to its own devices, the Quest for Accountability, with its accompanying control rhetoric and management toolkit, would fare very badly. Fortunately it is generally countered by more pragmatic management thinking.

THE QUEST FOR VALUE AND ITS CONSEQUENCES Management is essentially about organizing. Those who ‘do management’ include those formally appointed by their organization to perform a defined management role, and also all those who in some way identify their own ambitions with those of their organization, and contribute to organizing its work. Sound management does not have a single formula or method – a universal solution – but is reflective. Managers seek to understand their situation and look for pragmatic arrangements that will make things happen and take them forward. If we apply this concept of pragmatic organizing to projects, then the purpose of projects is to create value in the form of something new. For an organization the ‘new’ would be in the form of a capability to do something it could not do previously, or to deliver benefits for themselves and for those with whom they deal. The creation of value depends on the creative energy of those involved: energy located in diverse groups of people, and centrifugal – pulling

Q U E S T S F O R VA L U E A N D A C C O U N TA B I L I T Y

149

away from the centre. Projects are judged on the collective sense they make to concerned parties, and on their contribution to the creation of value. The stories in this book have been told by pragmatic managers and so reflect this type of thinking throughout. Our analysis of these stories reveals many of the principles of projects when they are understood in this fashion. The management of projects is concerned with sense-making (Chapter 9): the negotiation of the project form, and the enactment of the project through its artefacts – documented plans, models and prototypes. Management activities address the social context: scanning the social environment, dealing with intergroup relations, and understanding and exercising power. We have also seen that a project and its shaping are highly dependent on the personal volition of individuals, acting to further their personal ambitions (Chapter 10). We expect to witness mixed forms of management. In terms of the vectors of project diversity (Chapter 8), we would expect the opposite poles of these vectors – the control model or the organic model – to be applied to suit the situation: at some times controlling from the centre and at other times divesting power (umbrella management) to those at the periphery. There will be some quests for value, including some business transformations (Chapter 12), where we recognize that projectification is a mistake, and that the project is not the most appropriate vehicle for the journey. Uncertainty is recognized as social and endemic to projects. In the face of uncertainty, we adopt pragmatic strategies. The aim might be to reduce it and control deviation, or it might be to pause and reflect and to seek alternative courses of action. These approaches are adopted by expert practitioners to deal pragmatically with the traits of real projects – complexity, social interactions, diverse value creation – and so produce projects that are responsive to these characteristics. Projects are permeable in the sense that they are open to influence from the different parties having an interest. Social interactions will usually be made transparent (Chapter 7) to expose the interests and dealings that might otherwise lead to the distortion of the project into something fraudulent or dubious. Projects are dynamic entities. Strategies can emerge as the journey proceeds, the project being continually reshaped in the light of developments, and stabilized through enactments (Chapter 9). The

150

MAKING SENSE OF PROJECT REALITIES

possibility of peripety – the dramatic change of course – is a welcomed opportunity to achieve new forms of value. Projects will go through different phases. At some times they will be organic: fluid and creative, looking for new ideas and concepts. At other times, but not prematurely (Chapter 5), they will coalesce into defined tasks in accordance with the control model. At yet other times there will be journeys of change over extended timescales, during which the tangible outputs are taken on board and turned to good use. Organizations as a whole will make pragmatic decisions on whether the project mode of working (Chapter 6) is their operational policy, adopting it as a means to focus efforts on a central strategy, or discarding it to empower local and individual creative initiative. Projects driven by the Quest for Value are essentially optimistic. They can start out on the basis of nothing more than a possibility – a promising idea, which is investigated and developed as the project proceeds. Such projects may lead to a completely unexpected destination, or to nowhere of any value. This is not a fault. The real world abounds in journeys of this kind. The need is for the discipline of project management to be able to recognize, accept and handle this kind of project.

THE BALANCE OF POWER In summarizing the state of projects in terms of these two themes I have perhaps created an artificial dichotomy, as though our projects will be located on one side or the other of an unbridgeable divide: founded either in accountability or in value creation, managed through control or through pragmatic organising. In fact, all projects will be influenced by both elements. Those who run controloriented projects will have value-driven pragmatic decisions about changes of direction thrust upon them. Those who lead value-driven programmes of work will find they are subjected to demands for accountability, which they must deal with pragmatically (and oen through defined tasks and controls). The forces of projectification are a response to the fragmentation of work (Chapter 5): the outsourcing of work to multiple distributed organizations, the devolution of government services to the private sector. A tension will always exist, the initiative of the peripheral organizations being tied back into compliance with the policies of the centre through project control. The centrifugal force due to the distributed energy of those performing the work must be balanced by the centripetal pull of mainstream project management.

Q U E S T S F O R VA L U E A N D A C C O U N TA B I L I T Y

151

We can read this tension in the stories told by managers. Their concerns are twofold: how to create activity – ‘Is anyone doing anything?’, and how to create trust – ‘Are they doing what we expect of them?’. Most of the anguish of project management can be summed up in these two questions. The anomalies in the world of projects arise because these forces are not in balance. The Quest for Accountability, with its control model of projects, takes precedence, but as we have seen above this model is oen unable to deal with project realities. Projects, as a means to organize working life, are therefore not generally in a healthy state. If the state of projects is to improve, we must alter the balance in favour of the Quest for Value and its more flexible forms of management, which can beer handle complexity, social interactions and value creation. It is my aim in this book to raise the profile of this issue, but awareness itself is unlikely to have any significant impact. Politicians and the leaders of business are enslaved by the Quest for Accountability. They exist primarily to act out this concept, responding to the demands of their stakeholders – the electorate, the shareholders – for promises, control and delivery. As individuals working on projects we can, in principle, decide our own positions on this issue. However if we choose to veer towards the path of flexibility and pragmatic value creation, and resist calls to follow the dictates of control-oriented project management, we will be going against the flow of the traffic. This particular assertion of personal volition – ‘I don’t do it that way’ – demands perseverance and confidence. Some, including many of the speakers quoted in this book, have acquired that confidence through long experience. To support a faster learning process for others I have used the concept of ProjectCra to note the capabilities demanded as the issues have arisen. In the next chapter I will summarize these capabilities and tabulate them systematically. Encouraging new thinking among project practitioners will help, but the institutional problem still remains. Many organizations, in government and in business, continue to run thoroughly bad projects despite having, among their senior staff, individuals who understand the issues we have covered. We should therefore examine the functioning of the institutions of projects, which I shall do in Chapter 16.

This page intentionally left blank

CHAPTER FIFTEEN

ProjectCra Whenever we have identified some expert cra abilities I have assigned these to the category of skills labelled ProjectCra. The first part of this chapter draws together and tabulates all maers that have been raised: the second part discusses how such capabilities can best be acquired.

THE NATURE OF PRACTITIONERS – PROJECTCRAFT To recapitulate, in Chapter 2 we noted that the capabilities of individuals to perform in a project environment could be divided into mechanistic skills and expert cra skills. The former concern what we know about the contents of the toolkit of project techniques; the laer concern being effective in dealing with projects; understanding, thinking and knowing how to act. In this book I have not taken much interest in mechanistic skills, which are widely promoted in mainstream books, manuals and courses and automated in many soware applications. My general lack of interest should not be taken as implying a belief that those currently in use are perfect, and I have noted in passing some examples where significant improvement could be made, for example corporate veing of projects (Chapter 6), management of benefits realization (Chapter 12) and management of risks and uncertainties (Chapter 13). An important aspect of ProjectCra concerns being able to use these methods intelligently, and that, in turn, involves recognizing when they are deficient and how we can find a route forward despite their deficiencies. In the tables that follow I have collected together all instances of the second type of capability – ProjectCra – that have appeared in earlier chapters. Different people in different roles need different capabilities, but it is not possible to make generalizations about what people in named roles (for example project managers) should be able to do; despite many aempts at standardization, there is no single concise definition of these roles. Instead my organization of the tables is essentially tribal. Different groups of people have different forms of practice. It is their understanding of what they are there to do, their project experience, locally situated, and their shared knowledge of how to handle it, that makes them a distinct collective group that we can consider

154

MAKING SENSE OF PROJECT REALITIES

as a whole – a practice group or tribe. I have arranged the tables under the global headings of the typical tribes of the project world identified in Chapter 4. To these I have added an extra group whose skills need to be recognized – the opponents of projects. If your own tribe performs the functions in a table heading, then the contents of that table provide an outline of the ProjectCra your group will need, individually and collectively. Despite this subdivision there are some very important characteristics common to the life of all people, regardless of their role, who are touched by projects – the metatribe of project practitioners – and we shall start with these. Table 15.1

ProjectCraft for all

All who practise projects, whatever their roles, seek to be competent in a project environment, by understanding the forces and practices that frame their work. Social context (Chapters 4, 6, 7 and 9) Projects emerge from and are performed within a social world, populated by groups with their own interests. Groups may be semi-permanent (e.g. practice groups) or may be temporary (e.g. project teams). We must scan this world, recognizing the social groups who have an interest in our projects, and understand their agenda, power and influence. This ability depends on establishing close face-to-face relationships with all parties. Pendulum of power (Chapter 6) The power in organizations swings between different factions, and particularly between central control and distributed autonomy. The discipline of project management is an instrument of central control. We should recognize the swing of the pendulum, and deploy our project capabilities to aid it, in whichever direction. Local language (Chapter 2 and throughout) Every organization has its local language of projects, through which people negotiate project scopes and plans. At a minimum this will include terminology for different classes of project, for particular forms that projects may take, and different roles that parties and individuals might take. It may also reasonably be expected to address all topics covered in the vocabulary appendix, and other matters specific to the local business. We should be fluent in this language, and contribute to its development, recognizing needs for new terminology. Local heuristic theories (Chapter 3) Every organization has its local heuristic theories: explanations of how projects are to be organized and controlled. We should understand and apply these theories, make them explicit and contribute to their development, recognizing when new situations require new theories.

P R O J E C TC R A F T

Table 15.1

155

Continued

Mechanistic tools and standards (Chapters 3 and 9) The discipline of project management has a wealth of tools, techniques and standards within its domain of knowledge. We should use these methods – our toolkit – pragmatically to support our preferred shaping of project sense, applying them, amending them, or sometimes ignoring them, to create our preferred form of project order, furthering the project ends we are seeking. Vectors of project diversity (Chapter 8) Projects vary in their form along many dimensions or vectors. These are aspects of two more general contrasting poles: between a control model of projects, in which we define what the project is and then attempt to control it, and an organic model of projects, in which we create a space within which the project can take form and grow. We should seek to place our project work in the appropriate mode on each vector, recognizing when each pole is appropriate, and moving between them as the situation demands. Reflective practitioners (Chapter 9) People reflect on, and make sense of, the situations in which they find themselves. It is this understanding of what is going on that underlies how they go about their work. We can better serve the projects we work on by recognizing this process and encouraging it in ourselves and others, rather than by slavishly following the orders and practices laid down by managers. Allegiance (Chapters 4 and 10) As partisan players we choose our allegiances to the various groups who operate in the project world. We must do this with care (taking account of our understanding of the prevailing power relationships). Project identities (Chapter 9) Practitioners (ourselves and others) ‘create’ themselves so that they may be perceived by others in their desired form – their project identity. We must work to promote and maintain our chosen identities, constructing explanations of ourselves and our decisions, and protecting our reputations. Narrative skills, creating stories of projects and our roles in them, are essential to this work. If we aspire to a more senior identity (e.g. the company oligarchy) we must learn and speak the local language of the role to which we aspire. Learning (Chapter 15) Since ProjectCraft is about social practice, the learning of its skills must necessarily take place within the working environment rather than in remote training courses. To be effective as ProjectCraft practitioners we must be active in cultivating our learning processes. (See discussions below on reflective practice development and Action Learning.)

156

Table 15.2

MAKING SENSE OF PROJECT REALITIES

ProjectCraft for project directors

Working on behalf of governments and corporations to drive a central agenda of accountability and control, promoting management by projects as a way of life. Artefacts of corporate control (Chapters 6 and 13) Governmental and corporate directors set up managerialist arrangements to control projects: standards and procedures, the nurture of a profession, systems for project decisions and authorizations, judgements of success and failure, allocation of penalties and rewards. The intent is often to establish projects as the normal mode of business. We must ensure the arrangements provide adequate controls to prevent bad projects and reduce uncertainty as far as possible before significant investment is made. We must recognize that by privileging central control we devalue the agenda, initiative and creativity of the distributed parts of the organization. To counter this we must find ways to permit optimistic, speculative and autonomous work to continue. Beware projectification! Multiple projects – the pendulum of power (Chapter 6) The power in organizations swings between central control and distributed autonomy. We must understand our organization’s particular needs for centralized project management. There will be times to strengthen central vetting and approval of projects, and times to relinquish control and encourage autonomous action by the managers of the diverse departments and agencies of the organization. Promoting project management – and ProjectCraft (Chapter 14) Senior managers promote project management as part of their quest for accountability. We need to understand the limitations of mainstream project management, and the damage it can do: dubious projects, overspends and escalations, pessimism and inhibited creativity and alienation and resistance. We need to promote more pragmatic thinking about projects: aligned to their social context, dynamic and flexible, optimistic and creative.

P R O J E C TC R A F T

Table 15.3

157

ProjectCraft for strategists

Strategists of the centre are the agents of central policy-makers, using projects to deliver a strategy. They are concerned with creating projects, while preventing peripheral and non-essential activities. Vetting and approval of projects (Chapters 6 and 7) Programmes of the ‘right projects’ are established through structured decisions and stage-gate approvals that set up, delay or close down particular projects. We must ensure that evaluations and decisions are transparent, revealing the agenda of interested parties, to prevent the inadvertent initiation of fraudulent projects. However there will also be times when we have good reasons to kick off a highly optimistic project with little chance of meeting its declared aims. We should not force early creative work to comply with the strictures of the control model of projects. Beware premature projectification! We should also watch for unique opportunities, finding the moment when the political climate lets us proceed with a project that would not meet the usual criteria. Corporate value (Chapters 11 and 12) Programmes of projects are established to deliver corporate aims (where we are going, the value we seek to realize, and how we will get there). In evaluating potential projects we should take account of wider forms of value – social impacts – rather than merely the traditional criteria of time, cost and meeting performance demands. We should make pragmatic decisions concerning whether our aims will be best achieved through a central unitary project, or through autonomous working in different areas; when we should follow an agenda of control, and when an agenda of trust. Project language (Chapter 2 and Vocabulary; see also Table 15.1) Effective project negotiations depend on having a language that illuminates the issues that are critical. We must develop and make explicit the language we need to discuss the varied scope and nature of our projects. Project heuristics (Chapter 3) We should develop a local understanding of standard good project practice – how we handle projects: values and principles, heuristic models, systematic approaches, typologies for different problems and routine procedures for decisions. Uncertainties (Chapter 13) Managers often prefer to protect themselves by removing all uncertainties from projects before allowing them to proceed. We should recognize that projects are human and social endeavours and cannot be stripped of uncertainties. We should learn when to stand firm and delay the project until a more certain course can be found, and when to press ahead despite uncertainties, fully aware that we might later find we have taken the wrong course.

158

Table 15.4

MAKING SENSE OF PROJECT REALITIES

ProjectCraft for project shapers – general

Shapers are the project designers, negotiating and setting the agenda of individual projects. Drumbeat (Chapter 9) For a project to be effective it must have ‘drumbeat’: vision, clear identity, negotiated understanding and support. We, as shapers, must ensure our projects have drumbeat. Interested parties (Chapter 4) For any project there may be many would-be shapers, all pursuing their own version of value. For a project to be effective it must be supported by all groups with an interest and the power to impede the project, or their opposition will sap the project’s energy and it will stagnate. We, as shapers, must scan our social environment, identify all relevant parties, and flush out their agendas and their power and influence. We will engage in face-to-face negotiation and renegotiation, and shaping and reshaping of the project throughout its course. We can choose to defend our project against outside influence, or open it up to that influence, to hold our course or change course. Projectification (Chapter 5) The forces of projectification encourage the conversion of work into projects even when it is not the appropriate mode. We shapers must resist projectification unless we are satisfied that a project is viable. Value creation (Chapter 11) The purpose of projects is to create value for the interested parties. We shapers must ensure the project’s conception of value gives it strong direction. We must also guard against value overload, where too many stakeholder demands are incorporated into an over-complex scope that cannot be delivered. Enactment (Chapter 9) A project is given clear direction and stabilized through processes of enactment – the creation of artefacts that make it real. As shapers we must have a wide and varied repertoire of enactment skills. These will include the creation of documented plans, objects (eg models, prototypes) and leaders (the ‘face of the project’). Peripety (Chapter 9) All projects are open to peripety – a sudden change in the conception of what the project is about. We shapers should scan the social horizon for the messengers who may be bringing the news that could redirect our project. We must be able to make astute decisions as to whether we can or should hold firm, or change course. Exercising volition (Chapters 5, 9 and 10) The form of any project is highly sensitive to the decisions and volition of strong individuals. We shapers will exercise our volition to shape projects in accordance with our allegiance to our tribe(s), and in furtherance of our personal reputations, project identities and ambitions. This will normally require us to shape sound projects, but we will recognize that in any situation there will be a number of sound options from which we can choose.

P R O J E C TC R A F T

Table 15.5

159

ProjectCraft for project shapers – transformation agents

Transformation agents are concerned with shaping projects to achieve strategic aims through organization change. Transformation essentials (Chapter 12) The transformation of a business entails a mixture of time-limited projects with tangible deliverables, and extended journeys of change to realize benefits. We should understand the necessary mixture of management modes, ‘hard’ mainstream project management techniques, transactional management actions, and facilitation of continuous improvement. The tangible deliverables have a significant influence on the continuing journey of change. When possible we will create sufficient force majeure, so that the changes and benefits will follow on without the need for further project-level interventionist management. Transformation project (Chapter 12) A business transformation may not comply with the traditional mainstream definition of a project. We can make a powerful move – a clear statement of management intent – by defining the transformation as a project and managing it as such. Planning (Chapter 12) A transformation will be iterative, and involve changes in managerial ownership – a central project team for tangible deliverables, and also local managers to realize the intended benefits. We must recognize that it is not possible to through-plan a transformation. We may plan small sections (sub-projects) but the journey of change elements of the transformation will take on their own form, plans emerging as they proceed. Benefits realization (Chapter 12) Benefits will usually be realized through a complex interaction of subprojects leading to downstream social impacts. Complex maps of this process are not realistic. We should map benefits to create a simple narrative of where we are going: to show our purpose and how we propose to proceed, to highlight the deliverables from our subprojects, and to help us track tasks and actions.

160

Table 15.6

MAKING SENSE OF PROJECT REALITIES

ProjectCraft for project deliverers

Project deliverers are those who take responsibility for delivering a project (or part of a project). Project toolkit (Chapters 3 and 9) The project management discipline provides project deliverers with a toolkit of standard methods: the artefacts of project control. We should use these pragmatically, adapting them to support our needs of the moment, ignoring them when they are inappropriate. Value chain (Chapter 11) The ultimate purpose of the project will be to deliver value to interested parties. We should ensure that end points defined as our responsibility only include matters reasonably within our control. This will normally exclude social impacts as these are almost always subject to unknown social influences. Vectors of project diversity (Chapter 8) The mainstream project management toolkit enacts a control model of projects. This is not the only way to manage projects. We must recognize the variety of forms that projects take, and particularly the vectors of the organic model, for which different forms of managing are more appropriate. Uncertainties and commitments (Chapter 13) Projects are human and social activities, and so inherently uncertain. Despite this, those responsible for delivering projects are asked to give promises and commitments. Mainstream project management addresses this problem by listing and quantifying uncertainties on a risk register. Uncertainty spotting is a key skill. Social uncertainties predominate and cannot be quantified. We cannot therefore give reliable promises; quantified contingency statements are fabrications. We should give stakeholders honest appraisals of our level of confidence in the project, which may often be very low. We can protect our position by demanding that all uncertainties are eliminated or minimized before a project commences, but this is unlikely to be a successful tactic, or to be well received. When untoward events occur we will be pressurized to take remedial action. Such action should be resisted; it will invariably introduce further uncertainties, make successful completion less likely and will increase the risk of massive escalations in costs. Project manager for delivery (Chapters 9 and 10) Project managers are frequently appointed to deliver a defined scope of work, and are expected to resist changes to requirements in the interests of delivery. We must recognize that this is an illusion; we should always be looking for beneficial changes, and be prepared for peripety. An expert project manager for delivery is at the same time an active project shaper. Overwhelmed by chaos (Chapter 13) Despite our best endeavours, we will at times be overwhelmed by chaos, and there will be significant overspends and time over-runs. We must anticipate these and prepare explanations in defence of our reputation. We should always have an escape plan.

P R O J E C TC R A F T

Table 15.7

161

ProjectCraft for the priesthood

Various bodies act as custodians of project management knowledge. They include inhouse expert practice groups, independent standards organizations, associations that claim to be professional bodies and universities. Bodies of knowledge (Chapter 16) Written-down knowledge of techniques is mechanistic, and does not address ProjectCraft. We must develop practice-based ProjectCraft understandings of the field. Operatives and professionals (Chapter 16) Some bodies purport to represent professional practitioners, but their criteria for membership are based on the mechanistic skills of project operatives rather than on professional practice. We must develop a professional home for those practising ProjectCraft.

Table 15.8

ProjectCraft for opponents of projects

Many people are alienated by projects, feeling that this ethos does not support the work they carry out. Forms of resistance (Chapters 8, 9 and 13) Because of the need to give commitments, inexpert project managers attempt to draw all relevant areas of work into the project domain. This may be inappropriate. We should resist unreasonable imposition of project working. We can propose alternative organic forms for the project and its management, recognizing our need for autonomy (eg umbrella management). We should refuse to give project-like commitments to deliver output or promises for social impacts beyond our control, giving, instead, best-endeavour undertakings. We should act as project shapers and work to change the project scope to our advantage (e.g. by removing our work from the core deliverables). We will maximize our ability to support our interests thorough social scanning and by engaging in inter-group project negotiations. We should ally ourselves with those having the power to influence the project scope in our favour.

162

MAKING SENSE OF PROJECT REALITIES

HOW TO DEVELOP AS PRACTITIONERS To be good at projects we need both knowledge of mainstream tools and techniques and the cra skills of the expert practitioners. For the standard forms of knowledge there are books and manuals, and a plethora of taught courses that can provide us with details of the techniques. This knowledge concerns knowing about things: facts we can possess. We will do our best to store this knowledge – our project toolkit – as we acquire it, slo
ed into our mental pigeonholes, saved as presentation slides, or stacked as course notes in boxes under our desks, systematically accumulated and ready for retrieval when needed. This accumulation of knowledge will take the student forward through the territory of the project mainstream, to be trained and qualified as a project operative. For those with an inclination to occupy their time collecting facts, this route may be tolerable enough. A more purposeful and efficient approach is to wait until a real need to learn arises. This second strategy is more focused because it changes the nature of our learning question. Rather than asking ‘What is there to know about topic x?’ we are asking ‘How can I apply topic x to help me?’. We move away from knowledge as something to be possessed towards knowledge as a part of how we practise our work. Instead of a
empting to learn everything there is to know, hoping that we may one day find a use for it, we learn what we need, with a focus on specific ends. This is a very practical approach, and is an efficient use of our time because we will find that there is really not much that we need to know. In Chapter 5, for example, Mahew the ambitious young project manager learned, in ‘a few weeks’, sufficient to demonstrate his control of the project. In Chapter 13, Cameron turned his aention to benefits mapping, not to learn all about it but simply to find a way to explain his business case to his sponsors. In both cases they were diverting their energy from the acquisition of information to finding out about possibilities for action – shiing their aention from an interest in nouns to an interest in verbs. The taught course is a valid means to acquire this mechanistic type of knowledge because it can be defined and codified, and then imparted to the student. ProjectCra capabilities, on the other hand, are not susceptible to this approach because they are embodied in expert action rather than in facts. This type of learning was traditionally engendered through apprenticeship, where the student worked alongside and was mentored by the experienced master.

P R O J E C TC R A F T

163

Despite the unfortunate decline in the apprentice model, its basic principles, in which learning comes through participation in real action, remain crucial. The challenge for organizations is to provide their project people with structured programmes that give them opportunities to learn through experience. To provide such programmes, organizations must first address the multiplicity of roles and functions performed by their staff, and the different scopes of learning these demand. The best project organizations set out clearly the roles played by people at all levels in different parts of their organizations, and their expectations of the functions these people will perform in optimising project performance. If this is done well then it will not be a difficult additional task to map out each group’s responsibilities against my tribal grouping in the ProjectCra tables to produce a basic learning agenda: what people need to be able to do. In speaking of development we are considering both individual skills and collective organizational capabilities. It is not feasible to address one without the other. Our interest is to improve the collective practice of projects, how ‘we’ together go about our work. Given that we have defined the general scope of the subject maer we wish to learn (or wish others to learn), what types of programme can support the learning process? Without wishing to be prescriptive, I outline below two perspectives on learning that are compatible with the principles of ProjectCra. The Reflective Practitioner In Chapters 2 and 9, I introduced the concept of the reflective practitioner as a description of how individuals think and act in organizations, reflecting on the situations in which they find themselves, understanding the relevance of the practices they employ, and considering alternative possibilities for action. Our route to personal development can build on this concept, but to do so we need a structured framework. Learning arises not from pure reflection, nor from the acquisition of new theories, but from the interaction between the two. We advance our understanding by reflecting on our experience in the light of our theoretical understanding. This has been a guiding principle of this book. We hear a story about practice, and then evaluate that story against the frameworks of ideas available to us. However; our learning experience here has been vicarious, wrested from the experiences of others. To learn as reflective practitioners we must first tell our own stories. We can be systematic in our choice of what it is that we reflect on: significant events, critical incidents, interactions with others, project outcomes.

164

MAKING SENSE OF PROJECT REALITIES

Second we need frameworks against which we will compare our experience. My general preference in this book has been to reflect on our speakers’ experiences, initially against the standard practices of project management, assessing their relevance and value, and then against new frameworks, such as social processes and value creation. A similar structure can be adopted for further learning from experience in the workplace. The intent is to make pragmatic use of theory, using whichever perspective or perspectives are of value in helping us understand our practice. The ideas summarized above as ProjectCraft are a contribution to this repertoire.

Action Learning Action learning is a process through which a group of people communally develop their capabilities; participants learning with and from each other. Its starting point is an expression of doubt, the recognition of problems that have no solution. A team will be established to find new ways of working: a cooperative endeavour between comrades in adversity. Having identified a problem that needs attention, the process will follow the principles of a research programme: management action to set up the inquiry, the establishment of the learning group (an action learning set), problem definition, observations and the collection of data, the review of options and decisions and implementation of the conclusions via teamwork. The action learning process is itself very general: it can be applied to any problem and is not linked to any specific framework of thinking. However, we can focus it on the big issues of projects through an injection of the ideas of ProjectCraft. The problems we should choose to address are the topics that have concerned us in this book, for example: the dubious projects with impossible scopes, frauds, overspends and escalations, the inhibition of creativity, concern for social benefits and the handling of complexity and uncertainty. We can also use ProjectCraft to guide the direction of our researches, for example towards social groups and their interests, processes of sense-making, concepts of value and its creation, and the diversity of project forms and their management.

The essence of both of these approaches is similar. They are ways of proceduralizing processes of social learning: grounded in the local actuality of working on projects, and based on a collective process of inquiry into how we go about our work. Instead of a classroom ethos, in which rules and an illusion of certainty are transmi
ed from teacher to pupil, we have experience-based learning, building from doubt and uncertainty towards genuine understanding, emancipated from the unnatural constraints of conventional project wisdom.

CHAPTER SIXTEEN

The Business of Project Management Despite many criticisms the business of project management continues its relentless growth. Hundreds of thousands define themselves as project managers, many joining associations that claim to be professional bodies. Its exponents promote the discipline as ‘a profession’ and propose that the project form should be the norm for all work that is not day-to-day production. In fact the expansion of project working has itself many of the characteristics of a project – a mega-project to deliver a major transformation to the business world. If we consider its value chain, it has several tangible outputs: the tools and techniques, books and courses, and the hordes of project managers, qualifications in hand, who have infiltrated our organizations. Its outcome, the immediate effect on working life, is the encroachment of the project form of management across the world of business. Its intended social impacts are the two quests we have identified: for accountability and control, and to support the creation of value. I have already expressed my own view on this mega-project juggernaut. It is not going well. Precedence has been given to the artefacts of control, the illusion of the project-perfect, the obsession with success and failure (and too o
en the laer). In our forlorn efforts in search of the former quest, accountability and control, we have damaged our ability to pursue the laer, the creation of value. We have emphasized mechanistic technical skills, training people to be project operatives rather than helping them learn how to be accomplished performers of ProjectCra
. This mega-project also has disturbing similarities to typical less than successful business transformation projects: efforts are concentrated on the delivery of the tangible products, and lile coherent thought is given to how the intended social ends might be realized. Why has this come about? Having made this project analogy, we should perhaps analyse the situation using my preferred perspectives for understanding projects. We should examine the various institutions and social groupings of the project management world, their interests and conceptions of value and

166

MAKING SENSE OF PROJECT REALITIES

how they pursue them, their power, and the relationships between them. Since I have commended simple benefits mapping as a technique for managing business transformation, perhaps we should aempt to map the subprojects and benefits of the growth of project management itself? The main institutions of the project business are briefly described in the following paragraphs.

ASSOCIATIONS I am referring to the associations that are primarily for individual members and stake their claims to be the professional bodies for project management. The most prominent examples are the Project Management Institute in the USA and the Association for Project Management in the UK, but my remarks are general. These organizations act as custodians of project management knowledge. They commission studies on the subject and publish descriptions of the field as ‘Bodies of Knowledge’. They control membership, defining levels of practitioner capabilities, and regulating admission to different hierarchical grades of membership. They provide opportunities for training. They promote the ‘profession’, acting as protectors of the faith, championing and campaigning for their collective members and the discipline as a whole. They publish periodicals and books, expounding good practice and extolling its benefits. At first sight these organizations, with their domain of expertise, control of membership and campaigning roles, might be thought of as being professional bodies, and they make loud claims to be so. However their knowledge base is limited to the toolkit of the control model of projects, and their certificates of competence relate to project operatives – those who apply these tools and techniques. In making this the focus of their interest the associations are responding to government demands (see below) to qualify thousands of people to this limited level of competence. If we look across at professional associations in other fields we see a sharp contrast. Professionals in other fields are people who make independent professional judgements and decisions, based on abilities they have developed through years of training and experience. Project managers and other project practitioners do indeed regularly make decisions that could reasonably be described as professional: decisions

T H E B U S I N E SS O F P R O J E C T M A N A G E M E N T

167

concerned with the negotiation of sound projects. These call for profound understandings and judgements about the social world of projects; they are part of the practice of ProjectCra
. The project associations, however, exclude this area of expertise from their scope, employing a reductionist definition of project management concerned with planning and control. The capabilities they endorse, the mechanistic skills of toolkit project management, can be picked up in a few weeks. The associations do pay lip service to experience, demanding a number of years experience in each role to qualify the holder for advancement to the next. However there are no structured learning requirements aached to this experience, and the member promoted to a membership grade implying senior competence might well have learned very lile during this period of experience.

STANDARDS ORGANIZATIONS Standards organizations produce documented standards for the performance of project management. Some, such as the British Standards Institute (BSI) and the International Standards Organization (ISO), are general standards organizations who have chosen to expand the scope of their publications into the realm of project management. Others produce standards for specific industry sectors. One particular standard, PRINCE2 ©, started life as a standard for the management of so
ware development projects, but is now widely adopted as a general standard for project management. In principle these organizations provide an important function. Standards produce a commonality of concepts across organizations. The negotiation of a project scope across diverse interested parties can be performed more effectively if these parties can communicate in a technically advanced common language. Standards, however, tell you nothing of how to act, or how to differentiate a good strategy from a bad one. We also need to be able to judge when a standard will further our cause, and when it ought to be revised or ignored. There is a danger that senior management teams may completely misjudge the nature of standards, believing that the adoption of a standard will somehow bring effective project management into their organization.

168

MAKING SENSE OF PROJECT REALITIES

GOVERNMENT Government can be considered to be acting in two modes. In the first they are pursuing an agenda to create an environment of control over government programmes and expenditure. They promote the production and application of standards and the accreditation of individuals to apply these standards. Government departments responsible for the delivery of programmes are acting in a second mode using projects to deliver strategy. For them, the imposition of the standard mechanistic tools will o
en seem irrelevant because these do not deal with the problems surrounding the creation of effective projects. In the UK this discrepancy has at times led to strategic managers becoming severely alienated from the policy of introducing project management. Finding themselves in this dilemma, government strategists have responded by developing their own local versions of how they will do projects, moving towards the corporate model to handle the business of projects (see below).

CORPORATES When major corporations have a significant proportion of their work performed through projects they will generally define their own versions of how projects will be managed, covering standards, procedures, practice guidance, governance arrangements and staff development programmes. Effectively an internal expert practice group is formed who will develop their organization’s ability to perform projects, tailoring practices to address the issues faced by the business. To develop their staff they may use the associations, or related consultants, but only to train people to an entry level of qualification. To develop professional ProjectCra
capabilities they must set up their own development programmes, for which they may link up with universities (see below).

UNIVERSITIES Many universities have departments or groups expert in project management, operating either within their business schools or in the discipline departments for which projects are an important management approach (for example engineering, architecture, or computer science). Universities can provide postgraduate education, which should take students beyond the control-model toolkit and into the domain of ProjectCra
.

T H E B U S I N E SS O F P R O J E C T M A N A G E M E N T

169

The best adopt practice-based learning methods, guiding their students through a participative process of inquiry into the performance of real projects. Universities also carry out research into issues of concern about how projects are practised, developing new ideas and enhancements. In principle these two arms, the educational and the research, should be integrated and mutually supportive. These important roles for universities, however, are only taken up by a minority of institutions. Most prefer to respond to the lucrative demand for project operative qualifications. Degree-level courses in a wide range of subjects are supplemented by project management modules, in which the basics of mechanistic tools and techniques can be passed to students with minimal effort from either party. The organizations discussed in the sections above are major players in the world of projects. Their activities and impact are summarized in Figure 16.1. We can see from this diagram that our mega-project, the advance of project management, has two separate strands: the toolkit industry, and the corporate practice of projects. The former delivers to society the illusion of control and a legion of project operatives to sustain that illusion. The laer delivers value through projects and creates a community of professional managers competent The toolkit industry Accountability Standards development

Government Central need for environment of control

Toolkit knowledge

The illusion of control

Accredited project operatives Departmental need to deliver strategy Support: • Associations • Universities • Consultants

Corporate practice groups Universities Toolkit modules

Identities Qualified project operatives

ProjectCraft professionals

ProjectCraft practitioners

Pragmatic use of toolkit

Value

Practitioner development Knowledge of good practice Research ProjectCraft thinking

Figure 16.1

The business of project management

Value through projects

170

MAKING SENSE OF PROJECT REALITIES

in ProjectCra
. There is a severe dislocation between these two strands. The intense activities of the toolkit industry make a minimal contribution to the delivery of value. In the stories aired in this book , the experienced practitioners rarely mention the conventional tools of project management, which they treat as a minor preliminary to the real job, their pursuit of value through projects.

WHERE NEXT? It is tempting at this point to make radical statements about what should be done to rescue our mega-project from its problematic position; to produce a grand remedial plan to restructure the business and set it back on its feet, on course to its triumphant conclusion. However there is lile point in such sweeping proposals. There is no centralized power, a super-project manager we could advise and who would then take action. The power is distributed among the parties we have identified, and they appear in general to be content with the roles they play. As the mere author of a book I have no power base I can bring to bear. My strongest hope is that this and similar tracts might achieve some recognition. I should like to consider myself as bringing a dramatic message to the world of projects, but I do so more in expectation of being shot as an unwanted messenger than of heralding a radical peripety that will transform the project world. It is very tempting to be critical of the project associations. However, they are only acting as diligent suppliers, of toolkit knowledge and accredited operatives, to the toolkit industry. They manage a sub-project, the development of this reductionist version of project management. We might chide them for their over-inflated claims of professionalism and discipline leadership, but there is no reason to expect them to change their spots and become genuine professional bodies. Their position, with rapidly expanding membership, is a very comfortable one. A more likely route to producing an impact is through those who are concerned with developing professional practice, the universities and the expert practice groups within major companies and some parts of government. These groups may find the ideas we have discussed are a useful contribution to a continuing improvement in their ability to create effective projects and deliver value. The most significant gap in the organizational map of the project world is the absence of any institutional home for advanced thinking such as we have

T H E B U S I N E SS O F P R O J E C T M A N A G E M E N T

171

discussed under the label of ProjectCra
. Most professions have some form of central establishment, encapsulating their power and leading their new thinking. Here the forefront is distributed among a large number of universities, project directorates and centres of excellence in large organizations. These people get together in conferences, networks and various industry bodies, but is this sufficient? When we discussed how sense is made on projects we observed two critical factors: the concentration of power, and the enactment of sense through artefacts. The same factors are required to influence the mega-project that is the overall advancement of projects in the business world. If there is to be a shi
in the predominating sense that forms this mega-project, from its obsession with control towards the delivery of value though ProjectCra
capabilities, then there must be a new centre of power to balance that of the project toolkit industry. The expert knowledge of how we can develop effective practitioners must be captured and nurtured within it, and not merely scaered among diverse learned papers and books.

IN CONCLUSION To conclude I can only return, like a virtuous project manager, to the requirements in my introduction, where I laid three charges against the rationale of projects. What verdicts can we reach on these charges?

1.

Performance deficit The world of projects is obsessed with rhetoric of success and failure, driven largely by the current political and economic climate and the Quest for Accountability. When this demand for order and control comes face to face with the realities of complexity, individual and social interactions and uncertainty, problems arise. We see misshapen projects, failures that could have been predicted at the outset, and projects that head off in new directions despite futile efforts to restrain them. The ill-thought-out remedial actions of managers cause further escalations and lead to massive overspends. Instead of focusing entirely on plans and controls, we should endeavour to differentiate sound and unsound projects. The former are in harmony with their social context, with a vitality – a drumbeat – that drives them forward, delivering value to all who participate in them. Their strategies emerge as they proceed, and they are responsive to change. The creation of such projects is the aim of a mature project management profession.

2.

Alienation The mainstream management of projects is exclusively concerned with planning and control. O
en there are phases of

172

MAKING SENSE OF PROJECT REALITIES

projects where such management is valid and effective, but there are always other phases when it is inappropriate and projects should take an organic form where power is diffuse, strategies emerge, through-life planning is unrealistic, and contributors need the autonomy to be creative. If managers aempt to impose the control model where it is not wanted, then people will find its strictures unhelpful, and will resist. If managers can break their dependency on the control model, then constructive alternatives can be negotiated.

3.

Theory–practice disconnection The artefacts of mainstream project management techniques are the tools of project operatives, and do not reflect what experienced professional practitioners actually do. These cra
capabilities – of knowing how to act effectively in a project environment – have been collected under a heading of ProjectCra
. ProjectCra
cannot be taught through courses, but may be acquired through experience in the world of projects and work-based structured learning programmes.

WILL WE GET BETTER? Can project management be reformed? Unfortunately the main institutions of the discipline – governments and associations – are locked into the limited planand-control model of projects, and are unlikely to change. Learning processes for project professionals, in universities and in corporate project groups, can be improved, taking account of the issues raised in this book (and elsewhere). However this will be an uphill struggle unless more supportive institutions – a professional and intellectual home – can be developed to support them.

Vocabulary This is a list of the terms I have used in a specialist or technical sense, each with my preferred definition. They appear in the order in which they are defined in the text.

CHAPTER 2: MAKING SENSE OF PROJECTS ProjectCra
Capabilities of knowing how to act, demanded of those practising in the messy world of projects. Local vocabulary Words and concepts adopted to support the pursuit of a specific endeavour. Project A purposeful collective endeavour that takes up a concept and implements it in order to realize something new.

CHAPTER 3: PROJECTS AND COMPLEXITY Social interaction perspective Characterization of projects as emerging from the interactions between diverse social groups. Value creation perspective Characterization of projects as temporary enterprises to create value (in its diverse meanings).

CHAPTER 4: TRIBALISM AND RITUALS Stakeholder management A mainstream technique deployed to protect a project from the hazard that is other people. Practice group A group of people possessing and applying a shared body of expert knowledge. Tribes The set of practice groups forming the social context for a project or set of projects.

174

MAKING SENSE OF PROJECT REALITIES

Rituals The ideas and behaviours that characterize a tribe. Project team Temporary unstable group brought together to complete a project. (A project team is not a tribe.) Projectification Social and economic forces that demand the project mode of working Project directors The group seeking to impose project working within an organization. Strategists The agents of central policy-makers, using projects to deliver a strategy. Project shapers The project designers, negotiating and seing the agenda of individual projects. Project deliverers The group who take responsibility for delivering a project (or part of a project). Priesthood The groups who act as custodians of project management knowledge.

CHAPTER 6: MANAGING MULTIPLE PROJECTS Stage-gate The passage of a project from one stage into the next. Life-cycle management A management system to vet the passage of projects through its stage-gates. Programme management A management system to vet and control multiple projects in support of the delivery of a central strategy. Portfolio management A management system for handling the portfolio of projects that comprises the business, making decisions on priorities and the commitment of resources. Flywheel project A project that is spinning and ready to go, to which people can be reassigned if the main project on which they are working is delayed.

V O C A B U L A RY

175

CHAPTER 7: FRAUDULENT PROJECTS Fraudulent project A project whose actual purpose is not compatible with its declared purpose, and which cannot possibly deliver the outcome its managers have promised. Dog-day project A flawed unwanted pet project that gains approval by being made to appear as though it responds to an urgent political need.

CHAPTER 8: THE LANGUAGE OF PROJECTS Project-perfect A project-perfect is a hypothetical concept that defines idealized ends and plans for a collective endeavour: a specific objective, a set of welldefined tasks, a target completion date and an authorized budget. Control model A form of management that uses a project’s artefacts – its specifications and plans – to define what it is, and then a
empts to control its outcome. Organic model A form of management that aims to create a space defined by possibilities – of engagement, actions, outcomes – within which the project can take form and grow. Concentrated power Project in which power is held by one or two parties, making covert decisions and private deals. Diffuse power Project in which the formulation is open to discussion and agreement with diverse parties. Bounded scope The project content is fixed and well specified, having clearly defined limits. Notional scope The project content is understood only in broad terms. It is open to challenge and can be influenced by outside parties (permeable). Detailed strategy The plans and the resources to be applied are fully defined. Conceptual strategy Plans exist only in broad conceptual terms. Sequential Project in which each stage is finished before the next starts, the scope and form of the project being fixed before it is implemented.

176

MAKING SENSE OF PROJECT REALITIES

Iterative Project which continues to be re-formed throughout the implementation stage, the scope and strategy being subjected to serial reshaping. High-stability scope Project whose boundaries are fixed, unproblematic and not in dispute. The function of management is to prevent change. Low-stability scope Project whose content is contested and open to change, its boundaries being permeable. The function of management is to encourage and facilitate change. Centralized control The autonomy of participant individuals and organizations is limited by a controlling management. Distributed control Participant individuals and organizations are semiautonomous, empowered to act as they see fit under umbrella management. Controlling management Management team that seeks to impose its will on all project work. Umbrella management Management team that empowers project participants to act as they see fit within a broadly defined strategy. Predefined plan Plan in which the tasks to be performed are pre-agreed (ie by some form of contract) with the controlling managers, who monitor progress and compliance with the plan. Creative plan Plan in which tasks are performed in accordance with a conceptual scope, the work performed being flexible, and evolving in response to changing needs. Bounded resources Groups of people, in specified disciplines, are given approval by management to work on the project, as and when their efforts are necessary for the delivery of the defined tasks. Open resources Groups participate on their own initiative as and when they believe they can contribute to the holistic needs of the project. Structured relationships Roles and responsibilities are defined formally in organization charts and job specifications.

V O C A B U L A RY

177

Fluid relating Responsibilities and relationships evolve in response to the demands of the work in hand. Tangible output The project ends with the production of specified goods or the completion of defined services, being judged on its completion to the specification: time, cost and quality. Social impact The project makes continuing contributions to society: the development of social capital, benefits to the wider community, contributions to learning.

CHAPTER 9: CREATING PROJECT SENSE Sense-making A social process through which people collectively construct forms of sense: explanations of how things are. Reflective practitioner A concept concerning how people at work reflect on the situations in which they find themselves, understand the relevance of the practices they employ, and consider the alternative possibilities for action. Enactment Process to make a project ‘real’ by creating artefacts through which the project can be seen, inspected and queried. Peripety A dramatic turn (in response to the arrival of a ‘message’) which causes the understanding of a project to be fundamentally reframed.

CHAPTER 10: PERSONAL ENGAGEMENT Identity construction Activities of individuals to create themselves so that they may be perceived by others in their desired form. Honest worker A form of identity in which the individual works in a commi
ed manner to support the aims of the organization. Player A form of identity in which the individual will try to see things for what they really are, and use them to promote his or her own interests.

178

MAKING SENSE OF PROJECT REALITIES

CHAPTER 11: DELIVERING VALUE Project output The standard project deliverables: tangible products, which can be inspected. Project outcome Facility arising as an immediate consequence of a project; something can be done that could not be done beforehand. Project impact Effects of a project on people’s lives, continuing aer the formal managed phases have been completed. Value chain The chain of project consequences: from outputs to outcomes to impacts. Absent-client model An idealized model of projects, embodied in mainstream thinking, in which the customer, having handed over the specification, has no role to play until called upon to accept the completed product. Value overload An effect in a project (especially IT) where excessive claims are made for the forms of value it will deliver, with the result that the additional outputs and features added to the project scope make it unfeasible.

CHAPTER 12: BUSINESS TRANSFORMATION Business transformation Management endeavours, incremental or radical, to deliver major change to the functions and practices of a business. Transactional change Change that can be accomplished through the planned actions of managers. Journey of change A long term organic process of change. Force majeure An output delivered by a project which has the power to cause the intended social consequences without the need for further managerial intervention. Resistance to change Argument through which the extended timescale necessary to absorb and realize the benefits from an executive-driven change is blamed on the failings of middle managers.

V O C A B U L A RY

179

Benefits realization management Systems adopted to track the chain of cause and effect through which the benefits from a transformation can be realized. Benefits mapping A map of the chain of cause and effect through which the benefits are expected to be realized. Executive map A simplified benefits map directed at an executive, produced by the manager of a transformation to explain what he or she is doing.

CHAPTER 13: DEALING WITH UNCERTAINTY Risk register A schedule that lists all hazards faced by a project, whatever their form. Known risks Risks to the completion of a defined process that can be quantified using historical data. Task uncertainties Uncertainties in plans to complete a defined process that arise from assumptions and ignorance about the process. Staged uncertainty reduction A process whereby task uncertainties are minimized at each stage-gate to improve the likelihood of successful completion. Social uncertainties Uncertainties arising in the human and social processes of a project that are a hazard to all aspects, for example: performance of tasks, objectives, organization, basic strategy. The innocent Personal strategy for dealing with uncertainty that involves merely listing and tracking known risks and uncertainties. The protectionist Personal strategy for dealing with uncertainty in which a manager demands that all uncertainty be removed before accepting responsibility for project delivery.

CHAPTER 14: QUESTS FOR VALUE AND ACCOUNTABILITY Quest for Accountability The expectation, by society, that individuals and organizations will be held to account for meeting their commitments.

180

MAKING SENSE OF PROJECT REALITIES

Quest for Value The endeavours by managers to find ways to achieve valued ends for their organization.

CHAPTER 15: PROJECTCRAFT Project operative A person who has been trained in the techniques of the mainstream project management toolkit. Action learning A framework for the development of individual and for communal capabilities through a collective process of inquiry.

CHAPTER 16: THE BUSINESS OF PROJECT MANAGEMENT Toolkit industry The institutions that combine to promote and deliver the control model of projects, together with its toolkit and the legion of project operatives needed to sustain it.

Bibliographic Notes I have chosen not to interrupt the arguments of my main text with references to other books and papers. These bibliographic notes rectify that omission, and identify the works of a number of other writers whose ideas I have borrowed (and distorted) in writing this book. This bibliography covers only a small fraction of recent writings on the subject: many of the references below will provide the reader with a far more comprehensive survey of the field than I can possibly a
empt.

PEOPLE IN ORGANIZATIONS Etienne Wenger, Communities of Practice: Learning, Meaning and Identity (Cambridge University Press, 1998). Wenger’s work addresses issues of social learning and knowledge in organizations. His book is concerned with social structures and power, practice, situated experience and identity construction, building on his own earlier work with Jean Lave on situated learning. His thinking underlies my perspective on the significance of groups, social interactions and power, and their central importance to understanding the provenance and practice of projects. I have chosen not to adopt Lave and Wenger’s terminology of ‘community of practice’ because this term has subsequently become associated with a much looser form of sharing between individuals. In its place I have used ‘practice group’ when they are expert and ‘tribe’ when they are competitive. Karl E. Weick, Sensemaking in Organizations (Sage, 1995). Weick’s book sets out the principles of organizational sense-making. He identifies seven characteristics of sense-making: grounded in identity construction, retrospective, enactive of sensible environments, social, ongoing, focused on and by extracted cues, driven by plausibility rather than accuracy. In Chapter 9 I have applied Weick’s general principles to examine the specific forms of sense-making witnessed in projects and identify their key features. I

182

MAKING SENSE OF PROJECT REALITIES

have also adopted Weick’s position (and that of Wenger) that individual identity construction is fundamental. Donald Schon, The Reflective Practitioner: How Professionals Think in Action (Basic Books, 1983). Schon examines the performance of professionals, contrasting the overt foundations of the professions, based on technical knowledge (derived from research), with the reality of professional life, dealing with complexity, uncertainty, instability and conflicts. Professionals solve messes, not problems. Their mode of operation is reflection-in-action – the recognition of phenomena, and the accomplishment of effective actions. I have departed slightly from Schon’s position, in that I consider all people at work to be reflective practitioners. Professionals are differentiated from others by the substance – the corpus of expert subject ma
er – on which they reflect. One of my primary aims has been to take up Schon’s interest from a project position: to illuminate the messes that confront professionals in a project environment, and describe the phenomena on which they reflect and act.

CRITIQUES OF PROJECT MANAGEMENT Damian Hodgson and Svetlana Cicmil (eds), Making Projects Critical (Palgrave Macmillan, 2006). ‘Making Projects Critical’ is the title of a continuing series of workshops that have provided a forum for a range of critical perspectives on all aspects of projects; project management, project-based organizations and the ‘projectification’ of society. This publication contains many of the papers originally presented at the first two workshops, together with some additional papers. The intention of Hodgson, Cicmil and their co-authors is to challenge mainstream thinking. To do so they take in a wide range of relevant academic perspectives. Apart from subscribing in general terms to their critique, and to the need to progress beyond the mainstream, I have drawn on a number of specific topics from these workshops. Except where noted these are included in ‘Making Projects Critical’.

B I B L I O G R A P H I C N OT E S

Paper

183

Topics drawn upon

Damian Hodgson and Svetlana Cicmil, ‘Are projects real? The PMBOK and the legitimation of project management knowledge’.

The drives to reify projects and project management techniques (i.e. through the Project Management Body of Knowledge) as the norm for organizing work.

Carol Linehan and Donncha Kavanagh, ‘From project ontologies to communities of virtue’, and Manuela Nocker, ‘The contested object: on projects as emergent space’.

Alternative perspectives on the nature of projects, which I have reflected in my ‘vectors of project diversity’.

Eamonn Molloy and Richard Whittington, ‘Reorganisation projects and five uncertainties’.

The nature and impact of social uncertainties on projects.

Charles Smith, ‘A tale of an evolving project: failed science or serial reinterpretation’.

The role of the expert project manager in the reconstruction of project reality.

Stuart Green, ‘The management of projects in the construction industry: context, discourse and self-identity’.

The context of the construction industry and the forms of project management engendered by it.

Chris Ivory, Neil Alderman, Ian McLoughlin and Roger Vaughan ‘Sense-making as a process within complex projects’.

Projects as trajectories, and the role of sensemaking in project re-enactment.

David Courpasson, ‘Projects and the production of corporate elites in contemporary business firms’ (not published)

The role of project management in the formation of organization oligarchies.

Harvey Maylor (ed.) ‘Rethinking Project Management’ Special Issue of the International Journal of Project Management (2006). This special issue is the main academic output from the Rethinking Project Management network. Much of its scope parallels that of this book, but it is directed at future research directions rather than providing advice to practitioners. It therefore includes far more in-depth discussion of current research issues and publications. The special issue comprises eight papers: Mark Winter, Charles Smith, Peter Morris and Svetlana Cicmil

Directions for future research in project management: the main findings of a UK Government-funded research network

Mark Winter, Charles Smith, Terry Cooke-Davies and Svetlana Cicmil

The importance of ‘process’ in rethinking project management: the story of a UK Government-funded research network

Harvey Maylor, Tim Brady, Terry Cooke-Davies, Damian Hodgson

From projectification to programmification

Svetlana Cicmil, Terry Williams, Janice Thomas, and Damian Hodgson

Researching the actuality of projects

184

MAKING SENSE OF PROJECT REALITIES

Roger Atkinson, Lynn Crawford, and Stephen Ward

Fundamental uncertainties in projects and the scope of project management

Mark Winter, Erling S. Andersen, Roger Elvin and Ralph Levene

Focusing on business projects as an area for future research: an exploratory discussion of four different perspectives

Peter Morris, Lynn Crawford, Damian Hodgson, Miles Shepherd, and Janice Thomas

Exploring the role of formal bodies of knowledge in defining a profession – the case of project management

Lynn Crawford, Peter Morris, Janice Thomas and Mark Winter

Practitioner development: from trained technicians to reflective practitioners

ADDITIONAL THEMES The following books and papers give fuller expositions of themes I have covered. Gareth Morgan, Images of Organizations (Sage, 1997). Gareth Morgan’s aim is to support managers in the art of ‘reading’ the organization so they may act more effectively. To this end he puts forward nine metaphors for organizational life, the first of which is the machine model, whose deficiencies he outlines before moving on. He commends a multi-perspective approach, viz. that managers should adopt whatever metaphor is appropriate to any particular situation. My criticisms of mainstream project management parallel Morgan’s criticisms of the machine model, on which standard project management techniques are based. The perspectives I have used to examine the project world are similar to two of Morgan’s metaphors: the creation of social reality and culture, and organizations as political systems. I have preferred these because I believe they offer useful insights, and also because these are the terms in which expert practitioners speak of their work. By subtraction, this leaves a further six metaphors that I have not addressed, and which may well be of value to project practitioners. I am sure that other writers could usefully fill this gap. John Clarke and Janet E. Newman, The Managerial State: Power, Politics and Ideology in the Remaking of Social Welfare (Sage, 1997). Clarke and Newman examine critically the political forces that have enabled ‘more and beer management’ to be presented as a solution to the problems of the welfare state. I have enlisted their conclusions to support my arguments for the causes of the expansion of project management in the public sector. In

B I B L I O G R A P H I C N OT E S

185

particular the concept of the tension between centrifugal and centripetal social forces, driving the surge of managerialism, has been taken from their work. Annie Pye, ‘Leadership and organizing: sensemaking in action’, Leadership, 1/1 (2005): 31–50. Discusses concepts of leadership and the distinction between leaders (noun) and leading (verb), and concludes that leading is equivalent to sense-making. I reference this paper to support my decision not to include a specific section on leadership: leading as sense-making pervades the book. Mats Engwall and Gunnar Westling, ‘The peripety of projects: on the punctuated process of knowledge formation in R&D projects’, Fenix Working Paper (2001) 21. Available at www.fenix.chalmers.se/fenix/publications/2001.htm. The authors apply the concept of peripety to development projects. I have taken their idea and expanded its application to projects in general. David Buchanan and Richard Badham, Power, Politics, and Organizational Change: Winning the Turf Game (Sage, 1999). A guide to the politics of change within organizations which focuses on the roles performed by individuals, and the political skills they employ. I consider these issues as being applicable to all management of projects, and have drawn on this book for my discussion of individual strategies. Charles Margerison, ‘Work-based action learning and applied organisation science: a process for management research and organisation development’, Action Learning: Research and Practice, 2/2 (2005): 171–186. This paper provides an overview of action learning in the workplace, based on the principles and practices of Reg Revans. I commend this approach for the development of ProjectCra capabilities. The paper references the key literature on this subject, of which perhaps the most important work is: Reg Revans, Action Learning: New Techniques for Management (London, 1980).

This page intentionally left blank

Index middle manager resistance, 121 principles of, 117–21 ProjectCra for, 128 ProjectCra for project shapers, 159 simplified benefits mapping, 127–8 transactional change, 119, 119–20 value chains, 124, 124–5 see also food to supermarkets case study

Figures are indicated by bold page numbers, tables by italic numbers.

A absent client model, 108, 178 accountability balance with value, 150–1 as driver for projectification, 41, 49 quest for, 145, 146, 146–8, 179 action learning, 162–4, 189 agendas, unknown, 137 alienation from project management, 4–5, 171–2 ambition, 89 Aristotle, 85 Association for Project Management, 2–3, 166

B Badham, Richard, 185 benefits mapping, 122, 122–8, 123, 179 benefits realization management, 122–8, 123, 124, 126, 179 Bernard (case study), 76–8, 89, 141 bounded resources, 72, 176 bounded scope, 72, 175 Buchanan, David, 185 budgets, annual, distortion effect on projects, 61–2 business transformation approaches to, 113 benefits mapping, 122–8 benefits realization management, 122–8 case for project management, 114, 129 dangers of over-mechanistic thinking, 128 definition, 178 examples of, 118–19, 119 force majeure, 120–1 IT projects, 117 journey of change, 119, 119–20

C Central Artery Project, Boston (case study), 40, 42 centralized control, 72, 176 change during projects, dealing with, 84–9 change management. see business transformation Charloe (case study) narration, 68–9 peripety in, 86 vectors of project diversity, 71, 73 Christopher (case study) business transformation aspect, 116–17, 120 identifying the project, 120 narration, 114–15 staged nature, 115–16 Cicmil, Svetlana, 182–3 civic projects (case study), 68–9, 86 Clarke, J., 184–5 clients, engagement with projects, 108 Communities of Practice: Learning, Meaning and Identity (E. Wenger), 181 community projects, 68–70 complexity dealing with, 22 theories of, 18–19 see also uncertainty concentrated power, 72, 175 conceptual strategy, 72, 175 construction company case study, 17–18, 34

188

MAKING SENSE OF PROJECT REALITIES

construction industry, 1, 40 context, projects in, 108 continuing contests, 138 continuous improvement initiatives. see business transformation control model of projects, 71, 72, 73, 175 corporate practice groups, 169, 169 corporations, project management in, 168 creative plan, 72, 176 customers, engagement with projects, 108

D defence industry case study, 59–60 definitions by chapter, 173–80 idealized, of projects, 67 detailed strategy, 72, 175 development as practitioners, 162–4 diffuse power, 72, 175 disorder and order at work, 15–17 see also uncertainty distributed projects absence of feedback loops, 49 integration between departments, 49 life-cycle management, 46–8 management control of, 45–9 stages and gates, 46–8 DivCo case study group power, 78–9 narration, 25–7 negotiation of identity, 96 peripety during, 86–7, 87 practice groups, 28–39, 29 project teams compared to practice groups, 30–1 risk management in, 132–5 risk register for, 133 temporary teams and power, 79 tribal membership of Robert, 34 divergent strategies, 137–8 diversity, vectors of project, 72 documents as project enactment, 80–1 dog-day projects, 60–1, 175

E emergent strategies, 137 enactment definition, 177 documents, 80–1 fast, 82

hard product, 81–2 high and low stability of projects, 84 by leaders, 82–4 and phases of a project, 84 purpose of, 80 engineering, 1 Engwall, M., 185 estimating bias, 135 executive map, 125, 179

F Fiona (case study), 12, 34 fluid relating, 72, 177 flywheel project, 54, 174 food to supermarkets case study business transformation aspect, 116–17 identifying the project, 120 narration, 114–15 staged nature, 115–16 force majeure, 120–1, 142, 178 formation of projects, 72 fraudulent projects defence industry case study, 59–60 definition, 175 research project case study, 58–9, 63–4 transparency as tool against, 63, 63–4 victims of, 64 funding through project approval, 2

G glossary by chapter, 173–80 good practice, 22 government, project management by, 168, 169 groups within organizations, 28–30, 29 ProjectCra for cross-group understanding, 80 unstable, 138 see also practice groups

H hard product as project enactment, 81–2 Heather (case study), 48–9 high stability scope, 72, 176 Hodgson, Damian, 182–3 honest workers, 99–100, 177 Howard (case study), 17–18, 34

INDEX

I identities construction of, 89, 177 negotiation of, 95–8 personal strategies, 98–100 of project people, 93–5 Images of Organizations (G. Morgan), 184 implementation of projects, 72 innocent personal strategy, 139, 179 instability during projects, 84–9 IT projects, 117 iterative project, 72, 176

J James (case study), 96–7 Job Done! case study, 118, 120 journey of change, 119, 119–20, 178 Joyce (case study), 58–9, 79

K known risks, 134, 179

L language and projects, 11–13, 54, 67–8 leaders and enactment, 82–4 and peripety, 88–9 ‘Leadership and organizing: sensemaking in action’ (A. Pye), 185 life-cycle management, 46–8, 174 local vocabulary, 54, 173 low stability scope, 72, 176

M mainstream philosophy of project management, 9–10 Making Projects Critical (D. Hodgson and S. Cicmil), 182–3 Managerial State: Power, Politics and Ideology in the Remaking of Social Welfare (J. Clarke and J.E. Newman), 184–5 Manchester to Liverpool railway, 4 Margerison, Charles, 185 Mahew (case study) individuals involved, 39 narration, 38 and project hazards, 41–2 social groupings, 39

189

Maylor, Harvey, 183 middle manager resistance to change, 121 Morgan, Gareth, 184 multiple projects distributed, 45–9 portfolio management, 52–4 strategic management, 50–2

N negotiation of identities, 95–8 new brooms, 138 New Office, New Culture case study, 118, 120 Newman, J.E., 184–5 notional scope, 72, 175

O Oedipus Rex, 85 oligarchy within organizations, 100–1 open resources, 72, 176 opponents of projects, ProjectCra for, 161 order and disorder at work, 15–17, 19 organic model of projects, 68–71, 72, 73, 175 organizational complexity, 17–18 outcome and output of projects, 105, 178

P pensions office case study group power, 78–9 narration, 25–27 negotiation of identity, 96 peripety in, 86 risk management in, 132–5 risk register for, 133 temporary teams and power, 79 tribal membership, 34 peripety, 85–8, 87, 138, 142, 177 ‘peripety of projects: on the punctuated process of knowledge formation in R&D projects, The,’ (M. Engwall and G.Westling), 185 personal identity strategies, 98–100 personal work, 16 see also reputation work pet projects, 60–1 PharmaCo (case study), 52–3 plans as project artefacts, 90 players, 99–100, 177

190

MAKING SENSE OF PROJECT REALITIES

portfolio management, 174 local vocabulary of, 54 PharmaCo, 52–4 UK nuclear industry, 54 Power, Politics and Organizational Change: Winning the Turf Game (D. Buchanan and R. Badham), 185 power structures and sense-making, 78–80 practice groups compared to project teams, 30–1 corporate, 169, 169 definition, 173 within organizations, 28–30, 29 within project management, 35 sense-making based on, 78–80 practitioners development of, 162 and theoreticians, 7–8 pragmatic uncertainty skills, 141–3 see also uncertainty predefined plan, 72, 176 priesthood, 33, 161, 174 programme management, 174 project deliverers, 33, 160, 174 project directors, 33, 156, 174 project impact, 178 project management alienation from, 4–5 applied to business transformation, 114 assimilation of projects, 72 benefits map as tool for, 125–7, 126 at centre of organizations, 3 in the construction industry now, 40 control model of projects, 72, 73 critiques of, 182–4 form dictated by accountability, 41 formation of projects, 72 by government, 168, 169 growth of seen as mega-project, 165–6, 169–70 idealized definition of, 67 implementation of projects, 72 initiation of projects, 45 mainstream philosophy of, 9–10 major players in, 165–9, 169 need for institution for advanced thinking on, 170–1 need to explore uncertainties, 65–6

organic model of projects, 73 performance deficits, 4–5 politicized nature, 32 practice groups within, 35 related institutions, 2–3, 165–7, 170 sound and unsound, 171 stages and gates, 46 strategic, 50–1 theory-practice disconnection, 6, 172 tools and techniques of, 6, 9–10, 153, 162 two levels of knowledge, 10–11 vectors of project diversity, 72 Project Management Institute, 2–3, 166 project manager as aspirational career, 3 project operatives, 189 project outcome, 105, 178 project output, 105, 178 project-perfect, 68, 175 project risk management. see risk management project shapers, 33, 158, 174 project teams, 30, 174 project working, development of, 1–2, 165 ProjectCra, 173 action learning for, 162–4 for all involved, 154–5 for business transformation, 128 for business transformation project shapers, 159 cross-group understanding, 80 for general project shapers, 158 and institutions of project management, 165–7 introduction to, 10–11 multifaceted nature, 36 need to explore uncertainties, 65–6 need to understand social context of projects, 36 for opponents of projects, 161 players, 141 for the priesthood, 161 for project deliverers, 160 for project directors, 156 and the Reflective Practioner, 163–4 self-awareness, 89 for strategists, 157 value creation, 111 projectification, 31–2, 41–2, 174 projectionist personal strategy, 179

INDEX

191

projects approval of, 2 complexity of, 17–18 in context, 108 definition of, 13, 173 idealized definition of, 67 as imposing extra demands, 20 as maps, 21 as paper-based illusions, 20–1 as providers of order, 19–20 Projects with a Drumbeat (case study), 76–8, 89, 141 protectionist personal strategy, 140–1 public service change case study, 12, 34 Pye, Annie, 185

see also uncertainty risk register, 131–3, 133, 136, 141–2, 179 rituals, 28, 174 Robert (case study) group power, 78–9 narration, 25–27 negotiation of identity, 96 peripety during, 86–7, 87 practice groups, 28–39, 29 project teams compared to practice groups, 30–1 risk management in, 132–5 risk register for, 133 temporary teams and power, 79 tribal membership, 34

R

S

Reflective Practioner, 163–4 Reflective Practioner: How Professionals Think in Action, The (Donald Schon), 182 Reflective Practitioners, 10–11, 76, 90, 177 relationships, centrality and complexity of, 16 reputation work, 16, 89, 96–8, 99, 143 research project case study, 58–9, 79 resistance to change, 121, 178 Rethinking Project Management research network, 7–8, 183–4 Richard (case study), 106–7, 108–9 risk, business, 53–4 risk management continuing contests, 138 deviation control, 131 divergent strategies, 137–8 emergent strategies, 137 known risks, 134 known unknowns, 136 new brooms, 138 peripety, 138, 142 pragmatic skills for dealing with uncertainty, 141–3 project manager strategies, 139–41 remedial plans, 139 risk register, 131–3, 133, 136, 141–2 social uncertainties, 137–9 staged uncertainty reduction, 135–6 task uncertainties, 135–6 unknown agendas, 137 unstable groups, 138

Saving Lives case study, 118–19, 120, 121, 122, 123, 124–7 Schon, Donald, 182 school building case study, 106–7, 108–9, 109 self-awareness, 89 self-development as practitioners, 162–4 sense-making ambition of others, 89 based on group power, 78–80 definition, 177 enactment, 80–4 in organizations, 75 peripety, 85–9 process of, 76–8 Reflective Practitioner, 90 and reflective practitioners, 76 role of individuals, 89 Sensemaking in Organizations (K.E.Weick), 181–2 sequential project, 72, 175 social impact, 72, 177 social impact of projects, 107 social interaction definition, 173 DivCo case study, 25–7 and dubious projects, 62 importance in project management, 25 practice groups, 28–30, 29 sense-making based on, 78–80 skills to handle during projects, 43 stakeholder management, 25 transparency in, 63, 63–4

192

MAKING SENSE OF PROJECT REALITIES

tribal members, 33–5 view of projects, 35–6 as way of thinking about projects, 22–3 social projects (case study), 69–70, 79, 107 social uncertainties, 137–9, 179 staged uncertainty reduction, 135–6, 179 see also uncertainty stages and gates, 46–8, 174 stakeholder management, 25, 35, 173 standards organizations, 167 Stephanie (case study), 52–3 Stephen (case study), 40, 42 Stephenson, George, 4 Stewart (case study), 69–70, 73, 79 strategic project management, 50–1 strategists, 33, 157, 174 structured relationships, 72, 176 systems development for IT, 1–2

T tangible output, 72, 177 task uncertainties, 135–6, 179 theoreticians and practitioners, 7–8 theory-practice disconnection, 6, 172 Thomas (case study), 50–2 Tony (case study), 47–8 toolkit industry, 169, 169–70, 189 tools and techniques of project management, 6, 9–10, 153, 162 transactional change, 119, 119–20, 178 transparency as benefit of management controls, 55, 63, 63–4 tribes definition, 173 members of, 33–5 of the project world, 33 see also groups; practice groups

U umbrella management, 72, 176 uncertainty and complexity at work, 15–18 need to explore, 65–6 pragmatic skills for dealing with, 141–3 social uncertainties, 137–9 staged uncertainty reduction, 135–6

task uncertainties, 135–6 United Nations Development Programme (UNDP), 39 universities, 168–9, 169 unstable groups, 138 see also groups; practice groups

V value balance with accountability, 150–1 quest for, 145–6, 146, 148–50, 180 value chains, 105–6, 124, 124–5, 178 value creation definition, 173 diverse forms of value, 104, 104–5 measuring success by, 103–4 overload, 110 and performance criteria, 109 ProjectCra practitioners, 111 projects as vehicles of, 103 projects in context, 108 school building case study, 106–7, 109 social impact of projects, 107, 111 value chains, 105–6, 124, 124–5, 178 as way of thinking about projects, 22–3 value overload, 110, 178 vectors of project diversity, 72 victims of fraudulent projects, 64 vocabulary local, 54, 173 of projects, 11–13, 54, 67–8, 173–80

W Weick, Karl E., 181–2 Wenger, Etienne, 181 Westling, Gunnar, 185 William (case study), 135–6 work complexity and uncertainty at, 15–17 dealing with confusion and uncertainty, 18 see also uncertainty ‘Work-based action learning and applied organisation science: a process for management research and organisation development’ (C. Margerison), 185

If you have found this book useful you may be interested in other titles from Gower Advanced Project Management 4th Edition F.R. Harrison and Dennis Lock 0 566 07822 8

Accelerating Business and IT Change Alan Fowler and Dennis Lock 0 566 08604 2

Benefit Realisation Management Gerald Bradley 0 566 08687 5

The Bid Manager’s Handbook David Nickson 0 566 08512 7

Contracting for Engineering and Construction Projects 5th Edition Peter Marsh 0 566 08282 9

Failsafe IS Project Delivery Andrew Holmes 0 566 08255 1

Gower Handbook of Programme Management Geoff Reiss, Malcolm Anthony, John Chapman, Geof Leigh, Adrian Pyne and Paul Rayner 0 566 08603 4

Gower Handbook of Project Management 3rd Edition edited by J. Rodney Turner and Stephen J. Simister 0 566 08138 5 (hbk) 0 566 08397 3 (CD-ROM)

Law for Project Managers David Wright 0 566 08601 8

Project Delivery in Business as Usual Organizations Tim Carroll 0 566 08629 8

Project Management 8th Edition Dennis Lock 0 566 08551 8

The Project Manager’s Guide to Handling Risk Alan Webb 0 566 08571 2

The Relationship Manager Tony Davis and Richard Pharro 0 566 08463 5

Using Earned Value Alan Webb 0 566 08533 X

For further information on these and all our titles visit our website – www.gowerpub.com All online orders receive a discount