O blog da tenstep tem sempre ótimos artigos sobre as diversas dimensões do gerenciamento de projetos, vejam este post abaixo que aborda algumas diretrizes de como lidar com aqueles “malas” que todo gestor de projetos tem de conviver. A grande mensagem é: não empurre o assunto com a barriga, essa é sempre a pior solução.

empregado difícil: o que fazer?

Ao tratar com um empregado difícil, primeiramente você deve analisar o desempenho do mesmo. Se o empregado faz parte de um projeto, a primeira pergunta que você deverá fazer é se o comportamento do mesmo está impactando o projeto nos termos de entregas ou de prazos finais.

Na perspectiva do projeto, a segunda pergunta deve ser se o comportamento do mesmo poderá causar problemas no futuro. Em caso afirmativo, então nós poderíamos considerar isso um risco para o projeto. De fato, o risco é o maior problema neste momento. Há um número de riscos para considerar neste caso, por exemplo:

- O risco de que esse comportamento conduzirá a falha nas datas de entrega das entregas do projeto.

- O risco de que esse comportamento alienará o restante da equipe e que a coesão e a moral da equipe sofrerão. Em conseqüência, isso poderá fazer com que o desempenho de toda a equipe sofra.

- O risco de que a falta da partilha do conhecimento terá um impacto sério no projeto se o empregado sair.

Se o gerente perceber que o empregado poderá transformar-se em um risco significativo, ele deverá tratar desta situação de maneira próativa. O melhor lugar para começar a tratar dessa situação é realizar uma discussão frente a frente com o empregado. Nessa discussão, o gerente discutir suas percepções do comportamento do empregado e porque esse comportamento causará (ou poderá causar) problemas no projeto. O gerente compreende os riscos que o comportamento introduz ao projeto e deve comunicar estes riscos ao empregado.

Um dos benefícios desta primeira reunião é que o gerente compartilhará as preocupações, e o empregado terá uma oportunidade de contar seu lado da história. Você nunca sabe como esta primeira discussão irá progredir. Às vezes é difícil e não resulta no esperado. Entretanto, às vezes a pessoa concorda com suas observações e explica o motivo de seu comportamento. Como gerente, se você souber as causas, você poderá ter alguma habilidade para ajudar a repará-los.

O empregado poderá estar com problemas particulares (que poderá ou não ser compartilhada). Poderá ser problema de personalidade entre o empregado e outros membros da equipe. Também, às vezes as pessoas acumulam a informação quando pensam que seu trabalho está em risco. Se você puder descobrir o motivo do problema, você terá a possibilidade de determinar uma resolução.

De fato, poderá haver um número de resoluções que o gerente e o empregado poderão considerar. Isso pode inclui o aperfeiçoamento das habilidades de comunicação e a interação com as pessoas, coaching, ou mudando o trabalho do empregado de maneira que permita que o mesmo possa ser bem-sucedido. A solução exata dependerá do resultado da reunião, do quanto o empregado está disposto a mudar e da flexibilidade do gerente.

A reunião deverá terminar com alguns compromissos concretos para tratar o problema. O gerente precisa sentir-se confortável que o empregado começará a interagir novamente com o restante da equipe. Igualmente, o gerente deverá receber algum comprometimento da parte do empregado, que o mesmo ensinará suas habilidades e técnicas a outras pessoas da equipe. Se não houver concordância sobre estes pontos, então a reunião não terá sido bem-sucedida e uma terceira pessoa (talvez o seu chefe, ou setor de RH) deverá ser envolvida para tentar solucionar o problema. Se o empregado concordar com um plano de ação de curto prazo, mas não segui-lo completamente, então o problema deverá ser escalado de acordo com as políticas da empresa.

Com a intensa expansão do uso do gerenciamento de projetos e portfólio, as empresas buscam nas ferramentas escala, e assim prover condições de trabalho aos seus gestores de projeto, ao mesmo tempo que coletam uma visão executiva da situação do portfólio. Apenas para ilustrar, 80% do tráfego vindo dos mecanismos de pesquisa para este blog contém “ferramenta” nos termos de busca.

Diante da enorme variedade de opções, avaliações criteriosas ajudam muito. Segue então, documento produzido pelo Gartner em junho deste ano, comparando as melhores soluções do mercado.

Gartner: Quadrante Mágico Projetos e Portfólio

Foote Partners

