Gestão de projetos de arquitetura: guia prático

Gerir projetos de arquitetura é acompanhar cada projeto pelas suas fases — do programa base ao projeto de execução e à assistência técnica —, saber quem responde por ele, onde estão os entregáveis e o que o cliente já aprovou. Este guia mostra como montar esse sistema num gabinete português, com as fases da Portaria n.º 255/2023 como esqueleto e sem jargão de consultor.

O que torna a gestão de projetos de arquitetura diferente?

Um projeto de arquitetura vive anos, depende de aprovações externas e envolve o cliente em cada etapa. Por isso, uma lista de tarefas genérica não chega: o gabinete precisa de acompanhar fases, entregáveis e aprovações. Três características mudam a forma de gerir:

• Fases longas com aprovações externas. Entre submeter um projeto à câmara e ter resposta, o projeto não está parado — está noutra fase da sua vida. Um bom sistema distingue "à espera da câmara" de "à espera de nós".
• Muitas especialidades, um responsável. Estruturas, AVAC, eletricidade, acústica: o gabinete coordena e responde pelo conjunto. Os ficheiros dos consultores externos têm de entrar no mesmo circuito de entregas e aprovações que os internos.
• O cliente faz parte do processo. Ao contrário de um produto que se entrega no fim, o dono da obra aprova em cada etapa. A comunicação não é um extra: é parte do projeto.

É por isto que os quadros de tarefas genéricos envelhecem mal num gabinete: modelam trabalho, mas não modelam fases, entregáveis e aprovações.

Quais são as fases de um projeto de arquitetura em Portugal?

As fases de referência estão na Portaria n.º 255/2023, de 7 de agosto, que aprova as instruções para a elaboração de projetos de obras públicas e revogou a Portaria n.º 701-H/2008: programa preliminar, programa base, estudo prévio, anteprojeto (ou projeto base) e projeto de execução, seguidos da assistência técnica durante a obra.

Os pesos vêm do artigo 12.º do anexo I e servem para planear: dizem que parte do esforço total costuma caber a cada fase. A portaria permite outros pesos, desde que fundamentados, mas o programa base, o estudo prévio e o anteprojeto não podem somar mais de 55 %. E lembra que a assistência técnica não é uma fase de projeto: é um direito e uma obrigação do coordenador e dos autores.

A portaria aplica-se às obras públicas, mas a mesma sequência serve de referência a muitos projetos privados. Nas obras particulares, os gabinetes costumam acrescentar uma fase de licenciamento — a submissão à câmara municipal — antes do projeto de execução, e é aí que a rastreabilidade se torna crítica: o que foi submetido, quando, e em que versão.

Como transformar as fases num processo do gabinete?

Escreva as fases que o gabinete realmente usa, dê a cada uma uma duração esperada e guarde esse modelo para reutilizar em cada projeto do mesmo tipo. Uma moradia, uma reabilitação e um projeto de interiores não seguem o mesmo caminho, e o modelo deve refletir isso.

Um exemplo de tipo "Moradia unifamiliar", com durações apenas indicativas:

1. Programa base — 2 semanas.
2. Estudo prévio — 4 semanas, com duas rondas de comentários do cliente.
3. Anteprojeto — 6 semanas, já com as especialidades principais.
4. Licenciamento — 12 semanas, quase todas à espera da câmara.
5. Projeto de execução — 8 semanas, o maior volume de desenho e coordenação.
6. Assistência técnica — durante a obra.

Use os pesos da portaria como verificação: se o projeto de execução ocupa muito menos de um terço do esforço planeado, provavelmente está subestimado. Com o tempo, compare o planeado com o real e ajuste o modelo — é assim que as estimativas deixam de ser palpites.

No Vellum, este modelo é um tipo de projeto: define as fases e a duração esperada de cada uma, e cada projeto criado com esse tipo guarda essas durações. O plano Free permite 2 tipos personalizados, o Core 5 e o Professional ilimitados.

Como usar os pesos das fases para planear horas?

