Salve o Seu Projeto com um Documento de Iniciação do Projeto (com Maik Stettner da FCV Interactive)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa informático. Perdoe quaisquer erros, pois o sistema automático não está correto a 100%.

Ben Aston:

Obrigado por nos acompanhar. Eu sou Ben Aston e este é o podcast do Gestor de Projetos Digitais. Este podcast é-lhe apresentado pela Clarizen, líder em software empresarial de gestão de projetos e portefólios. Visite clarizen.com para saber mais.

Se há uma coisa que podemos garantir sobre um projeto, é que nunca correrá de acordo com o plano. Mas porque é que os projetos descarrilam? Por vezes, é simplesmente porque nos lançamos nos projetos demasiado depressa e vemos o prazo a aproximar-se cada vez mais; acabamos, assim, por iniciar o projeto num estado de pânico e sem visibilidade. Depois, quando as coisas começam a correr mal, perguntamo-nos porquê.

Embora normalmente tenhamos na cabeça todo o contexto do projeto, a estratégia, os detalhes, os requisitos e as métricas de sucesso, podemos cometer o erro de assumir que, por isso, todas as outras pessoas também devem saber tudo. A realidade é que, se não estiver documentado, é provável que a nossa equipa simplesmente não saiba.

Por isso, hoje vamos falar sobre uma ferramenta que podemos utilizar para colocar todos em sintonia no início do projeto. Trata-se do Documento de Iniciação do Projeto, ou, como é talvez mais comummente designado no nosso mundo, o Resumo do Projeto. Vamos, por isso, mostrar-lhe como pode criar um DIP e utilizá-lo para tornar os seus projetos mais eficazes.

Hoje, estou acompanhado por Maik Stettner, um dos meus amigos e colegas. Maik é um dos nossos especialistas em gestão de projetos digitais residentes no The Digital Project Manager. Bem-vindo, Maik.

Maik Stettner:

Olá. Como está?

Ben Aston:

Estou bem. É ótimo ter-te connosco. Maik, vamos começar por falar de ti e contar a todos um pouco da tua história, porque trabalhamos obviamente juntos e já trabalhamos juntos há, se não me engano, cinco anos?

Maik Stettner:

Sim, entre quatro e cinco anos.

Ben Aston:

Quando contratei o Maik, lembro-me de pensar: “Não sei se este rapaz vai conseguir fazê-lo.” Isto porque vens de um contexto ligeiramente diferente, não do contexto tradicional de uma agência. Conta-nos a tua história. Como te tornaste gestor de projetos numa agência digital?

Maik Stettner:

No total, tenho cerca de dez anos de experiência em várias áreas. Comecei originalmente no setor dos videojogos e da publicação, a gerir lançamentos de jogos na Europa e na América do Norte, e depois passei para outras áreas, como bases de dados médicas. De um modo geral, trabalhei sempre no desenvolvimento de software e em atividades relacionadas com gestão de projetos, com várias equipas, entre outras coisas. Ao longo da minha carreira, também adquiri alguma experiência em agências, com desenvolvimento de aplicações e algum desenvolvimento web inicial. Quando tivemos aquela primeira conversa sobre trabalharmos juntos, fiz essencialmente a transição para o desenvolvimento web e para o trabalho numa agência.

Ben Aston:

Sim.

Maik Stettner:

Tenho trabalhado na minha empresa atual, a FCV, há cerca de quatro anos. Atualmente, lidero a equipa de gestão de projetos da agência e sou basicamente responsável pela entrega global dos projetos e por garantir que os clientes ficam satisfeitos com os resultados que apresentamos.

Ben Aston:

Muito bem. Para as pessoas que nos estão a ouvir e que talvez estejam numa situação semelhante — algo que ouvimos com bastante frequência — e que dizem: “Sou gestor de projetos, tenho experiência a gerir software, mas agora estou a considerar uma transição para uma agência e tornar-me gestor de projetos digitais”, como foi essa experiência de transição para ti? Ao passares de um contexto mais ligado ao software para o mundo da gestão de projetos digitais numa agência, quais foram talvez as principais diferenças na forma como tens de gerir pessoas ou projetos? Gostaria de compreender melhor esse contraste e aquilo que as pessoas que estão a ponderar essa mudança devem ter em conta para se prepararem.

Maik Stettner:

