Logomarca IETEC

Buscar no TecHoje

Preencha o campo abaixo para realizar sua busca

:: Gestão de Projetos

Considerações Práticas do Gerenciamento de Projeto na Visão de um Subcontratado

Luiz Cláudio Araújo

Engenheiro Elétrica pela PUC MG, Pós-Graduado em Gestão de Projetos pelo Ietec e mestrado em Engenharia da Automação pela UFMG. Engenheiro de Automoção da Converteam Brasil LTDA
 

1. Título

CONSIDERAÇÕES PRÁTICAS DO GERENCIAMENTO DE PROJETO NA VISÃO DE UM SUBCONTRATADO

2. Tema central do artigo

Como utilizar as melhores práticas no gerenciamento de um projeto vendido a um cliente intermediário.

3. Resumo

Uma das principais motivações para este trabalho é a frustração vivida por profissionais, sejam eles executores ou gerentes de projeto, gerada, sobretudo, pela entrega de um produto / serviço fora das expectativas de um cliente final. Este impacto negativo pode chegar ao extremo de uma entrega final jamais vir a ser implementada pelo usuário devido à falta de atendimento aos requisitos considerados básicos por este cliente e que simplesmente não foram levados em consideração pelo contratado.

Considere-se ainda a possibilidade de um cliente final jamais retornar os comentários de uma entrega mal sucedida nestes moldes citados. Isto freqüentemente ocorre devido ao gap inserido pelo agente intermediário na relação de contato entre cliente final e contratado / desenvolvedor. Como conseqüência, por um período determinado, o fornecedor pode criar uma falsa expectativa em ser chamado a participar de novas concorrências para o mesmo cliente, simplesmente por não ter recebido um feedback de que seu projeto produziu uma entrega final em desacordo com expectativas primordiais para o qual fora contratado.

Este artigo aborda, de forma comentada para cada tópico relacionado, as melhores práticas que podemos adotar para que um projeto obtenha o sucesso gerencial tanto na análise dos requisitos internos da organização executura quanto no atendimento aos requisitos do principal Stakeholder – o Cliente Final.

4. Contextualização do trabalho

Grandes empreendimentos são realizados, em sua maioria, por consórcios onde a subcontratação de pacotes é característica inerente ao tipo de negócio. Com isto, torna-se cada dia mais desafiador gerenciar as expectativas do cliente final, tanto do ponto de vista de um fornecedor direto quanto de um subcontratado. Desta forma, serão evidenciadas ao longo do texto as considerações práticas do gerenciamento de projeto na ótica de um subcontratado, que será o referencial adotado para a caracterização de cada ator neste ciclo.

Só como exemplo de uma dificuldade inicial enfrentada, podemos dizer que uma vez internado o projeto, a declaração de trabalho a ser apresentada teria que se basear em uma especificação funcional fornecida pelo cliente final. Porém, em muitos casos, este descritivo é desmembrado e reescrito várias vezes até chegar em suas mãos, incorporando assim a interpretação do documento original (compilado por um cliente intermediário e/ou demais subcontratados). Portanto, apesar do compromisso legal do líder do consórcio com o cliente final, apenas este contrato não garantirá entregas dentro das expectativas deste cliente, sendo que toda uma cadeia de Stackholders deverá estar comprometida para o sucesso operacional da entrega considerada.

5. Introdução

Considere uma concorrência vencida por sua empresa (subcontratada), tendo como contratante um agente intermediário que, por sua vez, agregará sua entrega a um fornecimento em regime turn-key para um determinado cliente final no setor industrial. Ou seja, sua empresa assinará o contrato de prestação de serviços / desenvolvimento de produtos com um agente que apenas “repassará” sua entrega para o cliente final.

