(Este conteúdo suplementar faz parte da metodologia TenStep Processo de Gerenciamento de Projetos®)

Visão Geral (5.0.P1)

Definição: O Escopo é a maneira como nós descrevemos os limites do projeto. Ele define aquilo que o projeto irá entregar e o que não irá entregar. Em projetos grandes, poderão ser incluídos as organizações, as transações afetadas, e os tipos de dados incluídos, etc.

Se você investigar as razões pelas quais os projetos fracassam, você verá que normalmente há dois problemas que surgem com mais freqüência;

• A equipe não investiu tempo suficiente definindo o projeto e/ou

• Houve uma falha no gerenciamento do Escopo.

Mesmo se o gerente do projeto desenvolveu um bom trabalho de definição do escopo, a parte mais difícil será de gerenciar o projeto dentro do escopo acordado.

Primeiramente - sem uma definição apropriada do escopo, você não terá qualquer possibilidade de gerenciar eficientemente o escopo. Lembramos que invocar o processo de gerenciamento de mudanças do escopo implica em uma mudança que está fora do escopo acordado no documento de "Definição do Projeto" e as exigências do negocio. Se o escopo for nebuloso, ou deixar margem à interpretação, o cliente poderá dizer que a mudança está dentro do escopo, e será difícil para o gerente do projeto invocar o processo de gerenciamento de mudanças do escopo.

Se o patrocinador (Sponsor) concordar em incluir o trabalho adicional no escopo do projeto, então o gerente do projeto terá o direito a esperar que o orçamento e os prazos finais correntes também sejam modificados (normalmente aumentados) para refletir este trabalho adicional. Estas novas estimativas sobre o custo, o esforço e a duração do projeto agora se transformam nas suas metas aprovadas.

Às vezes, o gerente do projeto pensa que o gerenciamento do escopo significa ter que dizer "não" ao cliente. Isto faz com que o gerente do projeto fique nervoso e sinta-se desconfortável.

Entretanto, a boa noticia é que o gerenciamento do escopo é totalmente sobre fazer com que o patrocinador tome as decisões que resultarão em mudanças do escopo do projeto.

Isto é muito importante. Poucos clientes podem prever e expressar todas as exigências no inicio do projeto. Conseqüentemente, geralmente há mudanças que necessitam ser introduzidas durante o ciclo de vida do projeto. Estas mudanças podem ser muito necessárias para a solução ou para o produto do projeto, e poderá haver razões válidas para que elas sejam incluídas. O gerente e a equipe do projeto devem reconhecer quando estas mudanças forem solicitadas. Então, os mesmos devem seguir um processo pré-definido de  gerenciamento das mudanças do escopo. Este processo fornece as informações apropriadas ao patrocinador (Sponsor) do projeto e permite que o mesmo decida se as modificações devem ser aprovadas baseadas no valor obtido e no impacto do projeto em termos de custo e cronograma.

Definir Tarefas - Visão Geral (1.0.P1)

Quantas vezes você escutou ou esteve envolvido em um projeto que falhou terrivelmente? Ou que talvez não tenha sido tão bem sucedido quanto deveria? Você alguma vez perdeu tempo olhando para trás para descobrir o que fez com que o projeto falhasse? Se você o fez, possivelmente você disse, "Você sabe, deveríamos gastar mais tempo planejando". A maioria dos projetos possui prazos, e parece que eles estão se tornando cada vez mais curtos.

Cumprir com prazos curtos pressiona o gerente de projetos a iniciar o projeto o mais rapidamente possível. Contudo, antes do início do trabalho do projeto, é necessário haver um tempo de planejamento anterior para garantir que o trabalho está   adequadamente   compreendido,  e   que   há   uma concordância sobre ele. Isto não é perda de tempo ou 'overhead'. Este é o tempo que o gerente de projeto gasta para garantir que a equipe de projeto e o cliente tenham a mesma idéia sobre o que o projeto irá oferecer, quando o mesmo será concluído, quanto custará, quem fará o trabalho e como o mesmo será realizado.

Ao final de um projeto difícil, os benefícios do planejamento serão óbvios. Mas, os benefícios também são conhecidos antecipadamente. Em um nível alto, os benefícios incluem:

• Entender e concordar a respeito dos objetivos, deliverables, Escopo, risco, custos, abordagem do projeto, etc. (Definição do Projeto).