Parta do esforço total que estima para o projeto e distribua-o pelos pesos da portaria; depois compare cada fase com o que aconteceu em projetos parecidos. Os pesos não substituem a sua experiência, mas dão um ponto de partida que não depende de quem faz a estimativa.

Um exemplo: para um projeto de 400 horas, os pesos sugerem cerca de 40 horas no programa base, 80 no estudo prévio, 100 no anteprojeto, 140 no projeto de execução e 40 na assistência técnica. Se o gabinete costuma gastar 150 horas só no estudo prévio, há duas leituras possíveis — a estimativa total está curta, ou o estudo prévio está a fazer trabalho que pertence ao anteprojeto. Qualquer uma das duas é uma conversa útil a ter antes de assinar a proposta, não depois.

Que estado deve ter cada projeto?

Para além da fase, cada projeto precisa de um estado simples que diga se o trabalho pode avançar. Cinco estados chegam para quase tudo: Novo, Documentação em falta, Pronto, Em curso e Concluído.

O estado "Documentação em falta" é o mais útil e o mais esquecido. Um projeto parado porque o cliente ainda não enviou a caderneta predial ou o levantamento topográfico não é um atraso do gabinete — e deve aparecer como tal. Separar o estado (pode avançar?) da fase (em que ponto do método está?) é o que permite responder em segundos à pergunta "porque é que isto não anda?".

As fases só fazem sentido enquanto o projeto está Em curso: é aí que a equipa regista a fase em que se encontra, e cada mudança fica com data. Esse histórico é a matéria-prima para perceber quanto tempo cada fase demora na realidade.

O que fazer quando o cliente muda de ideias a meio de uma fase?

Registe a decisão, volte à fase que ela afeta e trate o novo entregável como uma nova submissão. Mudanças de programa são normais em arquitetura; o que corre mal é quando ficam só na memória de quem atendeu o telefone.

Na prática: o pedido do cliente fica escrito, com data; se a alteração reabre uma fase já fechada — um estudo prévio aprovado que afinal muda —, o projeto regista esse regresso, e o histórico de fases mostra quanto tempo a alteração custou; e os ficheiros revistos entram como uma nova submissão, que o cliente volta a aprovar. Meses depois, quando alguém perguntar porque é que o anteprojeto demorou o dobro, a resposta está no próprio projeto.

Quem é responsável por cada projeto?

Cada projeto deve ter uma pessoa responsável — não "toda a gente". É ela que mantém o estado e a fase atualizados e que responde quando alguém pergunta pelo projeto. Isso não impede que outros colaborem; impede que o projeto fique sem dono quando o trabalho aperta.

À volta do responsável, a equipa precisa de regras simples:

• Toda a equipa vê todos os projetos. A visibilidade por empresa evita os pedidos constantes de "podes partilhar-me aquilo?" e permite substituir alguém de férias sem perder o fio. O que muda entre pessoas é o que podem gerir, não o que podem ver. Veja a estrutura de papéis e permissões.
• Aprovações explícitas. "Ficou combinado por telefone" não é um registo. Os entregáveis importantes devem ter revisão e aprovação com data, autor e nota — sobretudo os que seguem para o cliente ou para a câmara.
• Prazos à vista de todos. Uma data limite por projeto, e os projetos em atraso assinalados na lista, antes da reunião de segunda-feira e não depois.

Como acompanhar prazos sem reuniões de ponto de situação?

Ponha as datas no mesmo sítio que os projetos e deixe o sistema mostrar o que precisa de atenção. Quando o estado, a fase e a data limite de cada projeto estão numa só lista, a reunião semanal deixa de servir para recolher informação e passa a servir para decidir.

Três hábitos ajudam:

• Uma data limite em cada projeto. Mesmo que seja provisória. Um projeto sem data nunca está atrasado — e é exatamente esse o problema.
• Um calendário partilhado. Reuniões com o cliente, visitas de obra e prazos de entrega no mesmo calendário, ligados ao projeto a que dizem respeito. Quem abre o projeto vê os seus eventos; quem abre o calendário vê a semana do gabinete inteiro.
• Um resumo diário. Os eventos de hoje, os prazos que se aproximam e os que já passaram, num só ecrã ao abrir o dia.

