INTRODUCTION

   

"But of course there is a leader," I hear you say, "it's the first thing we do when we start a new project. We appoint a leader."

And indeed this may well be true. Whatever else may be said about most projects that we come across, we can pretty much always identify the leader. And isn't it quite a nice sounding title to give to somebody or to have ourselves ? "Project Leader." "Project Manager." It's a title that settles easily on the shoulders like a fine coat. We walk that bit taller with the responsibility and pressure that we now carry. Yes indeed, we can always point out the project leader “ if nothing else we can tell him by the way he walks!

Let me re-state the chapter title. The project must have one leader. By that I mean it can't have no leaders and it can't have two leaders or a committee of leaders . There must be one leader.

Let's look at this statement a bit more closely. When I say leader, I mean not so much the person with the title, but a person who is going to get the project done. She lives, eats and breathes the project. She is going to get it done or die in the attempt. At any given time she has her finger on the pulse of the project and knows how it's proceeding. Her name is so intimately bound up with the project that when you think of one you think of the other. A fairly negative way of looking at it is that she is the person whose ass is pinned to the project and who will get fired if it doesn't work out. In the terminology of other books she is the project champion.

I have worked on a project where there was no leader, in the sense that I have described it above. I have worked on a project where there was a formal leader, and a person who took over the psychological leadership, thereby resulting in two leaders. Both projects were unmitigated disasters. In the first case, the person with the title project leader was fired, and in the second, both the project leaders were fired.

As you can see from the case studies below, sometimes the problem is finding a person, sometimes there are too many contenders.

CASE STUDY 1

One thing that can happen to you as a project leader is that your leadership can be subject to challenge by another member of the team. This means that somebody else tries to take over the psychological leadership of the project from you. If this happens you must neutralize the challenge. If you don't, you will end up with multiple leaders on your project.

Amundsen “ the project leader “ had a leadership challenge during his expedition to the South Pole in 1911 (Amundsen, 1912; Huntford, 1993). One of his men, Hjalmar Johansen, was a Polar explorer in his own right. He had been on an earlier expedition with Fridtjof Nansen, the father of Norwegian Polar exploration, and together they had made a dash for the North Pole. They didn't reach it but they did get 170 miles closer than anybody else had done, reaching 86 ° 14 ° North. Amundsen had reluctantly brought Johansen, urged to do so by Nansen.

From the beginning of the voyage, Johansen began to compare Amundsen's voyage unfavorably with Nansen's. Johansen was a better skier and dog-driver than Amundsen and felt he knew more about Polar travel. Often he would correct or contradict Amundsen, or volunteer advice. These matters later came to a head when Amundsen set out on his Polar journey. Amundsen was anxious to set out for the Pole, plagued by the thought that Scott might already have started and that Scott had brought motorized transport with him. His colleagues, and particularly Johansen, warned him against too early a start. Amundsen wanted to start on August 24th but having twice put it to a vote “ and having been defeated “ he yielded. Finally, on September 8th, 1911, which is still the Polar winter, Amundsen could restrain himself no longer, and the party of men, sledges and dogs set off from their base.

The start turned out to be a disaster. Temperatures plummeted; dogs died from the cold; liquid froze in compasses; and the men eventually turned back. At breakfast , after they had all returned, Johansen took Amundsen to task for what had happened . This challenge to his leadership was too much for Amundsen. Johansen was removed from the party going to the Pole. Years later he would commit suicide.

CASE STUDY 2

I have stated that not having one leader will guarantee failure. Unhappily, the converse isn't true: having a leader doesn't guarantee success. Scott (Huntford, 1993) is a case in point. He was all the things I have indicated above. He did live, eat and breathe the project. He was going to get it done or die in the attempt. Scott reached the South Pole a month after Amundsen and perished with all four of his team on the return journey.

In terms of structured project management, it was Scott's failure to carry out Steps 2, 5, 6 and 8 which sealed his fate. To reiterate, there must be one leader. Not zero, not two and not a committee. I believe your project will fail if this is not so.

CASE STUDY 3

I remember my first day on the job in a new company. I was given a copy of the Project Status Book. As the name suggested the book contained the state of every project in the organization. It was updated weekly, well laid-out and very pretty. Each page had some summary information about the project at the top; name, start and end dates, project leader, and so on.

I was amazed to see the same handful of names in all the project leader slots. There were people in there handling ten, fifteen projects. I was young then, and very impressed; I thought these guys must be absolute tigers to be able to stay on top of so many things. It was only later I discovered that they weren't on top of all these things, and that their names up there in the heading meant nothing. Sure they were responsible, maybe their necks were even on the line for those projects, but they sure as hell weren't leading them. There must be one leader.

CASE STUDY 4

One idea I have come across a few times in software projects is that of having a technical leader and a managerial or administrative leader. The managerial leader is more a manager-type person who has no interest in technical issues, while the technical leader doesn't want to be a manager, but still wants to have a big say in what goes on.

Forget it. Unless there is one manager and he has the final, overall say, then a Laurel and Hardy approach like this won't work. There must be one leader.

   


How To Run Successful Projects III. The Silver Bullet
How to Run Successful Projects III: The Silver Bullet (3rd Edition)
ISBN: 0201748061
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net