Archive for August 2008
The Jekyll and Hyde manager
Marty was in the server room, working with the consultant from Guaranteed Uptime, when Rob burst in. “Marty, I want you to go over to Jan’s desk right away,” he said. “She’s having trouble with the CMS again.”
“OK Rob, just as soon as I finish here.”
“No! You’ll need to go right away. If she doesn’t get looked after she’ll complain direct to Max. Then he’ll raise a stink about how inefficient IT is.” Rob’s tone was such that even the consultant looked up in askance.
Marty had been through this before. “Yeah Rob, give me five minutes. We’re almost done here.”
“You’d better get down there soon,” he said. Then , turning abruptly, he stomped off slamming the door on his way out.
The consultant looked at Marty, eyebrows raised.
“Don’t ask”, said Marty, and continued with his work.
Less than five minutes later…
“Uh oh,” said Marty sotto voce, as he heard Rob crash in again.
“I thought I told you to go over to Jan. Drop what you’re doing and go…NOW!”
Marty shook his head, and turning to the consultant he said, “I’ll be back in five.” He brushed past Rob and walked out.
—
The next day, word of Rob’s tantrum got around within the team. Regardless of the urgency of Jan’s problem, the consensus was that Rob’s behaviour was not acceptable. Yet, everyone knew that nothing would change. Rob had joined the company just under a year ago, and had been anxious to make a mark from day one. Obviously he’d succeeded, because although his team didn’t think much of him, senior management seemed to have a different view…
—
“Hi Max. Everything OK? Anything we can do for you?” asked Rob in a tone of faux sincerity. He’d spied Max entering the IT area and had rushed out to greet him.
“No. It’s all good. You’ve been looking after us very well. Jan mentioned that you sorted out some problems for her double quick yesterday.” He took Rob aside. “Look,” he said, “you’ve been doing a fine job since you took over. It’s been noticed, and even talked about at the recent board meeting. Well done, and keep it going.”
Max’s words sounded like an endorsement to Rob. “After all,” he thought, “if management likes what I’m doing, I must be doing a good job.”
—
Jekyll and Hyde and managers such as Rob are a fact of corporate life. They are easily recognised by the two faces they present at work – Jekyll to those who they report to and Hyde to those who report to them. Such behaviour enables them to get ahead in the short run but, because they ruin their work relationships in the process, they often lose out in the longer term.
There is another way, of course. That is to get ahead by doing things right. The two are not mutually exclusive, regardless of what Jekyll and Hyde managers may think. It is possible to advance and treat everyone, regardless of their position, with respect and consideration. If done this way, one will advance and also retain the loyalty of those who one may depend on in the future.
A pert myth
PERT (Program Evaluation and Review Technique) is a stock standard method to manage project schedule risk. It is taught (or at least mentioned) in just about every project management course. PERT was first used (and is considered to have originated) in the Polaris project, and is often credited as being one of the main reasons for the the success of that endeavour. The truth is considerably more nuanced: it turns out that PERT was used on the Polaris project more as PR than PM. It was often applied “after the fact” – when generating reports for Congress, who held the project purse-strings. This post is a brief look into the PERT myth, based on sources available online.
An excellent place to start is Glen Alleman’s post from 2005 entitled, Origins and Myth of PERT1. Glen draws attention to a RAND Corporation publication entitled, Quantitative Risk Analysis for Project Management – A Critical Review, written by Lionel Galway. The paper is essentially a survey of quantitative risk management and analysis techniques. The author has this to say about PERT:
…PERT was a great success from a public relations point of view, although only a relatively small portion of the Polaris program was ever managed using the technique. And this success led to adaptations of PERT such as PERT/cost that attempted to address cost issues as well. While PERT was widely acclaimed by the business and defense communities in the 1960s, later studies raised doubts about whether PERT contributed much to the management success of the Polaris project. Many contended that its primary contribution was to deflect management interference by the Navy and DoD (Department of Defense) by providing a “cover” of disciplined, quantitative, management carried out by modern methodologies…
Then, in the conclusion of the paper, he states:
…While the Polaris program touted PERT as a breakthrough in project management, as noted above not even a majority of the tasks in the project were controlled with PERT. Klementowski’s thesis in the late 1970s, although limited for generalization by the sampling technique, showed less than a majority of organizations using CPM/PERT techniques. And the interviews conducted for this report revealed a similar ambivalence: respondents affirmed the usefulness of the techniques in general, but did not provide much in the way of particular examples…
In a footnote on page 10 of the paper, the author draws attention to Sapolsky’s book The Polaris System Development: Bureaucratic and Programmatic Success in Government. Among other things, the book describes how the use of PERT on the project has been grossly overstated. Unfortunately the book is out of print, but there is an excellent review of it on Cadmus. The review has this to say about the use of PERT on the Polaris project:
…SPO (Special Projects Office) Director Vice Admiral William F. Raborn pushed PERT mercilessly. The colorful PERT charts impressed everyone, and coupled with the nature of the project, they exuded management “sex appeal.” This kept other DoD poachers at bay and politicians off SPO’s back. Other government services became so enamored with PERT, they quickly made it a requirement in subsequent contracts.A more objective assessment of PERT is that the network analysis2 is the major benefit. PERT can reduce cost and time overruns, and make its practitioners look like better managers…
The Royal Navy knew of the over-inflated success of PERT when it embarked on its own Polaris program in the 1960’s. The Royal Navy deliberately adopted PERT, essentially to keep Whitehall, Parliament and other critics away from their project. It worked just as well for the RN as it did for the USN
…
I found the accounts of PERT presented in these sources fascinating, because they highlight how project management history can be so much more ambiguous (and messier) than textbooks, teachers and trainers would have us believe. Techniques are often taught without any regard to their origins and limitations. Thus disassociated from their origins, they take on a life of their own leading to myths where from it is difficult to separate fact from fiction.
1 Glen Alleman also discusses some limitations of PERT in this and another post on his blog.
2 Network analysis refers to task sequencing (precedence and dependencies) rather than task durations.
Eight to Late 