Em primeiro lugar, há muitos paralelos. As coisas que encontramos noutras agências de desenvolvimento de software ou noutras áreas relacionadas com a gestão de projetos também aparecem numa agência. Teremos equipas diversificadas, os projetos descarrilarão por vários motivos e podemos aplicar as mesmas táticas para resolver essas situações.

Uma das principais diferenças para mim, quando comecei, foi compreender e aplicar a ideia de nos concentrarmos muito no tempo e nos materiais e em incrementos de trabalho mais pequenos, em vez de entregas maiores. Os clientes, sobretudo na área em que trabalho, querem mais transparência e mais controlo sobre os pequenos blocos de trabalho que estão a ser realizados. Isso implica relatórios mais detalhados e, de um modo geral, mais esforço para sermos transparentes e explicarmos ao cliente exatamente o que estamos a fazer para gerar esse nível de confiança. É sempre necessário um pouco mais de esforço e adaptação da minha parte do que quando se trabalha numa empresa de produto e se trabalha para um lançamento, que pode ser interno.

Essa foi, para mim, a principal diferença. No entanto, foi muito interessante perceber que, mesmo quando trabalhamos numa área completamente diferente, não importa muito se estamos a trabalhar num projeto de bases de dados, num jogo ou num website: acabamos por enfrentar problemas bastante semelhantes, que podem ser transferidos de uma área para outra. Se aplicarmos os conhecimentos adquiridos num emprego anterior — por exemplo, uma boa comunicação e algumas das melhores práticas padrão de um gestor de projetos — é provável que sejamos bem-sucedidos, independentemente do que estamos a construir.

Ben Aston:

Muito bem. Então, fala-nos desses desafios semelhantes. No teu cargo atual, não geres apenas projetos, também geres equipas. Em termos da equipa de gestão de projetos e da gestão do portefólio de projetos — gerir todo um conjunto de projetos diferentes com requisitos de recursos potencialmente incompatíveis — quais são os desafios típicos com que lidas ao liderar a equipa do PMO?

Maik Stettner:

Neste momento, o meu papel é mais abrangente. Basicamente, garanto que tudo continua a avançar. Uma das minhas principais preocupações é, como já disseste, a afetação de recursos e garantir que temos as pessoas certas para o trabalho certo e pelo período certo.

Ben Aston:

Sim.

Maik Stettner:

Muitas vezes, temos de fazer cedências quando as coisas demoram mais tempo, mas já temos outro projeto agendado. Depois, temos de gerir alguns desses ajustes e garantir que os clientes têm uma linha de comunicação aberta comigo. O risco de ocupar uma função mais abrangente e de nível superior é sermos praticamente a única outra pessoa responsável pelas escaladas. Não queremos estar apenas nesse papel, porque isso significa receber chamadas somente quando as pessoas estão zangadas.

Ben Aston:

Sim.

Maik Stettner:

É sempre bom desempenhar um papel mais ativo em vários projetos para desenvolver uma relação de confiança e, ao mesmo tempo, garantir que as coisas estão devidamente organizadas dentro da organização. Seja em termos de recursos, operações ou colaboração geral, porque temos alguns escritórios.

Para nós, é importante garantir que as pessoas do nosso escritório de Toronto conseguem trabalhar bem com o nosso escritório de Victoria, por exemplo. Essa é a maior parte do meu foco. Ainda assim, continuo a trabalhar muito de perto com alguns clientes e a fazer uma quantidade razoável de gestão de projetos, porque é nessa área que continua a estar a minha paixão e gosto realmente de trabalhar com pessoas. Não vou abdicar disso.

Ben Aston:

Então, voltando ao desafio da gestão de recursos — algo que qualquer pessoa que lidere uma equipa de gestão de projetos ou que seja responsável pela gestão de recursos terá de enfrentar — qual é a tua abordagem quando tens projetos incompatíveis, dois gestores de projetos na equipa, ambos com prazos para sexta-feira, e ambos precisam dos mesmos recursos? Qual é o teu processo de triagem? Qual é a tua abordagem de gestão do portefólio de projetos para decidir quem ganha? Muitos gestores de projetos estão constantemente a falar sobre isto: não têm os recursos para a sua equipa. Seria interessante perceber a perspetiva de alguém que toma a decisão sobre qual projeto avança e qual não avança. O que podes partilhar sobre a forma como decides o que recebe recursos e o que é adiado ou abandonado?

Maik Stettner:

