White paper Eles dizem que querem uma solução

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). Descreve alguns desafios comuns que você pode enfrentar durante o planejamento de projetos. Descreve a criação da melhor abordagem ao tentar determinar quantas tarefas e por quanto tempo devem vigorar para otimizar um cronograma de projeto. Discute como os diferentes setores normalmente exigem diferentes tipos de cronogramas (por exemplo, desenvolvimento de software, EPM [engenharia, compras e construção] e parada total da fábrica). Também discute vários fatores na escolha da resolução do projeto (por exemplo, a extensão do projeto, os recursos envolvidos, gerenciamento ou divisão de recursos, velocidade e esforço necessários na coleta de dados e cronograma de atualização de dados).

Para baixar a versão do Word deste white paper, consulte White paper Eles dizem que querem uma solução (Project Server 2010).

Para ver mais white papers, consulte os white papers da coluna "From the Trenches".

Eles dizem que querem uma solução

Pedindo desculpas aos Beatles pelo título, o tópico de hoje é a resolução de seu projeto.

Há muitos materiais disponíveis sobre como criar um cronograma, mas uma das lições mais importantes é muito difícil de aprender: quantas tarefas você deve ter em seu cronograma de projeto e quanto tempo cada tarefa deve tomar?

Regularmente, sou confrontado com cronogramas de projetos que parecem incrivelmente complexos, ou com gerentes de projetos que parecem incapazes de identificar problemas em seus cronogramas, pois esses cronogramas estão em um nível resumido. Já vi um projeto com mais de cem anos de duração (sim, é verdade) que era perfeitamente adequado com relação ao tamanho e com algumas tarefas que duraram décadas. Também já vi cronogramas de projeto que duravam apenas uma hora ou menos e eram perfeitamente adequados, e tinham algumas tarefas que duravam apenas um minuto. Já vi projetos com apenas um punhado de tarefas e outros com mais de 100.000 tarefas.

O software que utilizamos hoje pode lidar com milhares de tarefas e uma grande variedade de durações.

Então, qual é a abordagem certa?

Quanto tempo deve durar as tarefas e quantas devemos ter para otimizar nosso cronograma do projeto? Chamarei isso de resolução do projeto.

Traços diferentes para pessoas diferentes

Como o requisito pode ser diferente para setores diferentes, tipos diferentes de projetos e situações diferentes, vamos analisar como decidir quantas tarefas colocar em seu cronograma e qual a duração das tarefas.

