Author Archive
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.
Running successful projects – some lessons from strategy execution
In a recent Harvard Business Review article entitled The Secrets to Successful Strategy Execution, Gary Neilson, Karla Martin and Elizabeth Powers identify reasons why many companies fail in translating strategy to reality. Their research is based on surveys from over 100,000 employees in more than 1000 organisations worldwide. The article also lists the top five traits of organisations that are effective in executing strategy. When reading these, it occurred to me that the same characteristics are also crucial for successful project execution. Judge for yourself: the attributes, rephrased in project management terms, are listed and discussed below.
- Everyone has a good idea of the decisions and actions for which he or she is responsible: The project manager shouldn’t be the sole decision maker on the team. Many decisions (and follow-on actions) are best made by individual team members, especially when these pertain to their expertise. A smart project manager realises this and delegates specific decision rights and action responsibilities to appropriate persons on the team. Empowering the team in this way removes decision bottlenecks and keeps the project running smoothly. Moreover, delegating real responsibility demonstrates trust and improves team morale.
- Important information about the project and its environment gets to the project manager quickly: A project and its environment are dynamic – things change, sometimes from day to day. When changes that affect the project occur, it is important that the project manager is made aware of these as soon as possible. As an example, a developer realises that an approach he intended to use isn’t going to work. Rather than taking unilateral action – say, by shoe-horning his efforts into the time allotted – it’s better to let the project manager know so that both the developer and project manager can come up with a mutually agreed approach. This is critical because the project manager may be aware of certain things (like reserve time or resources, for example) that the developer isn’t. If project-related information doesn’t get to the manager quickly, it is inevitable that sub-optimal decisions will be made – either by the project manager or the team.
- Once made, decisions are rarely second guessed: If the project manager has delegated decision rights (as per the first point above), it is imperative that decisions made by team members aren’t second guessed. Too many project teams spend time reviewing decisions ad nauseum. Don’t do it – once a decision is made, get on with it. Decisions should be revisited only in exceptional circumstances, and only with very good reasons.
- Information flows freely across all project interfaces: This is all about communication. Many projects suffer from a lack of open communication between various stakeholders (see my post on obstacles to project communication for more on this). One of the important functions of a project manager is to ensure smooth communication, both within a team (internal interfaces) and between a team and other stakeholders (external interfaces). Most project managers are conditioned to ensure good communication across external interfaces, especially when the external party is a sponsor! But they often neglect to facilitate communication between team members. Dysfunctional communication within a team can kill a project, so project managers should continually watch for signs of intra-team communication problems. Communication, or information flow, is a good segue into the next point which is…
- Team members usually have the information they need to understand the impact of their day-to-day choices: Team members are at the coalface of the project. They’re the ones who, through their day-to-day work, are making it happen. Seemingly inconsequential decisions made by them can have a large knock on effect on the project. Given this, they should be fully aware of the impact that their choices (and actions thereof) can have on a project. This can happen only if they have all relevant information regarding the project. What’s relevant? That’s up to the project manager to figure out, and communicate to every team member.
Perhaps you’re asking, “Why should traits relevant to effective strategy implementation have anything to do with running projects?” Well, a strategy can be regarded as a set of time-bound objectives together with a plan for implementing them. This makes it a project. So it’s no surprise that traits which improve an organisation’s effectiveness in implementing strategy also make project teams better at executing projects.
Eight to Late 