Programming is a valuable tool in the pre-design process, and when it is successfully implemented, the result is a win-win for the client/owner, all stakeholders and the design team.
A successful program will allow the design phase to begin with the owner’s goals and requirements documented/understood and with a preliminary construction budget aligned with the project scope and requirements.
What is programming?
Programming is the process of obtaining and analyzing an owner’s requirements for a project, guiding the owner’s prioritization of his requirements and producing documentation of these requirements. The basic information needed to design the project should be in the resulting programming document.
Programming will provide a platform for stakeholder input on what should be in the project, allow for options to be developed and considered, distinguish “needs” from “wants”, and develop consensus on decisions in an organized, logical sequence.
While many public entities require programming for all of their larger projects, some public organizations and many private sector owners/clients are not on board with the concept of programming and do not understand the reasons and benefits of going through this pre-design process. Thus, it becomes incumbent on A/E’s to present the value of the programming process to their clients. While programming will have a “relatively” small up-front cost to the owner/client, there is research available (Construction Industry Institute for one) that a well conducted programming effort will likely appreciably reduce overall project costs, decrease the uncertainty in final project cost and schedule and better meet the Client’s requirements/goals.
The figure below depicts the underlying premise of programming: You can influenence/affect the outcome of a project the most during pre-project planning and for the smallest expenditure. Conversely, exerting a small influence on a project during construction (read change order) has a high relative associated expenditure.
From the A/E perspective, the absence of a formal programming process for a larger, loosely defined project puts the A/E in the position of trying to program during schematic and design development stages of a project. For many reasons, this situation is undesirable for both the Client and the A/E. Instead of beginning to structure and develop the design as is the intent of these early phases, design tasks become interwoven with programming tasks leading to a one-step forward and two-steps back scenario frustrating all involved. The result is often that all stakeholder requirements are not fully vetted and the A/E spends double the time their fee allotted for these stages without fully satisfying their Client. Scope and budget alignment is also difficult with this scenario because you have a continuously moving target.
So when the project size and type can justify a programming effort, it is in the best interest of all involved for the A/E to pro-actively present a sound, logical case for programming to their clients. – Tod Thompson , P.E., LEED AP – Principal Engineer.