• Determinar se o caso original do negócio (business case) ainda é válido. Quando o projeto foi aprovado inicialmente, o custo e a duração do projeto foram estimados provavelmente em nível elevado - talvez até +/- 50%. Agora que o projeto está começando, as estimativas devem ser reavaliadas para chegar mais perto de +/- 10%. Este refinamento adicional poderá resultar em estimativas muito acima das estimativas anteriores, e poderão fazer com que o caso do negócio (business case) não seja mais atraente. Por exemplo, um projeto que exige 10.000 horas de trabalho pode fazer sentido. Se o processo de planejamento mais detalhado resultar em uma estimativa mais refinada de 20.000 horas, o projeto poderá não fazer mais sentido.

• Certificar-se de que os recursos que necessários estarão disponíveis quando você necessitar deles.

• Uma linha de partida de alto-nível, a partir da qual o progresso possa ser comparado.

• Validar os processos utilizados no projeto antecipadamente com o cliente. 

Deveria fazer sentido que projetos pequenos necessitassem de um ciclo mais curto de planejamento, e que projetos maiores necessitassem de um ciclo de planejamento mais longo. O esforço necessário para planejar o projeto depende da quantidade de informações, e do nível de detalhes que deve ser entendido e documentado. A duração necessária para definir o trabalho depende do período de tempo necessário para descobrir e documentar a informação, bem como o tempo necessário para obter à concordância e a aprovação do cliente. Algumas vezes, o gerente do projeto pode se frustrar por causa das dificuldades para obtenção da concordância do cliente sobre o Escopo, o transcurso de tempo e os custos. Mas, esta é exatamente a razão porque este trabalho é feito antes. Pense nos problemas que você encontrará tentando obter a concordância do cliente sobre o Escopo, cronograma ou custos quando o trabalho tiver iniciado e os deliverables estiverem sendo realmente produzidos.

Antes do início do ciclo de vida do projeto (analises, design, construção, etc.), uma série de itens deve ser definido no processo de planejamento. Em projetos menores, muitas destas condições são atendidas de maneira informal ou implícita. Contudo, quanto maior for um projeto, mais importante é fazer com que estes critérios sejam formalmente e explicitamente atendidos.

• O cliente aprova o início do planejamento. Normalmente, a aprovação implícita é presumida de haver ocorrido até para fazer com que o projeto seja iniciado. Contudo, se o projeto não tiver um caso de negócios preparado e se não passar por um processo de priorização, a aprovação explícita deverá ser obtida antes do início do planejamento do projeto.

• O Projeto está definido. Isto é, documentado na Definição do Projeto, que contém objetivos, Escopo, hipóteses, deliverables, orçamento, etc. (Para projetos médios ou pequenos, isto pode ser a Definição Resumida do Projeto ou uma Solicitação de Serviço).

• O Workplan do Projeto é criado. Um workplan deve ser preparado e utilizado para gerenciar o esforço. Isto inclui pontos de verificação ou marcos, sempre que o projeto puder ser avaliado para assegurar a sua continuidade.

• O Cliente aprova o início do projeto. Isto significa uma Definição de Projeto assinada e aprovada. O patrocinador deve assinar o documento para garantir a concordância.

• Os Procedimentos de Gerenciamento do Projeto são definidos e aprovados – Os Procedimentos devem estar definidos para que se possa descrever como o projeto gerenciará Incidências, comunicação, riscos, qualidade, Escopo, etc. Isto é especialmente verdadeiro para grandes projetos, e menos importante quando um projeto se torna menor.

• Os recursos da equipe do projeto são designados – Você deve ter as pessoas certas para contratar e para executar o projeto. Algumas vezes, projetos válidos, aprovados necessitam ser atrasados porque as pessoas com as habilidades necessárias não estão disponíveis.

Antes de você entender como definir um projeto, você deve ter um claro entendimento do que é uma definição de projeto. Isto se tornará mais claro quando as técnicas de gerenciamento de um projeto forem apropriadas. Para uma visão geral, veja 1.2.01TS O que é um Projeto? Quando você tiver uma idéia do que é um projeto, você também poderá confirmar seu entendimento na função de um gerente de projeto em 9.1.01.1TS A Função do Gerente de Projeto.

Organização do Projeto - Funções e Responsabilidades (1.2.P5)

Em projetos pequenos, a organização é bastante simples - talvez apenas o gerente de projeto e o cliente / patrocinador. A pessoa que está gerenciando o projeto pode ser também a única pessoa que realmente trabalhe no projeto.