Em primeiro lugar, normalmente analiso a prioridade do projeto. Temos algum prazo a cumprir? Prometemos alguma coisa ao cliente? Tem de entrar em produção numa determinada data? Basicamente, verifico se existe alguma margem de manobra relativamente aos prazos.

O facto de algo estar finalizado no contrato, por exemplo, também desempenha um papel. Temos de garantir que tudo é concluído. O projeto quer simplesmente avançar e fazer um favor ao cliente? Isso é bom e teremos todo o gosto em fazê-lo se tivermos tempo, mas, se o outro projeto entrar em produção dentro de três dias, provavelmente não poderemos retirar ninguém desse projeto.

Esse é o ponto de partida. Idealmente, isto não acontece, porque o gestor de projetos deve antecipar determinados excessos e incluir margens de segurança. Pode parecer estranho, mas também espero que a minha equipa lute pelos recursos.

Ben Aston:

Sim.

Maik Stettner:

Muitas vezes, as pessoas são demasiado simpáticas e dizem: “Não há problema. Podes ficar com esta pessoa durante um dia.” No fim, isto faz com que o trabalho de todos seja adiado. Embora não goste de retirar recursos a outras pessoas, e isso seja absolutamente inadmissível, nas reuniões de gestão de recursos espero que alguém defenda o tempo de que precisa e transfira o problema para o responsável pela gestão de recursos, para que este encontre ajuda ou perceba como equilibrar a situação.

Ben Aston:

Talvez seja um problema de gestão de recursos canadiano.

Maik Stettner:

Um verdadeiro impasse canadiano.

Ben Aston:

Os canadianos são demasiado simpáticos, e nós, europeus, podemos dizê-lo. Ou será que só os canadianos podem fazer piadas sobre esses degenerados?

Maik Stettner:

Exatamente. Na Europa, vejo-os certamente de forma diferente.

Ben Aston:

Fala-nos das ferramentas. Descobriste recentemente alguma ferramenta que tenhas começado a utilizar e sobre a qual tenhas pensado: “Isto é fantástico. Porque é que não começámos a utilizá-la mais cedo?” Qual é o teu conjunto de ferramentas preferido?

Maik Stettner:

Estás a falar de gestão de recursos?

Ben Aston:

Gestão de recursos ou ferramentas de gestão de projetos em geral.

Maik Stettner:

Na realidade, utilizamos um conjunto bastante normal de ferramentas de gestão de tempo, e o MS Project é muitas vezes demasiado complexo para o cliente. Atualmente, estamos a experimentar bastante produtos baseados na nuvem. O Project, por exemplo, tem uma versão do Office 365. Também analisamos várias opções de software de gestão de tempo e de recursos. Ainda não encontrei a solução perfeita, porque temos um processo bastante personalizado que, infelizmente, também é parcialmente manual.

Na minha opinião, a ferramenta ideal para aquilo de que precisamos ainda não existe. O meu objetivo pessoal seria construir ou adquirir algo e depois adaptá-lo às necessidades individuais.

Ben Aston:

O que teria de ter essa ferramenta? Há pessoas que criam ferramentas e que também nos estão a ouvir. O que é que não encontras nas ferramentas atuais e que faria com que fossem viáveis? Ou o processo é tão complexo que as ferramentas ainda não conseguem dar-lhe resposta?

Maik Stettner:

Não necessariamente. Na verdade, é bastante simples. O que procuro é uma ferramenta que estabeleça uma ligação entre a simples gestão do tempo e o registo de horas — ou as folhas de horas das pessoas — e o planeamento de recursos. Algo como o Resource Guru, ou outras ferramentas que permitam mapear aquilo de que precisamos, mas que também integrem a vertente financeira. Especialmente quando trabalhamos com base no tempo e nos materiais, a conta simples é o número de horas multiplicado pela taxa de faturação. Depois, seria possível criar todo o fluxo de relatórios a partir daí.

Parece simples, mas há muitos aspetos a considerar relativamente à probabilidade de os projetos serem realizados, às alterações e à forma como os sistemas lidam com isso. Isso pode distorcer os relatórios e acrescentar tanto trabalho manual que as métricas deixam de coincidir. Ainda não encontrei a solução perfeita.

Ben Aston:

Muito bem. Vamos falar do artigo que escreveste sobre documentos de iniciação do projeto, ou DIP. Como referi na introdução, os projetos correm mal e penso que, muitas vezes, isso acontece porque não os iniciamos corretamente. Fazemos suposições sobre aquilo que a equipa sabe ou entregamos muitos documentos e dizemos: “Vão à unidade partilhada e leiam os documentos. Está tudo lá.” Pensamos que vão ler tudo e atualizar-se, mas, quando falham de forma espetacular, não sabemos porquê. Na realidade, é porque não compreendem o projeto.

