Good Practices for Design Document Development Process

From the Project Management View from Rail Transit Programs and Projects Blog
by
A collection of articles sharing project processes, design and construction experience, best practices, and lessons learned along with operational knowledge related to executing programs and projects in the rail transit industry.

About this Blog

RSS

Recent Posts

Good Practices for Project Outreach

Good Practices for Field Monitoring Construction

Good Practices for Project Team Members

Good Practices for Project/Progress Meetings

Good Practices for Design Document Development Process


Categories: Construction, PMO


Based on my experience in project management on rail transit projects, critical skills and activities by project managers are communications with the team, stakeholders, contractors, consultants, technical contributors, projects sponsors and funding partners. On rail transit there is added consideration to the system users/pre-paid customers, system operating personnel, agency oversight, public officials, and communities that are served and impacted by the system.

The effective review of design documents can impact the quality of construction contracts, including specifications and drawings. Coupled with a presentation and review meetings, the input from diverse reviewers can be vetted and focused on the scheduled completion of design deliverables that meet the project plan, project purpose and objective, and the expectations of various project participants and stakeholders.

Unless an Owner has designated staff, the development of technical requirements for construction contracts is usually performed by a design consultant. The Owner identifies the consultant’s scope, deliverables and performance schedule, and establishes the process for Owner representatives to participate with the consultant in developing and reviewing the design deliverables. In order to manage the work, the Owner typically assigns a Project Manager (PM) to monitor the consultant and to ensure project participants complete activities to support a defined project plan, schedule and budget.

Design deliverables typically consist of iterative packages, such as 30%, 60%, 90% and 100% design, that are reviewed and revised before becoming the technical requirements in a construction contract. The content, format and level of detail in the deliverables are defined in the design scope, which is supplemented by the Owner’s design input such as design criteria, standard terms and conditions, model Division I specifications, industry standard specification formats and contract forms, operating standards and rules, and government code and regulations.

During the design process, the consultants will submit the deliverables to the Owner, and the PM will promptly distribute deliverables to a pre-established list of reviewers along with initial assessment/comments. As needed, the PM will provide guidance to the participants in reviewing and returning comments on the deliverables regarding technical compliance, quality and completeness of content, and consistency of format and requirements for integration with other contract components.

In order to facilitate and maintain progress on the design schedule, the PM will compile comments and conduct meeting s to assure the consultant addresses the Owner’s comments in subsequent deliverables through acceptance of the final contract-ready deliverable.

Good Practices for Design Comments
• Use a pre-defined matrix for recording comments and documenting their disposition – with fields for item numbers, reviewer, comment, specification section/page, drawing number.
• Submit comments that are presented in context for action – prefaced by change, delete, replace, verify, confirm
• Complete and provide the comments by the designated due date
• Resolve duplicate or conflicting comments before submitting the comment matrix
• Avoid comments on typos, punctuation and format that can be addressed through word processing or CAD software and administrative processes
• Avoid open-end questions that can be answered through review of design scope or design criteria
• Avoid multiple line item comments for global comments/changes – change “vendor” to “contractor”

TIP: Comments should be measured for appropriateness with the design Scope of Work (SOW) in the contract issued to the consultant for the design work. Comments outside the SOW should be presented to the Owner for disposition, and as needed, the Owner will formally modified the contract, SOW and design criteria.

Good Practices for Design Review Meetings
• Schedule meetings for a date that allows time for attendees to prepare initial comments
• Identify meeting objectives, specify input needed or decisions that are required
• Outline the expected change in content for the next iteration of deliverable
• Clarify design questions and refine the feedback into actionable comments
• Record the meetings, establish action items, and identify comments in the matrix
• Review Lessons Learned on similar contract types with comparable scope

TIP: If the meeting Agenda includes finalizing comments on specific documents or making design decisions, the meeting Announcement should conspicuously indicate the expectation and the appropriate documents distributed with the Announcement.
      

Posted on: December 31, 2017 03:56 PM | Permalink

Comments (6)

Please login or join to subscribe to this item
The content was originally published in October 2016 under DISCUSSIONS. With encouragement from my PM.com peers, it is now part of a BLOG.

Henry, good that you previous discussion post are in a blog

Thank you Henry for sharing your experience of projects in rail transit industry and best practices of design comments and review meetings.

Thanks for posting this, very informative.

Always in important to do the documentation of the meeting. Thanks for the information

Please Login/Register to leave a comment.

ADVERTISEMENTS

"It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons."

- Douglas Adams

ADVERTISEMENT

Sponsors