PROJETO PMC

Conceito

Origem do PMC

Criado pelo professor Finochio Jr. Que utilizou como referencia o Business Model Generration (BMG)

PMC Digitaal

É um app que permite que um time de projeto geograficamente distribuído realize uma sessão de Co criação do plano de projeto, que pode ser projetado em tempo real para diversas localidades participantes.

Dificuldades com o Guia PMBOK

O guia PMBOK segue a utilização de uma serie de documentos que ajudam a gerenciar os projetos

O TAP por exemplo é um documento que envolve para sua elaboração um levantamento anterior das necessidades de negócio, um busines case para o projeto.

Metodologia

As quatro etapas da metodologia são as seguintes:

Conceber:

Nessa etapa são respondidas as 6 perguntas fundamentais em sequencia determinada da esquerda para a direita.

Os blocos na cor laranja receberão as respostas para a pergunta Por que?.

Os componentes na cor laranja são definidos da seguinte forma:

Justificativa:

Objetivo do Projeto:

Benefícios:

Os blocos na cor roxa receberão as respostas para a pergunta O que?.

Os componentes na cor roxa são definidos da seguinte forma:

Produto:

Requisitos:

Os blocos na cor branca receberão as respostas para a pergunta Quem?.

Os blocos na cor azul receberão as respostas para a pergunta Como?.

Os componentes na cor azul são definidos da seguinte forma:

Premissas:

Grupo de Entregas:

Restrições:

E os blocos na cor verde receberão as respostas para as perguntas Quando? e Quanto?.

Os componentes na cor branca são definidos da seguinte forma:

Stakeholders externos:

Fatores externos:

Equipe:

Os componentes na cor verde são definidos da seguinte forma:

Riscos:

Linha do Tempo:

Custos:

As limitações aplicáveis ao trabalho estão identificadas na forma de restrições?

Integrar:

Nessa etapa é checado se há consistência entre os blocos do canvas. A metodologia PMC fornece um Protocolo de Integração que é um conjunto de verificações predeterminadas e que são feitas numa sequencia coesiva.

São 8 os passos desse protocolo:

Passo 1:

Os pontos mencionados nas justificativas são sanados?

Passo 2:

O objetivo se revela suficiente e necessário?

Passo 3:

Todos os requisitos “têm dono” e definem o produto?

Passo 4:

Estão subordinados ao projeto aqueles que precisam estar?

Passo 5:

Objetivemos convergência formulando premissas válidas?

Passo 6:

Passo 7:

Os riscos cobrem o que já sabemos do projeto e vislumbram, ao mesmo tempo, o que ainda não sabemos?

Passo 8:

O cronograma e o orçamento estão orientados por entregas?

Resolver:

Nessa etapa é identificado se há indefinições, falta de informação ou contradições no projeto. A qualquer tipo de problema como esses apresentados, dá-se o nome de nó. O nó nada mais é que um ponto que estrangula o planejamento dali para adiante e que, portanto, precisa ser desatado para restaurar o fluxo de informações do projeto. A etapa de resolução do projeto é realizada seguindo o mesmo fluxo do trabalho da etapa de concepção, respeitando a ordem das questões fundamentais. Ao ler e analisar o projeto nessa sequencia as pessoas envolvidas na construção do canvas perceberão os problemas e para isso terão que seguir passos fundamentais para resolver o projeto.

São 3 os passos de resolução de projetos:

Identificar o nó:

Caracterizar bem qual é o problema que impede a concepção do projeto;

Lição de casa:

Levar o problema para a organização e dar espaço para propostas;

Alterar canvas:

Com a solução em mãos, avançar na concepção do plano.

Comunicar / Compartilhar:

Nessa etapa o plano do projeto visual estará disponível para as Partes Interessadas e poderá ser utilizado como entrada para a elaboração de outros documentos tais como cronogramas e apresentações do projeto.

A equipe necessária para planejar o projeto através dessa metodologia deve ser formada por pelo menos um profissional que domine os conceitos básicos de gerenciamento de projetos, por outra pessoa que conheça bastante do negócio a ser discutido e por outro integrante que contribua com críticas ao desenho de plano de projeto proposto. Vale à pena mesclar nessa equipe pessoas com mais experiência e pessoas com pouca experiência nos assuntos abordados de tal forma que o conhecimento seja compartilhado e que novas ideias possam surgir e ser aproveitadas no projeto.

Principios

O Project Model Canvas PMC é uma metodologia para planejar projetos de forma visual e colaborativa. O projeto é planejado em uma folha A1 dividida em 13 blocos ou componentes (FINOCCHIO JUNIOR, 2013). O conteúdo seguinte trará informações mais detalhadas sobre a metodologia PMC apresentada por Finocchio Junior.