O termo repassar foi utilizado porque na maioria das vezes o cliente intermediário não agrega nada a sua entrega, seja por falta de domínio técnico ou mesmo por impedimentos contratuais. O imbróglio aumenta ainda mais se considerarmos o envolvimento de sua empresa na implantação do respectivo pacote nas dependências do cliente final, ou seja, cumprindo todas as etapas de comissionamento em campo.

Considerando o cenário descrito, temos que nos atentar pelo menos para alguns questionamentos, em cada uma das óticas: (1) Cliente Intermediário: como fornecer vários pacotes subcontratados, integrando-os de forma transparente para o cliente final e que coexistirão com outros sistemas já em funcionamento neste cliente? (2) Subcontratado: Como contribuir para o sucesso não só de sua entrega, mas de todo o projeto turn-key em questão? Como cobrar a participação de um cliente final em um projeto sendo que não existem relações contratuais entre ambos? Quais as formas de mitigarmos o risco de um possível impacto no custo, prazo e escopo gerado pela incompatibilidade do sistema a ser entregue? (3) Cliente Final: Qual o papel do cliente final para garantir a funcionalidade do produto / serviço a ser recebido, conforme especificado para suas necessidades?

6. Melhores práticas de gerenciamento de projetos na ótica do subcontratado

6.1 Envolva o cliente final desde o início dos desenvolvimentos

Para tal, considere a figura do cliente intermediário não como uma barreira, mas utilize-a como um canal de acesso ao cliente final. Este facilitador deverá garantir uma aproximação entre as partes interessadas, pois formalmente não existem relações contratuais entre o cliente final e o subcontratado.

Lembre-se, não significa que o cliente final deva participar de todas as etapas de desenvolvimento de sua entrega. Por exemplo, ele não tem que opinar nas definições de escopo e forma de implementação da sua solução. O seu expertise e as necessidades dele têm que estar retratadas na proposta técnica consolidada e, posteriormente, nos descritivos funcionais que compõem a declaração de escopo.

Portanto, uma metodologia a ser seguida é a formalização dos canais de relacionamento entre o subcontratado, cliente intermediário e cliente final, durante todas as fases de desenvolvimento do empreendimento. Através da elaboração de uma matriz de responsabilidades, identifique e registre pelo menos um representante de cada área envolvida / afetada por sua entrega. Por exemplo, se sua entrega visa a fornecer um sistema completo de automação para uma determinada linha de produção, certifique-se de que seu levantamento de stakeholders contemplou do alto escalão da companhia, passando pelo supervisor de produção e chegando ao operador do processo.

Ao longo do desenvolvimento do projeto, o mapeamento de cada um deles, no seu respectivo quadrante de um plano cartesiano com os eixos “interesse” x “poder”, guiará os esforços e ações do gerente de projeto. Vale a pena ressaltar que a dinâmica deste mapeamento permite envidar diferentes esforços ao mesmo envolvido em fases diferentes. Assim, por exemplo, o envolvido “operador do sistema” receberá o mínimo de atenção durante a fase de especificação e engenharia básica e será o foco das atenções durante a fase de desenvolvimento da interface do operador (telas sinóticas e/ou tabulares).
 
6.2  Estabeleça a Matriz de Responsabilidades

Registre em ata, já na reunião de kick off Meeting (realizada para apresentação da equipe e oficialmente disparar o desenvolvimento do projeto), todos as responsabilidades e funções de cada envolvido (sugestão: Matriz de Responsabilidades). Defina qual o modo de comunicação e envio de documentação que o projeto adotará para que informações não se percam e nem deixem de chegar a todos os interessados.

Além de estabelecer os papéis que cada colaborador interno do projeto irá desenvolver, de acordo com os pacotes de trabalho, inclua na sua Matriz de Responsabilidades a figura do seu Cliente Intermediário e Final. Lembre-se que devem estar listados todos aqueles que têm influência / impacto direto na condução do projeto, ou seja: definir responsáveis por aprovação de aditivos, alterações de escopo, aprovação de documentação, liberação de pagamentos, inspeções técnicas, etc.

