This book is made up of TWO parts. A Novel which explains the THEORY and a Practical Workbook to help you APPLY it. Reviews from |
All Change! The Project Leader's
Secret Handbook |
I want to listen to the Whole Story (password) |
||
While ALL CHANGE!/The
Project Manager's Secret Handbook has a great series of steps for properly managing your
projects (it takes up the reverse half of the book), Obeng's focus is on helping you get
the right thinking on your project. No easy answers like in most management books, but
ways to approach projects and manage them to a successful completion. The first half, ALL CHANGE!, is actually a narrative about a project
manager coming to understand why his projects always seem to go wrong.
I'd compare this to Mythical Man-Month in how much it shaped my thinking
CONTENTS All Change! (The Novel) Chapter
One: Full circle. -Examples of managed change 3 THE PROJECT LEADER'S SECRET HANDBOOK Part 1 Diagnosing your own project 96 1.1. Is it worth doing? 96 1.2. What type is it? 99 1.3. What sort of problems should you expect? 108 1.4. What bubbles (skills/tools) should you focus on? 114 Part 2 - Try these. 115 2.1. Learning to learn. 116 2.1.1. Blowing bubbles. 125 2.1.2 Managing review . 141 2.2. Recognising Stakeholders. 143 2.2.1. Mapping Stakeholders. 146 2.2.2. Establishing the hard and soft criteria of success. 152 2.2.3. The Money. 168 2.2.4 Balancing stakeholder expectations . 175 2.3. Planning and co-ordinating . 183 2.3.1. Sticky Steps. 184 2.3.2. Pacing yourself. 192 2.3.3. The risk of being so near... Yet so far: Co-ordination, control and risk. 198 2.3.4. Communications strategies . 202 2.4. Working with and leading people 207 2.4.1. Leadership? What leadership? 213 2.4.2 Lead the followers. 218 2.4.3 Matching the person to the chunk. 223 Part 3 All those New Words. 226 3.1 The Explanations. All Change! Epilogue Contd. Out of the circle. 235
REFERENCES - Sources and further reading.
All Change! is recommended reading at many learning institutions such as: University of Sheffield
|
CHAPTER TWO: MY OLD MATE
In which the difficulties of successfully implementing change are discussed. It's been raining solidly for the past three days. Three days of horizontal rain striking against the window panes and then running down them in a thick uneven layer. A layer which makes the Cafe' de The' sign on the building opposite appear to sway and dance gently and unpredictably backward and forward and the most annoying part of it all is that it shouldn't be happening. This is, after all, the South of France. By mid-afternoon I am bored with staring at the walls of my room. Staying on the beach is fine when it's sunny, you are a few minutes walk from restaurants, sand and other fun seekers. When the weather is not good, it's the pits! There is absolutely nothing to do. I decide to visit the local chateau which will at least be dry and will allow me to stretch my legs. It is there, wandering around the cellar, that I notice the shiny bald patch. You can hardly miss it. It shines or rather glistens, even in the cool darkness of the cellar. Then he turns round, and I slowly realise that I recognise the face belonging to the beacon. Instinctively and without having worked out who exactly I am about to address, I smile, and say "Hello". The eyes in the face stare straight into mine and with a smile of recognition he says "G'day mate." "Did you ever find a job then?" A hand extends to meet mine in a warm, vigorous handshake. His question answers my question, it is Franck. I had first met him at Surfers Paradise in Australia. He had also been on an "extended holiday" At the time he had just finished six years of studying psychological diagnostic techniques. We had become firm friends for the simple reason that both of us at the time were looking for some way of putting meaning into our lives. We had lost touch and I hadn't seen him for years. I reply "Yes, eventually several but I've used them all up now." He says, "What we need is a cold tube of beer, but would a glass of sparkling white wine do instead?" I nod and point to the sign which says restaurant. In no time we are reminiscing over the bad old times convincing ourselves that they were the best times of our lives. I discover that Franck had also finally found a career, but now he works for himself. His description makes him sound like a supply teacher at a high school. He had described himself as an educator. It takes me about an hour to get round to the topic which has been on my mind all holiday. I tell him "twenty years in projects, I've had some success with about half." "What frustrates me is that I still haven't got a clue how to guarantee project success." He smiles at me as if I have said something really stupid, but says nothing. I continue. "I know that no one else has worked it out because they are all as surprised as I am whenever a project goes belly-up." He smiles again and it makes me feel that I need to put forward my theory on projects, so that he will not think that I am completely dumb. I have a voice I usually reserve for presentations to senior management. I call it my 'confident-bullshit' voice. I use it. I say "Of course, projects go wrong because we don't push people hard enough." That smile again, and then he asks, "So do you mean that you never have budget overruns from your team members claiming overtime?" "Yes we do," I reply "but they only do overtime because we don't have enough control over what they do, and so they don't do what we need, when we need it." "Oh, I see!" he replies, "Your fifty per cent success rate comes from projects where you have had a dedicated team over whom you have had total control." "No," I insist, "not quite." We also need better planning tools and techniques." "I understand" he says, and tops up my glass. "What you are saying is that if only we could plan it all out in greater detail then it would all happen exactly according to plan." "I don't think you understand," I say. "Even with good plans, life just isn't like that, and," I add, "it takes years and years to become a decent project manager. It's very complex. You have to know how to do most of the jobs on the project, and all the methods and computer planning and control techniques." "I see. So you've never worked on a project for a mature, widely experienced project leader which has gone awry? " I remember the building site and start to wriggle. "Well, sometimes there are special cases," I say. For the first time in our conversation, Franck offers an opinion. What strikes me is the way in which he does it. His voice seems calm, deep and resonant as if he is speaking through a muted megaphone. He says, "What I have found is that however complex the situation, it is unusual to find more than a half dozen underlying causes." My instinctive reaction to any statement that I don't really understand is to argue with it in the hope that in discussion it will become clearer. "I'm not sure I agree," I say. "This is a really thorny problem which has taxed many of the best minds for a long time." Franck says nothing but simply smiles, with much too much confidence. I say, "Maybe it can't be solved. Maybe there is nothing special which guarantees project success. It could just be luck." He smiles again and insists, "I don't think you really believe that or you would not have started this conversation. So what do you think is the real cause of project failure?...and anyway what do you mean by failure? Explain it all to me. Start from the beginning." CHAPTER THREE: HOLDING ON TO YOUR GAINSIn which the hard and soft criteria of project success are established. "So what do people say once it's over?" Asks Franck. He's stopped smiling now and looks at me as if he is hungry for a meal. He seems so serious over the problem that I get the feeling that he thinks that the meal is going to be me. "It depends on who you ask." I reply. "The classical measures of project success are Time - Cost - and Specification. The client is usually most concerned with the first two whilst the end user is usually most interested in specification. That is, 'does it do what we intended it to do for us?'. However, I find more that these days for business projects, clients are often as interested in revenues as costs. The additional revenue from a new product development can often far outweigh the costs. Also clients are more interested in the timeliness than time itself. To use the new product example again, as long as they beat the competition to the window of opportunity, the exact timing is not as important as its timeliness." I plough on in a steady stream. "But there are other groups of people who also have comments to make about project success. The person or steering group which owns or sponsors the project usually has a view. Their measure of success is usually in relation to them. Deciding how much political hassle it has been to push the project through? Furthermore, there is the project team, who try to assess whether they enjoyed the experience and would be willing to go through it with the project leader again. The accountants, who are still upset because you didn't spend, on what you said you would, when you said you would. And then there are the senior managers, whose noses are put out of joint because you have crossed into their patch unknowingly and they are determined to kill your project stone dead." "Whoa! Slow down, slow down" he says, waving his arms up and down. "It seems to me that lots of people hold a stake in the project." "Well yes but the only important one is the client, as long as we can keep the client happy..." "You just told me," says Franck steadily, "that sometimes when you are half way through a project suddenly, out of the blue, you have received an angry or aggressive memo or a rocketing from some senior manager or say union official or someone else who you thought had nothing at all to do with your project?" I'm thrown by the question. I'm sure I didn't mention the rude memos. How does Franck know about them? The answer to his question is yes. Yes. Frequently. It's a horrible feeling, just as things are getting going on the project, out of the blue, like a bolt of lightning, it strikes you. It leaves you disoriented, annoyed and confused, and not wanting to read memos or answer the phone for a while. They usually start 'I have just heard...' And if you don't handle them right they will fight you and obstruct you for the rest of the project. I reply softly, "Yes." He probes. "Why does this happen?" "I don't know." I reply perplexed. "I guess, they seem to think that the project is something to do with them." Franck continues to probe. "How does this same thing happen over and over and over?" "Busybodies?" I venture. "I don't think so." He says flatly. "Go back to what you said before. " "What?" I ask. "You mean 'that they think that the project has something to do with them'?" He nods. "Yes and what do you think?" "That it doesn't." I say slowly, as I begin to understand his point. "And who's right? He pauses and waits for a reply from me. I know he's right but don't reply. Eventually he continues. "It seems to me that there are a lot of people who have a stake and there are even more than you think." Section 2.2.1. Mapping Stakeholders The way of war is to know your opponents. So who are these stakeholders? These people who define project success and define for you, the boundaries and organisation of your chunk of change? Perhaps we should make a list of them and try to understand their motivations and agendas both hidden and open. Think about all the people who you need:
Think about all the people who your change:
Think about all the people in the sidelines:
Now go back to your bubble diagram (Section 2.1.2. Blowing Bubbles). Look at the bubbles at the bottom of the bubble diagram, the core drivers. The bubbles with no arrows going into them. What names are mentioned? Where you have written "we" or "they" who are you referring to? The people whose names are closest to the bottom of the bubble diagram will be the stakeholders who will have the greatest influence over your project. Why? Because they will need to alter something that they do or don't do in order for your change to become real and be translated into an improvement. Make sure that you have their names written down and underlined or highlighted. Now work your way up the diagram. Look for any other names you have missed. It's easiest to organise the names and groups as a grid or a map. But I advise drawing two maps. One for your personal use and another which you use publicly and stick on the wall. On the personal map some names may appear in more than one row. Give yourself about a quarter of an hour to complete it. Leave the map for a while and then return to it about an hour later and have another go. |
Translated into 5 languages The
world's most popular project management book
|
Copyright Pentacle1997 Eddie Obeng
1994 All rights reserved