建筑專業(yè)外文翻譯---項(xiàng)目管理統(tǒng)一的方法

1、<p><b>　　英語原文</b></p><p>　　A Unified Approach to Project Management</p><p>　　Thomas Froese* and Sheryl Staub-French*</p><p>　　*Dept. of Civil Engineering, Univ. of

2、British Columbia, Vancouver, BC, Canada, V6T 1Z4. e-mail: 1tfroese@civil.ubc.ca, 2sherylsf@civil.ubc.ca</p><p><b>　　Abstract</b></p><p>　　In current project management practice, the

3、overall task of designing, managing, and constructing a building is carried out by organizing the work into many distinct tasks assigned to many different groups. Most project effort is then directed towards carrying out

4、 these tasks in the most effective manner possible, while relatively little effort (concentrated within a few critical positions) is focused on managing the interdependencies between tasks and effectively combining these

5、 results to yiel</p><p>　　Motivation</p><p>　　Much of our previous research has been in the area of information technologies (IT) applied to the task of project management (PM) in the field of a

6、rchitecture, engineering, construction, and facilities management (AEC/FM). Within this field of research and development (R&D), a major theme has been the integration of information resources and tools throughout th

7、e AEC/FM project lifecycle. Great progress has been made in the concepts, technologies, and tools to support this integration. As of yet</p><p>　　From this initial perspective of IT, we have begun to explore

8、 potential weakness and opportunities for improvement in current project management practices. In the process, the perspective has broadened to identify several issues that are not specifically IT related. These are not

9、new concepts, but a collection of several current trends in AEC/FM and relevant ideas from other industries. In this paper, we consider several of these views on weakness in current project management practices and oppo&

10、lt;/p><p>　　Perspectives on Weaknesses and Opportunities for Project Management </p><p>　　Complexity and Interdependencies in AEC/FM projects. AEC/FM projects are often described as large and incre

11、asingly complex. A greater understanding of the nature of this complexity can point to the areas where the need for improved management is greatest.</p><p>　　Studies have identified the following characteris

12、tics as generally common to any</p><p>　　type of complex system1:</p><p>　　Complex systems are comprised of a multiplicity of things; they have a large number of entities or parts. Generally, th

13、e more parts a system contains, the more complex it is.</p><p>　　Complex systems contain a dense web of causal connections among their components. The parts affect each other in many ways.</p><p&g

14、t;　　Complex systems exhibit interdependence of their components. The behavior of parts is dependant upon other parts. If the system is broken apart, the components no longer function (like the parts of the human body).&l

15、t;/p><p>　　Complex systems are open to their outside environments. They are not selfcontained, but are affected by outside events.</p><p>　　Complex systems normally show a high degree of synergy am

16、ong their components: the whole is more than the sum of its parts.</p><p>　　Complex systems exhibit non-linear behavior. A change in the system can produce an effect that is not proportional to its size: sma

17、ll changes can produce large effects, and large changes can produce small effects. </p><p>　　To some extent, all of these features can be observed in AEC/FM projects. AEC/FM projects are made up of component

18、s such as the physical elements in a building, thedesign or construction activities, the people and resources utilized, etc. In many cases, the individual components are not complex. Yet the number of components that mak

19、e up the project is vast, and the causal connections between these components are numerous. For example, a change in the intended use of some space in a building coul</p><p>　　AEC/FM projects, then, are just

20、ifiably described as complex, largely because of the quantity and interdependence of the components that make up the project.</p><p>　　Explicit recognition of interdependency in project management approaches

21、. One of the fundamental mechanisms that the AEC/FM industry has developed for dealing with complexity is the approach of dividing project work into well-defined work tasks and assigning each work task to a specialist gr

22、oup. These tasks are then carried out, to a large extent, as if they are fairly independent from each other. To be sure, each participant has some notion that their work must follow certain work and must prec</p>

23、<p>　　Clearly, it is beneficial to organize work in such a way as to minimize interdependency among work tasks. However, we contend that a weakness of current project management practice is that it tends to treat ty