Tipos diferentes de projetos naturalmente pedem tipos diferentes de cronogramas. Vamos pensar em três exemplos diferentes:

  1. Desenvolvimento de software   . Muitos projetos de software têm características comuns. Embora todo projetos de software seja único, normalmente existe uma fase de design, uma fase de programação, uma fase de controle de qualidade, uma fase de documentação e uma fase de implantação. Projetos de software costumam ser avaliados em semanas ou meses e são ótimos para tarefas que duram um dia a duas semanas. Nesse caso, a alocação de recursos é frequentemente atribuída ao nível de individual.

    As pessoas que adotaram o processo Agile para o desenvolvimento de software procuram "sprints" rápidos de uma ou duas semanas, e dentro desse sprint colocam tarefas de curta duração, mas a duração geral do projeto ainda é medida em semanas. Falaremos mais sobre o desenvolvimento Agile um pouco mais adiante.

    Exibição do gráfico de Gantt de sprints Agile
  2. EPC, Engenharia, aquisição e construção   . Foi nos projetos de EPC que a metodologia do Cronograma de caminho crítico começou. Nesse tipo de projeto, algo muito grande está sendo desenvolvido. Pode ser um projeto grande de defesa, como o projeto Míssil Polaris, que deu início aos diagramas PERT, ou uma plataforma de petróleo no mar, um novo navio ou uma usina de energia. Nesses tipos de projetos, há uma fase de engenharia na qual o projeto concluído é concebido. A fase de Engenharia normalmente apresenta algum aspecto que nunca foi desenvolvido antes. A fase de Aquisição é responsável pela localização, contratação e gerenciamento da entrega de suprimentos ou subcontratos para elementos do projeto. Na fase de Construção, o produto final é construído e, em seguida, colocado em utilização. Normalmente pensamos em cronogramas de projetos de EPC com duração de meses ou alguns anos e com atividades que duram entre algumas semanas até alguns meses. Não é nem um pouco incomum ter de 5.000 a 20.000 tarefas em um projeto desse tipo. Nesse caso, o agendamento de recursos é quase sempre atribuído no nível de competência em vez de ser no nível individual, e (apenas para acrescentar um pouco de diversão) pode haver muitos subprojetos inseridos em um programa ou projeto mestre para facilitar o gerenciamento.

    Modo de exibição de gráfico de Gantt de vários projetos e subprojetos
  3. Parada total da fábrica   . Quando você faz um cronograma de projeto de uma parada total de fábrica para manutenção, você está trabalhando em um dos ambientes de cronograma mais desafiadores. A parada total de uma fábrica para realizar manutenção ocorre de duas maneiras: planejada e emergencial. Vamos deixar o tipo emergencial de lado por um momento; é um mundo por si só. A duração de um parada total planejada de fábrica depende muito do tipo de fábrica. Uma usina nuclear, por exemplo, pode realizar uma parada total "rápida" de 12 meses. Em uma refinaria de petróleo pode durar de 4 a 6 semanas. Mas o tipo de cronograma de projeto de fábrica que eu acho mais interessante é um moinho usina de fabricação, como um siderúrgica, uma fábrica de papel ou algo parecido. Há milhares ou dezenas de milhares de fábricas como essas em todo o mundo, e elas precisam passar por manutenção regular a cada ano.

    O custo da parada total nessas situações é normalmente medido em termos de custos de oportunidade; o custo do produto que não será produzido enquanto fábrica estiver inativa e passando por manutenção. Esse custo é medido em horas e pode variar de $150.000 a $250.000 por hora! Portanto, há pressão para terminar o trabalho a cada minuto. Nesse tipo de situação, a parada total normalmente dura de 5 a 8 dias e o atraso de um único dia é calculado em milhões. Se você estiver acostumado apenas a cronogramas mais longos e tradicionais, talvez você pense que em alguns poucos dias, "quantas tarefas pode haver normalmente?" mas não é nem um pouco incomum uma parada total como essa ter de 2.000 a 4.000 tarefas, cada uma durando de 15 minutos a algumas horas. As atribuições de recursos nesses casos são realizadas de acordo com a qualificação, mas a redistribuição de recursos raramente é feita com base na equipe. Com um custo por hora tão grande, não importa se você coloca mais pessoas no projeto, apenas termine-o rapidamente. A redistribuição de recursos nessa situação é frequentemente realizada para problemas altamente restritivos. Por exemplo: "podemos colocar apenas duas pessoas na sala de eletricidade, então isso tem que ser gerenciado separadamente".

    Modo de exibição de gráfico de Gantt de tarefas sequenciais

OK, agora temos três tipos de exemplos, e há muitos outros, mas esses atenderão às necessidades do debate. No primeiro tipo (Desenvolvimento de software), temos tarefas que duram normalmente um ou dois dias até duas semanas. No segundo tipo (EPC), temos tarefas que duram semanas ou meses. No terceiro tipo (Parada total de fábrica), temos tarefas medidas em unidades de seis minutos (1/10 de hora), 10 minutos, 15 minutos (1/4 de hora) até duas horas. É óbvio que, em alguns casos, as tarefas curtas fazem mais sentido e, em outros, tarefas mais longas são mais adequadas. Seguindo a mesma lógica, às vezes faz sentido ter uma grande quantidade de tarefas e, às vezes, simplesmente não faz sentido.

Fatores para a escolha da resolução de seu projeto

Com essas três diferenças, é fácil perceber que a tarefa de dois meses do projeto de EPC seria algo ridículo em um cronograma de parada total de seis dias, e que uma tarefa de 15 minutos não teria propósito no projeto de EPC ou de Software. Porém, além de mencionar este artigo e dizer “O Vandersluis disse que é um projeto de software, então as tarefas só podem durar de 1 a 10 dias” (e, por favor, não faça isso), quais características do projeto nos dizem qual nível de resolução escolher? Vamos analisar algumas óbvias:

Quanto tempo dura o projeto?

Vamos começar com a mais óbvia. Se a expectativa de duração de seu projeto é de alguns dias, tal como em nosso exemplo de Parada total, ter tarefas que durarão vários dias não faz sentido algum. Começar com uma abordagem de cima para baixo costuma ser produtivo quando pensamos em subdividir o escopo. Utilize o pensamento estrutural para divisão de trabalho. Comece com os principais componentes. Pense em ter não menos do que quatro e não mais do que 20 itens.

