It can be hard sometimes to bring up a problem to a project manager, especially when that problem feels like it should be something that you should be able to handle. After all, it's just a ceiling layout, or a pipe going through an exterior wall, or whatever, and you've been working in architecture for two, three, five, seven years. So if you kill a tree and print out the problematic area in question to ask for help in solving it, you look like you don't know how to do your job, right?
Wrong.
Asking for help with something in the drawings is very rarely a bad idea. First of all, if you've been struggling with something for a while and can't make it work, it's possible that all you need are some fresh eyes on the problem. I've wrestled for two hours with making rooms fit into an existing space (since space layout is something I do a lot as a licensed architect), and suddenly one of my bosses looks at my layout and scribbles in the solution in five minutes. I feel like a goober, but it's only because I've been too close to the problem for too long. Furthermore, by showing your project manager/architect/job captain the problem you're dealing with, it may jog his/her memory regarding something super-important: we removed this area from our scope, so you really don't need to try to work it out; oh yeah, there was something important going on in this area that I need to call the engineers about; wow, you're right, we can't specify this or that product because it won't work in that area; and so on. Sharing the problem allows it 1) to be solved sooner or 2) to get the team to realize that something big is happening, or is wrong.
That second scenario is what happened on my husband's job. The project was so big that there were two groups on the team: one worked on the core and shell, and the other worked on the interior tenant finish. The problem is that each group (including its interns) got tunnel vision and forgot that their scope has to work with the other team's scope. Core-and-shell and tenant-infill have to work together, and it's easy to forget that and just plug away at whatever problem comes up, thinking "well, the other group has to have what it has here, and I just have to make do." As long as nothing is built yet, most things can change, at least a little. And in the case of my husband's building, had someone printed out the clunky, weird-looking ceiling plan and showed it to him, he could have called together the infill group and the core-and-shell group and found a solution...when it didn't cost any money to do so.
It's easy to get focused on your role in architecture, both as a problem-solving architect-in-training and as the intern-who-documents-everything-having-to-do-with-this-part-of-the-building. Just because it's your job to work out the exterior walls or the vertical circulation or whatever doesn't mean that you work in a vacuum, and just because you do know something about how buildings go together doesn't mean that you know everything or even have to know everything. Pulling back and remembering how your work fits into the overall project--and then looking at that overall project--helps reduce that tunnel vision that can happen when you work on a smaller piece of a bigger project. Reaching out of your role and your scope and asking questions or for help to solve a problem reduces it even more. It's almost symbolic of how we do what we do: all the parts and pieces of a building make it what it is, and all the people involved in designing and documenting that building allow it to be built smoothly and solidly.
No comments:
Post a Comment