terça-feira, 25 de junho de 2019

Permissionamento & Direitos Efetivos no Project Online

Olá pessoal –

Do ponto de vista de segurança, é muito comum que as empresas limitem algumas permissões dos usuários que utilizam o Project Online para gerenciar os seus projetos. Um dos principais objetivos de restringir algumas permissões está associado à governança e conformidade, pois deve-se evitar que os usuários, por desconhecimento ou de maneira deliberada, executem algumas ações que não fazem parte da sua rotina de trabalho com a plataforma PPM.

Um exemplo clássico é a exclusão de projetos: por padrão, o Project Online permite que os gerentes de projeto possam excluir os projetos dos quais forem proprietários. Para evitar que esse tipo de ação seja tomada, muitas empresas decidem remover a permissão dos gerentes de projeto, deixando esta ação a cargo de administradores ou super-users (normalmente, membros do PMO com maiores privilégios na plataforma).

No Project Online, caso a sua empresa esteja utilizando o modo de permissão Project Server, os grupos de segurança irão possuir três possíveis opções de permissionamento: 1) Permitir, 2) Negar e 3) Não permitir. Permitir significa que as permissões foram concedidas ao grupo, de modo que seus membros poderão executar as ações associadas à permissão; Negar significa que, de maneira explícita, qualquer ação associada à permissão está proibida; a opção Não permitir acontece quando uma permissão não está concedida e nem negada explicitamente.

As configurações de segurança em vigor na sua empresa devem ser estudadas e bem planejadas para que os usuários possam ter acesso a todas funcionalidades inerentes ao seu trabalho, ao mesmo tempo que estejam dentro dos padrões de segurança, conformidade e governança estabelecidos. Recentemente tive uma experiência interessante com um cliente, a qual gostaria de compartilhar nesse post.

Havia um grupo de usuários que eram Administradores do Project Online, ao mesmo tempo em que também estavam inseridos no grupo Gerentes de Projeto. Uma das regras de negócio em vigor na organização determinava que os gerentes de projeto não poderiam salvar as Linhas de Base, uma vez que esta ação seria uma responsabilidade do time de PMO. Para aplicar tal configuração, a permissão ‘Salvar Linha de Base Protegida’ foi negada para o grupo gerentes de projeto. Pois bem, o que aconteceu em seguida foi que qualquer usuário que fizesse a tentativa de salvar uma Linha de Base seria impedido, mesmo que fosse membro do grupo de Administradores, os quais possuíam a permissão. Mas, então, qual a razão para este comportamento?

O que aconteceu nesse caso está relacionado à natureza da opção de negar explicitamente uma permissão: caso uma permissão seja explicitamente negada, ela irá se sobrepor à permissão Permitir, independentemente de o usuário possuir a permissão em outro grupo. Por este motivo, a utilização da opção Negar é recomendada apenas em cenários muito específicos, quando como desejamos limitar as permissões de usuários externos que possuem acesso ao ambiente da nossa organização.

Ok, mas o que os direitos efetivos tem a ver com isso?

Os direitos efetivos são uma excelente ferramenta para que seja possível entender as permissões que foram concedidas ou negadas a um determinado usuário. Pegando o gancho no caso anterior: você acabou de assumir a administração do Project Online em uma determinada empresa, e alguns usuários estão reportando que não possuem as devidas permissões para executar suas atividades. Você não tem o histórico do ambiente, e não sabe quais configurações e parametrizações de segurança foram feitas... então, como é possível descobrir a causa-raiz do problema?

Para isso, você pode navegar à página de Configurações do PWA e então clicar em Gerenciar Usuários. Em seguida, selecione o usuário que está reportando o problema e clique em Verifique os Direitos Efetivos:


Você poderá então navegar entre as permissões globais e os diferentes tipos de objeto de segurança (projetos, recursos e modos de exibição) para entender as permissões concedidas e negadas para o usuário, assim como o contexto na qual elas acontecem. Perceba que, neste exemplo, o usuário Arthur Mamede está com a permissão ‘Gerenciar Check-Ins’ negada no contexto do grupo de segurança Gerentes de projeto:


Alterando o tipo de permissão para o contexto dos projetos, é possível identificar que o mesmo usuário está com a permissão ‘Salvar Linha de Base Protegida’ para o projeto ‘Bay Plaza’, no contexto do grupo de segurança Gerentes de projeto:



Utilizando os direitos efetivos para identificar as restrições existentes irá ajudá-lo a entender o contexto das configurações de segurança em vigor na sua organização, de modo que você poderá elaborar um plano de reestruturação para sua melhor adequação às necessidades e parâmetros de segurança, conformidade e governança.

Por hoje, vou ficando por aqui. Espero que o post seja útil!

Um forte abraço!

terça-feira, 18 de junho de 2019

Erro ao excluir PDPs: Exception from HRESULT: 0X810200D0

Olá pessoal –

Outro dia um cliente me enviou uma mensagem dizendo que estava tendo problemas ao tentar excluir uma Página de Detalhes de Projeto (PDP) no Project Online. Ao tentar realizar o procedimento, o seguinte erro era apresentado: Exception from HRESULT: 0x810200D0


Infelizmente, a mensagem de erro não é muito clara, não oferecendo indicações do que pode eventualmente estar causando o problema. Porém, a resolução é mais fácil do que se imagina 😊

Uma PDP não pode ser excluída caso esteja sendo utilizada em algum estágio em um workflow no Project Online. No meu caso especificamente, ao navegar à área Estágios do Fluxo de Trabalho, pude verificar que a PDP que o meu cliente estava tentando excluir estava configurada para ser exibida em dois estágios do fluxo, e por este motivo havia o bloqueio do Project Online quando se tentava sua remoção:


Assim, foi só remover a PDP dos estágios em questão e a exclusão foi então efetivada sem problemas!

Um forte abraço!


sexta-feira, 31 de maio de 2019

Importando calendários locais para o Project Online

Olá pessoal –

Muitas empresas que decidem adotar o Project Online como plataforma unificada para gerenciamento de projetos, programas e portfólios já possuem um histórico de gerenciamento de projetos, que é na maioria das vezes realizado através da gestão dos cronogramas nas máquinas dos gerentes de projeto – onde os cronogramas são normalmente salvos localmente ou em um drive de rede compartilhado.

Com base nesse cenário, é muito comum que os gerentes de projeto possuam calendários personalizados que representem as datas de exceção em vigor na organização, como feriados, pontes, folgas, férias e etc. (inclusive, o tema calendários é bem recorrente aqui no blog). O problema é que esses calendários estão associados aos cronogramas locais, e não fazem parte das configurações padrão do Project Online – e assim, criá-los na plataforma PPM geraria um esforço considerável, a depender do número de calendários que devam ser replicados.

Eu mesmo passei por essa experiência recentemente: uma empresa de grande porte aqui no Brasil estava iniciando a adoção do Project Online, e seus funcionários estavam espalhados por todo o território nacional (assim como seus projetos). Nesse sentido, um dos principais requisitos a serem atendidos pelo Project Online determinava que os recursos deveriam estar associados a calendários locais, os quais iriam refletir as particularidades da cidade/município onde o funcionário está situado. A estratégia de adoção foi simples: o calendário Padrão, nativo do Project Online, deveria ser configurado para refletir apenas os feriados a nível nacional, sem considerar pontes ou emendas. Então, calendários locais de cada cidade deveriam ser criados na plataforma PPM, de modo que cada projeto e cada recurso fossem configurados individualmente.

Como sabíamos que os calendários locais já haviam sido configurados na máquina de alguns GPs, a questão foi: como importar os calendários para o Project Online, para que não houvesse a necessidade de criar cada um dos calendários do zero?

E é aí que a mágina acontece!

Como administrador do Project Online, abra o Project Desktop que contém o calendário que deseja importar, e garanta que você esteja conectado ao seu ambiente. Clique em Alterar Período Útil, e selecione o calendário que deseja importar. Em seguida, clique na opção Adicionar Calendário à Empresa...


Defina um nome para o calendário e então clique OK:


