Excellent analysis! This really hits home. It’s so frustrating when the goalposts keep moving and expectations are never properly defined. I wonder how you're supposed to truly 'own' something if the requirements are a shifting mistery? It's like being asked to write code without a clear spec.
For me, the biggest question is how to do the alignment up front; Especially when dealing with people that have no clue about what computational design is and how it works. In my experience, Talking about expectations with people that have no frame of reference for the work we do, usually doesn't result in valuable targets, often we discover that we need to throw out our entire approach a couple of times during the project.
Yes, you're absolutely right. I have found that too. I can't tell you how many "final_final_V10" I have in Grasshopper scripts.
There are two things that I have seen to help hedge against this.
a) Experience.
The more projects you do, the more of an instinct you will develop about the kind of brief that you need to deliver something valuable. I know when the sentence "This is vague and I am not sure what I am doing" pops up in my head. Most likely, either party doesn't yet understand the solution and the problem.
b) A discovery phase.
This is like R&D or maybe just exploration. But the idea is to just understand the situation and figure out a way to move forward from it. This is a harder one to push for especially with deadlines and KPIs, but it's the most valuable part, especially if it's a team you've never worked with before.
Excellent analysis! This really hits home. It’s so frustrating when the goalposts keep moving and expectations are never properly defined. I wonder how you're supposed to truly 'own' something if the requirements are a shifting mistery? It's like being asked to write code without a clear spec.
For me, the biggest question is how to do the alignment up front; Especially when dealing with people that have no clue about what computational design is and how it works. In my experience, Talking about expectations with people that have no frame of reference for the work we do, usually doesn't result in valuable targets, often we discover that we need to throw out our entire approach a couple of times during the project.
Yes, you're absolutely right. I have found that too. I can't tell you how many "final_final_V10" I have in Grasshopper scripts.
There are two things that I have seen to help hedge against this.
a) Experience.
The more projects you do, the more of an instinct you will develop about the kind of brief that you need to deliver something valuable. I know when the sentence "This is vague and I am not sure what I am doing" pops up in my head. Most likely, either party doesn't yet understand the solution and the problem.
b) A discovery phase.
This is like R&D or maybe just exploration. But the idea is to just understand the situation and figure out a way to move forward from it. This is a harder one to push for especially with deadlines and KPIs, but it's the most valuable part, especially if it's a team you've never worked with before.