6.3  Planeje e execute o Plano das Comunicações

Neste plano estará listado o que, como e quando cada stackholder receberá as informações do projeto. No caso de projetos com ciclo de vida curto, estabeleça em contrato datas limites para o recebimento de comentários em documentos considerados como fruto de tarefas do seu cronograma.

Não considere esta premissa uma salvação para seu projeto, pois se os atrasos acontecerem e você tiver que alterar seu cronograma e até mesmo interromper atividades que dependam de documentos a serem retornados com aprovação pelo cliente final, seu conforto se dará apenas no âmbito judicial, ou seja, seu projeto “irá para o buraco” assim mesmo.

Uma forma de minimizar o problema de atraso no retorno de documentação aprovada / comentada pelo cliente final é tentar marcar uma reunião para a aprovação da documentação em uma data próxima à do vencimento de prazo estabelecido em contrato. Vale a pena ressaltar que toda reunião entre você e o cliente final deve ter o contratante como participante também.
 
6.4  Faça uso da EAP – Estrutura Analítica do Projeto

Uma das formas de você gerenciar a expectativa de seu cliente final com relação ao conteúdo das entregas é através da EAP. Para que o usuário tenha a noção dos limites do projeto a ser entregue e que o empreendimento não seja penalizado com disputas jurídicas, a EAP deve ser validada em comum acordo entre as partes do contrato. Esta é a tarefa predecessora para a elaboração do cronograma do empreendimento.

Crie a cultura de detalhar ainda mais as entregas, descrevendo cada pacote de trabalho para que não se criem falsas expectativas. Dependendo do escopo, este Dicionário da EAP poderá trazer informações como: objetivo do pacote, resumo de como executar a tarefa ligada ao pacote, especificações técnicas, critérios de aceitação, etc.

6.5  Registre toda documentação de referência

Fique atento à documentação de referência a ser utilizada para desenvolvimento do projeto. Além da documentação utilizada para a elaboração da proposta inicial e que é citada como referência na proposta consolidada, após discussões iniciais com o cliente (quando aplicável, visitas técnicas de levantamento de campo), novas especificações se fazem necessárias para desenvolvimento do produto / sistema. Toda a documentação extra enviada pelo cliente deve ter uma análise rigorosa para verificar se houve ou não desvio de escopo inicial.

Além de compilar as informações pertinentes na documentação recebida pelo cliente, consolide uma lista mestra de documentos “a emitir” do projeto. A validação desta lista tende a disciplinar a geração de documentos e, muitas vezes, algumas emissões servem de marcos evolutivos para o projeto (ex. projeto básico, detalhado, arquitetura do sistema, etc.).

Sempre que nos deparamos em uma proposta técnica com um tópico do tipo: o sistema a ser ofertado pelo proponente deverá possibilitar integração com os demais sistemas existentes, acaba recaindo sobre sua responsabilidade, considerando-se o caso que sua empresa também participará do comissionamento e start-up do sistema a ser entregue.
 
6.6  Formalize um controle de mudanças

Estabeleça um fluxograma de controle de mudanças de escopo para que qualquer solicitação esteja devidamente documentada e fundamentada. Além da adoção do fluxograma, utilize um formulário para registro da solicitação incluindo pelo menos os seguintes campos:

Título: FORMULÁRIO DE SOLICITAÇÃO DE MUDANÇAS
• Data / local;
• Emissor;
• Solicitante;
• Referência ao Projeto;
• Descrição da solicitação;
• Motivo da solicitação;
• Custo estimado para implementação;
• Interfaces afetadas;
• Campo indicando aprovação ou não da solicitação, sendo que neste caso evidencie o motivo da não aceitação.

Lembre-se, este controle é de suma importância para garantir o foco do projeto. Um comitê para aprovação deverá analisar e decidir quanto às solicitações, que podem ter origem no cliente intermediário ou final.

6.7  Preocupe-se com as interfaces técnicas de seu sistema

