Plano de Projeto...

Qual é o plano ? ....Relaxa que eu tenho um plano!!

Fiz uma busca rápida no Google e encontrei um artigo interessante, 
e mais um post interessante que transcrevo (ctrl+c, ctrl+v) abaixo: 

O que deveria conter um Plano de Projeto Ágil?

Postado por Shane Hastie , traduzido por Lucas Souza em 01 Jun 2010 08:24 AM

O que faz um plano de projeto ser "bom o suficiente"? Projetos ágeis tem uma forte ênfase nas pessoas sobre os processos e a comunicação verbal sobre a comunicação via papel. Em contraste, muitas metodologias formalizadas exigem documentos muito complicados em relação a contratação/inicialização que tem ser completados a fim de ganhar credibilidade e aprovação para proseguir com o trabalho.
Com este possível conflito, o que deveria conter um plano de projeto ágil - quanta documentação é "suficiente" para responder as principais questões e qual o formato estas informações deveriam ser apresentadas?
Um número razoável de pessoas tentaram responder estas questões:
Michael Lant em um post entitulado “How to make your project not suck” define que muitos projetos começam sem uma afirmação clara do que sucesso se parece.  Ele afirma "Nenhuma indústria, a nenhuma empresa grande ou pequena, seja ela governamental, sem fins lucrativos, que estão começando ou grandes multi nacionais parecem ser imunes a esta gafe. Seja claro, nem todos os projetos sofrem com isso, mas é notávelmente comum. A definição clara de que ele fala é um plano de projeto bem profissional -

Grandes projetos parecem ser melhores neste ponto - possivelmente porque eles tendem a ter mais recursos de gerenciamento. Pequenos projetos, entretanto, tendem a ignorar os planos do projeto, e se eles criam um plano, é raramente seguido. Particularmente, e por uma variedade de motivos, projetos de menor porte, muitas vezes tomam atalhos, e um plano de projeto é frequentemente uma das primeiras coisas a serem deixadas.

Ele fornece algumas conselhos ao preparar um plano:

Separar todas as informações legais e outras extras que são comumente encontradas em um plano. Estas coisas são certamente importantes para o sucesso do projeto, mas geralmente não para as pessoas executarem, então coloque estas informações em um documento separado. Agora crie um plano de projeto que não é mais que uma página, cujo propósito é unicamente prestar uma definição clara e concisa do que o sucesso significa para esse projeto. O plano do projeto é o documento mais importante que você vai criar, e é essencial que todos os interessados participem da sua criação. Ele define as intenções, alinha as partes interessadas e fornece definições sobre o que seria o sucesso do projeto.

Embora ele seja uma única página, pode ser um trabalho desafiador criar um documento eficaz de verdade. Para criá-lo leva-se algumas horas, e mesmo em projetos pequenos, podemos levar um dia inteiro. Seu conteúdo deve ser definido em um consenso entre as partes interessadas. Este tempo é bem gasto, e pode salvar dias ou semanas de intermináveis revisões para realinhar o projeto.

Um plano de projeto usual, contém três elementos principais:

1.  Visão: A visão define o "Por Que" do projeto. Este é o principal propósito, ou a razão para existência do projeto.
2.  Missão: Este é o "O que" do projeto e ele define o que será feito para que o projeto alcance seu objetivo.
3.  Critério de Sucesso: O critério de sucesso são os testes de gerenciamento que descrevem efeitos fora da solução em si.

Em seu post ele fornece um exemplo de plano, e aconselha o uso de planos para ajustar a direção do projeto e mantê-lo focado. Martin Proulx fornece um exemplo de um plano de projeto ágil no blog Analytical Mind.
Outra ferramenta que é frequentemente usada como parte do plano do projeto são os Success Sliders. Debbie Schatz escreveu um artico descrevendo esta ferramenta na revista Mortgage Banking - ele está disponível no CCPace website.
Os Sliders são ajustados para indicar a relativa importância das várias "dimensões" do projeto, e fornecem um guia para quando as decisões potencialmente conflitantes acontecerem. Rob Thomsett descreve a ferramenta em detalhes em seu livro Radical Project Management.
Ryan Martens discute o valor de uma página A3 report. A A3 é uma técnica usada na Toyota para destacar a essência de um problema, e mostrar que ele pode caber em uma única folha de papel. Ele cita o artigo de John Shook no MIT Sloan Management Review

1. Estabelecer o contexto de negócio e a importância de um problema específico
2. Descrever as atuais condições do problema
3. Identificar o resultado desejado
4. Analisar a situação para estabelecer causalidade
5. Propor medidas defensivas
6. Prescrever um plano de ação para conseguir o feito
7. Mapear processos de follow-up”

Allan Kelly fornece um modelo para um A3 report.
Enquanto o A3 report descrito por Shook não contém todos os elementos do plano de projeto, a técnica fornece uma ferramenta simples que visa concentrar o foco de toda a equipa em uma declaração clara de qual é o problema a ser resolvido e que a solução que precisa entregar.