Agile Aquisições Projeto

Scrum para compras – Um caso de agilidade num ambiente preditivo

Já faz algum tempo que um cliente me perguntou se eu conseguiria utilizar Scrum para compras, afinal era necessário uma análise de um produto que ele não tinha certeza de como fazer e seu setor de comprar por vezes acabava adquirindo algo que muitas vezes deixava de ser utilizado por não ter as funcionalidades necessárias.

Como consultor, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar.

Vou relatar aqui alguns pontos do que fizemos neste caso, além de mais alguns itens sobre agilidade e procurement (compras) mas em alguns casos não poderei revelar os nomes de algumas das empresas, caso tenha necessidade de uma conversa com maiores detalhes, me convide para um café, posso ajudá-lo transformar sua empresa também.

Neste caso ele me pediu para ajudá-los a adquirir e implementar um produto comercial pronto para uso1 – mas eu tive que usar o Scrum para fazê-lo.

Dito isto, quando cheguei lá, recebi uma RFP de 326 páginas de um Benchmarking2 que uma organização semelhante havia feito para o mesmo tipo de aquisição. Isso era exatamente o contrário de agilidade, MEU DEUS! Era muita informação técnica, neste caso fizemos uma experimentação logo depois do meu desabafo:

Eu não vou fazer uma RFP destas! Bora tentar agilizar isso?

Então, como fizemos isso? Aqui estão os três passos:

1 – Descobrir por que a empresa precisava de um produto comercial pronto para uso

O primeiro passo era descobrir por que os negócios precisavam do produto de prateleira. Para fazer isso, fiz um Mapeamento de resultados (que é uma variante do Mapeamento de Benefícios) para ajudá-los a articular mais claramente por que eles precisavam fazer o projeto de uma perspectiva de negócios e não de uma perspectiva tecnológica.

O documento de RFP de 326 páginas que recebi foi focado principalmente em tecnologia, e foi por isso que senti que precisávamos evitar uma armadilha dessas.

Assim que tivemos o primeiro rascunho do mapa de resultados criado, imprimimos em uma folha A1 e colocamos na parede em nossa sala de guerra para o projeto (sim realizar compras também é um projeto, o problema nesse caso é que encontramos um programa).

Ter um mapa visível do “porquê” permitiu que as equipes de negócios e de TI adicionassem detalhes ou fizessem perguntas usando post-its sempre que olhassem para o mapa.

Em seguida, ficávamos todos os dias revendo o mapa como uma equipe e revisamos o conteúdo dos últimos lembretes para descobrir onde precisávamos atualizar nosso mapa com nossa compreensão, agora emergente, do problema comercial que estávamos resolvendo.

Uma vez que concordamos sobre o que precisava ser mudado, nós atualizavamos o mapa, o reimprimiríamos e colocaríamos o mapa recém-revisado de volta na parede.

Isso criou uma oportunidade de novas descobertas para o negócio e para a TI, pois eles andavam e estudavam o mapa.

Enquanto eles olhavam para o mapa, frequentemente outros acabavam por parar e analisar também, o que, é claro, levou-os a falar sobre o mapa juntos. Essas conversas ad-hoc levaram a algumas das mais perspicazes adições ao mapa.

As identificações referentes ao mapa

Durante o período de aproximadamente 8 semanas, o grande mapa visível do motivo do projeto levou à identificação de:

Quatro grandes áreas de processos de negócios deveriam ser projetadas, desenvolvidas e implementadas, já que a empresa não tinha pensado anteriormente por somente trabalhar com os requisitos técnicos enviados.

Pronto acabamos de começar a usar a agilidade num projeto e caímos num programa!

O fato de que o produto de prateleira que pretendiam comprar era apenas uma das cinco ferramentas diferentes que eram realmente necessárias e era apenas uma das duas na área de processo de negócios em que ele seria usado.

O que me remete aos 45% das funcionalidades de um produto que não são usados após a entrega, por este motivo o Scrum foi adaptado para as compras e nos artigos posteriores vou mostrar com maiores detalhes.

  • À medida que você cria um mapa de resultados, existem estruturas naturais que o ajudam a categorizar diferentes partes do mapa.
  • À medida que esse quadro toma forma, ele também ajuda a identificar o que você precisa fazer (projetos / iniciativas) para satisfazer o motivo pelo qual você está fazendo (os resultados).

2 – Descobrir o que o produto a ser adquirido precisava fazer

É fato que como Triber, Gerente de projetos ou Agile Coach nem sempre somos contratados sabendo exatamente do que se trata um projeto, em projetos preditivos usamos o planejamento em ondas sucessivas, no Scrum fazemos isso de forma incremental trazendo valor com Sprints.

Eu facilitei os grupos da área de negócios na identificação dos requisitos de negócios necessários que o produto precisava cumprir, juntamente com as declarações de requisitos em cada área em relação ao que eles precisavam que o produto fizesse.

Isso permitiu que eles classificassem cada declaração de capacidade de acordo com uma escala de importância comercial (Muito Alta, Alta, Média, Baixa, Muito Baixa). Isso levou cerca de 8 semanas ou neste caso 4 Sprints. As regras de negócio foram as responsáveis por essas priorizações.

Criamos um Business Service Canvas para essa etapa, que era um derivativo do Business Model Canvas. Como no mapa de resultados, imprimimos a tela em uma folha de A1 e a colocamos na parede para que a equipe usasse post-its para capturar suas adições ou perguntas.

Os Serviços na tela começaram com o grupo de P&D (o grupo de negócios) que já tinha fornecido informações para o restante da organização.