24、pical AEC/FM work tasks as being far more independent than they actually are. Instead, project management approaches should strive to make the interdependencies between work tasks more explicit. This does not increase in

25、terdependence and complexity, but it does make the existing interdepend</p><p>　　Information, Information Management, and Information Technology. All design and management tasks on AEC/FM projects are fundam

26、entally information processing tasks: they take existing project information as input and produce new project information as output. Even construction tasks, which deal with the processing of physical resources, require

27、information as a significant resource. Yet the information resources and information flows are rarely considered and managed explicitly, and are instead t</p><p>　　Information Management. We suggest the fol

28、lowing general approach to information management (IM) on AEC/FM projects. The IM should adopt a processbased approach, organizing the project into its work tasks. The IM approach should then consider three main issues:

29、1) the information requirements for each task, 2) the communication requirements between tasks, and 3) the integration across tasks and communications. For each task, the IM should evaluate what the information input req

30、uirements are, wh</p><p>　　Disparate views of a project. As stated previously, all design and management tasks work with information rather than physical resources. This information all describes or models t

31、he physical construction project, and thus it can be said that all designers and managers work with information models of the project. However, each task often works with its own unique view, perspective, or type of info

32、rmation model. This wide range of disparate views adds to the fragmentation of these tasks. There is</p><p>　　A unified IT view. One of the opportunities of emerging IT is the ability to create building info

33、rmation models: semantically rich information models of construction projects that include both 3D geometric information (3D CAD) along with nongeometric information (everything from material properties to construction c

34、osts and schedules). These models support a wide range of advanced analytical and predictive software tools, including virtual project representations such as photo-realistic 3D rende</p><p>　　This technolog

35、y offers opportunities to create a more unified approach to project management in two ways. First, by linking together disparate views of project information and supporting software interoperability, it provides a techni

36、cal platform for achieving a more integrated approach to project management. Second, the “virtual building” created by these technologies has the potential of acting as a common focal point, or unifying view, for all pro

37、ject participants, particularly during pre-con</p><p>　　Lean Construction and Workflows. There is currently a great deal of attention being paid to the area of lean construction, which spans a wide range of

38、issues that relate to the management of AEC/FM projects (Lean Construction Institute, 2002). Among these issues is the concept that when a project is made up of many interdependent tasks, a focus on optimizing each task

39、independently leads to sub-optimization of the overall project. Therefore, project management practices should ensure that tasks </p><p>　　Software Engineering and the Unified Modeling Language. Although pro

40、ject management has a much longer (and perhaps more successful) history within the field of AEC/FM than in the field of software engineering, there are some valuable lessons that AEC/FM can learn from developments in the

41、 software industry, particularly related to integrated information structures for managing projects.</p><p>　　Much of the software engineering community has consolidated around the Unified Modeling Language

42、(UML) (Object Management Group, 2002), a standard language for representing the components involved in the design and implementation of software projects. The UML provides a much more uniform and integrated (if less comp

43、rehensive) view of project requirements, processes, and elements, than comparable representations within AEC/FM (i.e., project plans and specifications, construction schedules, etc.)</p><p>　　Furthermore, U

44、ML-based software development methodologies have emerged (e.g., the Unified Process, Kendall, 2002) that tightly integrate the various project workflows with the various project artifacts (deliverables) throughout each p

45、hase of the project lifecycle. These methodologies also accentuate the cyclical and repetitive nature of the related work tasks that are carried out within workflows as they move through the phases of the project lifecyc

46、le. Unlike approaches that treat each activity</p><p>　　A Unified Approach to Project Management</p><p>　　We have argued that existing project management practices underemphasize the interrelati

47、onships between individual work tasks and other project components. This leaves the interdependencies under-recognized and under-managed, and promotes a “one-time event” thinking that hinders the quest for ongoing perfor

48、mance improvements. We have begun to conceptualize a unified approach to project management that addresses some of the weaknesses and opportunities identified above.</p><p>　　The basic approach is to adopt a