Vamos falar sobre como podemos fazer isto melhor, como podemos escrever melhores resumos de projeto ou, utilizando a linguagem da gestão de projetos, criar um documento de iniciação do projeto. Vamos estabelecer o contexto. Podes explicar-nos o teu processo para iniciar projetos e dizer-nos onde se enquadra o documento de iniciação do projeto ou o resumo do projeto? Quando o crias? O que fazes para chegar ao ponto de poder escrever esse documento?

Maik Stettner:

Normalmente, imaginemos que temos um novo cliente. Estamos todos entusiasmados porque o contrato geral foi assinado. É provavelmente um acordo-quadro de prestação de serviços ou algo semelhante, que indica que a sua empresa e a outra empresa vão começar a trabalhar em conjunto. Para mim, o passo seguinte consiste sempre em perceber como transformar isso em passos e termos mais concretos.

Normalmente, pensamos numa declaração de trabalho. O problema é que, numa fase tão inicial do projeto, tudo está num nível extremamente elevado e é apenas uma aproximação daquilo que acabaremos por fazer. O documento de iniciação do projeto, bem como as reuniões de arranque, são boas ferramentas para conhecer melhor o cliente e perceber se existem outros fatores que não foram considerados nos resumos iniciais da declaração de trabalho.

Normalmente, depois de ser redigida a declaração de trabalho inicial — que também pode ser um rascunho — a equipa decide internamente o que vamos fazer na agência. Realizamos um arranque interno para alinhar todos e, depois, um arranque externo com o cliente, num nível mais elevado, para explicar: isto é o que vamos fazer, esta é a equipa, é assim que colaboramos e este é o âmbito que definimos até ao momento.

Para mim, o documento de iniciação do projeto ou resumo do projeto é o passo seguinte para tornar as coisas um pouco mais concretas. No entanto, nesta fase inicial, temos de o tratar como um documento vivo, porque ainda não é totalmente claro em que direção iremos avançar em todos os detalhes. É uma excelente ferramenta para fornecer contexto empresarial e garantir que os parâmetros básicos do projeto são claros, não só para o cliente, mas também para a equipa interna.

Ben Aston:

Sim. Portanto, começa-se com uma declaração de trabalho geral ou com algum tipo de acordo jurídico entre a agência e o cliente. É neste ponto que a base da declaração de trabalho e do acordo-quadro foi estabelecida, e este documento fica acima dela, definindo as coisas com maior clareza ou trabalhando em conjunto com a declaração de trabalho para definir alguns aspetos.

No teu artigo, explicas alguns dos elementos que deve incluir. Falas de fornecer contexto, especificar os parâmetros do projeto, apresentar uma estrutura de decomposição do projeto, identificar quem é quem no projeto e abordar a gestão de riscos. Vamos começar pelo contexto. Quando estás a reunir este documento e a fornecer contexto à equipa do projeto, como o fazes sem confundir as pessoas e as sobrecarregar com informação? Como distingues o que é ruído do projeto daquilo que será realmente útil? Quais são os principais elementos que tentarias incluir na descrição do contexto?

Maik Stettner:

Penso que tudo se resume a perceber por que razão o cliente está a realizar o projeto e quais são, em termos gerais, os problemas que precisam de ser resolvidos. Existem fatores empresariais subjacentes? Quer aumentar as vendas? Quer educar um público sobre aquilo que faz? Existe um esforço de reposicionamento da marca? A pergunta principal é: como se define o sucesso? Como saberemos, no fim — tendo em conta que ainda estamos num nível bastante elevado — se fomos bem-sucedidos?

Pode ser algo tão simples como melhorar as conversas de vendas ou, por exemplo, criar um website de autosserviço que retire todo o conteúdo de um sistema de gestão de conteúdos. É bastante importante estabelecer o contexto para garantir que a equipa sabe aquilo para que está a trabalhar. Mesmo que os passos ainda não estejam detalhados nesta fase, isto ajuda a enquadrar a atividade geral.