Entretanto, em projetos grandes, pode existir uma estrutura organizacional elaborada e formal. Você pode ter membros de equipe, um patrocinador executivo, um patrocinador de projeto, um gerente de clientes, um diretor de projeto, um comitê de direção, vendedores, clientes, e outros envolvidos. Você não deseja tornar as coisas demasiado complexas, mas quanto mais pessoas estiverem envolvidas no projeto, mais importante será que todos sejam esclarecidos com relação a suas funções e responsabilidades. Por exemplo, a última coisa que você deseja é ter pessoas lhe dando instruções como se fossem o patrocinador, quando realmente podem ser apenas grupos interessados de gerenciamento. Você também não quer pessoas agindo como membros da equipe quando na verdade as mesmas são stakeholders.

Um dos aspectos relativos à definição do projeto é a estrutura da organização e quais são as funções e as responsabilidades de todos os principais participantes. Geralmente, as funções e as responsabilidades características podem ser definidas antecipadamente para sua organização, e então reutilizados de acordo com cada projeto.

Estabelecer a Restrição Tripla (1.2.P7)

No final do processo da definição e do planejamento (nos passos 1 e 2 da metodologia TenStep) você deve ter um acordo com o seu patrocinador sobre o trabalho que será realizado e o custo (tempo) e a duração que serão necessários para concluir o trabalho. Estes três itens dão forma então a um conceito chamado "Restrição Tripla". O aspecto chave da restrição tripla é que se um dos três itens mudar, obrigatoriamente no mínimo mais um dos três itens necessitará ser mudado também. (A restrição tripla pode ser escrita de varias maneiras similares. O item custo também pode ser referido como esforço, que faz sentido se os custos de mão de obra forem todos internos e se não houver custos para os itens não relacionados diretamente com os custos de mão de obra. Às vezes, o item escopo é referido como qualidade, que focaliza então em entregar um determinado nível da qualidade com um custo e uma duração predeterminado. Estes aspectos são mais limitados da restrição tripla, mas os conceitos gerais continuam verídicos.)

Tente compreender as necessidades expressadas do seu cliente e as suas necessidades reais (1.2.P9)

A definição do projeto descreve o projeto em um nível elevado. A definição do projeto descreve especificamente as necessidades do cliente, também as estimativas fornecidas pela equipe do projeto sobre o esforço, duração e custo necessário para cumprir estas necessidades. Então, os detalhes das necessidades do cliente são definidas mais detalhadamente através do recolhimento de exigências do negócio.

É importante que o gerente e a equipe do projeto compreenda que as verdadeiras necessidades do cliente podem não ser as mesmas que lhe são expressadas e que estas são a fundação da definição do projeto e das exigências do negócio. Em muitos casos, o cliente não compreende suas necessidades verdadeiras quando o projeto começa. As necessidades verdadeiras podem às vezes evoluir sobre o curso do projeto. Do mesmo modo, o cliente pode ter uma visão desobstruída de suas necessidades, mas pode ter uma grande dificuldade para expressar as suas necessidades a equipe do projeto. Até certo ponto, esta é a finalidade do gerenciamento das mudanças do escopo – para permitir que o cliente mude as exigências do projeto quando o projeto estiver em andamento.

A equipe do projeto pode não fazer nada melhor do que documentar as necessidades expressadas do cliente e usar estas necessidades como base para obter a aprovação dos documentos Definição do Projeto e Exigências do Negócio. Entretanto, é também verídico que a equipe do projeto deve fazer um trabalho tão bom quanto possível para descobrir as necessidades reais do cliente. Isto envolve técnicas tais como fazer boas perguntas, e dar continuação com perguntas mais especificam, recolhendo as informações de todos os Stakeholders chaves e fazendo mais perguntas quando as exigências não parecerem fazer sentido, etc. Obviamente, a equipe do projeto deve fazer o que for necessário para tentar descobrir as verdadeiras necessidades do cliente. Quanto mais próximas forem as verdadeiras necessidades do cliente com as necessidades expressadas, mais próximo você estará de completar certo o projeto na primeira vez.

Criar um Cronograma de Curto Prazo para Guiar os Processos de Definição e de Planejamento (2.2.P9)