É uma regra? Não, é claro que não.

É bom senso. Menos de quatro faz você pensar porque dividiu o trabalho afinal de contas, e mais de 20 é muito difícil de manter o controle. Pessoalmente, eu escolheria no máximo oito itens por elemento de WBS, e isso graças a um artigo que li há alguns anos que sugeria que um octógono era a forma simples mais complexa que a mente pode reconhecer imediatamente.

Pense nisso por um momento. Você pode identificar um círculo, um triângulo, um quadrado, um pentágono, um hexágono, que possui seis lados, um heptágono, que possui sete lados (ok, esse é difícil de visualizar) e um octógono.

Você consegue identificar uma forma com nove lados sem contar? Eu não consigo. Ela é chamada de "eneágono", só para você saber.

Por isso, pessoalmente, eu me esforço para chegar ao limite de oito itens, mas minha regra básica é de 4 a 20.

Para cada elemento que você analisou, pense em como você deve dividir o trabalho. Mais uma vez, pense na regra de 4-20. No entanto, saber quando parar é o segredo. Gerentes de projeto mais novos subdividirão e subdividirão e subdividirão até que toda etapa possível será uma tarefa gerenciada. Veja algumas questões divisoras de águas que você pode fazer a si mesmo sobre a duração de uma tarefa:

  • Qual ação eu executaria se esta tarefa estivesse atrasada?    Se a resposta for “nenhuma”, é uma boa indicação de que a tarefa na qual você está pensando é muito pequena para valer a pena ser gerenciada. Se esse for o caso, você se preocupando com muitos detalhes. Volte um nível, dê um passo atrás e veja se a situação é solucionada.

  • A coleta de dados na atualização desta tarefa vai demorar mais do que a própria tarefa?    Nem sempre pensamos sobre o tipo de esforço despendido para gerenciar uma tarefa agendada, mas vale a pena pensar nisso, nem que seja por um momento. Se vai ser necessário mais esforço para gerenciar a tarefa do que para concluí-la, é uma boa indicação de que a tarefa está sendo definida em um nível muito detalhado.

  • Quanto tempo dura essa tarefa?     Quando estamos subdividindo o trabalho, às vezes perdemos de vista o quanto a tarefa se torna pequena. As grandes fases no nível superior talvez durassem semanas, mas à medida que descemos alguns níveis de granularidade, podemos facilmente cair na armadilha de definir uma tarefa para ser gerenciada apenas durante alguns minutos. Ao chegar às tarefas muito pequenas, temos que perguntar qual será o benefício de gerenciá-las.

Vamos aplicar uma verificação de realidade sobre o que acabei de falar. Num projeto de EPC de dois anos, se uma tarefa de uma semana atrasar um dia, certamente não valerá a pena tomar alguma atitude. Em um projeto de Software de seis meses, provavelmente não vale a pena tomar alguma atitude com relação a uma tarefa de uma semana que atrasa um dia. Em um projeto de Parada total de seis dias, uma tarefa de uma semana que atrasa um dia é uma grande emergência. Em outras palavras, uma tarefa de uma semana no projeto de EPC pode ser muito detalhista; no projeto de software, provavelmente está tudo certo; e no projeto de Parada total, certamente ela precisa ser detalhada ainda mais.

Quantos recursos estão envolvidos?

Sei que estamos apenas trabalhando no escopo, mas quando analisamos qual tipo de resolução precisamos, vale a pena pensar em quantas pessoas trabalharão em uma tarefa. Em um projeto grande de EPC, por exemplo, podemos ter dezenas de trabalhadores de uma competência envolvidos em uma fase do trabalho. Mas quando acabamos com muitas competências diferentes na mesma tarefa, o gerenciamento dessa tarefa se torna muito desafiador, se não impossível. Portanto, nessa situação, as tarefas que exigem muitas competências diferentes provavelmente precisam ser divididas.

Em um projeto de software, tendemos a pensar em quase todas as pessoas como um recurso altamente técnico com capacidades exclusivas. Além disso, em projetos de software é comum ter muitas tarefas reatribuídas dentro de um departamento, mas apenas uma tarefa atribuída a uma pessoa. Assim, quando há tarefas alocadas para um nível individual de um grupo de recursos ou departamento específico (por exemplo, programação de interface) estamos próximos a afirmar que não precisamos de mais detalhes.

