Melhor resposta
A Histórico do projeto descreve o histórico organizacional no qual o projeto ocorre. Você deve tentar torná-lo compreensível para alguém que nada sabe sobre o negócio ou a tecnologia. Deve ser de alto nível, apenas algumas frases em cada elemento-chave. Por exemplo, quando eu era Chefe de Bibliotecas Digitais na Biblioteca Britânica, eu explicaria o que era a Biblioteca Britânica, por que ela tinha uma biblioteca digital, o que era o programa da biblioteca digital e que parte do sistema de biblioteca digital o projeto estava afetando. Depois de escrevê-lo para um projeto, você deve ser capaz de reutilizá-lo para qualquer outro projeto dentro do mesmo programa
A Definição do Problema descreve o problema que o projeto deve resolver. Ele deve descrever o problema em termos dos benefícios comerciais que você espera obter quando o projeto for concluído. Muitas pessoas entendem isso errado. Digamos, por exemplo, que seu projeto seja atualizar um grupo de servidores do Windows Server 2003 para 2016. Já vi muitas pessoas escreverem algo como: “O problema é que os servidores x, y e z estão executando o Windows Server 2003”. O fato de um servidor estar usando um sistema operacional obsoleto não é em si um problema. Você precisa se aprofundar no problema real de negócios que está sendo resolvido. Pode ser a segurança ou pode ser que você não possa cumprir seus SLAs porque o sistema de monitoramento não suporta 2003. Digamos que você inicie o projeto e descubra que um dos servidores não pode ser atualizado porque o software que ele executa é incompatível com 2016. Seu projeto agora é um fracasso. No entanto, o software será executado no Server 2010. Se você dissesse que o problema é sobre segurança, poderia apenas instalar o 2010 e o projeto ainda será um sucesso.
Se você olhar o que PRINCE2 e o gerenciamento bem-sucedido Os programas (MSP) falam sobre projetos – eles se referem à implementação de um recurso. Os objetivos do projeto devem ser sobre os recursos que você espera que estejam disponíveis até o final do projeto. Digamos, por exemplo, que você esteja desenvolvendo um site para uma empresa de reservas de viagens. Os objetivos seriam permitir que os usuários pesquisassem, reservassem e pagassem por viagens de trem, táxi, riquixá etc. etc.
O Justificativa do Projeto é o caso de negócios para o projeto. Só porque há um problema que precisa ser resolvido, não significa que a empresa deva gastar dinheiro resolvendo esse problema. Qualquer organização tem muito mais coisas que poderia fazer do que tempo ou dinheiro para realmente realizar. id = “f1fe275139”> A justificativa do projeto deve informar ao leitor qual é o retorno esperado do investimento para o projeto
O O escopo do projeto deve ser uma lista com marcadores do que o projeto fará e, mais importante, do que não fará. Por exemplo, o projeto vai entregar materiais de treinamento? O projeto recrutará a equipe que usará os resultados? O escopo do projeto é um país, uma região ou global?
Resposta
Histórico do projeto – Este é apenas o contexto, e não o projeto em si. Por exemplo, a empresa está crescendo e, portanto, contratando mais funcionários. Seu projeto é uma atualização tecnológica e aumento da capacidade do sistema de RH. Você não está proporcionando crescimento ou equipe. Você está entregando o novo sistema de RH.
Definição do problema: este não é um termo puro de gerenciamento de projetos. Eu diria que está relacionado com o fundo, porque pergunta qual é o problema que precisa de solução. Seu projeto pode não estar entregando a solução completa, então não pode consertar o problema subjacente. Por exemplo, sua atualização de RH não fará o crescimento correspondente no sistema de folha de pagamento.
Objetivos do projeto: O usual O termo é objetivos e existem dois tipos.
Objetivos de negócios: Isso pode incluir ser capaz de lidar com um crescimento de x\% na equipe. Você não vai entregar isso – você está apenas consertando o RH. Mesmo se o sistema de RH fosse o único que precisava de crescimento, o cliente tem que olhar para os processos de negócios, equipe de RH, etc, para poder tirar proveito do novo sistema que você entregar. É bom saber e declarar os objetivos do negócio, MAS NÃO estão ao seu alcance.
Objetivos do projeto: Esses são os resultados que seu projeto deve alcançar. Estão dentro do seu dom. Eles ainda são de alto nível, então não os confunda com resultados.
Justificativa do projeto: Novamente, isso é realmente parte do pano de fundo. Em grande medida, não é da sua conta! Se um cliente deseja um grande poste vermelho em seu escritório e está preparado para pagar por ele, isso é problema dele.Alguém, não o PM, mas geralmente um Analista de Negócios, precisa criar um caso de negócios para justificar o trabalho e obter a aprovação dos gastos pelos detentores de orçamentos. Normalmente, isso seria a) Se eu gastar X, ele retornará X + Y, ou b) se eu gastar X, evitamos ou mitigamos o custo de risco Y. Este não é o seu trabalho e já terá sido feito antes de você solicitado a definir e executar um projeto.
Escopo do projeto: O escopo do projeto está absolutamente no centro de seu domínio como PM. O escopo define, nos termos mais exatos possíveis, duas coisas: 1) O que o projeto fará? 2) O que o projeto NÃO fará? Seu projeto entregará um novo sistema de RH, mas (talvez), não entregará treinamento para a equipe de RH do cliente. Não vai entregar pessoal extra de RH. Provavelmente inclui o final do RH da integração da folha de pagamento, mas provavelmente não inclui mudanças na folha de pagamento. Etc. O escopo é mais bem definido de forma estruturada. Eu uso POLDAT
Processo de negócios, Organização, Localização, Dados, Aplicação, Tecnologia.
O que o seu projeto está mudando, ou não mudando, nesses domínios de mudança?
Estrague tudo e você está profundamente envolvido —-