Se, no fim, estivermos a trabalhar num projeto de reposicionamento da marca cujo objetivo é reposicionar uma empresa e alguém perguntar: “Mas porque é que as minhas vendas não aumentaram?”, podemos responder: “Esse não era realmente o objetivo nem fazia parte do contexto do projeto. Pode haver efeitos indiretos que contribuam positivamente para isso, mas não era o foco do projeto.”

É sempre bom manter um registo do que foi discutido inicialmente e alinhar com o cliente o objetivo geral.

Ben Aston:

Penso que isso é muito útil. O contexto do projeto é sempre importante, a menos que se trate realmente de trabalho de manutenção, em que não é necessário conhecer a estratégia geral para manter ou corrigir algo. Mas, quando estamos a criar algo novo, compreender por que razão o cliente está a avançar com o projeto, o problema que estamos a tentar resolver, os objetivos empresariais e o aspeto do sucesso é essencial para fornecer à equipa a informação de base que a ajudará a definir a solução. Incluir esse contexto no resumo do projeto ou no documento de iniciação do projeto é fundamental. Vamos falar dos parâmetros do projeto. No contexto, os parâmetros do projeto enquadram, de certa forma, a posição do projeto naquilo que o cliente está a tentar fazer estrategicamente. Mas, dentro do próprio resumo, que parâmetros estás a tentar definir? Estamos, essencialmente, a limitar a equipa. O que tentas delimitar e de que forma é positivo limitar as equipas?

Maik Stettner:

Não queremos limitar os especialistas. O problema é que, se lhes dermos liberdade total, podem trabalhar num projeto completamente diferente daquele que imaginávamos. É sempre muito importante fornecer o enquadramento e os elementos básicos, incluindo restrições como o orçamento, o calendário e o planeamento geral definido. Idealmente, isto foi estimado com parte da equipa, pelo que não deve ser novidade. As pessoas devem saber que o cliente tem um determinado orçamento. Não queremos ser repreendidos por mostrar à equipa um orçamento de que não tinha conhecimento.

Acho muito importante abordar estes aspetos. Também é importante que a equipa compreenda que isto não é uma limitação: é aquilo que foi acordado e que será entregue ao cliente por um determinado orçamento. Mesmo que as coisas mudem — por exemplo, se alguém da equipa considerar que precisa de mais tempo — cabe à equipa perceber como tornar o trabalho possível. É bom realizar esta discussão de alto nível com a equipa e não dar a impressão de que estamos a dificultar o seu trabalho. Devemos capacitá-la para fazer o que precisa de ser feito e garantir que compreende que terá o nosso apoio perante potenciais aumentos de orçamento, riscos que já possam ser visíveis nesta fase inicial e alterações ao calendário.

Em última análise, a equipa precisa de confiar na sua capacidade de entrega e estar entusiasmada por iniciar o projeto, tal como o cliente, porque também quer concretizar o trabalho.

Ben Aston:

Falemos de outros elementos que também devem ser incluídos. Não vamos estragar o artigo para quem ainda não o leu, mas há uma última coisa que gostaria de abordar: a inclusão, no documento de iniciação do projeto ou no resumo do projeto, de uma decomposição do projeto, de uma estrutura de decomposição do trabalho e de um plano de afetação de recursos. No início do projeto, quando as coisas ainda estão bastante indefinidas, como se chega a um plano — ao teu plano preliminar — antes de o projeto começar e antes de se saber realmente como irá decorrer? Como crias um plano quando ainda não sabes totalmente em que consistirá o projeto?

Maik Stettner:

Para ser sincero, nessa fase é provavelmente a melhor estimativa possível. Baseamo-nos na declaração de trabalho, no que já existe ou na estimativa criada pela equipa. Ainda há muitas coisas por esclarecer: o cliente responde? Precisamos de um número de revisões que esteja suficientemente definido? Há muitos fatores potenciais. O plano que elaborarmos pode não funcionar exatamente como está.

Mas, voltando ao que disse anteriormente sobre a maior dificuldade de uma agência, essa é também a razão pela qual afirmo que ter uma aproximação de um plano ajuda claramente a agência e as outras equipas de projeto a planear a obtenção dos recursos certos e a garantir a estabilidade da equipa. Mesmo que seja um plano inicial ambicioso que ainda precise da aprovação do cliente, e que este diga, depois da primeira ou segunda reunião, “Precisamos de mais tempo. Isto não é realista”, continua a ser útil mapear as coisas a partir da nossa perspetiva e compreender algumas das complexidades pelas quais a equipa terá de passar.