Procure em sua proposta técnico / comercial consolidada o item que trata das interfaces que seu sistema terá nas instalações do cliente final. Mesmo que você esteja resguardado contratualmente pela não citação de qualquer pacote de trabalho a este respeito, dificilmente seu sistema trabalhará de forma isolada.

Desta forma, mesmo que este item não tenha sido contemplado inicialmente em contrato, trabalhe proativamente no sentido de extrair do cliente final quais são estas interfaces e tente revertê-las em oportunidades de negócios para aumentar a margem financeira de seu projeto. Uma vez identificadas as interfaces, um outro grande esforço deverá ser dispendido para estabelecer os limites e providenciar a adequação com o sistema / produto do outro fornecedor.

6.8  Faça a validação do sistema antes de implantá-lo

Uma vez finalizados os desenvolvimentos dos pacotes, valide-os junto ao cliente final antes da implantação no canteiro. Mesmo tendo como contratante o cliente intermediário, somente o usuário final estará apto a aprovar ou não a entrega de acordo com os critérios de aceitação estabelecidos.

Esta validação deverá ser registrada e, caso a caso, deverá ser encontrado um meio de “congelar” o desenvolvimento aprovado para garantir que a mesma “versão” testada será a considerada na entrega.

6.9  Comissionamento dos pacotes de trabalho

Considere que você será o responsável técnico para colocar em funcionamento o sistema desenvolvido em uma unidade industrial de seu cliente final, ou seja, o cliente intermediário mais uma vez será apenas a interface legal entre as partes. Nesta fase, todo o seu esforço inicial em manter o cliente final atualizado com o seu desenvolvimento evitará a criação de falsas expectativas com relação aos pacotes a serem entregues.

Execute o planejamento estabelecido para cada intervenção no processo do cliente, estabelecendo: cronograma das implantações, pessoas envolvidas, pacote a ser implantado, plano de contingência, observância das regras de segurança, etc.

Crie o hábito para que cada funcionário envolvido preencha um relatório diário de obra com o registro das atividades de cada dia e, quando houver, descrição dos impedimentos que impossibilitaram a realização das atividades programadas para o dia. Sempre que possível, solicite a validação destas informações para o cliente com quem você tem o contrato da prestação dos serviços. Estes registros são de suma importância para que a empresa executora possa atualizar e controlar seu planejamento. Em caso de claims, este será o documento mais completo para a apresentação de fatos em um possível conflito.

 
7. Conclusão

As informações compiladas nas seções anteriores visam a criar um alerta para alguns pontos críticos no gerenciamento de um contrato sob a visão de um subcontratado. Abordou-se a dificuldade em se formalizar um canal de comunicação com o cliente final, especificamente quando não existe relação contratual entre as partes. Algumas considerações práticas foram discutidas no sentido de formatá-las junto às melhores práticas difundidas via PMBOK.

Em resumo, não adianta conduzirmos de forma primorosa um empreendimento baseado apenas na chamada tríplice restrição – custos, prazo e escopo – ainda que sob o manto da qualidade. Se a devida atenção não for dada aos papéis dos Stakeholders seu sucesso estará comprometido. Especificamente falando, mesmo tendo o papel do cliente intermediário em um projeto, o foco no cliente final ainda ocupa o vértice direito superior do quadrante formado pela intersecção dos quesitos Influência x Capacidade de Decisão.

8. Referências bibliográficas

VARGAS, RICARDO. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos, Brasport;
PROJECT MANAGEMENT INSTITUTE. Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, PMBOK® Guide. Newtown Square, Pennsylvania, USA, 2004.
KERZNER, HAROLD Gestão de Projetos - As Melhores Práticas 2ª Edição. BOOKMAN. 2006.
ROLDÃO VICTOR , Gestão de Projetos: uma Perspectiva Integrada, Edufscar.

Indique este artigo a um amigo

Indique o artigo