In a professional design practice, there are 6 main management facets, discussed under the corresponding hexagonal links above right:
Practice, Client Relationships, Risk, Quality, Design, and Projects.
In contrast to Design Management, PM is project-specific. Projects, by definition, have a start and an end, and are more or less linear in between.
Especially in small-to-medium sized practices, the same person is frequently both Design Manager and Project Manager – wearing two different hats, usually with differing agendas for each.
PM has (in this DesignNode model) the 12 core functions listed below, plus an additional category “Specialist Services”. Some of these functions are the continuation of similar functions in other functional areas. For example, “Managing Scope” starts in the CRM area, continues on through Design, and finally ends when the project is completed. Accordingly, the DM and PM functions operate side-by-side throughout the whole of the delivery process.
Core functions are those applicable to almost every construction project. Specialist services are added to the core services on an as-needed basis.
To avoid a VERY long page, I break discussion of these functions into 3 pages. F01 – F06 are outlined below. F07 – F12 are outlined in Part 2, and F13 is outlined in Part 3.
F01 Project Planning
F02 Project Communication
F03 Team Assembly & Coordination
F04 Managing Stakeholders
F05 Managing Project Scope
F06 Managing Project Information
F07 Construction Cost Planning
F09 Managing Project Schedules
F10 Managing Project Documents
F11 Managing Contracts & Bids
F12 Contract Administration & Completion
F13 Specialist Services
Planning a project is an “umbrella” activity that organizes all of the other project management functions. In generic PM systems, such as the PMI PMBOK model or the PRINCE2 model, the Project Management Plan (PMP) must be signed off by internal project stakeholders before it is implemented.
Signoff on the PMP is always a good idea, but it is less common in design & construction projects. In any case, the PMP must define the agreed scope of work between client and consultant team, as well as a schedule – and therefore describes the essence of the contract for services, with the exception of the fee for the services, which is typically contained in a separate fee letter.
Good PMPs also include a Communication Plan, a Risk Plan, a Quality Plan, and a Resources Plan. Often, the internal project team needs more information about a project than would be prudent to share with other team members and/or the client. Examples would be the client’s proclivity for litigation, slow payment, etc., or an “opportunity” plan to “grow” the project.
There are two ways to deal with this matter. First, have 2 versions of the PMP, one internal and private, and one that can be shared with the entire project team. Alternatively, keep those internal aspects of the project out of the PMP and issue a memorandum covering them. My preference is for the latter option.
Effective project planning starts before a proposal is written, and is updated as needed throughout the entire design, development, procurement and delivery process.
Project planning, at the outset, goes hand-in hand with the Proposals & Presentations and Negotiating Scope functions of Managing Client Relationships.
An important part of project planning is the selection of the method of delivery, unless that decision has already been made by the client. This is because the structure of documentation can be strongly affected by delivery method.
For example, if the delivery method is CM or CM at risk, it is quite common to break up the documentation into “trade packages”. This is no big deal if it is known before documentation starts – the documentation can be structured by trade. But if this decision is made late, a huge amount of re-documentation is often required, and it is difficult or impossible to get reimbursed for the expense.
As I have noted elsewhere in this site, there is abundant evidence and expert opinion that roughly half of claims against design professionals are caused by a breakdown of communication between designers and clients.
The Design Manager has responsibility for internal team communication, but the Project Manager has responsibility for all communication between firms in the overall design team, between those firms and the client, and all other external communication, including communicating with various authorities and public stakeholders.
This overall responsibility should not be perceived as applicable to the communication of design issues between members of the project-wide design team – that is best left to designers. The PM needs to know enough about that interaction to know that it’s working as it should – but should not concern herself about the resolution of design issues unless requested to do so by some member of the design team.
We’ve been grunting at each other without any plan for millions of years, and this method is so core to our DNA that we go on doing it – even when the situation calls for something more formal, if only to avoid half of the claims that get filed against us.
Even if you have an in-depth chat about communication with a client before starting a project, it may not be adequate. What I say, and what you hear, are not necessarily the same, because with all listen with filters, and are likely to hear what we want to hear.
Writing down the details of communication: When email and phone calls are answered, who prepares meeting agendas and minutes, and when, and all the other stuff of daily project communication provides a framework for understanding and agreement – often with amendments required. This is called a “Communication Plan”, and needs to be part of every PMP.
The Communication Plan can be standard “boilerplate” of how you prefer to work, amended only if needed to reach agreement with the client.
Team Assembly & Coordination
Putting a project team together and coordinating it throughout the project is arguably the most labor-intensive and important part of the entire PM role. I can’t, in a few paragraphs here, begin to scratch the surface of what’s required: It’s worth a book in its own right.
Fortunately, that book has been written: Leading the Team: An Architect’s Guide to Design Management; Dale Sinclair; RIBA Publishing; 2011. Although Sinclair’s work is focused on the Design Management team, his observations are equally valid when extended to the full project team. It’s the best source in print at this writing; other resources are identified under (TBC later)
Text to follow
Managing Project Scope
Text to follow
Managing Project Information
Text to follow
Ed. Note: 04.03.2016: This page is under construction. Watch this space!