Em seguida, lideramos a equipe de negócios por meio de uma série de comparações em pares de “comprar um recurso” para cada uma das instruções em cada nível de prioridade dentro de cada área de recursos, da seguinte maneira:

  • Digamos que a área de capacidade 1 tenha 4 declarações de capacidade classificadas em Muito alto.
    Queríamos que eles comparassem os dois primeiros perguntando o seguinte: “Você só tem condições de comprar 1 deles, qual você seleciona como prioritário?
  • Se eles escolhessem um sobre o outro, a declaração “perdedora” seria alterada para Alta ao invés de Muito Alta. Se eles não pudessem escolher um sobre o outro, ambos ficariam em Muito Alto.
  • Fizemos isso para todas as prioridades e para todas as áreas envolvidas.
  • Uma vez que todas as declarações das áreas foram re-priorizadas, pedimos que elas considerassem as de Baixa e Muito Baixa e se queriam incluí-las na RFP, já que elas já haviam dito que não eram tão importantes com base em seu nível atribuído.

Depois de alguma discussão, a empresa decidiu retirá-los da RFP. Isso nos permitiu confeccionar um documento de RFP de 7 páginas ampliado por planilhas pré-preenchidas com as declarações de requisitos organizadas por área de capacidade dentro do negócio.

Fornecemos espaço nas planilhas para os fornecedores preencherem suas respostas reais, que tinham que se referir à documentação de seu próprio produto que suportava suas declarações de adequação do produto.

Os fornecedores não puderam enviar respostas vinculadas ou impressas à RFP.

🎯 Dica: O uso do Business Service Canvas também ajudou a empresa a identificar a necessidade de reavaliações de função com base em lacunas de habilidades recém-realizadas, bem como funções ausentes em sua organização.

Esta etapa levou cerca de 4 Sprints para ser concluída.

3 – Mãos na massa, fazendo compras

Agora que sabíamos por que estávamos fazendo o projeto e tínhamos uma sólida compreensão do que o produto de prateleira precisava, estávamos prontos para executar a compra em si, o que significava:

  1. Emitir a RFP
  2. Avaliar as respostas dos fornecedores
  3. Realizar uma demonstração do produto em algumas reuniões para que os fornecedores mostrasseem como o produto atenderá aos recursos necessários para os negócios
  4. Selecionando um vencedor

As respostas dos fornecedores à RFP foram recebidas depois de estarem em cotação por 4 semanas. As avaliações de respostas completas levaram menos de uma semana, incluindo as demonstrações em salas de reuniões dos três principais fornecedores.

Os demonstrativos nas sala de reuniões também levaram a uma troca dos primeiros fornecedores classificados em 1° e 2° lugares, eles geralmente ganhavam as cotações da empresa e eram melhor rankeados, mas muito do que era apresentado gerava desperdício, trazer transparência na contratação e uma RFP melhor desenhada fez com que eles estivessem fora desta vez, o que raramente acontece em aquisições tradicionais.

A implementação do produto levou ao todo três meses.

Nota: Enquanto alguns atrasos internos estenderam o cronograma geral de entrega para 12 meses, ele estava dentro do tempo esperado original, que também foi de 12 meses. Sem esses atrasos, teríamos terminado cerca de 4 meses antes

O gasto real com o software adquirido foi apenas cerca de 25% da expectativa original de despesas, pois apenas avaliamos as coisas que o cliente realmente precisava – o negócio gastou apenas R$ 25.000,00 dos R$ 100.000,00 originalmente alocados originalmente para o produto.

O processo de seleção de fornecedores também considerou a capacidade do fornecedor de ajudar com uma implantação incremental e usar práticas ágeis para desenvolver a integração necessária com outros sistemas corporativos dentro do escopo de negócio.

Usar práticas ágeis de aquisição significa estar disposto a repensar o próprio processo de aquisição, bem como a capacidade do fornecedor escolhido de oferecer suporte a práticas ágeis em suas implementações de produto.

Conclusões

Scrum, mapeamento de resultados e o Business Services Canvas, bem como outras práticas que introduzimos nos permitiram:

  • Perceber que o “projeto” era na verdade um programa e não um único projeto como se pensava inicialmente. Ao todo, foram seis iniciativas em quatro áreas principais de negócios
  • Orientar a equipe de negócios na definição de seus recursos de produto minimamente viáveis ​​para o produto de prateleira, que economizou 75% do orçamento original de R$ 100.000,000
  • Identificar e definir os novos serviços que eles precisavam para se destacar na área de P&D para satisfazer as quatro áreas de negócios.
  • Identificar, projetar e desenvolver todos os Processos de Negócios Minimamente Viáveis ​​necessários.
  • Identificar as novas funções podem alterar as funções existentes que seriam necessárias para dar suporte aos serviços novos e existentes com base nos novos processos das áreas de recursos

A aquisição em si levou menos tempo, custou consideravelmente menos que o planejado (apenas 25% do orçamento de R$ 100 mil), utilizou um processo de aquisição muito menos complexo e alcançou os resultados certos para o negócio.

O projeto foi concluído dentro do custo orçado global original, dentro do mesmo prazo esperado de 12 meses, afinal houveram atrasos internos, mas entregou processos de negócios, serviços e ferramentas adicionais recém-identificadas (com o dinheiro economizado na aquisição), nenhuma das quais foram identificados na definição e do escopo do projeto original e que deveriam ser entregues.

Vou dar maiores detalhes em novos artigos ainda nas próximas semanas, você já pensou em usar Scrum fora da TI? Comente!

Referências

  1. Produto comercial pronto pra uso ou COTS é o mesmo que um programa pronto de prateleira assim como o Microsoft Office por exemplo
  2. Benchmarking em gerenciamento de projetos
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

This site uses Akismet to reduce spam. Learn how your comment data is processed.