建筑項目管理外文翻譯

1、<p>　　二 ○ 一一屆 畢 業(yè) 設(shè) 計</p><p><b>　　外文翻譯</b></p><p>　　學(xué) 院：建筑工程學(xué)院</p><p>　　專 業(yè)：工程管理</p><p><b>　　姓 名：盧未</b></p><p>　　學(xué)

2、 號：2802070123</p><p><b>　　指導(dǎo)教師：來延肖</b></p><p>　　完成時間：2011.6.15</p><p><b>　　二〇一一年六月</b></p><p><b>　　英語原文</b></p><p>　　A

3、Unified Approach to Project Management</p><p>　　Thomas Froese* and Sheryl Staub-French*</p><p>　　*Dept. of Civil Engineering, Univ. of British Columbia, Vancouver, BC, Canada, V6T 1Z4. e-mail: 1

4、tfroese@civil.ubc.ca, 2sherylsf@civil.ubc.ca</p><p><b>　　Abstract</b></p><p>　　In current project management practice, the overall task of designing, managing, and constructing a bui

5、lding 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 these tasks in the most effective manner possible, while r

6、elatively little effort (concentrated within a few critical positions) is focused on managing the interdependencies between tasks and effectively combining these results to yiel</p><p>　　Motivation</p>

7、<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 architecture, engineering, construction, and facilities mana

8、gement (AEC/FM). Within this field of research and development (R&D), a major theme has been the integration of information resources and tools throughout the AEC/FM project lifecycle. Great progress has been made in

9、 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 potential weakness and opportunities for improvement in cu

10、rrent project management practices. In the process, the perspective has broadened to identify several issues that are not specifically IT related. These are not new concepts, but a collection of several current trends in

11、 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</p><p>　　Perspectives on Weaknesses and Opport

12、unities for Project Management </p><p>　　Complexity and Interdependencies in AEC/FM projects. AEC/FM projects are often described as large and increasingly complex. A greater understanding of the nature of t

13、his complexity can point to the areas where the need for improved management is greatest.</p><p>　　Studies have identified the following characteristics as generally common to any</p><p>　　type

14、of complex system1:</p><p>　　Complex systems are comprised of a multiplicity of things; they have a large number of entities or parts. Generally, the more parts a system contains, the more complex it is.<

15、/p><p>　　Complex systems contain a dense web of causal connections among their components. The parts affect each other in many ways.</p><p>　　Complex systems exhibit interdependence of their compon

16、ents. 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).</p><p>　　Complex systems are open to their outs

17、ide environments. They are not selfcontained, but are affected by outside events.</p><p>　　Complex systems normally show a high degree of synergy among their components: the whole is more than the sum of its

18、 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: small changes can produce large effects, and large changes can

19、 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 components such as the physical elements in a building, thedesign or

20、 construction activities, the people and resources utilized, etc. In many cases, the individual components are not complex. Yet the number of components that make up the project is vast, and the causal connections betwee

21、n 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 justifiably described as complex, largely because of the quanti

22、ty and interdependence of the components that make up the project.</p><p>　　Explicit recognition of interdependency in project management approaches. One of the fundamental mechanisms that the AEC/FM industr

23、y 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 group. These tasks are then carried out, to a large extent, a

24、s 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><p>　　Clearly, it is beneficial to organize work in su

25、ch 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 typical AEC/FM work tasks as being far more independent than

26、they actually are. Instead, project management approaches should strive to make the interdependencies between work tasks more explicit. This does not increase interdependence and complexity, but it does make the existing

27、 interdepend</p><p>　　Information, Information Management, and Information Technology. All design and management tasks on AEC/FM projects are fundamentally information processing tasks: they take existing pr

28、oject information as input and produce new project information as output. Even construction tasks, which deal with the processing of physical resources, require information as a significant resource. Yet the information

29、resources and information flows are rarely considered and managed explicitly, and are instead t</p><p>　　Information Management. We suggest the following general approach to information management (IM) on A

30、EC/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: 1) the information requirements for each task, 2) the commu

31、nication requirements between tasks, and 3) the integration across tasks and communications. For each task, the IM should evaluate what the information input requirements are, wh</p><p>　　Disparate views of

32、a project. As stated previously, all design and management tasks work with information rather than physical resources. This information all describes or models the physical construction project, and thus it can be said t

