So we are having an office discussion of where the different phases of services overlap and occur out of sequence. For example when a client makes a change once CDs are well underway... What are some of the forum members opinions on what exactly can be classified as schematic design, design development and then obviously the end product of the CDs... what milestones, triggers., etc are there to determine you have began to transition to DD or CD phases...any feedback would be greatly appreciated.
You have to define what is what in your contract. If you're asked to do something outside the contract, it's an additional service requiring a contract and fee amendment. So, if your client wants you to redesign something after you've got their approval on the previous design work and have started executing contract documents, and you want to get paid for that, you need to insist on an add services agreement first.
So, as a general rule, you should insist and write into your contracts that delivery, acceptance, and payment for deliverables at a key milestone (e.g. 100% Schematic Design) implies acceptance of the underlying design work described therein. Thus further changes to those things require more time and money to accomplish.
More broadly, the whole idea of linear process as strictly-defined design phases is LOL. That's how our contracts are written, but that's not how the process actually works. Decades ago, we adopted this phased waterfall model of our work process from the manufacturing sector. But designing buildings is not even a little bit like making cars. The process isn't linear, and it doesn't fit into tidy phases one after the other. It's parallel, iterative, and non-linear.
The standard AIA phases are simply a tool for trying to manage that chaos (and not a very good one, frankly), not a map for what the process really is or how it should work. Failure to grasp that distinction (e.g. taking the map for the territory) is the source of most business and process management failures I've seen in this profession. To be blunt, there is no such thing as "Schematic Design," "Detailed Design," etc. So trying to describe a set of uniform, universal components of any of those things is a fruitless and wasteful enterprise.
Some firms have forms they have clients sign which acknowledge the closure of each of these phases, assuming they've gone fairly sequentially, and by their very nature signifies that more moolah is needed for capricious changes. For architect errors, noncompliance to the program, and being markedly over a realistic and communicated budget, the architect usually does it on their dime. I think phase completion sign-offs are a better idea than not. In some firms, maybe during internship, I don't know if they were used or not, because I wasn't privy to the financial aspects of projects.
I have no clue as to what the industry standard or format is for determining these benchmarks or if the phases sort of abut each other while the billing just continues. Perhaps someone else can weigh in on the defining parameters for the architect and the client agreeing that a phase is complete.
Yes, the phases as defined for us by the AIA are a tool and only as good as their implementation. There are many opportunities for gray areas in the chaos and, realistically, even the best implementation of the process can get fuzzy.
It can be like herding cats sometimes. All that said, we have to bring structure to the process or it will very easily get out of hand. Definition of milestones and clarity in what is included and what's extra is our best defense.
There are many kinds of clients and some will abuse this process taking any advantage they can but there are also many who understand the process and work with a "win/win" mindset. These are the ones you want to take care of.
The AIA phase definitions are not "only as good as their implementation." They're garbage, based on an old, inapplicable, and obsolete approach to project and process management. You can use them to manage what you're doing, and you might have some success at it if you are especially diligent about it and what you're doing is relatively straightforward and simple, but doing so will limit your effectiveness and profitability substantially.
By adhering to these old and poorly-adapted theories of contract and project management, architects hurt ourselves tremendously. Here are some fun links for you if you're interested in the subject:
If you want to see how architects could be doing project and contract management much better, take a look at Agile Development and Lean Design in particular.
SD / DD / CD
So we are having an office discussion of where the different phases of services overlap and occur out of sequence. For example when a client makes a change once CDs are well underway... What are some of the forum members opinions on what exactly can be classified as schematic design, design development and then obviously the end product of the CDs... what milestones, triggers., etc are there to determine you have began to transition to DD or CD phases...any feedback would be greatly appreciated.
You have to define what is what in your contract. If you're asked to do something outside the contract, it's an additional service requiring a contract and fee amendment. So, if your client wants you to redesign something after you've got their approval on the previous design work and have started executing contract documents, and you want to get paid for that, you need to insist on an add services agreement first.
So, as a general rule, you should insist and write into your contracts that delivery, acceptance, and payment for deliverables at a key milestone (e.g. 100% Schematic Design) implies acceptance of the underlying design work described therein. Thus further changes to those things require more time and money to accomplish.
More broadly, the whole idea of linear process as strictly-defined design phases is LOL. That's how our contracts are written, but that's not how the process actually works. Decades ago, we adopted this phased waterfall model of our work process from the manufacturing sector. But designing buildings is not even a little bit like making cars. The process isn't linear, and it doesn't fit into tidy phases one after the other. It's parallel, iterative, and non-linear.
The standard AIA phases are simply a tool for trying to manage that chaos (and not a very good one, frankly), not a map for what the process really is or how it should work. Failure to grasp that distinction (e.g. taking the map for the territory) is the source of most business and process management failures I've seen in this profession. To be blunt, there is no such thing as "Schematic Design," "Detailed Design," etc. So trying to describe a set of uniform, universal components of any of those things is a fruitless and wasteful enterprise.
Thanks for the feedback, I agree chaos management sounds about right.
Some firms have forms they have clients sign which acknowledge the closure of each of these phases, assuming they've gone fairly sequentially, and by their very nature signifies that more moolah is needed for capricious changes. For architect errors, noncompliance to the program, and being markedly over a realistic and communicated budget, the architect usually does it on their dime. I think phase completion sign-offs are a better idea than not. In some firms, maybe during internship, I don't know if they were used or not, because I wasn't privy to the financial aspects of projects.
I have no clue as to what the industry standard or format is for determining these benchmarks or if the phases sort of abut each other while the billing just continues. Perhaps someone else can weigh in on the defining parameters for the architect and the client agreeing that a phase is complete.
++gwharton
I use single-page letter agreements that memorialize verbal contracts.
Jaffe's Second Rule: If you need a lawyer, it's already too late.
Yes, the phases as defined for us by the AIA are a tool and only as good as their implementation. There are many opportunities for gray areas in the chaos and, realistically, even the best implementation of the process can get fuzzy.
It can be like herding cats sometimes. All that said, we have to bring structure to the process or it will very easily get out of hand. Definition of milestones and clarity in what is included and what's extra is our best defense.
There are many kinds of clients and some will abuse this process taking any advantage they can but there are also many who understand the process and work with a "win/win" mindset. These are the ones you want to take care of.
GSFulton,
The AIA phase definitions are not "only as good as their implementation." They're garbage, based on an old, inapplicable, and obsolete approach to project and process management. You can use them to manage what you're doing, and you might have some success at it if you are especially diligent about it and what you're doing is relatively straightforward and simple, but doing so will limit your effectiveness and profitability substantially.
By adhering to these old and poorly-adapted theories of contract and project management, architects hurt ourselves tremendously. Here are some fun links for you if you're interested in the subject:
Stuck in the '60s
The Underlying Theory of Project Management is Obsolete
Wicked Problems & Social Complexity
If you want to see how architects could be doing project and contract management much better, take a look at Agile Development and Lean Design in particular.
++ Wicked link. Thanks.
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.