O processo de criação dos documentos "Termo de abertura do projeto" e do "Cronograma", poderá requerer um longo tempo e ser muito complicado. Então, este processo deve ser bem organizado. Após o gerente do projeto ser designado, ele deverá criar imediatamente um cronograma de curto prazo para planejar e gerenciar as atividades iniciais. Este Cronograma inicial, deverá abranger o tempo necessário para criar o documento "Termo de abertura do projeto" e o Cronograma do Projeto. Se este processo requerer duas semanas, o gerente do projeto deverá criar um Cronograma provisório que abranja no mínimo duas ou três semanas. Se o tempo necessário para criar o documento Termo de abertura do projeto e o Cronograma final for quatro semanas, este Cronograma inicial deverá abranger no mínimo quatro semanas, mas poderá fazer sentido criar um plano que abranja cinco ou seis semanas. Este Cronograma provisório, deverá abranger tudo nas atividades iniciais em termos de organização e planejamento do projeto, até que o Cronograma formal do projeto esteja completo para guiar o restante do projeto.

Definindo o Escopo - Visão Geral (5.1.1.P1)

Use Objetivos Elevados Como Ponto de Partida (5.1.1 P2)

Quando o projeto foi apresentado para fins de financiamento, deveria haver um grupo de objetivos e de entregas definido em um nível elevado. Também Poderia haver algum tipo de declaração do escopo em um nível elevado. Todas as informações criadas anteriormente devem ser usadas como um ponto de partida para definir as declarações mais detalhadas do escopo. Se você achar que não possui informações suficientes para criar um escopo abrangente e claro, você deve trabalhar com o patrocinador para coletar informações adicionais. Esta é uma das finalidades do processo de definição e planejamento.

Utilize os objetivos para ajudar a moldar as declarações do escopo. Por definição, deverá haver uma ou mais entregas criadas para realizar cada objetivo. A definição das entregas do projeto é um dos aspectos principais do escopo do projeto. Depois que você determinar quais serão as entregas principais que o projeto produzirá, comece a fazer outras perguntas para determinar outros aspectos do escopo. As entregas descrevem “o quê” o projeto entregará. Você também pode identificar “quais” organizações sofrerão o impacto, “que” tipo de dados serão necessários, “que” características e funções serão necessárias, etc.

Para maior clareza e contraste, você também poderá identificar condições que estão fora do escopo, descrevendo que entregas não serão criadas, quais as organizações que não serão impactadas, que características e funções não estão incluídas, etc. Naturalmente, há um número infinito de declarações fora do escopo. Para as finalidades de definição do escopo, você quer incluir somente aquelas declarações que lhe ajudam a definir os limites do projeto, e tocar naquelas áreas as quais o leitor possa ter perguntas. Por exemplo, se você tiver que instalar um software financeiro, você poderá declarar que um pacote de “Contas a Pagar” está dentro do escopo, mas que o Sistema de “Compras” relacionado ao mesmo está fora. Isto fará sentido desde que os processos de “Compras” e “Contas a pagar” sejam relacionadas entre si e poderá haver interrogações sobre o sistema de compras, se o mesmo está dentro ou fora do escopo. Mas você não deve listar todos os outros sistemas que estão fora do escopo – somente aqueles que os leitores poderão questionar.

Uma boa prática é documentar as organizações que estão dentro do escopo e aquelas relacionadas que estão fora do escopo. Os leitores poderão, então, determinar com maior facilidade se serão impactados, ou se ajudarão no projeto. Também, pode fazer sentido identificar quais as organizações que estão dentro do escopo, de modo que você possa ter pessoas daquelas organizações representadas na equipe do projeto - talvez em um comitê de direção.

Alinhando os Objetivos e o Escopo (5.1.1.P3) Quando você terminar de documentar os seus objetivos e as declarações do escopo, retorne e certifique-se de que eles estão todos alinhados. Você não deve ter nenhum objetivo referente as entregas que não esteja definido no escopo. Se o projeto não esta criando alguma coisa para satisfazer um objetivo, o projeto não poderá completar com sucesso o objetivo. Da mesma maneira, você não deve incluir entregas em seu projeto que não o ajudem a alcançar seus objetivos.  Se você propor-se de construir as entregas que não lhe ajudam a conseguir os objetivos do seu projeto, você deverá perguntar-se por que. Assim como os objetivos descrevem a finalidade do projeto, por que você construiria entregas que não lhe ajudarão a conseguir seus objetivos? Se os objetivos e as entregas na seção do escopo do projeto não são alinhados, você necessita determinar como alinhá-los. Se você tiver um objetivo sem uma entrega, você necessita validar se o objetivo realmente é importante. Se for, então você terá que adicionar ou modificar as entregas para satisfazer o objetivo. Se você tiver uma entrega sem um objetivo associado, então você terá que perguntar se a entrega realmente é importante. Se não for, remova-a do projeto. Se a entrega for realmente importante, você deverá trabalhar com o patrocinador para determinar o objetivo para criá-la.