49、 framework that: 1) explicitly represents the various views that are critical for managing projects, and 2) explicitly represents the interconnections between these views. Examples of project views include the physical v

50、iew (“what”), the process view (“how, who, when”), the cost view (“how much”), etc. (Russell and Froese, 1997). If the total collection of project information is thought of as a multi-dimensional information space, then

51、the views define the dimensi</p><p>　　elements. The simplest representation of a view would be a list or hierarchical breakdown structure of the elements that make up the view (e.g., a work breakdown structu

52、re, WBS). More complex representations would capture additional relationships between the elements, such as a CPM network or an IFC model.</p><p>　　Primary Views. There are many views that can be useful for

53、managing projects. To act as a unifying management tool, however, these views should be shared with all participants, and this places a practical limit on the maximum number of views, since it would become too complex to

54、 require all participants to work with numerous, interconnected views. We propose that the following three views to be used as the primary project coordination mechanism for all participants:</p><p>　　The pr

55、oject lifecycle dimension: The first primary view is time-based, organizing the project into well-defined project phases, which are further refined into iterations. These phases are arranged in sequential chronological

56、order, constituting a logical time-view. This dimension can also provide an absolute time-view by defining the calendar dates for activities that take place within the phases. Unlike current project management practices

57、where project phases are treated “l(fā)oosely”, the phases</p><p>　　The workflow dimension: The second primary view is process-based. It organizes the work into the various work disciplines required to complete

58、the project. This is somewhat like the normal division of work into work packages, but rather than describing the tasks as discrete work packages, the work is organized as ongoing workflows, which can be further broken d

59、own into sequences or networks of sub tasks. Thus tasks are more explicitly placed in the context of the overall workflows than is common</p><p>　　The product/deliverable dimension: The third primary view or

60、ganizes the outputs or deliverables of work. This view combines two important main elements, the information that describes the construction product (facility) being created, and the physical product itself. During the

61、early phases of the project, the deliverables of design and management tasks are information about the physical facility. The collective sum of all of this information can be thought of as the building information model

62、</p><p>　　As a highly simplified example, an AEC project might be organized into the following primary views:</p><p>　　Project Lifecycle Dimension:</p><p>　　Inception Phase</p>

63、;<p>　　Design Phase</p><p>　　Construction Phase</p><p>　　Operation Phase</p><p>　　Workflow Dimension:</p><p>　　Architectural workflow</p><p>　　Struc

64、tural workflow</p><p>　　Building Services workflow</p><p>　　Cost workflow</p><p>　　Product/Deliverable Dimension:</p><p>　　IFC Product Model</p><p>　　Proje

65、ct Documents</p><p>　　Building Superstructure</p><p>　　Building Systems and Finishes</p><p>　　Integrating and Representing the Primary Views. Given these three primary dimensions, t

66、he work can be further organized by expressing the interrelationships between the dimensions:</p><p>　　Workflows vs. project lifecycle: Placing workflows and their constituent tasks within project lifecycle

67、phases creates a schedule view of the project, showing what should happen when. This can include both the logical schedule (sequencing) and absolute schedule (calendar dates). It can also show that most workflows span mu

68、ltiple phases/iterations, and can indicate the amount of effort expended on each workflow over time, which emphasizes the “ongoing processes” nature of the work.</p><p>　　Product/deliverables vs. project lif

69、ecycle: Similarly, the various project deliverables can be mapped to the project phases/iterations. The deliverables are generally cumulative, thus this shows how the total project output (the collective body of project

70、information and the physical structure) develops over time.</p><p>　　Product/deliverables vs. workflows: The assignment of project deliverables to workflows and tasks shows how work processes collaborate to

71、produce the required deliverables.</p><p>　　The definition of the three primary views and the interrelationships between them defines a three-dimensional space, as illustrated in Figure 1. Key to the applica

72、bility of this approach is the ability to represent the primary views and their interrelationships in a simple, intuitive manner that all project participants can work with. It would be ideal if this could be achieved in