Pesquisa realizada recentemente pela Foote Partners com mais de 22mil especialistas, apontou as certificações mais procuradas no mercado americano de TI. Despontam aquelas ligadas a Arquitetura e Segurança. Também muito procuradas, as certificações de gestão mais quentes são ITIL e PMP. Uma novidade, de certa forma esperada, é a perda de valor das certificações de natureza mais técnica.

A CIO americana aborda a pesquisa:

As the economic crisis has deepened, good enterprise architects have become treasured assets. (…) says David Foote, president of Foote Partners. “One of the things you invest in during tough times is architects,” he says, “because if you want to save money, you have to architect carefully.”Certification plays well in areas that are grand in scope (and thus ill-defined), business-critical, and chock-full of complexity. Experience varies from enterprise architect to enterprise architect. Job histories on résumés can be exaggerated or even contain outright lies. Enterprise architecture certifications, on the other hand, “bring industrial strength” to the résumé and can be more easily confirmed, says Carole Schlocker, who runs iSpace, a technical staffing firm.

Enterprise architects are “abstract thinkers at the design level, almost like business analysts,” says Foote. They transcend technology and cross into the business realm. Indeed, many tech workers aspire to journey down this path, and a certification can show that they are making progress.

Hiring managers, too, want to see more than just technical chops from job candidates. “They’re looking for people who are good thinkers, have a feel for what goes on in other parts of the business, and understand how IT can be integrated,” says Jerry Luftman, vice president at the Society for Information Management.

Quem já foi gestor de um projeto de TI com alguma complexidade técnica, sabe o quanto um bom arquiteto faz diferença em todo o processo. A dificuldade é achar um, já que tem gente que depois de fazer um diagrama UML começa a se anunciar como arquiteto de software. A certificação certamente baliza a seleção, como dito.

Na questão da certificações PMP, vale destacar outro comentário:

The oft-ballyhooed PMP (Project Management Professional) certificate and its related certificates from the Project Management Institute (PMI), for instance, ride on the process-improvement wave. “When companies are hiring project managers, they like to see the PMI certification,” Schlocker says. “Often, the hiring manager is PMI-certified.”

Indicando uma certa fragilidade no selo do PMI. Alguém discorda?

O seu tempo é um recurso escasso e você deve gasta-lo com rigor no dia-a-dia. Excelente vídeo, muito inteligente! Vale cada um dos  35 minutos de duração.

Detalhes: nos primeiros segundos o som é baixinho mas fica normal rapidamente e é tudo em inglês. Tive contato com o material através do blog Efetividade.Net, abaixo parte do post e o video.

Uma palestra ministrada no Google, cujo aspecto central é o valor que damos (ou deveríamos dar) ao nosso tempo e à nossa atenção.

Conforme nossos processos mentais ficam mais importantes para o andamento e o resultado de nosso trabalho, nosso tempo e atenção tornam-se mais valiosos, e o custo de aceitar interrupções que não agregam valor cresce. E o pior: tempo e atenção são recursos individualmente finitos, e a busca por dar mais tempo e mais atenção a tudo que nos rodeia leva a um nível crescente de stress e a ansiedades que não podem ser satisfeitas, a não ser que repensemos nossa vida em níveis essenciais, reconhecendo que não temos tempo para tudo, e que precisamos dar atenção para aquilo que faz diferença positiva - não apenas para nossa atividade profissional, mas também para nossas vidas.

A apresentação dele, caprichosamente editada pelo Google, apresenta esta necessidade de renegociar (conosco mesmo e com os outros) os nossos compromissos, dando um jeito de controlar, restringir e reduzir quem tem acesso a estes recursos tão limitados e valiosos - reduzindo assim o stress e a ansiedade causada por ter de dedicar tempo e atenção a mais coisas do que é desejável.

E o mais interessante: além de apresentar alguns exemplos extremos, ele ainda indica uma série de exemplos de comportamentos que podem ajudar a atender a este objetivo.

Os padrões de gerenciamento de projetos lançados ao longo das últimas décadas têm sido uma grande contribuição para as mais variadas indústrias como TI, Engenharia Civil e Petroquímica. Mas uma coisa que sempre senti falta neste material foi um melhor esclarecimento das relações da gestão de projetos com os demais processos e modelos presentes na organização. Como, por exemplo, conciliar Escritório de Projetos e PMBok com as versões locais do ITIL, RUP, CMMi, COBIT e BSC da minha empresa? O que vemos na prática é um isolamento do gerenciamento de projetos destes frameworks, definindo-se apenas algumas entradas e saídas a serem trocadas.