Como os recursos são gerenciados ou subdivididos?

O modo como os recursos são gerenciados é um fator muito determinante para o modo como as tarefas são subdivididas. Em projetos grandes de EPC, por exemplo, os projetos são frequentemente divididos em subprojetos e parcelados em vários subcontratados. Nesta situação, precisamos fazer algumas coisas:

  • Definir o trabalho de uma maneira que permita a um gerente de projetos supervisionar o subcontratado com a confiança de que ele está fazendo progresso é um fator muito importante.

  • Definir as tarefas de uma maneira que o gerenciamento de projetos e a equipe de engenharia do subcontratado compreendam o que elas significam sem ambiguidade.

  • Assegurar que o nível de resolução adotada como padrão seja compreendido e aceito pelo subcontratado.

Quando analisamos projetos executivos como software, pesquisa biológica ou engenharia, há uma grande probabilidade de encontrarmos uma estrutura de Gerenciamento matricial, na qual os gerentes de projeto não possuem recursos e precisam trabalhar entre os departamentos que alocam esses recursos para vários projetos diferentes. Nesse caso, as principais perguntas seriam:

  • Em quantos projetos um recurso provavelmente trabalhará no curso de um único dia?

  • Quanto tempo demora para um funcionário mudar de um projeto para outro?

  • O trabalho é definido de uma maneira que tanto os funcionários quanto os gerentes de departamento de recursos compreendem como alocar a competência correta?

Quando analisamos um projeto de Parada total ou de Construção, temos a tendência de trabalhar entre equipes criadas com uma finalidade. Nessas situações, um Líder da equipe de recursos pode gerenciar a Equipe elétrica (mesmo que essa equipe inclua carpinteiros e pedreiros), uma Equipe de encanadores ou uma Equipe de recondicionamento do aquecedor. O trabalho precisa ser organizado de uma forma que a equipe possa ficar ocupada durante todo o turno e evitar que cheguem ao local enquanto outra equipe já está trabalhando em algo na área. Devido à pressão intensa para concluir um projeto de Parada total, o trabalho é frequentemente organizado primeiro de acordo com o trabalho, agendado e depois reagrupado e subdividido por um Líder da equipe de recursos de modo que cada líder de equipe possa cuidar apenas de suas tarefas em um documento e com o todo o projeto em contexto em outro documento. Dessa forma, as tarefas precisam ser definidas de modo que fiquem claras para o funcionário e para o Líder da equipe de recursos. Provavelmente, as tarefas são definidas por hora ou até mesmo em intervalos menores, a cada seis ou quinze minutos.

Quão rápido você consegue coletar os dados e quanto esforço é necessário para isso?

Parece uma pergunta boba quando você está acostumado a ver os dados de seu projeto todos alinhados para revisão ao final da semana, mas quando você está tentando determinar o nível de resolução de seu projeto, essa pergunta pode ser fundamental. Por exemplo, quando você trabalha com vários subcontratados, há uma probabilidade de que você receba algum tipo de atualização semanal ou mensal. Na verdade, inserir a cláusula de atualização de gerenciamento de projetos em seu contrato é essencial. Nesta situação, você precisa integrar os dados dessas empresas diferentes em seus próprios dados, validar se os dados do progresso fazem sentido e, em seguida, fazer sua própria análise e gerar seus relatórios. Em um modo de EPC, isso é provavelmente algo que ocorre mensalmente.

Em um projeto de parada total, será necessário atualizar seu projeto a cada turno, atualizá-lo rapidamente e enviar as atualizações para os Líderes de equipe de recursos no meio do próximo turno. Nesta situação, a equipe do projeto invade toda a fábrica durante o turno, coletando os dados o mais próximo possível do tempo real enquanto os Líderes de equipe de recursos e Capatazes usam planilhas para anotar o progresso de suas atribuições. Em um projeto de software ou de pesquisa, provavelmente você trabalha com base em um cronograma semanal, ou algo parecido, e as pessoas informam seus próprios progressos e passam por processos de aprovação a cada um ou dois dias.

Esse é um ponto importante a ser considerado quando você está analisando quantas tarefas existem em seu projeto, pois existe um custo para coletar os dados.