Onde devem ficar os ficheiros de cada fase?

Os entregáveis devem ficar ligados à fase a que pertencem, com uma pasta por fase e regras de nomes que toda a equipa siga. Assim, encontrar o que foi submetido no licenciamento não depende da memória de quem o submeteu.

Duas regras fazem a maior diferença: cada nova versão de um entregável é um ficheiro novo, numa nova submissão, e as anteriores ficam guardadas com o seu histórico de revisão; e os documentos que não pertencem a uma fase — especialidades, estudos, documentos do cliente — vivem em pastas próprias, não espalhados por e-mails. Escrevemos um guia dedicado sobre como organizar ficheiros CAD num gabinete, com estrutura de pastas, nomes e referências externas.

Como manter o cliente informado sem perder horas ao telefone?

Dê ao cliente um sítio onde ver o estado do seu projeto e aprovar o que lhe diz respeito. Quando o cliente acompanha as fases e aprova cada ficheiro com uma nota que fica registada, os telefonemas de "em que ponto está?" diminuem e as decisões deixam de se perder em e-mails.

O ponto crítico é a aprovação: deve ser ficheiro a ficheiro, com data e comentário, para que meses depois se saiba exatamente o que foi aprovado. Desenvolvemos o tema em portal do cliente para gabinetes de arquitetura, com um modelo de atualização que pode copiar.

Excel ou software dedicado: quando mudar?

Mude quando a folha de cálculo deixar de responder às perguntas do dia a dia sem trabalho extra. Quase todos os gabinetes começam com uma folha — e ela funciona, até deixar de funcionar. Os sinais clássicos de que o método informal esgotou:

• A folha do "estado dos projetos" está desatualizada no momento em que é apresentada.
• Encontrar a versão certa de um ficheiro demora mais do que trabalhar nele.
• Um colaborador sai de férias e um projeto fica ilegível para os restantes.
• O cliente liga a perguntar o estado — e a resposta exige três telefonemas internos.

Nesse ponto, a escolha da ferramenta passa a ter impacto direto nas horas que o gabinete consegue faturar. Comparámos as opções mais usadas na comparação do melhor software de gestão para arquitetos, incluindo quando o Vellum não é a melhor escolha.

Como saber se o sistema está a funcionar?

Meça três coisas todos os meses: quanto tempo cada fase demora face ao previsto, quantas entregas saem fora do prazo e onde os projetos ficam parados. Não precisa de relatórios à parte — se a equipa regista estados, fases e datas, os números saem do próprio trabalho.

Perguntas para a revisão mensal:

• Que fase está sistematicamente acima da duração esperada? É o modelo que está errado, ou o processo?
• Os atrasos concentram-se num tipo de projeto, num cliente ou num escritório?
• Quantos projetos estão em Documentação em falta ou à espera da revisão do cliente — e há quanto tempo?

No Vellum, as estatísticas usam esses mesmos dados: o Core compara a duração real de cada fase com a esperada nos projetos concluídos, e o Professional junta a duração média de cada fase, os atrasos nas entregas e os projetos parados.

Checklist: implementar em 30 dias

Um sistema de gestão não se implementa num fim de semana, mas também não precisa de um trimestre:

1. Semana 1 — modelar. Defina os tipos de projeto e as fases reais do gabinete, com a duração esperada de cada uma. Não copie modelos alheios: copie o vosso processo.
2. Semana 2 — migrar o que está ativo. Só os projetos em curso, com o estado e a fase atuais desde o primeiro dia. O arquivo histórico pode esperar.
3. Semana 3 — juntar a equipa. Cada colaborador cria a conta e entra na equipa; combine uma regra única: se não está na plataforma, não existe.
4. Semana 4 — envolver os clientes. Dê acesso ao portal a um ou dois clientes recetivos, recolha reações e alargue.

No fim do mês, a pergunta "em que ponto está o projeto X?" deve ter resposta em dez segundos, sem interromper ninguém. Se quiser percorrer este caminho no Vellum Architecture, o guia de introdução segue estes passos — e pode começar grátis enquanto modela o primeiro tipo de projeto.