Durante minha experiência, já vivi situações que mostram que essa estratégia nem sempre dá certo, além de prejudicar a percepção da relevância da gestão de projetos como um diferencial competitivo para a organização. Para exemplificar com um caso que considero emblemático, convido vocês a imaginar um cenário onde temos projetos e operações acontecendo simultaneamente sob um mesmo produto.

Tudo começa depois daquele árduo ano de trabalho para lançar o sistema Portas. Finalmente você consegue colocar a versão 1.0 em produção, faz a sua reunião de encerramento, todo o pessoal vai comemorar o fim do projeto na churrascaria e agora você pode partir para o próximo projeto, certo? No mundo da TI agente sabe que após o lançamento de um produto, os meses que seguem provavelmente serão de intenso trabalho. O que não vai faltar é demanda de evolução e correção para este sistema. Neste caso a empresa dificilmente vai abrir mão da sua experiência na condução dos processos particulares do projeto e na articulação dos interesses de clientes, equipe de desenvolvimento, pessoal da produção e fornecedores.

Vivendo neste novo momento, será que você ainda atua como um gerente de projetos ou agora deve ser chamado de gerente de operações? Você considera um projeto cada pequena demanda de 2 dias que chega para a equipe ou apenas aquelas que duram mais 1 mês? Me conta uma coisa, o pessoal de negócios ainda continua chamando tudo de Projeto Portas, não é mesmo?

Extrapolando a situação para toda a carteira de sistemas da sua organização, cada um vivendo momentos parecidos como este, qual a fronteira de atuação do Escritório de Projetos no posicionamento quinzenal para o CIO? Pensem nele entrando na sala do chefe com o relatório em mãos, vocês acham que o gerente fica satisfeito ao ver apenas o quadro de situação de parte dos empreendimentos em andamento? Imaginem o gerente sendo posicionado ou solicitado à priorizar um projeto de 6 semanas da versão 1.8 do sistema Portas, mas passando em branco pela equipe de cinco programadores alocados para tratar das demandas corretivas e pequenos ajustes que chegam diariamente para o sistema, ou sem saber que a fila do sistema Portas já chega a 15 demandas acumuladas.

No artigo “Hand in Hand”^1., Michael Thiry declara que gestão de Portfólio é basicamente um processo de alocação de orçamento. Seguindo esta linha de raciocínio, é fácil visualizar que quando o gerente da TI quiser entender como anda seu portfólio, com certeza vai querer enxergar como está distribuída toda a equipe e demais recursos críticos de que é responsável.

Quando soube do padrão de gerenciamento de portfólio do PMI (vejam o artigo introdutório sobre gerenciamento de portfólio de projetos) fui tomado pela expectativa que estaria lá a resposta para essa dificuldade. A publicação diz que as operações não podem ser descartadas quando tratamos de gerenciamento de portfólio, até prevê um componente chamado other work dentro do portfólio (figura 1) que, com uma certa criatividade, poderia ser interpretado como um caminho de se colocar operações e projetos lado a lado sob o mesmo guarda-chuva. Por outro lado quando o Padrão fala sobre o contexto organizacional do gerenciamento de portfólio, posiciona o gerenciamento de portfólio como um consumir de informações de um outro processo, de mesmo nível, chamado gerenciamento de alto nível das operações, vejam na figura 2.

Figura1: PMI, other work

figura2: PMI, contexto

Mas nem este ou outros padrões do PMI devem ser encarados como uma restrição na hora de definir a estratégia da sua organização. Voltando ao artigo de Michael Thiry, o autor defende que os objetivos estratégicos não são alcançados apenas com projetos, mas também por meio das operações; e que para ser efetivo, o gerenciamento de portfólio deve abarcar todas as atividades da empresa, não focando apenas em projetos. Não poderia concordar mais com o autor.

