Fichamento Sistema de Bagagens Aeroporto de Denver em Dallas

[pic 2]

UNIVERSIDADE ESTÁCIO DE SÁ

MBA EM GERENCIAMENTO DE PROJETOS

Resenha Crítica de Caso

Caso Proposto: “Medisys Corp.”

Aluna: Magali Regina Cantisani

Trabalho da disciplina EAD - GERENCIAMENTO DE INTEGRAÇÃO E ESCOPO

                                                                      Tutor: Prof. Carlos Fernando da Rocha Santos, MSc, PMP

São Paulo

2019

---

MEDISYS CORP.: A EQUIPE DE DESENVOLVIMENTO DO PRODUTO INTENSCARE

Referências: Harvard Business School Brief Case 312-P03 -  Anne Donnellon, Joshua D. Margolis. Guia PMBOK, Sexta Edição – Project Management Institute (PMI), 2017. Managing Transitions: Making the Most of Change, William Bridges, 2009.

Introdução: O texto nos apresenta uma situação bem estressante enfrentada na empresa MediSys pelo time de desenvolvimento do produto IntensCare, há seis meses de seu lançamento. A equipe de desenvolvimento de produtos, composta por pessoas de diversas áreas funcionais, enfrenta problemas com o design do produto, testes clínicos, cumprimento de prazos e com a própria dinâmica do grupo. A relação entre equipe membros é bastante tensa, o lançamento do produto e o resultado esperado com o lançamento estão em risco.

O caso inicia apresentando a MediSys: fundada em 2002, em 2008 tinha um faturamento de US$ 400 milhões e 1750 funcionários. No entanto, estava começando a constatar uma desaceleração no crescimento, e contratou o executivo Art Beaumont em janeiro de 2008. Beaumont trouxe mudanças na estrutura da organização e no desenvolvimento de produtos. Priorizando a velocidade, criou várias equipes multidisciplinares para o desenvolvimento paralelo de produtos, chamando cada uma delas de “equipe central”. O produto Intenscare já havia consumido mais de 20 milhões de dólares em desenvolvimento, e era o projeto mais ambicioso da empresa nos últimos 10 anos.

Desenvolvimento: Analisei o histórico da criação do produto IntensCare (vide Figura 2 – linha do tempo), onde nota-se a formação da equipe ad hoc a partir da ideia do produto, no entanto não se vê claramente em que momento houve o desenho do business case. Adicionalmente, e ao invés de se iniciar um projeto de acordo com as melhores práticas, optou-se por criar uma “equipe central”, mas que no entanto não tinha uma estrutura projetizada e continuava a responder para a hierarquia tradicional funcional. Embora Beaumont tivesse boas ideias, não se baseou em melhores práticas de GMO (Gestão de Mudança Organizacional), como o modelo de Bridges (Bridges, 2009) ou em melhores práticas para o Gerenciamento de Projetos (PMBOK, 2017) - ao criar as “equipes centrais”.

Na primeira parte da minha resenha, irei pontuar as principais diferenças encontradas entre as melhores práticas de gerenciamento de projeto e as situações apontadas no estudo de caso, e na conclusão irei apresentar algumas sugestões que poderiam trazer melhores resultados.

A seguir alguns dos pontos em que notei de diferença entre as melhores práticas de gerenciamento de projetos, de acordo com o PMBOK, e o estudo de caso apresentado: 1) Falta dos objetivos de negócio, normalmente detalhados em um business case; 2) falta da formalização do início do projeto, com a clara abertura de um projeto para a empresa, com a designação do gerente de projetos; 3) falta do papel e responsabilidade clara do gerente de projeto: embora a iniciativa tivesse um líder, este tinha outras várias atribuições, e o orçamento e outras atribuições eram realizadas pela gerente de marketing, Valerie Merz. Em decorrência da falta de governança clara, havia uma demora na tomada de decisões, e dúvidas sobre quem deveria toma-las; 4) falta do gerenciamento do escopo, sem uma clara definição do produto que seria entregue, e sem uma clara definição sobre a modularidade do produto mesmo há poucos meses do lançamento. Neste caso também não se encontra uma solução via controle integrado de mudanças, já que não há controle do escopo; 5) falta de comunicação e coordenação, sendo que os membros da equipe muitas vezes conscientemente optavam por esconder informações. Ninguém também tinha visibilidade do que estava sendo realizado pelo time terceirizado na Índia; 6) falta na gestão de recursos, onde houveram cortes de pessoal na empresa sem uma avaliação do impacto que isso ocasionaria no projeto; 7) Falta de uma visão clara das entregas e dos marcos do projeto; 8) Falta de monitoramento e controle, onde os atrasos são apenas identificados tardiamente; 9) Falta de gerenciamento dos riscos, onde não se identifica um plano de resposta aos riscos que o projeto apresenta; 10) falta de planejamento, falta de controle de qualidade (testes insuficientes); 11) falta dos critérios de sucesso do projeto, de acordo com o desejo dos clientes finais e com as solicitações do marketing: ao desconsiderar a modularidade e apresentar essa facilidade em uma versão futura, o produto pode não atender o mercado, e perder o time to market. Mas além de todos esses pontos, o que mais chamou a atenção foi a falta de integração como processo, sendo que o papel de integrador ficou baseado na pessoa de Jack Fogel, que deveria “unir as pessoas”, mas falhou miseravelmente. Ao basear toda a integração em Jack, e não em processos, ao passo que este tinha outras atribuições e falhava no seu papel de manter o time coeso, o projeto como um todo começou a desintegrar-se.