Assim, o novo calendário será incorporado ao Project Online e poderá ser utilizado pelos usuários:


Uma configuração simples, mas muito útil! 👌

Um abraço e até o próximo post!

quarta-feira, 22 de maio de 2019

Importando cronogramas para o Project Online

Olá pessoal –

Uma situação muito comum nas empresas que implantam o Project Online como plataforma de PPM para suportar seu processo de gerenciamento de projetos é a necessidade de importar para o ambiente seus cronogramas em execução, que na maioria das vezes estão sendo gerenciados individualmente no Project Professional. Com base nessa necessidade, este post irá explorar o ‘Assistente de Importação, recurso que pode ajudar os gerentes de projeto no processo de importação de seus cronogramas para o Project Online.

Após conectar o Project Professional ao Project Online você poderá salvar o seu cronograma local na plataforma PPM. Para isso clique em Arquivo > Salvar como, selecionando a opção Usar Assistente de Importação:


O assistente de importação é um guia que irá prestar auxílio na identificação e resolução de eventuais problemas e inconsistências existentes no cronograma, em virtude da necessidade de padronização deste em relação às configurações realizadas no Project Online. Essas inconsistências podem acontecer em razão de divergência nos nomes dos recursos, utilização no cronograma de calendários locais desconhecidos pelo Project Online, mapeamento de campos personalizados, entre outros.

Etapa 1: mapeamento de recursos

Ao optar pela utilização do assistente de importação, um Wizard contendo 5 etapas será exibido na barra lateral esquerda do Microsoft Project. A etapa 1 consiste em mapear os recursos locais para que seja possível associá-los a recursos corporativos, quando aplicável:


Veja o exemplo abaixo... a maior parte dos recursos locais existentes no cronograma foi mapeada automaticamente para o recurso da empresa correspondente (considerando que os recursos corporativos tenham sido cadastrados previamente no Project Online). O mapeamento automático acontece porque a plataforma verifica os nomes dos recursos locais e então efetua a comparação com os recursos da empresa: caso os nomes sejam idênticos, a sugestão de mapeamento é apresentada; caso o assistente de importação não encontre o nome correspondente dentro da lista de recursos corporativos, os recursos serão mantidos como locais até que se opte por efetuar o mapeamento manual:


Assim, para os recursos locais que não encontrarem um correspondente no diretório de recursos corporativos, você poderá realizar o mapeamento manual (especialmente caso algum recurso local possua o nome diferente em comparação à relação existente no diretório de recursos corporativos):


Uma vez resolvidos os conflitos e mapementos, continue para a etapa 2.

Etapa 2: importar recursos

Após resolver os problemas de mapeamento dos recursos locais, convertendo-os em recursos corporativos (quando aplicável), você deverá determinar quais recursos locais devem ser adicionados ao Project Online. Recursos locais são aqueles que não existem no diretório de recursos da empresa, ou seja, não são recursos corporativos de fato mas precisam ser mantidos no cronograma. Particularmente, não sou favorável à utilização de recursos locais no Project Online, e sempre procuro orientar meus clientes a não utilizar esta abordagem (este será assunto para outro post). Entretando, entendo que existem situações que requerem a aplicação desta abordagem e, como se trata de uma situação suportada pela plataforma, vamos considerá-la no post.

Perceba que na etapa 2 o assistente de importação irá validar se existem erros associados à importação de recursos locais – como calendários específicos associados a esses recursos:


Não havendo erros na validação da importação dos recursos locais, continue para a etapa 3.

Etapa 3: mapeamento de campos personalizados

Caso seu cronograma possua campos personalizados associados às tarefas que tenham de ser mapeados à campos personalizados criados pela sua empresa no Project Online, este será o momento de efetuar o mapeamento:


Uma vez realizada a ação, você poderá avançar à etapa 4.

Etapa 4: confirmar e validar erros nas tarefas

Na etapa 4 o assistente de importação tentará encontrar possíveis erros e inconsistências nas tarefas do cronograma. Por exemplo, seu cronograma pode conter um calendário personalizado associado a uma tarefa que não é válido no contexto do Project Online, conforme exemplo abaixo (onde a tarefa possui um calendário chamado ‘Weekend’):