Isso não representa um desejo de unificação dos processos de gestão, precisamos ter cuidado em organizar bem as competências de cada processo e função neste arranjo. O gerenciamento de portfólio pode alinhar objetivos estratégicos com alocação de recursos, acompanhamento contínuo de performance e resultados, independente do componente ser um programa, projeto, sub-portfólio ou, como proposto aqui, uma operação. Entretanto, cada um destes componentes pode ser executados com o processo que lhe compete. É uma ingenuidade simplificar a gestão de um sistema em manutenção gerindo cada pequena demanda como um projeto independente na tentativa de aplicar um processo de gestão de projetos a todo esforço dentro da empresa. Manutenções de sistemas são operações e neste caso, a gestão recai sobre a sobre a fila de demandas e não em uma demanda individualmente. Quando falamos de um projeto, a maior preocupação é eliminar os riscos que podem afastar os resultados reais das expectativas das partes interessadas, quando falamos na sustentação de um sistema, a preocupação está em manter o níveis de serviço (não levar mais de 1 hora na correção de um bug), não acumular demandas no backlog, etc. Ou seja, cada tipo de componente pode ter seu processo especifico de gestão e mesmo assim serem todos alinhados e acompanhados num processo executivo de gerenciamento de portfólio.

É um assunto polêmico e quando começamos a vislumbra-lo na prática, mais considerações surgem em nossa mente, como, por exemplo, onde fica o Escritório de Projetos nesta história toda? De qualquer forma a provocação está no ar, vamos explorar mais este assunto nos próximos posts.

1. PMI, PM Network edição julho 2008 [↩]

Em 2006 o PMI lançou “O Padrão para Gerenciamento de Portfólio”^1., onde, numa centena de páginas, contextualiza o gerenciamento de portfólio de projetos e descreve sua proposta de processo para a atividade. Vou tentar passar para vocês neste post, uma visão geral do assunto.

O padrão define portfólio como uma coleção de projetos, programas e “outros trabalhos”^2.; cada portfólio, por sua vez, pode conter outros portfólios dentro dele. Estes sub-itens passam a ser chamados de “componentes” do portfólio. Veja um exemplo na figura 1.

Figura 1 - PMI: um portfólio e seus componentes

Gerenciamento de portfólio de projetos, ou simplesmente gerenciamento de portfólio, é o processo centralizado de gerir este conjunto de componentes de forma a promover os objetivos estratégicos da organização. “Estratégico” é uma palavra chave no gerenciamento de portfólio, ao contrário do gerenciamento de projetos e programas, em que os respectivos gerentes buscam eficiência, fazendo seu trabalho bem feito. O foco do gerenciamento de portfólio está na seleção, priorização, alinhamento, etc dos componentes, preocupando-se, desta forma, com a eficácia da organização, respondendo quais projetos e programas devem ser feitos.

Outra diferença essencial é que o gerenciamento de portfólio é uma atividades contínua; não tendo início, meio e fim, como acontece com projetos e programas.

Entendidos esses conceitos passamos para os processos propriamente ditos. O PMI organizou seu padrão em dois grupos de processos. O primeiro, chamado de Grupo de Processos de Alinhamento^3., orquestra a inclusão dos componentes ao portfólio, seguindo um ciclo que começa na identificação dos componentes; passa pela categorização, avaliação, seleção, priorização; até, finalmente, chegar na autorização formal de entrada do componente ao portfólio, com conseqüente alocação de recursos e início efetivo do programa ou projeto.

Figura 2 - PMI: Grupos de Processo

No segundo grupo, Grupo de Processos de Acompanhamento e Controle^4., temos as atividades relacionadas com o monitoramento contínuo dos componentes  e resposta à mudanças na estratégia da organização. Percebam que toda vez que acontecerem mudanças na estratégia da empresa, necessariamente nova rodada de alinhamento deve acontecer. Na figura 2 vocês podem um diagrama com os dois grupos e seus respectivos processos.

Complementando a descrição de cada um deles, e uma das minhas partes favoritas do livro, o apêndice D demonstra técnicas e ferramentas do gerenciamento de portfólio. Nesta seção encontramos coisas como métodos de priorização de projetos, exemplos de gráficos de acompanhamento, etc.

Como o Brasil já vem em um ritmo forte de implantação e melhoria contínua do gerenciamento de projetos desde o final da década de noventa, o novo padrão foi absorvido rapidamente pelos empresas de treinamento especializadas e empresas acostumadas com a aplicação do PMBOK^5.. Nos principais centros do país, além de treinamentos teóricos, você já encontra casos de aplicação real e bom material para análise. Palestras e eventos exclusivos sobre o tema pipocam por aí, como por exemplo, a Oficina de Gestão de Portfólio que vai acontecer no 3° Congresso Brasileiro de GP e o IPMAC 2008.

