■ 2.7 Given a project description/overview and a list of the project requirements, do the following:
o Decide if the project is defined well enough to achieve a measurable outcome and metrics for success o Determine if the requirements include the necessary range of inputs (assumptions, expectations, technical issues, industry issues, etc.) in order to validate the input given and gaps related to scope o Distinguish any input provided which do not relate to the project at hand in order to achieve greater focus o Recognize whether the list of requirements is complete, accurate, and valid enough to move on to the planning step o Given a situation where the project outcomes are not possible to verify o Recognize the role poorly detailed requirements, assumptions, expectations play o Identify the high level value of the project to sponsor and users of the outcome o Describe the role of project value and its importance to individual and team effectiveness.
■ 2.8 Describe the goals of a useful program requirements review with the client
(e.g., verify mutual understanding of client ' s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.
■ 2.9 Given the client ' s approved project requirements and the input of stakeholders, decompose these requirements into business and functional requirements while maintaining traceability within strict configuration control.
■ 2.10 Demonstrate the ability to perform risk assessment and mitigation by doing the following given a scenario including the appropriate project documentation:
o Identify and prioritize the most important risks that will impact the project o Evaluate the severity of the risks to successful completion of the project o Identify risks contained on a project' s critical path and identify procedures to reduce potential impacts on schedule Project management generally involves requirements analysis, but the need for accurate requirements gathering is especially critical in the IT world. If you only think you understand what your users want and you create something without really understanding their requirements, then you ' re likely to create something they either won' t like or won't use or both. In this chapter, I talk about the project, program, functional, and business requirements associated with what you' re trying to do. We ' l l also spend some time on a very key and many-faceted topic: risk assessment.
Was this article helpful?