Se este for o caso, você poderá utilizar a coluna Calendário da tarefa para realizar os ajustes e atribuir os calendários disponíveis no seu ambiente à tarefa:


Etapa 5: salvar o cronograma no project online

Após finalizar todas as etapas de validação e correções, você poderá salvar o cronograma no Project Online clicando em Salvar:


A caixa de diálogo Salvar no Project Web App será aberta, e você poderá então preencher as informações do projeto conforme o processo em vigor na organização:


Durante o processo de salvamento, o assistente de importação poderá validar mais uma vez os recursos locais, comparando-os aos recursos corporativos e sugerindo sua substituição. Nos casos aplicáveis, clique Sim (ou Sim para tudo):


É importante perceber que os recursos locais que não forem mapeados como recursos corporativos continuarão disponíveis no cronograma, com suas respectivas tarefas:


Por fim, você deverá publicar o projeto para compartilhar suas informações com os demais interessados. Neste momento, a depender das configurações do ambiente, você poderá criar um site para o projeto (por se tratar da primeira publicação):



ações complementares

Após publicar o seu cronograma no Project Online, você terá de executar algumas ações adicionais que irão complementar o trabalho. Por padrão, quando um projeto é importado para o Project Online através do assistente de importação do Microsoft Project, ele é associado ao tipo de projeto padrão. A depender dos tipos de projeto utilizados na sua empresa, será necessário que você converse com um administrador do Project Online para que ele o ajude a alterar o tipo de projeto, de modo a associá-lo à categoria adequada.

Quando isso acontecer, a depender da configuração do ciclo de vida dos projeto em vigor na organização, você poderá ser solicitado a mover o projeto ao longo das fases e estágios associados ao tipo de projeto escolhido:



Certifique-se de conversar com a equipe de PMO, com os administradores do Project Online ou então com os responsáveis pela plataforma na sua organização para entender melhor o ciclo de vida que os projetos devem seguir.



segunda-feira, 13 de maio de 2019

Criando relatórios para o Project Roadmap - parte 2


Olá pessoal –

Esta é a parte 2 da série de posts sobre a criação de relatórios utilizando dados do Project Roadmap. Se você ainda não leu a primeira parte, volte lá pois é importante.

Bem, agora que nós já sabemos como estabelecer uma conexão com o CDS, como configurar as permissões adequadas para termos direito a obter os dados, e quais as tabelas que armazenam as informações do Roadmap, vamos entender um pouco melhor a estrutura das tabelas mais importantes para criarmos nosso primeiro relatório.

A primeira tabela que iremos analisar no contexto atual é a tabela msdyn_roadmap. Como seu próprio nome sugere, esta tabela armazena dados gerais dos roadmaps criados na organização. Dentre as várias colunas existentes na tabela, as mais relevantes (e que iremos utilizar para construir o nosso relatório) são:

Nome da coluna
Detalhes
msdyn_name
O nome do roadmap ou dos itens (linhas) criados para cada roadmap
msdyn_roadmapip
O código único identificador do roadmap ou item (chave primária)
msdyn_type
O tipo de dado (0 = Roadmap | 1 = RoadmapRow)
msdyn_type_display
O nome por extenso do tipo de dado



Ao analisar a estrutura desta tabela, é interessante notar que, por mais que seu nome seja msdyn_roadmap, ela não armazena apenas informações dos roadmaps criados... a tabela também é responsável por armazenar as linhas (rows) criadas para cada roadmap. Para evitar qualquer confusão e criar uma estrutura de dados que mantenha uma organização mais lógica, eu prefiro segmentar a tabela para que ela exiba apenas informações a nível dos roadmaps, sem incluir as linhas. Assim, apliquei um filtro na coluna msdyn_type para que apenas sejam selecionados dados onde o valor seja igual a 0 (zero):



O passo seguinte foi duplicar a tabela msdyn_roadmap e criar uma nova tabela chamada msdyn_roadmaprow, a qual será responsável por incluir apenas dados onde o valor da coluna msdyn_type seja igual a 1 (um), ou seja, as linhas (rows) de cada roadmap:




Após duplicar a tabela e alterar o filtro, uma ação complementar foi realizada: a coluna msdyn_parentroadmapid foi adicionada à tabela. A inclusão desta coluna é muito importante e deve ser feita na tabela duplicada, uma vez que cada uma das linhas (rows) estará conectada a seu respectivo roadmap. Em outras palavras, cada linha é um filho do roadmap (pai).

Após realizar as alterações, vamos dar uma pausa para estabelecer um relacionamento entre as duas colunas, de modo a compreender melhor como será a sua comunicação:




A imagem acima deixa as coisas mais claras: para cada roadmap existente, podem haver múltiplas linhas (rows) criadas. Faz sentido pra você?

Então vamos lá...

O próximo passo será organizar as informações disponíveis na tabela msdyn_roadmapitem. Esta tabela tem como finalidade apresentar todas as tarefas e marcos cadastrados em cada uma das linhas existentes nos roadmaps. Está ficando complicado? Dê uma olhada na imagem abaixo, que tenta demonstrar cada um dos elementos disponíves em um roadmap:




Então, vamos em frente!

Da tabela msdyn_roadmapitem vamos precisar das seguintes colunas:


 Nome da coluna
Detalhes
msdyn_duedate
A data de vencimento do item
msdyn_name
O nome do item
msdyn_roadmapid
O id do roadmap ao qual o item está relacionado
msdyn_startdate
A data de início do item
msdyn_status_display
O status do item, conforme definido no Roadmap
msdyn_type_display
O tipo de item (fase ou data key date)




O passo seguinte será estabelecer um relacionamento um-para-muitos entre a coluna msdyn_roadmapid da tabela msdyn_roadmaprow e a coluna msdyn_roadmapid da tabela msdyn_roadmapitem, pois para cada linha de um roadmap podem haver múltiplos itens:



Agora está ficando legal. Se voltarmos para a área de relatórios do Power BI, será possível criar uma visão inicial de um relatório, usando informações dos roadmaps, das linhas e dos itens:




Porém... (já reparou que sempre há um porém?), temos um pequeno problema: o Project Roadmap permite que key dates sejam criados sem que necessariamente estejam associados às linhas. Estes são key dates que pertencem ao roadmap de maneira geral, não estando vinculados às linhas existentes. Quando isso acontece, por não estarem associados à nenhuma das linhas, os key dates do roadmap acabam ficando órfãos no relatório – é essencialmente o que está acontecendo com os quatro primeiros itens da visão acima.

Na imagem abaixo, é possível visualizar os key dates do roadmap:




Para resolver o problema, vamos tomar as seguintes ações:

1) Duplicar a tabela msdyn_roadmapitem, criando uma nova tabela chamada msdyn_roadmapkeydates
2) Aplicar um filtro na nova tabela para que os dados da coluna msdyn_type_display seja apenas do tipo KeyDate
3) Remover a coluna msdyn_duedate da tabela



Por fim, deve ser criado um novo relacionamento do tipo um-para-muitos entre a coluna msdyn_roadmapid da tabela msdyn_roadmap e a coluna msdyn_roadmapid da tabela msdyn_roadmapkeydates:



Uma vez realizados os ajustes e configurações necessárias em cada uma das tabelas principais, com seus respectivos filtros e relacionamentos, você poderá começar a montar o seu dashboard. Aqui um exemplo visual de possíveis resultados que podemos obter:




Próximos passos

Além das configurações sugeridas neste post, você também pode utilizar as tabelas adicionais (msdyn_roadmapitemlink, msdyn_roadmapRowLink e msdyn_roadmapusersetting) para estabelecer conexões entre os dados dos roadmaps e os projetos existentes no seu ambiente do Project Online. Neste cenário, além de exibir informações relacionadas aos roadmaps, você também poderia exibir informações gerais dos projetos e das tarefas dos cronogramas, de modo a criar uma visão muito mais abrangente do relacionamento existente entre os projetos e tarefas com os roadmaps.

Vou ficando por aqui, e espero que você tenha gostado do post!

Um forte abraço.