版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐ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
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法(英文)
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法.docx
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法.docx
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法(英文).pdf
- 建筑項目管理外文翻譯--項目管理統(tǒng)一的方法(英文).pdf
- 建筑項目管理外文翻譯
- 建筑專業(yè)外文翻譯
- [雙語翻譯]項目成本管理外文翻譯--項目成本管理的全球?qū)I(yè)標(biāo)準(zhǔn)
- 外文翻譯---統(tǒng)一消息系統(tǒng)
- [雙語翻譯]項目成本管理外文翻譯--項目成本管理的全球?qū)I(yè)標(biāo)準(zhǔn)(英文)
- 建筑專業(yè)外文翻譯--智能建筑
- 外文翻譯---建筑智能化系統(tǒng)的項目管理
- [雙語翻譯]項目成本管理外文翻譯--項目成本管理的全球?qū)I(yè)標(biāo)準(zhǔn)中英全
- 工程管理專業(yè)畢業(yè)設(shè)計外文翻譯---研究建筑施工企業(yè)的項目成本控制
- 網(wǎng)絡(luò)管理實現(xiàn)統(tǒng)一的方法
- 外文翻譯--建設(shè)項目管理方法的比較
- 工程管理畢業(yè)外文翻譯--建筑項目招投標(biāo)
- 建筑專業(yè)畢業(yè)設(shè)計外文翻譯---英國建筑公司的知識管理
評論
0/150
提交評論