Abordagem - Visão Geral (2.1.3.P1)

A abordagem do projeto é uma seção do documento "Definição do Projeto" ou "Termo de abertura do projeto" que descreve em palavras a idéia que ocorre na criação do Plano de Trabalho do Projeto (Workplan). Há dois benefícios para criar uma seção de abordagem:

• Primeiro, está informação auxiliará os clientes e as partes interessadas a entender como o produto será executado sem a necessidade de interpretar o plano de trabalho (Workplan).

• O segundo beneficio da abordagem do projeto é que ela permite que o gerente e a equipe do projeto criem um plano em um nível elevado para a execução do projeto e utilizar este plano para auxiliar na criação do Plano de Trabalho (Workplan) mais detalhado. As vezes, a equipe do projeto encontra dificuldade para construir um plano de trabalho (Workplan) lógico para completar o trabalho. Criar primeiramente uma abordagem em um nível elevado, fornecerá a equipe mais facilidade para criar um plano de trabalho (Workplan) mais detalhado.

Há várias maneiras de preparar esta seção. Normalmente, você inicia com o conteúdo geral sobre como a organização e o ambiente impactaram a execução do projeto. Então, você descreve cronologicamente as etapas principais para executar o projeto,  partindo de seu princípio, até chegar ao final. Claro que você não irá descrever os detalhes em um nível de atividade. O seu objetivo é permanecer no nível de Marcos, de estágios ou de fases.

As vezes é difícil iniciar a criação desta seção. Então, as informações seguintes lhe fornecerão maiores detalhes e exemplos das áreas que podem ser descritas. Você notará que a maior parte destas informações podem estar disponíveis em outros locais, mas é nesta seção que você irá reunir todas estas informações para beneficiar o leitor.

• Documente qualquer iniciativa ou estratégia da empresa que poderá impactar o projeto.

• Identifique quaisquer restrições de orçamento, empenho, tempo ou qualidade, e seus impactos no projeto.

• Documente qualquer padrão ou política da empresa que poderá impactar o projeto.

• Documente algumas melhores práticas da empresa ou da indústria que exercerão um efeito sobre o projeto.

• Descreva outras opções de abordagem e explique por que você não as escolheu. Também, documente porque você acha que a abordagem que você escolheu terá maiores chances de sucesso em relação às outras.

• Descreva como as entregas serão apoiadas e mantidas após o final do projeto. Também indique se a abordagem foi influenciada por implicações de suporte e de manutenção.

• Documente alguns outros projetos relacionados que já foram concluídos, que estão em andamento ou pendentes que influenciarão na abordagem deste projeto, e por quê.

• Descreva, em um nível elevado, como o projeto avançará do início até o final e as interdependências entre as fases e os estágios do projeto.

• Descreva qualquer técnica que possa ser de interesse do leitor. Por exemplo, se as exigências serão coletadas em uma sessão de Desenvolvimento de Aplicação Conjunto (JAD - Joint Application Development) dentro de três dias.

• Documente se serão utilizadas novas tecnologias ou processos, e por quê.

• Identifique qualquer exigência deferente relacionada aos recursos humanos, tais como consultores ou especialistas, e explique por que você necessita deles.

• Descreva qualquer utilização de serviços terceirizados, contratantes ou vendedores, principalmente se eles realizarão trabalhos importantes.

É claro, que estas são somente sugestões para criar a seção de abordagem. Você não necessita comentar sobre todos esses itens e poderá haver algumas sugestões que não são aplicáveis ao seu projeto. Lembre-se de que o objetivo desta seção de abordagem é para descrever os fatores e os impactos que eles exercerão sobre o plano de trabalho (Workplan) do projeto. Normalmente, esta seção é para beneficiar o leitor - o autor já conhece as informações. Há uma tendência para escrever esta seção de maneira breve e rápida e, em conseqüência disto fornecer um valor pequeno para o leitor. Se o autor for diligente e fornecer um bom contexto, esta seção poderá provar que pode fornecer informações muito valiosas para o leitor.

Análise dos Stakeholders - Visão Geral (1.2.5.P1)