Portanto, pensar na rapidez com a qual você pode coletar, aprovar, integrar, analisar e reportar os dados de forma regular e cíclica é fundamental, assim como considerar o custo da coleta dos dados e o retorno sobre o investimento desses dados coletados.

Com que frequência vamos atualizar?

Aqui estão dois fatores essenciais para determinar a quantidade de dados que você pode coletar:

  • Pense em como você vai coletar seus dados.

  • Pense com que frequência você pode atualizar seu projeto de forma razoável e forneça ao gerenciamento as ferramentas necessárias para a tomada de decisão a fim de orientar o projeto e os recursos na direção correta.

Já vi alguns gerentes de projeto insistirem que desejam coletar e gerenciar os projetos em “tempo real” e, embora isso seja possível teoricamente, é muito difícil realizar na prática.

Ao analisar os dados de gerenciamento de projeto podemos fazer alguma suposições. Supomos que:

  • Todos os dados estão ali   . Não há uma expectativa de que algumas tarefas são atualizadas enquanto outras não o são.

  • Os dados foram atualizados em horários parecidos   . Não há uma expectativa de que metade das tarefas foram atualizadas há alguns minutos, mas a outra metade não é atualizada há duas semanas.

  • Todos os apresentam algum nível de aprovação   . Esperamos que o gerente de projetos confie nos dados apresentados e que ele ou ela possa dizer: "Esta é uma representação justa e precisa do projeto".

  • Os dados se complementam   . Não esperamos ser confundidos com muitos custos e recursos, a menos que tenhamos projetado nossos relatórios e análises especificamente dessa forma.

Costumo perguntar aos executivos que estão empolgados sobre o conceito de gerenciamento de projeto em tempo real o que eles fariam para resolver as questões que acabei de mencionar. "Você está preparado para tomar decisões de gerenciamento durante toda a semana?", eu pergunto. A resposta dependerá do nível de resolução. Em um projeto de parada total, é melhor que a resposta seja “Sim”. Em um projeto de software, a resposta é provavelmente “Não, faremos isso semanalmente”. E, em um projeto de EPC, a resposta seria “Mensalmente”.

Em algum momento, a lei dos rendimentos decrescentes surgirá para dizer: “Entregar relatórios de projeto mais rápido não aumentará nossa eficiência”.

Revisando seu trabalho

Agora você tem algumas ideias para digerir, usou o Método de divisão de trabalho para subdividir seus dados e ficou atento a alguns dos sinais de aviso de que os dados estão definidos de forma muito detalhada. Agora é hora de pendurar o cronograma na parede, dar um passo para trás e analisar o projeto de alguma perspectiva. Surpreendentemente, muitos gerentes de projeto nunca fazem isso. Eles ficam tão preocupados em definir os últimos detalhes e estão tão ocupados subdividindo tarefas que chegam ao prazo de ativação e nunca levantam a cabeça para ver se o que criaram será um pesadelo para gerir.

Em alguns casos, os executivos têm certeza, com base em todo aquele treinamento do MBA, de que "quanto mais detalhes, melhor" e insistem naquelas tarefas de 5 ou 15 minutos em projetos de seis ou mais meses de duração.

Alterar o projeto antes de iniciá-lo é sempre mais fácil do que em qualquer outro momento posterior. Por isso, incorpore um período em sua atividade de criação do cronograma para refazer o cronograma, se for necessário.

Isso é pedir muito?

Às vezes, os gerentes de projeto analisam o escopo do que criaram e percebem que estão um nível muito alto de detalhes. Se esse for o caso, a correção é óbvia. Talvez seja muito trabalho, mas você agradecerá mais tarde por simplificar o cronograma simplesmente subindo um nível.

Às vezes o quadro não é fácil. Em alguns casos, apenas quando o cronograma está montado que o gerente de projetos consegue ver sua complexidade. Projetos complexos são, por sua própria natureza, mais arriscados, e risco na economia atual é um fator fundamental para a seleção de projetos. Veja algumas questões que valem a pena considerar antes que um projeto complexo desse tipo passe:

  • Podemos executá-lo em partes?    Alguns projetos arriscados podem ser divididos em partes menores e, sendo projetos menores, o risco diminui. No entanto, se você estiver usando essa estratégia, cada projeto discreto deve ter seu próprio valor quando for concluído.

  • Devemos repensar o escopo?    Às vezes, as ações mais simples são ir até os designers do trabalho em primeiro lugar, explicar a complexidade que parece aparente no cronograma e verificar se o trabalho pode ser refeito. Isso frequentemente gera um pensamento inovador que nunca teria ocorrido de outra forma.