Por exemplo, precisamos de um designer que não tínhamos considerado? Se conseguirmos que a equipa discuta algumas destas questões desde cedo, nós, enquanto gestores de projetos, compreendemos melhor as complexidades da entrega do projeto. Isso ajuda-nos a fazer as perguntas certas e a orientar o cliente. Mesmo um plano aproximado é melhor do que não ter plano nenhum, porque as pessoas falam sobre ele e, à medida que o tempo passa, é provável que se torne mais detalhado e mais próximo da realidade.

Ben Aston:

Penso que isso descreve bem a perspetiva de que algum plano é melhor do que plano nenhum, porque podemos sempre evoluí-lo. Quando se inicia um projeto e se reúne a equipa para falar do resumo do projeto, sem existir um plano real para a entrega nem uma reflexão sobre as dependências ou o papel que o cliente precisa de desempenhar, começa-se o projeto com muito pouco impulso: “Está bem, equipa, como vamos fazer isto?”

Se formos ter com a equipa com um plano, este dá às pessoas algo a que reagir: “Maik, estás louco. Como vamos conseguir fazer isso?” Pelo menos, oferece um ponto de partida para a discussão, em vez de uma folha em branco para a qual todos olham enquanto pensam: “Como é que isto vai ser entregue?” Ter algum tipo de plano, mesmo que seja o plano errado, é melhor do que não ter plano nenhum.

Falámos do resumo do projeto e do documento de iniciação do projeto, que parece um documento muito sério. Mas não tem necessariamente de ser um documento grande e formal, pois não? Essencialmente, estamos a fornecer contexto, parâmetros e um plano. Isto pode assumir diferentes formas. Que formas pode assumir o resumo do projeto e como vês o seu papel a evoluir ao longo do ciclo de vida do projeto?

Maik Stettner:

O guia que criei é basicamente um exemplo das coisas que podem ser incluídas. Existe certamente um mínimo de informação que deve constar de um documento de iniciação do projeto ou de um resumo do projeto, mas há obviamente outras formas de o fazer. Por exemplo, podemos abordar a gestão de riscos e integrá-la noutro documento. Ou podemos utilizar um quadro RACI integrado nos relatórios de estado, entre outras opções.

Não precisa de ser sempre muito formal. O importante é que todos estejam de acordo. Pode estar publicado no SharePoint ou no BaseCamp, e pode ser atualizado através de iterações e conversas. Se, por exemplo, o projeto chegar a uma determinada fase e todos concordarem: “Quando definimos o âmbito, esquecemo-nos da vertente comercial, por isso temos de a incluir e garantir que fica registada”, isso terá obviamente implicações no âmbito que precisam de ser tratadas.

Desde que seja um documento — até um e-mail formalizado —, algo escrito que as pessoas possam aprovar e que seja reconhecido, é suficiente. Não tem necessariamente de ser assinado e carimbado por todas as partes, mas, no mínimo, tem de ser reconhecido e todos têm de estar de acordo, porque é com base nele que o trabalho será entregue e realizado.

Ben Aston:

Muito bem. A boa notícia é que, se ainda estiver a pensar, depois de ouvir isto, “Parece tudo muito bem, mas por onde começamos?”, o Maik criou um excelente modelo que pode utilizar para o seu resumo do projeto ou documento de iniciação do projeto. Consulte o artigo para o descarregar. Maik, muito obrigado por fazeres isto hoje. Foi ótimo ter-te connosco.

Maik Stettner:

Obrigado pelo convite.

Ben Aston:

Não tens de quê. Como um dos nossos especialistas em gestão de projetos digitais, se gostou daquilo de que o Maik falou, ficará satisfeito por saber que o Maik participará no nosso próximo curso, com início em setembro, chamado Dominar a Gestão de Projetos Digitais. Se não sabe do que estou a falar, mas sabe que precisa de formação em gestão de projetos, consulte o curso. É um curso intensivo de sete semanas que inclui aulas de vídeo interativas, tarefas semanais, discussões de grupo e a opção de sessões de acompanhamento. Visite digitalprojectmanagerschool.com e inscreva-se antes de o curso ficar completo.

Se quiser contribuir para a conversa sobre documentos de iniciação de projetos ou resumos de projetos, visite a secção de recursos do digitalprojectmanager.com para se juntar à nossa equipa no Slack, onde encontrará todo o tipo de discussões interessantes. Não se esqueça de comentar o artigo e de o partilhar também. Até à próxima, obrigado por nos ouvir.