NoCode,NoKey(ProjectTypologies)

　　William R. Duncan
　　For the past seven years, I have used one key to open both the outer and inner doors to my office. I recently changed the lock on the inner door, and asked the locksmith for a new key that would, like the old one, open both doors. He asked if I had the code for the outer door. I didn抰. "Sorry," he announced, "no code, no key."
　　
　　I think my keys are a lot like project managers. Some are good at opening certain doors (managing certain types of projects) and not so good at opening others (managing other types of projects). I began to wonder, was there a key-code that I could use to match project to project manager such that I could be (reasonably) sure of a good fit?
　　
　　
　　
　　
　　Project Typology
　　What we need for a key-code is a project typology — a systematic classification of project types that have characteristics or traits in common. Over the past decade, several authors have published articles that attempted to provide a typology by classifying projects aclearcase/" target="_blank" >ccording to size, sector or industry, end result, or some combination of several factors. Few of these typologies, however, were explicitly targeted at developing a mechanism — a key-code — to help match project to project manager.
　　
　　
　　
　　APM Key-Code
　　The Association of Project Managers (APM) in the UK has developed a fairly typical typology as part of their project manager certification program. Their key-code identifies four categories of projects:
　　Level One: an in-house project involving a single disciplinary team.
　　Level Two: an in-house project involving a multidisciplinary team.
　　Level Three: a multicompany multidisciplinary project.
　　Level Four: a multicountry multicompany multidisciplinary project.
　　The implicit assumption in this key-code is that a project manager who has demonstrated competence (which APM defines as "the ability to acquire and apply knowledge and skills in the appropriate context") at a given level can be expected to perform well in any project at that level. However, this simplified approach fails to answer some important questions, for example:
　　Can a project manager at a given level be expected to perform well at that level regardless of the size or length of the project?
　　Will a project manager who has demonstrated competence on a level three construction project be equally effective managing a level three systems integration project?
　　Where do we classify a project manager who manages across national boundaries within a single corporate structure?
　　Should we expect a project manager who is successful with a British-Australian team to be as successful with a Japanese-Nigerian team?
　　
　　
　　
　　Other Dimensions
　　These concerns lead to a more general question: what are the other dimensions of a project that may influence the fit between project and project manager? In no particular order, I think the APM list could be expanded to include at least the following:
　　Size. Success on a small project does not guarantee success on a large one.
　　Project product. Few project managers are expert in all the technologies involved in their projects, but they generally need to be familiar with some of the fundamentals. What level of technical knowledge should we expect from a project manager?
　　Phase range. A construction project manager may be only be involved in a single phase of the owner抯 project.
　　Cost elements. Capital facilities projects generally involve substantial quantities of purchased goods and services. Research and development projects generally involve little of either.
　　Form of agreement. My firm has performed large projects on little more than a handshake and small projects where the contractual documentation was thicker than the final report.
　　Media visibility. Some projects are managed on the front pages of the local tabloids while others barely see the light of an internal employee newsletter.
　　Number of sponsors. The person with the gold may make the rules, but when there are many people who share the gold, the rules may be in a constant state of flux.
　　Public vs. private. Work in the public sector isn抰 necessarily harder (or easier), but it sure is different.
　　Technology. Is it complex or simple? Proven or not? Experimental, evolving, or untried?
　　Labor supply. The project manager who cannot easily replace a worker or subcontractor faces a more severe challenge than the PM who can.
　　Most organizations currently use at least some of these factors to match their projects to their project managers. For example, one electric utility identifies "critical factors" during the feasibility study, and then does its best to assign a project manager with demonstrated skills in the critical areas.

原文转自：http://www.ltesting.net