PITCH

É um processo com quatro etapas e com ordem predeterminada deve ser seguido para a sua construção.Tópico flutuante

PITCH

São os problemas e necessidades não atendidas atualmente ou oportunidades ainda não exploradas.

É aquilo que o projeto permitirá que seja alcançado ao utilizar todos os esforços e recursos disponíveis. Deve ser escrito no formato SMART (sigla que deriva das iniciais de cinco palavras em inglês que significam Específico, Mensurável, Alcançável, Realista e Delimitado no Tempo).

São as melhorias e o valor agregado que o projeto produzirá. Devem ser quantificáveis e poderão ser mensurados após finalização do projeto com o intuito de verificar se o projeto teve êxito.

É o que será entregue ao Cliente no final do projeto. Pode ser um produto, um serviço ou um resultado.

São as informações de alto nível que o Cliente passa para a Equipe do Projeto sobre o comportamento, funções, qualidade, desempenho e confiabilidade que o produto deverá possuir. É comum colocar os post-its de requisitos mais prioritários no topo do bloco.

São todas as pessoas ou organizações envolvidas ou afetadas pelo projeto e que não trabalham nele; ou Fatores externos: são os fatores que de alguma maneira poderão afetar o planejamento do projeto de maneira significativa. Os stakeholders ou fatores externos devem ser monitorados pelo Gerente do Projeto.

São os fatores que de alguma maneira poderão afetar o planejamento do projeto de maneira significativa. Os stakeholders ou fatores externos devem ser monitorados pelo Gerente do Projeto.

São todas as pessoas que trabalham no projeto ou fazem entrega para ele. A equipe deve ser controlada pelo Gerente do Projeto ou receber influência do Gerente do Projeto.

São suposições dadas como certas no plano do projeto sobre componentes que não estão sob o controle e a influência do Gerente do Projeto. As premissas quando aprovadas pelos Stakeholders, protegem o Gerente do Projeto e garantem que as promessas de tempo e de custo só serão consideradas se as premissas valerem e forem verdadeiras.

São as partes menores que, uma vez integradas, garantirão que o projeto seja concluído. Elas são palpáveis, mensuráveis e verificáveis. Especialistas podem participar da Equipe do Projeto e contribuir sobremaneira para a identificação dessas entregas. Não devem ser identificadas muitas entregas e sim as mais relevantes para que os Stakeholders tenham uma noção lógica do projeto. Na hora de identificar essas entregas deve-se simplificar, agrupar entregas pequenas em entregas maiores e organizar grupos de entregas.

São limitações impostas, originadas tanto dos Stakeholders quanto da Equipe do Projeto, que diminuem a liberdade dos membros da equipe para realizar o seu trabalho. Elas devem ser analisadas e respondidas à tempo com soluções viáveis que contribuam para a continuidade do projeto. Para identifica-las no projeto basta que se faça a pergunta: por que não se pode entregar o trabalho antes? Ao responder a essa pergunta tem-se uma ou mais restrições identificadas. Uma restrição bem formulada deve: ser específica, quantificável (quando possível), indicar quem por ela é limitado e indicar quem impõem a restrição.

São as incertezas que efetivamente podem afetar os objetivos do projeto. Uma vez identificados, eles deverão ser gerenciados para proteger os objetivos do projeto. Eles podem ser positivos e assim serem chamados de oportunidades; ou negativos e assim receberem a denominação de ameaças. Devem ser identificados tanto os riscos globais do projeto quanto os riscos específicos do projeto. O processo de gerenciamento de riscos prevê as seguintes etapas: identificação, avaliação e destaque para os mais relevantes, desenvolvimento de respostas para os riscos mais relevantes e implantação dessas respostas. Para o risco global do projeto deve-se utilizar uma tabela para categorizar e avaliar os riscos do projeto.

Não representa uma precisão absoluta de quando as entregas serão feitas para o Cliente. É definida através do julgamento das pessoas que estão elaborando o canvas. São assumidas datas de compromisso das entregas. Uma boa estratégia a ser seguida é dividir a linha do tempo do projeto em 4 partes iguais (entre a data de início do projeto e de término do projeto), reordenar os grupos de entrega numa sequencia de liberação e colar post-its pequenos em cada uma das partes da linha do tempo para indicar quando cada entrega será disponibilizada.

São estimados por grupos de entrega em ordens de grandeza. É adicionada ao custo total do projeto uma reserva proporcional ao risco do projeto. Quanto maior o risco maior essa reserva de contingência. Para simplificar pode decompor os custos em outros elementos menores como trabalho, material e contratação. Isso não é mandatório, podem ser definidos outros elementos que não esses, segundo as especificidades do projeto ou mesmo da cultura organizacional.