33、hat 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 information model. This wide range of disparate views adds to t

34、he 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 information models: semantically rich information models of con

35、struction projects that include both 3D geometric information (3D CAD) along with nongeometric information (everything from material properties to construction costs and schedules). These models support a wide range of a

36、dvanced analytical and predictive software tools, including virtual project representations such as photo-realistic 3D rende</p><p>　　This technology offers opportunities to create a more unified approach to

37、 project management in two ways. First, by linking together disparate views of project information and supporting software interoperability, it provides a technical platform for achieving a more integrated approach to pr

38、oject management. Second, the “virtual building” created by these technologies has the potential of acting as a common focal point, or unifying view, for all project participants, particularly during pre-con</p>&

39、lt;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 issues that relate to the management of AEC/FM projects (Le

40、an 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 independently leads to sub-optimization of the overall proj

41、ect. Therefore, project management practices should ensure that tasks </p><p>　　Software Engineering and the Unified Modeling Language. Although project management has a much longer (and perhaps more success

42、ful) 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 software industry, particularly related to integrated info

43、rmation structures for managing projects.</p><p>　　Much of the software engineering community has consolidated around the Unified Modeling Language (UML) (Object Management Group, 2002), a standard language

44、for representing the components involved in the design and implementation of software projects. The UML provides a much more uniform and integrated (if less comprehensive) view of project requirements, processes, and ele

45、ments, than comparable representations within AEC/FM (i.e., project plans and specifications, construction schedules, etc.)</p><p>　　Furthermore, UML-based software development methodologies have emerged (e

46、.g., the Unified Process, Kendall, 2002) that tightly integrate the various project workflows with the various project artifacts (deliverables) throughout each phase of the project lifecycle. These methodologies also acc

47、entuate 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 lifecycle. Unlike approaches that treat each activity</p>&

48、lt;p>　　A Unified Approach to Project Management</p><p>　　We have argued that existing project management practices underemphasize the interrelationships between individual work tasks and other project com

49、ponents. This leaves the interdependencies under-recognized and under-managed, and promotes a “one-time event” thinking that hinders the quest for ongoing performance improvements. We have begun to conceptualize a unifie

50、d approach to project management that addresses some of the weaknesses and opportunities identified above.</p><p>　　The basic approach is to adopt a framework that: 1) explicitly represents the various views

51、 that are critical for managing projects, and 2) explicitly represents the interconnections between these views. Examples of project views include the physical view (“what”), the process view (“how, who, when”), the cost

52、 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 the views define the dimensi</p><p>　　elements

53、. 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 structure, WBS). More complex representations would capture additi

54、onal 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 managing projects. To act as a unifying management tool, ho

55、wever, 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 require all participants to work with numerous, interconne

56、cted views. We propose that the following three views to be used as the primary project coordination mechanism for all participants:</p><p>　　The project lifecycle dimension: The first primary view is time-b

57、ased, organizing the project into well-defined project phases, which are further refined into iterations. These phases are arranged in sequential chronological order, constituting a logical time-view. This dimension can

58、 also provide an absolute time-view by defining the calendar dates for activities that take place within the phases. Unlike current project management practices where project phases are treated “l(fā)oosely”, the phases</

59、p><p>　　The workflow dimension: The second primary view is process-based. It organizes the work into the various work disciplines required to complete the project. This is somewhat like the normal division of w

60、ork 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 down into sequences or networks of sub tasks. Thus tasks are

61、 more explicitly placed in the context of the overall workflows than is common</p><p>　　The product/deliverable dimension: The third primary view organizes the outputs or deliverables of work. This view comb

62、ines two important main elements, the information that describes the construction product (facility) being created, and the physical product itself. During the early phases of the project, the deliverables of design and

63、 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 </p><p>　　As a highly simplified example, an A

64、EC project might be organized into the following primary views:</p><p>　　Project Lifecycle Dimension:</p><p>　　Inception Phase</p><p>　　Design Phase</p><p>　　Constructi

65、on Phase</p><p>　　Operation Phase</p><p>　　Workflow Dimension:</p><p>　　Architectural workflow</p><p>　　Structural workflow</p><p>　　Building Services work