73、 a single, three-dimensions format, but it seems unlikely that such a representation is possible (even the simplified</p><p>　　Figure 1: Schematic of the dimensions in a unified approach to project managemen

74、t.</p><p>　　Additional Views. We have suggested that the three primary views seem to be appropriate for the overall project organization and the coordination of all participants. However, those responsible f

75、or managing the project can add several more interrelated views. This would provide a very powerful representation of the project from all of the perspectives that are important for achieving project objectives, along wi

76、th explicit representations of the interrelationships that exist between these views.</p><p>　　Organization View: An organizational view identifies the project participants; can link participants to workflow

77、s/tasks, deliverables, etc.</p><p>　　Cost View: This view identifies the various cost schedules (estimates, costcontrol accounts, etc.) that are important to the project. Costs can be related to workflows/ta

78、sks, deliverables, organizational units, etc.</p><p>　　Risk View: As part of a risk management approach, significant risks can be identified and associated with specific workflows/tasks, deliverables, organi

79、zational units, cost items, etc.</p><p>　　Quality View: Quality management programs may identify quality metrics, inspection tasks and results, etc., associated with the workflow/tasks and deliverables.</

80、p><p>　　Requirements View: Software engineering methods formally capture system requirements using constructs such as use cases. On AEC/FM projects, requirements would typically be less structured, but it may b

81、e possible to define a view that explicitly represents the project requirements in a way that helps</p><p>　　As-Built View: As construction work proceeds, the actual results of the work, in terms of final co

82、nstruction results, actual cost and productivity data, etc., can be captured in an as-built view.</p><p>　　Other Views: A view can be created for any other area of interest on a project where a set of items

83、can meaningfully be identified that relate to other defined view, such as a contractual view, safety view, environmental impact/sustainability view, punch list/defect view, maintenance view, etc.</p><p>　　Th

84、e possibility of defining a large number of views does not imply that a significant amount of additional management work is required. Rather, it suggests that when issues are already being addressed with some form of exp

85、licit management effort, that a representation structure can be used that can capture the relationships with other management issues.</p><p>　　In many cases, the relationships between any two views may form

86、a narrowly banded matrix: each item in one view would be associated with a small number of items in the other view. This may lead to interesting possibilities, such as the ability to partially automate the creation of on

87、e view from another (e.g., automatic generation of approximate lists of construction activities and estimate items from a building product model), or the ability to recognize “exceptions”, cases where relationships d<

88、/p><p>　　Changing the Project Mindset. The unified approach to project management involves not only a change to the representational structures as outlined above, but this also a change in the way participants

89、think of the underlying project mechanism and their role in it. Currently, projects are regarded as custom, unique endeavors and project tasks as a collection of one-off activities. The thought process is to find a satis

90、factory solution to the project requirements rather than to find “the best” sol</p><p>　　In the unified approach to project management, the integrated project representations acts as project prototypes or mo

91、dels that can play the same centralrole in construction as prototypes do in manufacturing. They provide integrated, computer-based collections of all known project information. They may contain geometric information to a

92、llow tools like 3D visualization, but they also contain nongeometric design and management information, such as material properties, supplier information, cost an</p><p>　　Working with the Unified Approach t

93、o Project Management. As shown, the unified approach to project management is based on defining formalized views of project information along with the interrelationships between the views. This section will discuss how t

94、his approach might be carried out by comparing it with best practices in how project scheduling is carried out. If good scheduling and schedule control practices are used on an AEC/FM project, the project will benefit fr

95、om good work coordination</p><p>　　The project management team would define the project views to be used on the project.</p><p>　　Project planning would be carried out much as on a typical proje

96、ct, except that the results would be represented using the defined project views. This would result in lists or breakdown structures for the project phases, workflows/tasks,deliverables, etc. This would be analogous to a

97、 typical project scheduling process, where the results are represented in a CPM network.</p><p>　　The key inter-relationships between the views would be defined. This would be analogous to the way that prece

98、dence relationships are captured in a schedule, or the way that a schedule can be mapped to cost accounts, resource plans, or to a building information model (as in the case of 4D CAD). Other than the precedence relation