Managing the Design Project PDF - RAIC Chapter 5.1 2021

10/24/21, 4:21 PM Chapiter 5.1 - RAIC Chapter 5.1 Managing the De...

10/24/21, 4:21 PM Chapiter 5.1 - RAIC Chapter 5.1 Managing the Design Project Print this page Preamble There is much information available about project management in general and managing the design project in particular. This chapter provides an overview of the key aspects of and relevant tools for design project management. This chapter cannot provide detailed information about applications or methodologies. Each firm must transform project management standards and processes to develop core competencies and competitive advantage. Introduction Effective management of the design project is an essential element of good professional practice. This chapter presents the overarching processes of managing a design project, the deliverables that those projects produce, and the role of the project architect (also called a project manager or design team leader) — the person in an architect’s office who directs and administers an architectural project. This chapter does not cover: project management as a separate professional service or form of delivery; construction management as a form of project delivery. These topics are discussed in Chapter 4.1 – Types of Design-Construction Program Delivery. This chapter provides an overview of fundamental processes and select tools appropriate for architectural practice. There are numerous texts, software, references, educational opportunities, and websites that provide detailed information about project management processes, tools and techniques. Many web-based and standalone software programs provide accessible and affordable project management solutions and tools for firms both large and small. The architect should be mindful that any project management solution must be tailored to support a practice’s processes as well as the value proposition that it offers to clients. This chapter will describe and expand on three areas of project management pivotal to project success: scope management, schedule management, and the role of the project manager or project architect. Project stakeholder management is addressed separately in Chapter 5.2. Design project cost management is discussed in Chapter 3.9 – Architectural Services and Fees. Risk management is discussed in Chapter 3.8 – Risk Management and Professional Liability. Project procurement management is discussed in several chapters, including Chapter 2.2 – The Client, Chapter 2.3 – Consultants, and Chapter 4.1 – Types of Design and Construction Program Delivery. Predictive and Adaptive Project Management The traditional approach to managing the design project is based on predictive project management. The scope of the project is defined, the costs are estimated with a degree of certainty, and the completion dates are established. Milestones are put in place and the work proceeds in sequence, following the traditional five-phase project life cycle. Predictive management reinforces adherence to the plan, sequential workflows, not moving forward without client sign-off at each phase, and limiting change. If all goes according to plan, the scope, quality, cost and schedule expectations are met, and project stakeholders are satisfied. Predictive management reduces project risk and increases the probability that project objectives and profitability will be achieved. In a predictive management environment, change is the anathema. Change may originate from multiple sources. The advent of multiple design-construction project delivery methods challenges the traditional approach to predictive project management. The value propositions of design-build (DB) and construction management (CM) both build on a fast-track approach, meaning design work continues concurrent with construction. Alternate financing and procurement (AFP) and the integrated project delivery (IPD) both expand on the number of stakeholders involved in the design-construction project during design, thereby increasing project risks and the probability of change. Change can be difficult and stressful to manage. The risk factors that influence change must be managed proactively. Without careful management, change in scope or quality may lead to decreased profitability and client satisfaction. These risk factors may result in one of project management’s biggest pitfalls, rework. That said, architects are required to address change frequently, and change may be the norm rather than the exception. https://chop.raic.ca/chapter-5.1 1/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC Although well established, predictive project management is not the only approach to managing the project life cycle and addressing change. Innovations in program and project management have resulted in change-focused methods that incorporate tools and techniques to address a need for flexibility while at the same time achieving results. A combination of predictive and adaptive project management may result in a hybrid methodology that enables a firm to capitalize on change and enhance stakeholder satisfaction. The design-construction industry is a disparate one with many players and no centralized supply chain management structure that coordinates the entire endeavour from inception to operations. In fact, a contractor’s profitability often derives from their customized supply chain management structure, wherein their competitive advantage arises from negotiated procurement and execution arrangements. Any profitability arising from process innovation may not be realized by all players, making change slow and innovation hard to adopt. The adoption of the integrated project delivery (IPD), with its shared risk and reward structure, may accelerate innovation in design and construction processes, technologies, and management methodologies. There is no one-size-fits-all approach to design project management. Each firm must build a methodology combining traditional and innovative processes and tools that are adaptable to the increasing variety of construction procurement approaches. A firm’s project management methodology should speak to how it engages its various stakeholders and the value proposition it presents to the marketplace. Investment in innovation may pay off by enhancing a firm’s core competency, leading to competitive advantage. Management of the Design Project: Differentiating the Design/Construction Program from the Design Project The term “project” can describe multiple endeavours undertaken by a variety of stakeholders in the course of achieving the desired outcomes. Design, construction and operation of a facility is multi-faceted and usually involves the following activities by the various project team members: studying the feasibility of the project; securing financing; developing the concept; developing and documenting the design; obtaining regulatory approval; obtaining agreements for construction; building the project; commissioning the project; managing issues arising during the warranty period; operating and maintaining the asset after construction completion; regenerating the existing facility for new uses or demolishing and recycling the asset. However, all of this work is typically divided into multiple clearly articulated and separate projects. For example, to a building owner, the “project” may include the land acquisition, functional programming, design, construction, and commissioning of a new facility. To the architect and engineers, the project is the design work needed as part of the delivery of professional services. To the construction contractor, the project is the construction of the building, and so on. The design/construction/commissioning endeavour is multiple projects managed as a program of interrelated undertakings. Each is carried out by different organizations with defined responsibilities. An architect may deliberately or inadvertently assume responsibility for managing the client’s planning/design/construction program. The architect’s understanding of the relationships between multiple individual projects is crucial to delivering professional services. Critical to the sustainability of the design firm is defining the scope of both products and services for each of these different projects and establishing who is responsible for the work and deliverables of each project. These variations between individual projects, as well as core and specific services required by regulation, building code (the community), project complexity, client, contractor and consultant variations, and climatic imperatives, are all subject to logical management. In the absence of management, misunderstandings of scope and responsibility can lead to lack of clarity among all parties. At worst, this lack of clarity can lead to reduced confidence in the architect, resulting in a loss, no repeat business, or litigation. Opportunities may be presented to a firm when it can identify distinct program management scope in addition to design project management scope. Program management services may be additional services that add value for the client. Clarity is required to resolve gaps or overlaps in work and responsibility in the program of related projects. Developing a Firm’s Project Management Methodology Architects work in an environment that is almost exclusively project-based, and project management is firmly within the scope of architectural practice. Unlike operational environments, such as manufacturing plants or schools, projects have a beginning and an end, and create a unique outcome. Working on projects is second nature to architects. However, with the pressure to generate https://chop.raic.ca/chapter-5.1 2/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC deliverables to meet deadline, investing resources in planning and organizing the work of the project may become a lower priority. The effort to create deliverables requires that work is planned and executed by being assigned to responsible individuals, monitored and controlled, and that the outcome is transferred to the next stakeholder or team member. Each architecture firm must develop a methodology for managing the work involved in delivering the variety of its design services. At the simplest level, that methodology includes systems for: planning the work to be done – a work plan; assigning the most appropriate resources to the work, including ongoing professional development and training; managing schedule and resources through tracking what is being done, what is pending, and what is completed; managing design project costs; identifying that quality and scope requirements are being met; transferring the deliverables in an orderly manner to the next stakeholder in the design-construction chain. Multiple national and international not-for-profit organizations have created both generic and industry-specific project management standards and certification programs. However, a project management standard is not a methodology, and a certification in project management does not guarantee performance in the role of project manager. Each firm must develop its own methodology in managing the design project. Through analyzing a firm’s mission, objectives, and culture, and the client’s need for progress reporting and deliverable status, the firm develops its own processes and applies standard or customized tools to the management of the design project. A firm’s project management methodology is not merely a set of processes to be executed but rather a core competency that demonstrates to clients the firm’s unique approach to meeting their needs at the same time as differentiating the firm from its professional competitors. One approach to project management is the project management body of knowledge developed by the Project Management Institute, which includes knowledge areas, processes and tools that apply to any project endeavour, including building design. The study and application of project management methods has grown substantially over the past two decades. A distinct project management discipline has emerged. Although the fundamental elements of managing projects, scope, schedule, cost and quality have not changed in over 70 years, the body of knowledge has expanded, and clients have increased expectations of the scope of project management services related to design service delivery. Increased expectations have led to a rise of consulting firms specializing in project management services delivery. Project management service providers (PMSP) may mediate the relationship between the client and the architect. The impact of this change in the design-construction industry, particularly with public sector clients, has resulted in changed relationships between the client and the architect, and repositioned the architectural practice in the value chain of the design-construction industry. Setting Up the Project Much of this Canadian Handbook of Practice for Architects addresses establishing the infrastructure that enables architects, technologists, specification writers, interior designers, and contact administrators to do their work efficiently and effectively. This infrastructure includes the operating systems needed to run a practice, such as accounting and payroll systems (Chapter 3.4), human resources (Chapter 3.6), and technology systems (Chapter 3.7). Chapters throughout the Handbook provide information about these basic business systems. Infrastructure also includes the systems that allow for the efficient and effective management of projects. Those systems include communications management (Chapter 5.3), quality management (Chapter 5.4), and workflow/process management (Part 6). Although there may be an apparent contradiction between the sometimes frenetic drive to create unique design deliverables and the regularization of design processes and work flow systems, great work can originate from a disciplined approach to management of the project. Establishing structured systems using checklists, reviews and approvals, and workflow tools will support the creative endeavour. The management of structured workflow systems becomes more important with the increase in integrated design activities. This becomes apparent in the implementations of the integrated design process (IDP), integrated project delivery (IPD) (see Chapter 5.5) and building information modeling (BIM) (see Chapter 5.6). Refer to the Canadian Practice Manual for BIM, Volume 2 – Company Context, Chapter 7 – Project Delivery Considerations, and Volume 3 – Project Context, Chapter 4 – Workflows for discussions of project planning within the context of establishing BIM systems within the firm. Management of the Design Project Effective management of a design project includes: identifying the project’s stakeholders, their interest in the project and their ability to influence project outcomes, and managing stakeholder engagement (Chapter 5.2 – Stakeholder Management); https://chop.raic.ca/chapter-5.1 3/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC defining both the product scope (drawings, models, and specifications) and the project scope (stakeholder engagement management, design activities, coordination, etc.); developing a plan of work that can be achieved within a realistic time frame by applying an appropriate level of human and financial resources commensurate with the fees charged, and that is validated by those doing the work; selecting, recruiting and managing people, including in-house staff and outside consultants (Chapter 3.6 – Human Resources); developing and executing a communications plan that responds to the information and decision-making needs of all project stakeholders (Chapter 5.3 – Communications Management); delegating tasks appropriately; monitoring and controlling project activities, making management interventions as necessary to achieve deadlines and financial targets (multiple chapters); controlling and managing the design process with attention to changes in scope of both the design product and the design services. Role of the Project Architect/Project Manager Before discussing the roles and characteristics of all project stakeholders, let’s first look at the project architect as a key stakeholder in the success of a design project. The role of the project architect is challenging and complex, as it requires the knowledge and skills related to architectural design as well as project management. It is widely accepted in the project management community that a competent project manager with good interpersonal skills and process knowledge should be able to manage, within reason, any type of project. However, this view may not be widely accepted outside of the project management community. The role of the project architect is complex as it encompasses not only the role of a project manager, but also that of the an architect. The project architect requires knowledge and abilities in design, building technology, document production and contract administration, as well as interpersonal, leadership, management and business acumen skills. The success of a design project depends on someone who can combine the strengths of a project manager and a designer – the project architect. The project architect or project manager is a leader generally responsible for: organizing the management of the project endeavour, including the work, schedule, budget, human resources and risk; providing the client representative and contractor with the point of contact for the design team; ensuring that the project proceeds through successive stages, from program approval to project implementation; keeping the project on time and within budget; managing the progress of the project by: directing an internal team; directing and coordinating the contribution of engineers and other consultants; achieving the firm’s financial objectives; providing proper project closeout. The project manager may be a principal, partner-in-charge, senior architect or other individual (preferably an architect) with experience in the practice of architecture, business acumen and practice management, and in leading a diverse team through the dual focus of task execution and relationship building. There are numerous sources that describe the attributes of the successful project architect/project manager. A couple of them can be found on the PSMJ Resources Inc. website, including: “What Are the Traits of the Best Project Managers?”; “9 Essential Skills of Highly Effective Design Leaders.” Coordinating Engineers and Other Consultants See Chapter 2.3 – Consultants regarding the role of consultants and agreements with consultants. See Chapter 3.8 – Risk Management and Professional Liability for issues to consider when assembling the design team. The project architect is responsible for: ensuring the scopes of work for team members are complementary and comprehensive; providing engineers and consultants with all information promptly and clearly in order to optimize their participation; ensuring that their designs and specifications are properly coordinated; maintaining morale as well as ensuring the respect and recognition of all consultants. Refer also to the standards of the Project Management Institute that provide a structured methodology for project management at www.pmi.org. The Project Organization https://chop.raic.ca/chapter-5.1 4/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC The design project organization is comprised of representatives of the client and all the firms involved in the design endeavour. Typically, the project architect is responsible for managing and coordinating the work and communications for the entire project organization. The project organization includes not only the architectural firm(s) but also all the consultants working on the project. However, a client may retain consultants individually, and coordination of the separate consultants must be included in the scope of work of the architect or one of the other consultants. Virtual Teams Most design work is conducted using virtual teams, or teams that are geographically distributed, and has been since building design specializations emerged. Architecture and engineering firms have worked collaboratively at a distance, achieving higher levels of integration through ever more sophisticated communication technologies. Even if all architectural and engineering work is undertaken by a single firm, members of that firm may be in separate and distant offices. The building and development of effective virtual project teams requires resources and time. It does not happen automatically as a result of simply knowing an individual’s role and task responsibilities. Individual firm goals and cultural differences may challenge virtual team effectiveness. Leadership and interpersonal skills are required of the project architect to meld the virtual team into a coordinated working unit. “All hands” kick-off meetings and retreats, and detailed and effective communication planning will support the project architect in enhancing the performance of the team. The advantages of virtual teams are that any one firm can manage work assignments efficiently and staff can work on multiple projects concurrently. As well, an office that is discipline-specific can sustain a high degree of expertise in their area of specialty, be it architectural design or engineering. A disadvantage of virtual teams is that staff of an office separate from that of the project architect may be required to re-prioritize the work of multiple projects on a constant basis, and any given project may suffer from the inefficiencies associated with multi-tasking. As well, differing firm cultures may obstruct effective communication and a shared understanding of project objectives and stakeholder satisfaction. Co-located Teams The common approach to design project organization is to work in virtual teams. Occasionally, a project’s complexity, scale or risk warrant the co-location of the design team. All members of the design team are brought together from different firms to a single location to optimize planning, design integration, production and collaboration. The co-located team may be situated in a project- specific office created just for the project or in a space provided by the client. The advantages of a co-located team include optimal management of project-oriented workflows, increased performance through design integration, and an opportunity to foster a high degree of team spirit and collegiality. Disadvantages may include increased project costs, as a firm may charge a premium for employees who are not available to the office for a period, and reduced discipline- specific advancement and development as project-specific objectives take priority. As well, additional costs may be associated with setting up a project-specific office. In-house Teams For small projects, project managers may carry out several of the tasks themselves. For large and complex projects, several people participate in the same task. The project manager must identify the manpower and skills required and must also constantly direct and motivate the in-house team. The composition of the team is the key factor in achieving both architectural and financial objectives. The team may include the project manager and several architects, intern architects and technicians. More complex projects or very specialized services (such as acoustics, vertical transportation systems, architectural conservation and wind studies) often require hiring outside experts. Client-Architect Agreements The project architect must review the client-architect agreement before starting work. It is preferable to use a standardized agreement such as the Canadian Standard for of Contract for Architectural Services because: standard agreements are widely recognized and accepted; the architect’s and the client’s responsibilities are clearly defined; the scope of work is clearly distinguished, between basic services and additional services. The prudent project manager will review the terms of both the client-architect and the various other consultant services agreements to fully understand the scope and limitations of the consulting services to be provided. This should forestall later misunderstandings or unreasonable expectations. The project manager should identify when any subsequent increase in fees as a result of additional https://chop.raic.ca/chapter-5.1 5/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC services is warranted, and then consult with the principal or partner-in-charge and assist in any adjustment to fees. They should also identify for resolution any shortcomings or issues associated with consultant services. See Chapter 3.8 – Risk Management and Professional Liability for more detail on client-architect agreements. Planning the Project Design Project Scope Planning Project scope includes all the work that must be done to realize a successful outcome. This includes both the scope of the design product, i.e., drawings, models and specifications, and project scope, the activities of the services being delivered. Scope management, using a traditional, predictive project planning model, starts with collecting project requirements, defining the scope of the project and the product, developing a detailed plan of work, executing the plan, monitoring the work and comparing the actual results with the plan, and making management interventions to either bring the work in line with the plan or change the plan, as required. The Business Case Scope management starts through an analysis of the client’s business case. The business case links the expected outcome of the project with an organization’s strategic objectives. Undertaking a project starts with both the architect’s and the client’s documented needs. The client’s need may be, for example, to improve response times in an emergency department, to produce more product to meet market demand, to enhance a corporation’s image in the marketplace, or to update a facility to meet occupational health and safety requirements. In commercial and institutional projects, this document may be titled “business case,” “feasibility study,” “needs assessment” or something similar. The document makes the connection between a client organization’s strategic interests and objectives, and the desired future condition. The document should present the problem at hand, including analysis, constraints and assumptions. It may or may not include a specific scope or even a defined solution to the problem. It should include the resources, financial and otherwise, that the organization is prepared to invest in the endeavour to solve the problem, although not an estimate of the cost of the yet unknown solution. The client’s business case links the client organization’s strategic need with a desired program or project outcome. For example, a board of education’s business case for a new school would outline the changing demographics of a school district over a decade or more, capital funding available for a new school, and the maximum design-construction program expenditure. It would also include operating costs and the impact that the new school would have on adjacent school zones. The architect’s business case for pursuing the design commission of the new school would include the benefits to the firm of pursuing the project over other possible opportunities, as well as the impact that the project would have on firm resources. Those benefits may include profitability, recognition, or stronger footholds in existing or new markets. The architect’s business case should link the reason for pursuing the project with the firm’s strategic goals. Analysis of the client’s business case and the architectural firm’s business case will educate the architect in the scope of the design product, the scope of the design project, and the work that needs to be done to achieve the desired outcome. Requirements Gathering Pivotal to managing project scope is having a complete a grasp of the requirements for both the product and project. Requirements may come from many sources, including the client, building users, neighbours, authorities having jurisdiction, and any stakeholder who may express an interest in the project and has the influence and power to impact project work and outcomes. Product requirements include the functional program for spaces, building systems, operational parameters, and constraints and limitations. Project requirements include the services to be provided. As well, project scope includes how communications are to be managed, the review processes of the owner, stakeholder and authorities having jurisdiction, and expectations of the format of deliverables, such as models, renderings, drawings and specifications. Requirements gathering is a process that requires leadership and interpersonal skills, communication skills, and group facilitation techniques. Three significant risks to any architectural project at this early stage are lack of clarity and understanding of the stated client requirement, unstated client requirements, and both stated and unstated stakeholder requirements. Time invested in requirements gathering is never wasted. See the ten values of effective decision-making early in the project as demonstrated in the MacLeamy Curve in Chapter 6.1 – Pre-design. Scope Definition https://chop.raic.ca/chapter-5.1 6/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC Scope definition includes the steps required to develop the project and ensure that it includes all and only the required work. Project scope definition is primarily concerned with defining what is and is not included in both product and project. Controlling project scope requires that clear definitions are established at the outset so that variations from the agreed-upon scope can be identified, documented and addressed appropriately. Activities of scope definition include: analyzing the stakeholder requirements and expectations, including those of the client, authorities having jurisdiction, building users, etc., to identify processes that require work on the part of the design team, such as the preparation and presentation of reports, applications for regulatory approvals, or information gathering sessions; identifying the requirements of the construction project delivery method; deconstructing the overall built outcome into systems and components to identify the deliverables and subdeliverables of the design process, such as a schematics design report or construction documents. Scope definition results in a scope statement. The scope statement outlines the description of both the intended product and the project. A scope statement of the product is often included as an appendix to a request for proposals (RFP) document. A scope statement of product requirements should describe the major objectives of the solution required to meet the client’s defined problem/opportunity of the project. The project objectives should also relate to the criteria the client would use to evaluate the project. Product scope may include the following example topics: spatial and physical relationships: functional spaces, facility physical size and special relationships; operational requirements; geographic boundaries; pedestrian, public transport, and vehicular site access; parking; security; special purpose functions and spaces; swing space. design considerations and building systems: environmental compliance and sustainable development; heritage considerations; structural capacity; operating and maintenance; building environmental systems; high performance envelope and systems design; emergency power. The project scope statement may include any or all of the following items: client processes and operations: client strategies, applicable policies, industry regulations (different from building codes) and possible standards violations arising, and their effects; source of funds for the project; project-specific health and safety standards; client preferred or required design-construction delivery methods – procurement management; scheduling, timing and phasing; security; value generation and design analysis. The scope statement should describe in detail the scope of the project needed to meet the stated objectives. It is important to keep in mind the requirements for both the product scope (the features and functions of a product or service) and project scope (the work required to deliver the product). The project objectives should also define the criteria that can be used by the stakeholders to judge the success of the project. The project team should work together to prepare a detailed scope statement which produces the project deliverables (scope of physical deliverables, services and activities). Assumptions and Constraints All scope statements should include a discussion of project assumptions and constraints. Assumptions should be explicitly stated and represent unknowns that need to be tested and validated in the course of the project. Assumptions may include: the building’s existing structure is capable of supporting the new changed use; https://chop.raic.ca/chapter-5.1 7/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC neighbouring landowners will object to the proposed new building’s height; the municipal services, potable water, storm water and sewage have the capacity to handle the needs of the new building. Each of these assumptions represents significant risk to a project’s success and stakeholder satisfaction if not tested, found to be valid or invalid, and acted on appropriately. Constraints are typically external to the control of the design team, such as a client’s funding deadline, a construction start as soon as the ground thaws, or a client’s desire to use a design-construction project delivery model. All assumptions and constraints should feed into the project risk management plan. Work Breakdown Structure Development The work breakdown structure (WBS) is a hierarchical, graphic representation of the work of the project. It is the hub of all other project planning and management processes and activities. It decomposes the project’s deliverables into assignable and manageable pieces. The WBS can be developed based on project phases, activities or physical deliverables and services. FIGURE 1 Work Breakdown Structure of Renovation and Addition to Elementary School (only schematic design and design development phases shown above, the linked image extends to tendering) The top level of the WBS represents the major deliverables of the project. The deliverables are broken down or “decomposed” into subdeliverables, which are then decomposed into tasks. The WBS may be many levels deep, depending on the project’s scale and complexity. The objective of decomposition is to break the work of the project into tasks that are discrete enough to be: individually understood and clearly defined (e.g., “design elevations,” “stair details drawings,” or “specification section XX-XX-XX”); clearly communicated to those delegated to do the work, including a schedule, work instructions and level of effort (cost) that can be estimated with reasonable accuracy; tracked as to status (not/started, in process, completed). The advantage of using a WBS is that it supports the project team in previewing what is included in the project, and helps to better understand how the various stages will come together to produce the final product. The WBS becomes the scope baseline, meaning it illustrates the approved work to be done, all of the work to be done, and only the work to be done. Any changes to the scope of the product or the project should be documented and approved, and then the scope baseline should be revised. Project costs are controlled at the level of each task. Resource requirements are estimated for each task. Responsibility for the execution of the project is managed through assigning tasks. Tasks are broken down into time-consuming activities, which are then sequenced before durations are estimated. The WBS is the hub of all project planning and control processes. The purpose of WBS development and other project planning and control processes is to reduce the burden of management of the project and to efficiently and effectively monitor, control and report on project progress. Design Project Schedule Planning Architects work in a deadline-driven environment. Although scope, quality and cost are all pivotal to stakeholder satisfaction, when push comes to shove, schedule often becomes the driving force in project decision-making. A well-developed project schedule may assist the architect in maintaining control over expected work when time becomes short. Project schedules are planning tools that help the project architect and teams organize various defined tasks to meet the deadlines established by client expectations and contractual obligations. In addition, schedules help to monitor progress on tasks until the project is complete. Although a variety of scheduling techniques are available for many types of projects, the project manager must select a method which can be adapted to the scale and complexity of the work. This chapter will review the basic scheduling tools commonly used in managing design projects. Milestone Chart https://chop.raic.ca/chapter-5.1 8/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC This simple tool relates the delivery of project deliverables with constraining calendar days. It may take several formats and include other information. It provides a high-level snapshot of expectations of the completion of major project phases. It typically links the completion of a specific deliverable with a calendar date. FIGURE 2 Project Milestone Chart The project milestone chart is intended to communicate executive-level information and to frame project schedule constraints. It can be created in different formats using a range of software tools. The example in Figure 2 was created using Microsoft Project and collapsing the detailed schedule to show only the date ranges of phased deliverables. Activity Lists For the schedule to be developed, the tasks of the work breakdown structure (WBS) should be further broken down into lists of activities. Ideally, each activity should include associated work instructions, forms and templates, so that team members have information to proceed with where more active mentoring is unavailable. Where project costs are controlled at the task level, the development of time-consuming activities may require that tasks are further broken down into activity lists. Where a task may extend over two weeks (a typical maximum duration for project tasks), detailed decomposition may be needed to estimate the resource requirements and the duration of activities, and to sequence the activities. FIGURE 3 Project Activity Breakdown The breakdown in Figure 3 illustrates the decomposition of work-consuming tasks to time-consuming activities. Determining the Critical Path The critical path is the longest pathway of sequential and parallel activities through a project’s schedule. It represents the shortest time in which a project can be completed. Determining the critical path requires estimating the duration of activities and sequencing activities. Network Diagram The network or precedence diagram shows the relationships between activities. https://chop.raic.ca/chapter-5.1 9/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC FIGURE 4 Overall Project Network Diagram The network diagram illustrates the relationships between all project activities. FIGURE 5 Project Network Diagram Detail - Design Development Phase Optimizing the duration of activities and carefully sequencing them by rearranging resources can result in the reduction of the length of the critical path and, therefore, the critical path. A network diagram is an excellent tool to demonstrate at which point in the development of the design project stakeholders play a role in review and approval. Where a project has required milestone or completion dates (e.g., move in before the first day of school), the network diagram may assist in identifying limits on client decisions as well as deadlines for design team progress. Gantt Chart The Gantt chart, invented by mechanical engineer Henry Gantt, moves schedule development to the next step by taking the work breakdown structure (WBS), the scheduled activities with their accompanying durations, and sequencing it on a linear calendar. The work of the project can then be visualized with each activity interpreted as a bar on a linear calendar, its length in proportion to the activity’s duration. The Gantt chart is very common because it is easy to create and use, is visually clear, and satisfies the requirements for most projects. FIGURE 6 Project Gantt Chart The Gantt chart has numerous variations. Contemporary software allows for a host of variables, such as resource names, cost or completion date. It may illustrate the linkages between the activities, as does a network diagram. However, architects are cautioned that too much information may result in a confusing diagram where the main points to be communicated are lost among a plethora of lines, text and bars. The project architect should be mindful of the information needs of project stakeholders and tailor the chart for each stakeholder group. Refining the Schedule The initial project schedule should be developed based on the assumption that all work is completed during normal working hours with no overtime, at a standard rate of pay, and applying resources at levels to optimize efficiency. Only after the complete schedule is developed can the actual duration of the project be determined. An assessment can then be conducted to ascertain whether the project’s scheduled duration is acceptable and whether the resources are available at the times planned. The techniques of fast- tracking and crashing (see below) can be applied to compress schedule duration. Resource leveling can be done to more evenly distribute resources across the project schedule and limit erratic swings in resource usage. Crashing and Fast-tracking Crashing is a schedule compression technique in which additional resources are applied to activities on the critical path to shorten activity durations and therefore the length of the critical path. Crashing is systematically applied to shorten those activities by first applying additional resources of the lowest unit cost or hourly rate, then progressively applying additional resources at increasing rates of cost until the desired duration of the critical path is achieved. A hazard in crashing is that as the critical path is shortened, other critical paths emerge. Shortening the duration of an increasing number of critical paths becomes progressively more expensive. Another disadvantage of crashing is that the cost of the project disproportionately increases. Fast-tracking is the process of changing the relationships of activities by performing work in parallel that would normally be done in sequence. An example would be completing upper floor design while foundations are already being dug. Unlike crashing, project costs are not anticipated to increase beyond the cost estimate; however, project risk does increase as out-of-sequence work may result in needed corrections and rework. Design Project Cost Planning Generally, at the beginning of a project, the client will prepare an overall budget for “their” project. The budget represents the financial resources that the client is prepared to invest. It includes the budget for the design project, the construction project, and any other facets of the overall capital asset program. It is important to obtain, review and, if necessary, question the assumptions inherent in the client’s budget, remembering the client is generally not a designer or builder and may have made unsupportable assumptions. Out of that review process should come a clear understanding by the design team of what funds are actually available for the construction contract. https://chop.raic.ca/chapter-5.1 10/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC The project architect’s/project manager’s financial roles are to manage the financial resources of the design project, monitor construction costs, and certify payments for the construction project. The tasks in the design project cost management process include: establish systems for tracking and reporting resources based on the work breakdown structure (WBS); estimate the cost of resources needed for each task, including those of the architect, engineer and specialist consultants, and apply the estimated costs of each task to the schedule to create the cost baseline (what is being spent on which tasks, when); as the project is being executed, gather resource-use data (timesheets and expense reports), typically using a time sheet reporting method where the team record their effort hours committed to individual tasks listed in the WBS; compare the actual resource use against the cost baseline, and calculate the variances; if the variances between the actual costs and the plan are unacceptable, make management decisions to either bring work in line with the cost baseline, change the baseline, or a combination of both. See Chapter 3.4 – Financial Management for controlling costs within the architectural office. See Chapter 4.2 –Construction Project Cost Planning and Control for the role of the architect in supporting the management of construction project costs. Executing the Design Project and Controlling Scope, Quality, Cost, Schedule, and Risk Controlling scope, quality, schedule, cost and risk of the design project involves the following: communicating the project plan to the project team, clearly articulating their roles and responsibilities and the project architect’s expectations; ensuring appropriate resources are available and capable of execute the work needed to create the deliverables; providing training, coaching and leadership; managing project communications, information, and stakeholder communications, including: meetings; issues log and actions arising; telephone communications; electronic and paper messages such as correspondence, memos, e-mail; record-keeping, such as meeting minutes, notes, project files and other documentation; removing obstacles that inhibit project team performance; monitoring and controlling the design project: review the work output created by the team; compare it to the project plan; control quality of the design deliverables through reviews, coordination and inspection for correctness; validate the scope of design deliverables for completeness; identify scope, quality, schedule and cost variances between the actual work and the plan; take managerial action to either bring the scope, quality, schedule and cost of the work in line with the design project plan, or change the plan, or use a combination of both; constantly monitoring and managing stakeholder engagement. Project Closeout The design project is not complete until the final steps of the closeout are finished. These document that the project, including its construction, has been properly and fully completed. Closeout must be planned to ensure that: enough resources are available to execute closeout tasks; the project’s documentation is distributed in the appropriate format to those stakeholders that need it; all design project contractual obligations are met. Contemporary software includes applications that are designed to capture project work in real time, including project completion work. This may reduce additional resources and effort at project completion. Project Evaluation The firm should assess whether the project has achieved its financial and professional objectives. This might include an external evaluation with the client. The project manager should analyze the project and if the objectives were not met, determine why and suggest corrective action for future projects. This evaluation should be communicated as widely as possible within the firm, so that lessons learned may be applied to other current and future projects. https://chop.raic.ca/chapter-5.1 11/13 10/24/21, 4:21 PM Chapiter 5.1 - RAIC Record Drawings If engaged for this service, the project manager will oversee the preparation of CAD or other format record drawings for the client, based on the contractor’s “mark-ups” which show changes made to the construction documents. Also, the project manager should return to the client any documentation, such as construction drawings and specifications, which was provided as reference for the design of renovations or additions to an existing building. Archiving Project documents, including electronic communications and record drawings, should be kept and filed so that they may be readily and quickly retrieved if they are needed for other projects or in the event of a claim. Firm Database The project manager should extract information that could be used to develop a database for future work, such as: the construction cost estimates specific to a client, project type, project delivery type or geographical location; particular process requirements for a client, contractor, contract type, community, project type or complexity, or climatic area, including environmental management systems such as LEED; re-usable construction details or specifications. This type of information may inform a rm’s master work breakdown structure (WBS). Promotional Documentation Based on some of the project documents (such as sketches, perspectives, plans and photographs) and data, project managers should prepare or assist in the preparation of a “project record” or “project data sheet” that can be added to the rm’s portfolio for future use. This record should highlight the project’s special features and main challenges, as well as demonstrate the architect’s contribution to its success. See also Chapter 3.3 – Branding, Public Relations and Marketing. Use of the “Checklist for the Management of the Architectural Project” A “Checklist for the Management of the Architectural Project” has been provided at the end of this chapter. The checklist is based on the Ontario Association of Architects’ former Practice Bulletin Number 67, Architect’s Project Progress Record. The document has been reformatted, references to provincial terms have been modi ed, and minor editorial improvements have been included. Although the design and management of architectural projects are not necessarily linear nor quanti able, this checklist can assist the