66、flow</p><p>　　Cost workflow</p><p>　　Product/Deliverable Dimension:</p><p>　　IFC Product Model</p><p>　　Project Documents</p><p>　　Building Superstructure&

67、lt;/p><p>　　Building Systems and Finishes</p><p>　　Integrating and Representing the Primary Views. Given these three primary dimensions, the work can be further organized by expressing the interrel

68、ationships between the dimensions:</p><p>　　Workflows vs. project lifecycle: Placing workflows and their constituent tasks within project lifecycle phases creates a schedule view of the project, showing what

69、 should happen when. This can include both the logical schedule (sequencing) and absolute schedule (calendar dates). It can also show that most workflows span multiple phases/iterations, and can indicate the amount of ef

70、fort expended on each workflow over time, which emphasizes the “ongoing processes” nature of the work.</p><p>　　Product/deliverables vs. project lifecycle: Similarly, the various project deliverables can be

71、mapped to the project phases/iterations. The deliverables are generally cumulative, thus this shows how the total project output (the collective body of project information and the physical structure) develops over time.

72、</p><p>　　Product/deliverables vs. workflows: The assignment of project deliverables to workflows and tasks shows how work processes collaborate to produce the required deliverables.</p><p>　　Th

73、e definition of the three primary views and the interrelationships between them defines a three-dimensional space, as illustrated in Figure 1. Key to the applicability of this approach is the ability to represent the pri

74、mary 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 a single, three-dimensions format, but it seems unlikely t

75、hat such a representation is possible (even the simplified</p><p>　　Figure 1: Schematic of the dimensions in a unified approach to project management.</p><p>　　Additional Views. We have suggeste

76、d that the three primary views seem to be appropriate for the overall project organization and the coordination of all participants. However, those responsible for managing the project can add several more interrelated v

77、iews. This would provide a very powerful representation of the project from all of the perspectives that are important for achieving project objectives, along with explicit representations of the interrelationships that

78、exist between these views.</p><p>　　Organization View: An organizational view identifies the project participants; can link participants to workflows/tasks, deliverables, etc.</p><p>　　Cost View

79、: This view identifies the various cost schedules (estimates, costcontrol accounts, etc.) that are important to the project. Costs can be related to workflows/tasks, deliverables, organizational units, etc.</p>&l

80、t;p>　　Risk View: As part of a risk management approach, significant risks can be identified and associated with specific workflows/tasks, deliverables, organizational units, cost items, etc.</p><p>　　Qual

81、ity View: Quality management programs may identify quality metrics, inspection tasks and results, etc., associated with the workflow/tasks and deliverables.</p><p>　　Requirements View: Software engineering m

82、ethods formally capture system requirements using constructs such as use cases. On AEC/FM projects, requirements would typically be less structured, but it may be possible to define a view that explicitly represents the

83、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 construction results, actual cost and productivity data, etc.

84、, 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 can meaningfully be identified that relate to other defined

85、 view, such as a contractual view, safety view, environmental impact/sustainability view, punch list/defect view, maintenance view, etc.</p><p>　　The possibility of defining a large number of views does not

86、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 explicit management effort, that a representation structure ca

87、n be used that can capture the relationships with other management issues.</p><p>　　In many cases, the relationships between any two views may form a narrowly banded matrix: each item in one view would be as

88、sociated 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 one view from another (e.g., automatic generation of approxim

89、ate lists of construction activities and estimate items from a building product model), or the ability to recognize “exceptions”, cases where relationships d</p><p>　　Changing the Project Mindset. The unifie

90、d 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 think of the underlying project mechanism and their role in

91、 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 satisfactory solution to the project requirements rather than to

92、 find “the best” sol</p><p>　　In the unified approach to project management, the integrated project representations acts as project prototypes or models that can play the same centralrole in construction as

93、prototypes do in manufacturing. They provide integrated, computer-based collections of all known project information. They may contain geometric information to allow tools like 3D visualization, but they also contain non

94、geometric design and management information, such as material properties, supplier information, cost an</p><p>　　Working with the Unified Approach to Project Management. As shown, the unified approach to pro

95、ject management is based on defining formalized views of project information along with the interrelationships between the views. This section will discuss how this approach might be carried out by comparing it with best

96、 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 from good work coordination</p><p>　　The project

97、 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 project, except that the results would be represented using the

98、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 typical project scheduling process, where the results are