O que você provavelmente vai perceber lendo o livro ou durante o treinamento é que muitas destas atividades já são, de alguma forma, executadas na sua organização; talvez não com a sofisticação apresentada, mas pode ter certeza que se seu diretor quando ver um daqueles gráficos vai dizer que já sentiu falta daquilo.

Nesse contexto o padrão veio num momento muito bom. As empresa já tem alguma maturidade no gerenciamento de projetos e na prática do planejamento estratégico, pré-requisitos para implantar a gestão de portfólio. Entretanto, o texto ainda carece de maior profundidade, deixa várias lacunas em aberto e sua integração com os outros dois grandes padrões do PMI^6. é sutil.  Outro questionamento, este menos consensual, diria até polêmico, é o posicionamento em relação as operações da empresa. Sendo um processo estratégico, algumas pessoas questionam se o portfólio deveria ser apenas de projetos ou abraçar também o alinhamento e monitoramento dos resultados das operações, mas isso é tema para outro artigo.

Bom fim-de-semana à todos.

1. The Standard for Portfolio Management [↩]
2. Other work [↩]
3. Aliging Process Group [↩]
4. Monitoring & Controlling Process Group [↩]
5. A Guide to the Project Management Body of Knowledge [↩]
6. PMBOK e gerenciamento de programas [↩]

Em julho publiquei o artigo Ferramentas Livres para Cronograma, falando um pouco da minha experiência em três softwares desta categoria. Alguns dias atrás, pesquisando um pouco mais sobre o assunto, encontrei um ótimo artigo do Miguel Koren que, apesar de ter sido escrito em março de 2006, oferece análises e conclusões muito interessantes. O autor avalia 6 ferramentas livres para gestão de projetos, sendo 3 para desktop (Gantt Project, Planner e Real Time Project) e 3 web (dotProject, ProjectOPEN e Gforge). Ele foca na análise dos pontos fortes e fracos de cada sistema oferecendo um base para a escolha.

Gráfico de Gantt do ClockingIT

Lendo os dois artigos citados no parágrafo anterior, vocês percebem que o grande desafio destas soluções é conseguir conciliar todos os benefícios da centralização web com a agilidade que a interface desktop oferece. Essa semana, lendo a edição 45 da Linux Magazine, descobri alguém que deu um passo forte neste sentido: ClockingIT. O software traz avanços significativos na interface web apesar de, infelizmente, não acabar com a frustração de criarmos atividades preenchendo um formulário, ao invés de podermos digitar os dados direto numa planilha; mas já se consegue manipular vários atributos das tarefas direto na visualização Gantt^1.. Outro recurso bacana é a hospedagem gratuita dos seus projetos no servidor do ClockingIT, serviço bastante profissional. O código fonte pode ser baixado no wiki do projeto. Vale uma espiada, depois me contem o que vocês acharam.

Se pararmos de falar só de cronograma e formos para outras disciplinas, também pipocam soluções livre por aí para todo tipo de necessidade de gestão. Tem para finanças como o Buddi; podemos usar as “ferramentas de bug tracking”^2. como o Mantis para receber qualquer tipo de requisição de clientes ou distribuir tarefas dentro da empresa; você tem também o Twiki com um potencial e tanto para aumentar a produtividade da equipe na construção colaborativa de artefatos como especificações técnicas, planos, relatórios — quem for esperto põe até o cliente no processo de colaboração — e por aí vai.

Com toda essa diversidade, com o custo de hospedagem web saindo por menos de r$50,00 ao mês e com a maioria dos serviços oferecendo módulos de instalação rápida para uma série destas ferramentas livres^3., qualquer pequena ou média empresa consegue manter um parque de ferramentas de gestão operando com um custo mínimo.

1. Gráfico de Gantt: um gráfico usado na gerência de projetos para planejar e acompanhar o progresso do projeto. O tempo é indicado por colunas atravessadas no gráfico, com tarefas individuais representadas por flechas terminando em pontos. O tamanho e posições das flechas mostram a data de início e a duração das tarefas. Você também pode usar linhas sólidas ao invés de flechas terminando em pontos. Fonte: http://hsw.uol.com.br/ [↩]
2. Sistemas baseado em workflow desenvolvidos para agilizar o tratamento de erros encontrados durante o desenvolvimento e manutenção de um software [↩]
3. Vejam o Fantastico [↩]

