Nestas semanas tenho me ocupado de reflexões sobre a Estratégia, resultado das minhas longas leituras em meus estudos de doutorado, aliadas às boas conversas com amigos e mentorados sobre o tema.
Estratégia, ou “a arte do general”, em sua versão corporativa pode ser entendida como um conjunto deesforços para manter a organização integrada ao ambiente.
Nota-se a importância do meio exterior, rico em estímulos, como elemento constituinte, um ingrediente necessário na definição de diretrizes estratégicas.
Mas, não posso deixar de mencionar aqui a Competitividade, que em minhas formidáveis aulas com o Prof. Oswaldo Luiz Agostinho na Unicamp vislumbrei a luz do entendimento: Competitividade é um processo no qual uma entidade (país ou estado) se empenha a superar outra…
“A Estratégia é função da Competitividade”
Oswaldo Luiz Agostinho
Explico melhor a citação do mestre, se pensarmos como os matemáticos, em uma função matemática elementar como y=f(x) temos em x, variável independente, a Competitividade; já em y, variável dependente, a Estratégia.
Logo, para pensarmos em Planejamento Estratégico temos que pensar primeiro na Competitividade.
E como fazemos isso?
É preciso entender os elementos constituintes da Competitividade, nosso mestre Prof. Agostinho entende a competitividade sob dois pontos de vista: Competitividade Externa e Competitividade Interna…
Modelo de Competitividade Adaptado de: Agostinho (1995)
Como Competitividade Externa tem-se o conjunto de estímulos do meio exterior, oriundos de três grandes fontes: Mercado, Ciência e Tecnologia e Sociedade.
A Competitividade Interna constitui o conjunto de atributos que visam fazer contraposição aos estímulos do meio exterior, são características internas da organização, agrupadas em 3 grandes subconjuntos: Mercadológicos, Organizacionais e de Capital Humano.
Na formulação do Planejamento Estratégico, primeiro faz-se necessário identificar os estímulos do meio exterior mais relevantes (vindos das três fontes) que afetam a organização, mediante um ranking.
Definidos os estímulos, deve-se analisar quais os atributos de competitividade interna (seja mercadológicos, organizacionais ou de capital humano) que tem maior relação com os estímulos priorizados.
Trata-se de uma análise qualitativa, realizada mediante uma metodologia desenvolvida pelo notável professor: a Metodologia de Foco.
Metodologia de Foco Adaptado de: Agostinho (1995)
A matriz que correlaciona estímulos do meio exterior com atributos de competitividade interna é uma forma para se determinar quais atributos da organização precisam ser suportados no planejamento estratégico.
Alinhados com a Missão e Visão da organização, tais atributos são os pilares organizacionais que viabilizam o enfrentamento dos estímulos externos.
Ou seja, trata-se da essência do Planejamento Estratégico, a definição das diretrizes estratégicas…
Assim, antes de pensar em introduzir metodologias e/ou tecnologias na organização, guiados apenas por intuição, ou por modismo, por que não pensar na Estratégia de forma mais madura, muito além do SWOT?
Referência:
Agostinho, O. L. (1995). Integração Estrutural dos Sistemas de Manufatura como Pré Requisito de Competitividade. Tese de Livre Docência, Universidade Estadual de Campinas, Campinas, SP, Brasil.
Como já mencionado nos artigos anteriores, tais boas práticas foram reunidas ao longo de 20 anos de atividade profissional minha (e de colegas) com projetos, em diferentes organizações.
Vamos então às últimas 5 boas práticas:
BP#11: A partir das entregas do projeto, crie uma WBS para obter uma visão comum do escopo do projeto.
Certamente aqui os defensores do ágil vão “torcer o nariz” pelo fato desta ferramenta ser mais ortodoxa mas, por favor, me deem tempo para explicar.
Como já explorado na BP#10, entregas são um importante instrumento para materializar os resultados do projeto, inclusive auxiliando na árdua tarefa de “alimentar os tigres” corporativos (alta gestão).
Assim, uma interessante alternativa para melhorar a comunicação com estes e demais stakeholders chave, inclusive seu time, é criar um mapa gráfico do escopo do projeto, mesmo que ele venha a mudar, fruto da evolução na jornada de descoberta e entrega de valor.
Exemplo de WBS. Fonte: O Autor.
Este mapa do escopo, já entendido como evolutivo por natureza, pode ser representado em uma WBS – Work Breakdown Strucutre ou Estrutura Analítica de Projeto (EAP).
Uma WBS ajuda muito em mostrar os elementos do seu desafio, da entrega de valor do projeto, além de ser uma forma evidente (gestão a vista) de mostrar o que já foi feito e o que há por fazer.
Assim, entendo como importante recorrer a este instrumento para “colocar todos na mesma página”, como um GPS do caminhar da execução, pense nisso.
BP#12: Crie um cronograma enxuto do projeto.
Novamente corro o risco de ser mal interpretado aqui, não me refiro nesta boa prática aos cronogramas tradicionais, com muitas tarefas e relações lógicas.
Na minha visão tais cronogramas mais funcionam como uma “camisa de força” para o projeto, prejudicando a adaptabilidade frente aos desafios externos, ao invés de direcionar caminhos…
Um cronograma enxuto, com apenas as macro etapas e deadlines (datas limite) serve para, assim como a WBS, mostrar o caminho que o time seguirá na sua jornada de entrega de valor.
Este caminho, demonstrado desta forma, ajuda inclusive a trazer uma certa segurança ao time, evitando que se sinta perdido, risco observável em cenários de equipes praticando o ágil.
Neste cronograma as entregas podem e devem ser identificadas, associadas aos marcos do projeto (milestones), sem detalhamento de tarefas, visto que tais pormenores serão definidos à medida que o projeto avança e por decisão da equipe.
Um cronograma assim é um belo instrumento para apaziguar os ânimos dos “tigres” corporativos, visto que demonstra o projeto em um racional de entrega, servindo assim como uma ferramenta de stakeholder management.
BP#13: Cuidado ao determinar a relação custo-benefício do projeto.
Este é um tema sério que aflora ao ver apresentações (pitchs) de projetos mal preparadas, orçamentos mal feitos e projeções de retornos ou mal calculadas, ou com otimismo demasiado.
Um pitch é um momento vital para o projeto (e para quem o apresenta), nele a alta gestão fará sua apreciação e teremos o go/no go.
Assim minha recomendação é que qualquer orçamento de projeto seja feito com o apoio de um especialista, que pode ser da área financeira ou do próprio PMO (Project Management Office) da organização.
O mesmo vale para o cálculo dos benefícios…
Uma certeza podemos ter, na hora de apresentar os números (Orçamento e ROI do Projeto) alguém vai perguntar sobre como foram determinados e é necessário ter segurança neste momento, é um teste importante.
Esteja preparado para este momento, busque conhecimento, não ache que sabe o suficiente para fazer estas demonstrações, alinhe antes todos os racionais de cálculo também com o patrocinador (sponsor) do projeto…
Segurança em um pitch é vital, números são a linguagem dos gestores, tenha fluência neste idioma.
BP#14: Seja ágil! Acompanhe a execução do projeto através de um quadro de SCRUM.
Um quadro de SCRUM do projeto, o qual apresenta o conjunto de atividades, nos seus respectivos status (A FAZER/FAZENDO/FEITO) tem uma simplicidade e poder sobre a execução do projeto que não consigo encontrar em outro instrumento, quando o assunto é manter o time focado nas atividades que agregam valor.
Mas é preciso ter um cuidado, é importante que este quadro seja atualizado de forma contínua, assim alguém do time precisa assumir esta responsabilidade, em alguns cenários este indivíduo é o chamado scrum master.
Esta ferramenta é muito eficaz para fazer o acompanhamento da execução, e inclusive não precisa de nenhuma tecnologia rebuscada, basta um simples quadro branco.
“Simplicidade é o mais alto grau da sofisticação”, já dizia Leonardo da Vinci.
Mantenha este quadro em um local visível para todos do time, esta ferramenta inclusive o ajudará a manter o senso de urgência no grupo, condição tão importante, já comentada em nosso artigo anterior, como instrumento de engajamento da equipe.
E agora a última (e não menos importante) boa prática…
BP#15: Arquive toda documentação de forma organizada ao longo do projeto, ao final conduza uma reunião de post mortem.
Em 20 anos de consultoria sou capaz de contar nos dedos de uma das mãos situações em que me deparei com departamentos que faziam uma gestão minimamente adequada da documentação de seus projetos, para fins de arquivamento.
E para isso não estou falando necessariamente de gestão do conhecimento em último grau ou softwares específicos, apenas de uma simples boa vontade em organizar as informações, imaginando que um dia, no futuro, elas podem ser consultadas para algum novo projeto (servindo de lições aprendidas ou lessons learned).
Pois é, frustrante é começar um projeto e saber logo depois que algo muito semelhante foi conduzido anos atrás, e a informação se perdeu, particularmente nos notebooks de seus idealizadores, que agora estão em outras organizações…
Daí a constatação de “reinventar a roda” tem seu espaço, desperdiçando energia com indivíduos comentendo os mesmos erros, mesmo por ignorância…
Melhor do que aprender com os próprios erros, é aprender com os dos outros.
Minha dica aqui é, se não há uma boa gestão de documentos dos projetos na sua área ou organização, comece a fazer esta gestão a partir do seu projeto, reúna as principais reflexões, entregas, resultados de testes, documentações de provas de conceito, além dos documentos mais tradicionais, como cronogramas e especificações de produto.
Organize em pastas, quer físicas ou na rede, digo na rede pois quantas não foram as vezes que tais documentos estavam em um computador em particular e, como a sorte nem sempre sorri para nós, uma falha na máquina fez todo o conteúdo do seu HD ser perdido, e aí se foram as informações.
Outra alternativa é o uso de pastas na nuvem, a qual eu indico e tenho feito intenso uso.
Uma dica final é conduzir uma reunião de post mortem com os principais stakeholders e o time ao final do projeto, a fim de coletar como foi a experiência do projeto para eles, quais os momentos mais difíceis, quais os mais fáceis, que comportamentos precisamos mudar e que lições tiramos para futuros projetos.
Como sei que é difícil reunir todos, o uso de teleconferência é uma alternativa, você pode organizar um webinar para fazer isso, é até um meio elegante de “fechar” o projeto.
Muito bem, aqui concluímos nossa jornada pelas 15 boas práticas, espero que você tenha gostado, procurei organizá-las e detalhar cada uma delas de forma que você possa aplicá-las nos seus projetos.
Se você gostou destes artigos, compartilhe-os na sua organização! A intenção é esta, trazer conteúdo de qualidade aos amigos que vivem a dura (e emocionante) rotina de gestão de projetos.
Olá! Vamos continuar neste artigo a apresentação da sequencia de boas práticas para uma boa condução de projetos…
Aqui vamos tratar de mais 5 boas práticas (6 a 10), se você não leu as 5 primeiras, segue o link do primeiro artigo.
Como comentei no artigo anterior, todas estas boas práticas são fruto da minha experiência (e de meus colegas) nestes últimos 20 anos como consultor na área, envolvido em projetos de diferentes naturezas e em diferentes ramos de negócio.
Vamos então às boas práticas…
BP#6: Crie uma lista de características da sua solução (ou requisitos), tenha conciência que ela evoluirá à medida que as hipóteses da solução forem comprovadas (ou não).
Como citamos na BP#5, projetos envolvem o estabelecimento de hipóteses para a solução de um problema (ou explorar uma demanda), tais hipóteses estão atreladas às características daquilo que vai ser construído (um produto e/ou serviço).
Os mais conservadores em gestão de projetos chamarão tais características de requisitos, os agilistas chamarão de user stories, não importa a denominação, tais atributos da solução são uma ótima forma de descrever o que vai ser criado, clarificando os horizontes para os que vão usufruir dela, assim como para o time que vai construí-la, servindo de direcionador (uma bússola) para os trabalhos.
Muitos até relacionam tais características a serem criadas com o chamado Sprint Backlog, que nada mais é que uma lista de coisas que precisam ser feitas, na forma de funcionalidades (features) da solução.
Deixo claro aqui que isto vale para a grande maioria dos projetos, e não somente para os de software…
BP#7: Identifique os stakeholders (partes afetadas), entenda como influenciá-los em favor da condução do projeto.
Um projeto é um evento político, explico, a equipe de projeto e a comunidade de stakeholders (partes afetadas) que assiste os trabalhos tem demandas e percepções diferentes. Fazer com que todos caminhem para um objetivo comum consiste na da arte da política de condução de um projeto.
Assim, para conseguir esta coesão, inicialmente faz-se necessário entender como cada indivíduo enxerga o projeto, fazendo uso da empatia.
Compreendendo como cada stakeholder é afetado parte-se para a segunda e terceira etapas do gerenciamento político de um projeto, priorização e resposta.
Como priorização entendo em identificar quais são os stakeholders que podem impactar de forma significativa a entrega de valor do projeto (o seu legado), o que não necessariamente quer dizer que estamos tratando de um gerente ou executivo, pois um usuário de uma solução mal envolvido no projeto pode por muita coisa a perder…
Cabe ressaltar que um dos princípios da geração de hipóteses em projetos é testá-las, e quem vai fazer isto e nos dar feedbacks é peça-chave na nossa jornada de entrega de valor e descoberta.
Identificados os stakeholders mais importantes, inicia-se uma reflexão sobre como se pode obter o apoio de cada um deles (etapa de resposta), Alan Cohen, autor do Livro “Influência sem autoridade” costuma dizer que todos, de alguma forma, esperam algum tipo de recompensa. Exemplos de recompensas podem ser oferecer um desafio ao indivíduo, dar um significado ao seu trabalho, dar-lhe visibilidade, etc, ou seja, entender como se pode estabelecer uma zona de sombreamento entre os interesses e objetivos do projeto e os interesses e objetivos do indivíduo.
Em alguns cenários stakeholders relevantes podem nos trazer novas demandas, a fim de criarmos esta zona de sombreamento, o que pode, em última instância, a reconfigurações no projeto. Destaco que isto está longe de ser um descontrole no projeto, mas precisamos sempre ter em mente o velho ditado que “o melhor é inimigo do bom” e política (no bom sentido) faz parte do contexto.
BP#8: Cuide do engajamento do time.
Certamente você já deve ter ouvido uma dica desta natureza em outros posts, mas aqui queria deixar algumas questões um pouco mais práticas.
Além de identificar o que motiva cada indivíduo na equipe, é pertinente estabelecer um senso de urgência, a fim de “elevar a temperatura” do time.
John Kotter, autor do livro “Liderando mudanças” explica que o senso de urgência é o combustível da equipe, assim estabelecer metas ou entregas muito distantes não funciona, pois o indivíduo em última instância se questiona…”Em que isto vai mudar minha vida agora?”
Logo a procrastinação, este fantasma corporativo, precisa ser exorcizado, metas próximas são uma alternativa, muitos denominam tais metas como quick wins, ou seja, vitórias de curto prazo.
Cumpridas estas vitórias, nada mais justo que pequenas comemorações, a fim de estabelecer uma retribuição ao time, um reconhecimento pelo trabalho feito.
Só tome um cuidado, não comemore em demasia, se não o jogo vira e a equipe acha que “já ganhou”, ok?
Um outro ponto a se comentar que ajuda muito no engajamento do time é a presença do líder, assim nada de ficar no seu computador disparando emails somente fazendo cobranças (já vi muito disso…), é preciso ter skin on the game, ou seja, estar junto do time.
Vamos esclarecer melhor este ponto, visite a equipe com maior frequencia, tenha conversas com cada um deles (não necessariamente sobre o projeto), procure identificar reais ou potenciais bloqueios para a realização dos seus trabalhos e atue como um jardineiro.
Um jardineiro!?! Isso mesmo, o novo paradigma de liderança não é mais o de um comandante, mas de um jardineiro que identifica impedimentos e procura retirá-los, permitindo que cada indivíduo (ou planta do jardim), floresça e se desenvolva melhor.
BP#9: Identifique quais são as premissas e restrições do projeto, entenda suas relações com os riscos.
Acho que aqui é importante trazer as definições de premissa, restrição e risco, visto que em workshops e consultorias rotineiramente me deparo com situações as quais revelam a confusão dos termos.
Como restrição podemos entender todos os fatores que limitam as opções do projeto, quer em termos de tecnologia, pessoas, recursos financeiros e tempo. Também é muito comum verificar questões de compliance como restrições, visto que a adequação às boas condutas da organização, e em última instância às leis, servem de condições de contorno na definição de hipóteses e realização de testes.
As premissas podem ser entendidas como fatores que assumimos como verdadeiros no contexto do projeto, ou seja, são pontos de partida nos quais o projeto é construído.
Costumo usar a seguinte metáfora para explicar este conceito, imagine que seu projeto é uma grande torre, na sua base temos os alicerces de concreto, entenda cada alicerce como uma premissa, note que ele não faz parte da torre (o seu projeto), mas depende totalmente dele para não cair.
Um exemplo que acabo me deparando com frequencia é o caso de projetos na área de business intelligence, os quais buscam gerar dashboards para análise de dados, gerando informação para a tomada de decisão da alta gestão, seja na área financeira ou operacional.
Nestes projetos uma premissa certamente está na fidedignidade dos dados que serão utilizados na criação do dashboard, pela minha experiência esta premissa costuma falhar em muitos casos e o projeto acaba atrasando porque foi necessário enxertar uma etapa de tratamento de dados (remoção de redundâncias, verificação de valores, adequação de formato do banco de dados, etc).
Daí que se conclui que é importante estudar o contexto do projeto para mapear as premissas, visto que elas são fontes de riscos para o projeto.
Deixo aqui o link de um outro artigo interessante que escrevi sobre competências necessárias para a boa condução de um projeto, nele detalho mais quais as questões do contexto que precisam ser levadas em conta.
Há quase um axioma nesta questão….“toda premissa tem ao menos um risco associado”.
Bom, agora que mencionamos a relação entre premissas e riscos, precisamos definir o que é um risco.
Risco é um evento que pode ou não acontecer e, em acontecendo, trará um impacto positivo (isso é bem raro) ou negativo ao projeto, este impacto normalmente se materializa em atrasos nas entregas por conta de retrabalho.
Assim é importante mapear os riscos do projeto, pode-se começar analisando cada uma das premissas e refletindo….“e se esta premissa se mostrar falsa, qual ou quais serão os desdobramentos sobre o projeto?”
Uma simples pergunta como esta levada ao time pode levantar várias respostas ou, como gosto de dizer, contramedidas para reduzir a chance do risco acontecer ou minimizar os impactos.
Tais reflexões do time pela minha experiência acabam em contramedidas que trazem em um ligeiro aumento no prazo, por conta da criação de contingências, mas é importante dizer que isto faz parte do contexto, pois o que se quer é aumentar a chance de sucesso (entrega de valor) do projeto.
Riscos devem ser mapeados continuamente ao longo dos sprints, incite este tipo de pensamento no time, o maior inimigo neste momento é o excesso de confiança…
BP#10: Defina entregas bem claras para demonstrar a geração de valor contínua do projeto.
Alguns chamam as entregas pelo seu termo em inglês: deliverables. Entende-se entrega como qualquer artefato gerado ao longo do projeto, pode ser o resultado de um teste, a criação de um protótipo, a validação de uma hipótese, todos estes e mais outros momentos importantes do projeto, os quais relacionam a materialização de uma descoberta à linha do tempo.
Este tipo de artifício é ótimo para acalmar os ânimos dos executivos, os quais normalmente estão ansiosos por resultados…Assim não demore muito para gerar entregas, crie uma linha do tempo macro do projeto com, pela minha experiência, ao menos uma entrega importante por mês.
Aliás este conceito vai de encontro com as quick wins que mencionamos na prática #8.
Uma expressão que se costuma ouvir neste caso é “temos que alimentar os tigres…”, entendendo o tigre como um animal corporativo (executivo) ansioso por resultados. Assim, gere entregas continuamente, mesmo dentro do contexto dos sprints (geração de hipóteses, condução de testes e tratamento dos feedbacks).
Esta estratégia te dá um pouco mais de calma para trabalhar com a equipe, reduzindo a pressão externa.
Muito bem, concluímos aqui o segundo artigo, falamos de mais 5 boas práticas de gestão de projetos, perfeitamente aplicáveis quer em um contexto ágil ou mais ortodoxo.
Aguarde o próximo artigo com mais 5 boas práticas… Espero que este material o ajude a ter melhores resultados em seus projetos, quer pessoais ou profissionais…
Após 20 anos envolvido com projetos em diferentes organizções e de diferentes naturezas, consegui reunir um conjunto de 15 boas práticas, fruto da reflexão quer minha, quer de experiências de colegas…
Encontrei que o conjunto de boas práticas, em um total de 15, se mostraram muito bem alinhadas com uma ferramenta conhecida por alguns, criada pelo colega José Finocchio Jr., o Project Model Canvas.
Assim quero compartilhar estas boas práticas com você, a fim de que, através desta troca de experiências, consigamos melhorar a assertividade com a qual projetos são idealizados, planejados e executados, tendo o objetivo final um legado de valor para as organizações e sociedade.
Então vamos às boas práticas… Neste artigo vou citar as 5 primeiras, depois publicaremos mais dois artigos neste blog a fim de trazer as demais práticas, agrupadas de 5 em 5…
BP#1: Tenha uma ferramenta que, em um único local e em uma única visão, traga de forma organizada as informações essenciais do projeto, o Project Model Canvas é uma excelente alternativa.
Um dos maiores problemas que vivencio em projetos é a falta de integração entre os elementos, a começar pelo escopo, tempo e custos, mas é comum observar projetos com uma carência de clareza nos objetivos, benefícios mal descritos, os quais levam a requisitos definidos sem levar em consideração o legado para a organização, a resposta a uma dor, quer de um indivíduo, quer materializada na deficiência de um processo.
O Project Model Canvas é uma ferramenta bem interessante, costumo dizer em meus workshops que nele podemos ter uma verdadeira noção das ligações invisíveis, mas essenciais, dos elementos do projeto, como se fosse uma estrutura de uma grande construção.
Esta visão sistêmica apurada responde à muitos problemas que vejo durante a fase de execução.
BP#2: Defina um objetivo SMART para o projeto, alinhe-o com seu gestor ou patrocinador, este objetivo o ajudará a manter o foco.
Falta de foco é um problema sério em projetos, muitas são as demandas e é fácil perder o controle.
Às vezes é preciso dizer não para os anseios dos stakeholders (ou partes influenciadas), o que nem sempre é fácil, pois alguns tem grande poder na organização.
Por isso o estabelecimento de um objetivo SMART (Específico/Mensurável/Atingível/Relevante/Atrelado ao Tempo) pode ajudar a definir uma bússola para o projeto, pois é preciso dizer que um plano é passível de mudança, mas mudar o legado ou, em outras palavras, o valor a ser entregue, não.
O objetivo SMART materializa muito bem este legado.
Uma forma alternativa que também observo ser empregada hoje é o uso de OKR´s (Objectives & Key Results), o qual tenho encontrado como uma forma bem elegante de estabelecer a régua de sucesso do projeto.
BP#3: Faça um bom benchmarking! (ou “não reinvente a roda”)
Bom, quando o assunto é benchmarking, ou seja, pesquisar lições aprendidas de projetos semelhantes, usualmente vejo dois cenários: ou não temos estas lições registradas, ou nós que estamos conduzindo o projeto achamos que não precisamos delas.
Suspeito que nos dois casos estamos enganados, primeiro porque há uma boa chance de encontrarmos alguém dentro da organização que já trabalhou com um projeto semelhante…
Costumo dizer que pouco conhecemos das organizações que trabalhamos, ou que prestamos serviços…
No segundo caso, é comum sermos acometidos pela soberba e acreditarmos que não precisamos de ninguém , até por crermos que assim faremos um planejamento mais rápido, ledo engano…
Melhor que aprender com seus próprios erros, é aprender com os dos outros…Um pouco de humildade faz bem nesta hora…
BP#4: Crie um cenário “As is” e “To be” do projeto, faça uma boa avaliação do seu custo-benefício.
Nenhum projeto é aprovado sem uma boa argumentação, na forma de uma apresentação ou pitch, assim um possível patrocinador, para entender o projeto e seu legado, precisa entender o contexto atual (“As is”) e como será o novo contexto (“To be”), ou seja, como será o novo cenário com o produto do projeto “rodando”, quer seja uma melhoria de processo, um novo produto ou ainda um serviço para um cliente interno ou externo.
A definição destes cenários é muito útil também para manter o foco da equipe, é normal durante a execução o time identificar oportunidades de implantação de novas funcionalidades ou melhorias mas, em muitos casos, pela minha experiência, são mais fruto de um desejo da equipe que de uma real necessidade, logo precisamos estar atentos para não perder o rumo.
Aqui vale um ditado…”Quem muito abraça pouco aperta”…Pense nisso.
BP#5: Procure criar um protótipo ou faça um piloto da solução, não demore muito para testá-la.
Aqui cabe dizer que um projeto tem dois momentos bem distintos, o primeiro no qual faz-se uma imersão no problema, a fim de entender sua estrutura e implicações no modelo de negócio (pessoas, processos e infraestrutura). E um segundo no qual hipóteses são geradas…
Hipótese nada mais é que um bom “palpite” para resolver o problema, fruto do conhecimento da equipe.
Mas hipóteses precisam ser testadas e o quanto antes isto ocorrer, melhor, assim a criação de testes piloto, uso de protótipos (MVP´s: Produto Mínimo Viável) e demais artifícios para comprovar se as hipóteses estão corretas precisa ocorrer, na minha opinião, ao menos logo no final do primeiro terço do projeto (ex: em um projeto de 6 meses, lá pelo final do segundo mês seria importante ter um teste em curso…).
Esta estratégia é interessante, inclusive bebe das fontes do agilismo, visto que, se a hipótese se mostrar falsa (e isto pode ocorrer, apesar de todo conhecimento e experiência do time), o erro pode levar a novas hipóteses, em uma rota evolutiva, com mais chances de sucesso.
Por ora seguimos até aqui, no próximo artigo vamos discutir mais 5 boas práticas.
Espero que tenha gostado, desejo que estas boas práticas lhe façam refletir melhor sobre como gerir projetos, com mais chances de um final feliz…
Competitividade é uma palavra muito citada na mídia sobre economia e negócios, executivos constróem discursos e artigos inspiradores fazendo uso do termo com aparente fluência.
Confesso que, ao ouvir e ler muito que é tratado sobre o tema, percebo vários mal entendidos.
O primeiro é sobre a própria definição do termo, o que é Competitividade de fato?
Competitividade é uma capacidade da organização de criar soluções dentro do timing e custo aceitáveis pelo mercado, com qualidade, desejável pelo cliente e que seja aderente às exigências da sociedade.
Perceba que a definição de competitividade demanda 3 elementos: um ligado aos clientes, um segundo à qualidade e um terceiro à sociedade, entendida como o conjunto de stakeholders (partes influenciadas).
É partindo desta definição que quero discutir neste artigo quais são os passos ou pontos de atenção que uma organização precisa ter para ser competitiva, ou seja, capaz de criar valor de forma sustentável e de difícil cópia.
Vamos aos passos então?
O primeiro passo é ligado aos clientes, organizações precisam estar próximas dos usuários de seus produtos e/ou serviços (soluções), esta proximidade permite que entendamos como os clientes usam o que geramos, quando usam, quais os gatilhos que definem as aquisições e, principalmente, que sugestões eles tem para melhorarmos o nosso portifólio.
Mas muitas organizações dizem que tratam muito bem esta questão com pesquisas de marketing, me permito discordar.
O novo management tem nos colocado mais e mais evidências que dados qualitativos são tão ou mais valiosos que os dados quantitativos tradicionais, em muitos casos a boa frase “menos é mais” cabe aqui, com menos clientes e práticas de Design Thinking como jornada de clientes e pesquisas qualitativas, conseguimos verdadeiras “pérolas”, insights valiosos para criação de valor.
Em última análise temos a cocriação, o cliente e a organização trabalhando juntos para desenhar a solução.
Agora vamos ao segundo passo, como comentei a interação com os clientes é muito valiosa em apontar oportunidades de melhoria, muitas delas não somente ligadas ao produto final, mas também à forma de ser produzido e entregue.
Em outras palavras, uma organização precisa usar com sabedoria e excelência seus ativos (máquinas, equipamentos, processos e pessoas), é através destes elementos que o valor é criado.
Nas minhas atividades de consultoria quantos não são os casos que me deparo com empreendedores ansiosos por ampliar sua capacidade, fazendo aquisições de máquinas, equipamentos, veículos e expandindo instalações.
Mas me pergunto, será que os ativos originais não poderiam ser explorados de forma mais inteligente?
Aí entra o fator mais importante deste passo, o Capital Humano, as pessoas que trabalham na organização, os colaboradores, são uma fonte valiosa de conhecimento, capazes de propor soluções para os problemas de capacidade/qualidade/otimização de forma criativa, eficaz e eficiente, permitindo adiar aquisições, melhorar a qualidade e redesenhar a forma de se entregar valor.
Isso exige uma revisão do paradigma de liderança nas organizações, saindo de uma concepção tradicional do líder, como alguém que indica caminhos e inspira as pessoas a seguí-lo (o comandante), para alguém que remove impedimentos e permite que o conhecimento venha a emergir do grupo (o jardineiro).
Agora entra o último passo, não menos importante, uma organização precisa cuidar dos stakeholders (pessoas e instituições) que influencia.
Quais valores sua organização propaga para a sociedade? São estes efetivamente praticados pela liderança e demais colaboradores?
Uma organização não existe apenas para entregar soluções, ela dever ter um conjunto de crenças, um Credo Interno, que precisa ser externalizado, tais crenças são sua âncora ética.
A imagem de uma organização está, nos dias de hoje, cada vez menos associada à campanhas institucionais, mas sim a evidências de ações sociais coerentes com suas crenças, expressas nas midias sociais.
Engajamento, empresas precisam ser engajadas, é disso que falamos aqui.
Concluindo, os três passos que comentei, na verdade, também podem ser entendidos como pilares, assim poderíamos imaginar um framework de competitividade como uma mesa com três pés, um nos clientes, outros nos processos internos (ou uso dos recursos) e um último nos stakeholders.
São estes três pés que formam as chamadas três visões da competitividade: uma no Marketing, outra nos Recursos e a terceira nos Stakeholders.
Estes pilares sustentam, como uma mesa, a criação de valor de forma sustentável e de difícil cópia, ou seja, competitividade em sua melhor concepção.
Agora eu te proponho um exercício, reflita sobre como sua organização trabalha estes três passos (ou pilares), esta prática pode ser de muita valia para a definição de estratégias e planos de ação.
Por fim, quero te deixar uma mensagem…
Competitividade é quem define a Estratégia, e não o contrário, pense nisso…