Devemos mesmo executar esse projeto?

Alguns projetos nunca deveriam existir, e o momento mais barato para cancelá-los é antes de iniciarem. Se o risco do projeto for aparente apenas agora, é melhor agora do que mais tarde. Quando você combinar os resultados do retorno de seu cronograma para o processo de Gerenciamento de Portfólio de Projetos (PPM), poderá perceber que o risco do projeto mais complexo tem a pontuação de trabalho muito pior em uma escala de retorno sobre o investimento.

Um projeto ágil… não, um projeto Agile

Prometi dizer algumas coisas sobre o gerenciamento de projetos Agile, e se você for um fã de Agile e leu até aqui, agradeço sua paciência. O gerenciamento de projetos de software por meio do método Agile é algo parecido com uma filosofia, mas é uma filosofia cada vez mais popular entre aqueles desgastados por grandes projetos de desenvolvimento de software que falharam.

Em um mundo de desenvolvimento de software Agile, tentamos dividir o projeto em “sprints” pequenos de uma a três semanas, e a meta de cada miniprojeto é terminar com um código utilizável. Neste caso, estamos trabalhando com algumas restrições bem conhecidas, de modo que nosso nível de resolução já foi escolhido para nós.

Temos um período de uma a três semanas, os recursos estão disponíveis para nós e vamos atribuir o trabalho a cada recurso. O número de tarefas possíveis que podemos definir nessa estrutura é finito e isso se deve à manutenção de um nível adequado de resolução. Sim, você pode ter problemas em Agile ao definir tarefas que são muito pequenas. “Definir Campo1: 10 minutos, Definir Campo2: 10 minutos, Definir Campo3: 10 minutos” etc., mas é muito menos comum.

O Agile foi projetado para um ambiente de desenvolvimento corporativo no qual criamos o software para utilização interna, e seu uso muitas vezes é expandido para o desenvolvimento de softwares comerciais. (Usamos o método aqui na HMS para nosso próprio desenvolvimento do TimeControl.) O método Agile resulta em um departamento de desenvolvimento mais móvel e ágil, mas não será aplicável a todos os setores ou até mesmo a todas as empresas de software. Se você estiver realizando o gerenciamento de projeto em um ambiente de software, minha recomendação é ler sobre o Agile, aprender com ele e adotar os elementos (todos, alguns ou nenhum) que o tornarão mais efetivo.

Conclusão

Tal como acontece com a maioria dos aspectos do gerenciamento de projetos, não há uma resposta pronta para perguntas que, em um primeiro momento, parecem tão óbvias. Quantas tarefas há em seu projeto e quanto tempo deve durar cada uma dessas tarefas é algo que você precisa pensar para decidir… mas é preciso decidir.

Escolher o nível de resolução de seu projeto é uma responsabilidade de gerenciamento de projetos que pode ser um fator importante para o sucesso do gerenciamento do cronograma do projeto.

Sobre o autor

Chris Vandersluis é presidente e fundador da HMS Software, com base em Montreal, Canadá, um parceiro certificado da Microsoft. Ele é formado em Economia pela McGill University e tem mais de 30 anos de experiência em automação de sistemas de controle de projetos. Membro do Project Management Institute (PMI), ele participou da fundação dos capítulos de Montreal, Toronto e Quebec do Microsoft Project Users Group (MPUG). As publicações para as quais Chris já escreveu incluem a Fortune, a Heavy Construction News, a Computing Canada e a PMNetwork, além de ser colunista regular da Project Times. Professor de Gerenciamento Avançado de Projetos na McGill University, frequentemente dá palestras sobre as funções da associação de gerenciamento de projetos na América do Norte e no mundo. A HMS Software é a fornecedora do sistema TimeControl de controle de horas orientado para projetos e tem sido Parceira de Soluções de Projetos da Microsoft desde 1995.

Chris Vandersluis pode ser contatado pelo email: chris.vandersluis@hms.ca.

Se quiser ler mais artigos relacionados a Gerenciamento de projetos corporativos (EPM) de Chris Vandersluis, consulte o site da HMS (http://www.epmguidance.com/?page_id=39).

Expanda suas habilidades no Office
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×