Confesso que nutria um orgulho silencioso das minhas aventuras gastronômicas, descobrindo novos sanduíches nas esquinas mais inusitadas. Um dia agente paga por isso.  Eu paguei internado uma semana com muita febre e aguentando aquele clima de hospital. O pior momento é a Emergência, ninguém te olha no olho, tudo parece que é um favor enorme que estão te fazendo. Espera-se horas por coisas simples como um travesseiro.

Eles até que tentam, mas sem muito compromisso. De uns tempos para cá começou a circular uma moça sorridente perguntando se falta alguma coisa, normalmente elas se apresentam como do setor de qualidade. A princípio é uma boa idéia, mas basta insistir por algo fora do padrão, como um cobertor em menos de uma hora que o sorriso no rosto ou a dona dele somem rapidinho.

Lembrei das discussões que costumo provocar sobre o papel da garantia de qualidade nos processos como o de gestão de projetos. Defende-se que esta atividade não é mera auditoria para checar se todos estão produzindo os documentos conforme estabelecido. O papel do consultor de qualidade seria aumentar a produtividade das equipes apontando o melhor uso do processo, alertar sobre as armadilhas, carregar lições aprendidas entre projetos diferentes. Perfeito, mas se não houver determinação em garantir este perfil de atuação, uma força da gravidade leva estes profissionais para o “cara-crachá”, e lá estamos nós apenas checando se o processo foi seguindo ou não.

Há alguns anos trabalhei por período como consultor de qualidade em projetos de software, o modelo adotado na área foi muito interessante. Os consultores de qualidade eram necessariamente líderes de projeto que acumulavam as duas responsabilidades. Assim, nos ciclos de qualidade quando você avaliava o projeto do colega trazia sua experiência para a mesa. Discussões muito ricas surgiam quando um líder, por exemplo, explicava porque ele ou a equipe não fez essa ou aquela atividade do processo, era porque ela realmente não se aplicava a realidade deles. Outras vezes você demonstrava, baseado na vivência do seu projeto, que os riscos de não fazer aquilo que ele achava desnecessário eram altos demais e comprometia o líder da necessidade daquele artefato.

É claro que pode-se obter resultados posisitivos com modelos diferentes, a mensagem que fica é da responsabilidade do patrocinador da garantia da qualiadade de não transformar esta atividade numa figura sem credibilidade, em que as pessoas vão associar a necessidade de fazer um documentos que eles consideram inútil apenas para não tomar nota baixa.

A oferta de ferramenta livres para gestão de cronogramas tem aumentado muito nos últimos tempos. Apesar de ter baixado uma penca aqui na minha máquina, de 2007 para cá tive mais contato com GanttProject, OpenProj e DotProject.

A proposta geral do programa é positiva, mas tive sérios problemas com o Gantt. Ele não se entendeu bem com as dependências entre as atividades. Você altera a data de inicio ou de fim de uma atividade e a coisa não se refletia (ou refletia errado) nas demais, tanto nas datas quanto no gráfico. E para corrigir depois?! Também tive problemas no compartilhamento de arquivos entre membros da equipe. Já faz algum tempo que usei, acho de lá para cá novas versões devem ter sido liberadas. Vale conferir.

Na escolha deste tipo de ferramenta acho que o grande requisito é determinar se é mais importante para você ter uma base centralizada ou agilidade na elaboração dos cronogramas. Se informações integradas for decisivo o Dotproject é o caminho, é estável e tem várias funções que ajudam a gerenciar o que cada um está fazendo. O problema chega para quem está acustumado a fazer cronogramas em interface tipo planilha eletrônica, no DotProject você tem de preencher e submeter um formulário web para cada atividade.

No quesito agilidade para elaboração de cronograma, até o momento não vi nada mais completo que o OpenProjet, ele também tem várias funcionalidades legais como ver o cronograma no formato de EAP (infelizmente não deixar montar a EAP nesta tela) e para gestão da alocação e custos associados aos recursos. Empresas maiores perdem na consolidação de informações e no gerenciamento multi-projetos porque a solução, ao contrário do DotProject, é stand-alone.

Continuo procurando a ferramenta livre que vai conseguir juntar a base centralizada e interface de edição ágil. Quem conseguir vai dar muito trabalho por aí. Vamos aguardar.

E as suas sugestões de ferramentas?