A project description is not an artistic statement; it’s a focused account of what a project entails. To nail this down, specificity is key. Address the crucial questions: where, what, why, when, and how. For example, the American Institute of Architects’ model agreement contains an architect’s fill-in-the blank project description as stated below.
AGREEMENT made as of the « » day of « » in the year « »
(In words, indicate day, month and year.)
BETWEEN the Architect’s client identified as the Owner:
(Name, legal status, address and other information)
« »« »
« »
« »
« »
and the Architect:
(Name, legal status, address and other information)
« »« »
« »
« »
« »
for the following Project:
(Name, location and detailed description)
« »
« »
« »
The Owner and Architect agree as follows.
Likewise, the Engineers Joint Contract Documents Committee’s model agreement EJCDC E-500 Agreement Between Owner & Engineer for Professional Services states:
While it is true that many times an architect’s or engineer’s client comes to the table with a pre-determined project description. But many times, that is not the case. Or, the client has a vision of their project, but the architect’s or engineer’s experience and education may be able to fine-tune the project’s description. This is especially true for certain project types, such as high-end residential or signature projects like a museum or civic center.
Too Much Detail
Caveat—but do not over-step your bounds with too much detail that can haunt you. True story—architect’s project description included “X” number of parking spaces (more than 200) in an attached garage to a proposed office building. The client had not paid the architect up to that point, but promised that when financing came through the fees would be paid. The client’s funding fell through at the end of the preparation of the construction documents. The architect demanded payment, but the client’s position was the project was contingent upon financing, and the architect breached the agreement because the final parking garage design contained a few spaces than in the project description that the architect crafted. The client’s attorney maintained that the exact number of spaces was a material condition of the project, and that was why the final garage design caused the financing to fall through. I reality, it wasn’t the parking spaces was the issue, rather it was the client’s unstable financial condition. Regardless, the dispute was settled out of court, with pennies on the dollars for the architect. Lesson learned.
That Being Said, as Applied
The “art” of drafting a project description lies in using clear, compelling language to sell the vision, while the “science” is in structuring that information with precise, measurable details. A strong project description balances a high-level overview with specific components to inform stakeholders and set the team's direction.
The practice of architecture and engineering is both an “art” and a “science.” They blend creative vision with practical, technical knowledge. The art lies in designing visually appealing structures that evoke emotion, reflect culture, and harmonize with their surroundings, while the science is in the engineering, math, and materials science required to ensure the building is structurally sound, safe, and functional.
The Art: Communicating the Project Vision
- Tell a compelling story. Explain why the project matters and the problem it will solve, not just what the project is. The description should justify the investment by highlighting the business value and benefits.
- Know your audience. A grant application, a project proposal for a boss, and a resume all require different levels of detail and tone.
- External stakeholders, like investors, need straightforward language that avoids jargon.
- Internal teams can handle more specific terminology, but need the document to be approachable and easy to reference.
- Create a strong hook. The beginning should capture attention and clearly state the project's purpose. For example, a "50-word-or-less" elevator pitch is a concise way to state how the project will solve a specific problem.
- Maintain clarity and conciseness. Avoid complex jargon, acronyms, or overly technical language that might confuse readers. Use an active voice and focus on the "what," "how," and "result" to keep the writing tight.
The Science: Structuring for the Project’s Success
- Establish SMART objectives. Goals must be Specific, Measurable, Achievable, Relevant, and Time-bound. Vague or generic language is ineffective. For instance, instead of "improve user interface," write "achieve 95% positive feedback on the user interface within two months of launch".
- Define the scope clearly. Outline exactly what the project will and will not include to manage expectations and prevent "scope creep".
- Outline deliverables and milestones. Specify the tangible outputs (deliverables) and the key checkpoints (milestones) that will be produced throughout the project's lifecycle. This helps stakeholders track progress.
- Detail the methodology and approach. Briefly describe the methods and strategies you will use to achieve the objectives, such as using a Scrum framework for a mobile app or specific research methods for a study.
- Identify stakeholders and their roles. Clearly define who is involved in or affected by the project, including decision-makers, team members, and external partners.
- Estimate the timeline and budget. Provide a high-level timeline that includes key milestones and a general estimate of the budget and resources needed.
- Address risk management. Acknowledge potential risks or hurdles and describe the plan to mitigate them. This shows foresight and builds credibility.
- Plan for monitoring and evaluation. Briefly explain the key performance indicators (KPIs) and strategies you will use to track progress and measure success.
Putting it all Together
Writing a project description is a process of refinement, not a one-and-done task. A good workflow includes:
- Draft a summary answering the who, what, where, how, and why of the project.
- Define the problem or purpose to justify the project's existence.
- Expand on the plan, covering the project's scope, objectives, methodology, and key components.
- Gather feedback from a variety of stakeholders to ensure clarity and alignment.
- Revise and refine the description. The document is often treated as a living document that can be updated as the project evolves.
____________________________________________________________________________
About the Author of this Risk Management Building Block Article
As a risk manager for the last 20 years for the design profession, Eric O. Pempus, FAIA, Esq., NCARB has experience in professional liability insurance and claims, architecture, engineering, land use, law, and a unique background in the construction industry. Prior to risk management, he has 25 years of experience in the practice of architecture/engineering, and as an adjunct professor teaching professional practice courses at the undergraduate and graduate levels for 37 years at Kent State University’s College of Architecture & Environmental Design.
As a Fellow of the American Institute of Architects and AIA National Ethics Council 2021 Chair, he has demonstrated his impact on architectural profession. He has presented numerous loss prevention and continuing educational programs to design professionals since 2000 on topics of ethics, contracts, and professional practice in various venues across the United States and Canada. He is a former member and chair of his city’s Board of Zoning & Building Appeals for 24 years, and is a licensed architect, attorney, and property & casualty insurance professional.
His educational background includes a JD from Southwestern University School of Law, Los Angeles; Master of Science in Architecture from University of Cincinnati; and BA in psychology/architecture from Miami University, Oxford, Ohio.
The above comments are based upon DesignPro Insurance Group’s experience with Risk Management Loss Prevention activities and should not be construed to represent a determination of legal issues but are offered for general guidance with respect to your own risk management and loss prevention. The above comments do not replace your need for you to rely on your counsel for advice and a legal review, since every project and circumstance differs from every other set of facts.
Disclaimer: The viewpoints expressed in this article are those of the author(s) and are not necessarily approved by, reflective of or edited by other individuals, groups, or institutions and this article is an expression by the author to generate discussion and interest in this topic.