OBJECTIVE |
CHAPTER |
---|---|
Domain 1.0 IT Project Initiation and Scope Definition |
|
This domain requires that the candidate possess the knowledge to: Identify stakeholder objectives for an IT project and prepare a high- level scope statement the correctly defines the work required to achieve those objectives. Define high-level business and technical requirements, outcomes , criteria for success, stakeholders low-level needs and expectations including boundaries for project budget, duration, and risk Identify the project roles of stakeholders including project manager, project sponsor, and project team members . Secure stakeholder/client consensus and obtain approval of the project charter and preliminary scope documents. |
|
1.1: Given a vague or poorly-worded customer request or business need, determine the appropriate course of action in order to handle various business-and project- related issues such as: Understand a business case scenario and create a proposal, and/or analyze an RFP and create a project proposal. |
2 |
Generate and refine a preliminary project concept definition or statement of work. |
2 |
Informally determine the business need and feasibility of the project. |
2 |
Identify project sponsors who will help obtain resources. |
2 |
Understand the concept of cost-benefit analysis to justify the project. |
2 |
Obtain formal approval by the project sponsor. |
2 |
Confirm management support. |
2 |
1.2: Given a set of criteria which outlines an enterprise s minimal requirements for a project charter, together with stakeholder input, synthesize a project charter Including: |
2 |
Project title and description. |
2 |
Project manager. |
2 |
Key roles and responsibilities. |
2 |
Project objectives and success criteria. |
2 |
High-level cost benefit analysis. |
2 |
OBJECTIVE |
CHAPTER |
Business case/ mission. |
2 |
Product/ deliverable description, performance criteria and enhancement opportunities. |
2 |
High-level risk assessment. |
2 |
Consensus building. |
2 |
1.3: Identify strategies for building consensus among project stakeholders. Select an appropriate course of action involving negotiation or interviewing strategies, meetings, memos, etc. |
2 |
1.4: Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organization resources as the project charter is refined and expanded. |
2 |
1.5: Given a scope definition scenario, demonstrate awareness of the need to secure written confirmation of customer expectations in the following areas: |
3 |
The background of the project (e.g., a problem/opportunity statement, strategic alignment with organizational goals and other initiatives, why the project is being initiated at this time, etc.). |
3 |
The deliverable from the project (i.e. what the product will look like, be able to do, who will use it, etc.). |
3 |
The strategy for creating the deliverable. |
3 |
Targeted completion date and rationale behind that date. |
3 |
Budget dollars available and basis upon which that budget was determined. |
3 |
Areas of risks which the project client is not willing to accept. |
3 |
The priority of this project as it relates to all the other projects being done within the organization. |
3 |
The sponsor of the project (i.e., who will provide direction and decisions). |
3 |
Any predetermined tools or resources. |
3 |
Assumptions that resources will be available as needed. |
3 |
1.6: Given a project initiation document (a project charter or contract), including a confirmed high-level scope definition and project justification, demonstrate the ability to identify and define the following elements: |
3, 5 |
The stakeholders, including the primary project client, the ultimate end users and any other impacted parties (internal or external to the organization), their roles and special needs. |
3 |
An all-inclusive set of requirements presented in specific, definitive terms which include: Differentiation of mandatory versus optional requirements; Success criteria upon which the deliverable will be measured; Completion criteria (for example: what needs to be delivered; such as a fully tested system or a system after being live for three months); Requirements that are excluded from the project. |
3 |
OBJECTIVE |
CHAPTER |
Targeted completion date including: Relative to a specific target date; Expressed as a 1) specific date i.e. mm/dd/yyyy; 2) range of dates; 3) specific quarter and year (3rd quarter, 2000); The consequences if that date is not met; A milestone chart including any phase reviews, if appropriate. |
3 |
Anticipated budget, including any or all of the following: Plus or minus tolerance; Contingency funds and/or any management reviews, if negotiated; The consequence if that budget is not met. |
5 |
Which of the above three criteria ” for example, technical performance (quality), completion date (schedule) or anticipated budget ” is the highest priority to the project client. |
3 |
All assumptions made relative to completion date, budget and priorities. |
3 |
1.7: Given a project initiation document (a project charter or contract), including the client s highest priority between quality, time, and budget, estimate any or all of the following: |
3 |
The potential impact of satisfying the client s highest priority at the expense of the other two. |
3 |
The impact of the project on business operations. |
3 |
Worse case scenario targeted completion date, budget, and quality-level. |
3 |
Your confidence level in the projected completion date, budget, and prospects for a high quality deliverable. |
3 |
1.8: Given a project charter or contract, including a statement of work (SOW), recognize and explain the need to investigate specific industry regulations requirements and contractual /legal considerations for their impact on the project scope definition and project plan. |
2 |
1.9: Given a proposed scope definition and based on the scope components , assess the feasibility of the project and the viability of a given project component against a pre-determined list of constraints, including: |
3, 6 |
A clearly defined project end date. |
3 |
A clearly defined set of monetary resources or allocation. |
3 |
A clearly defined set of product requirements based on a thorough decomposition of the system s hardware and software components. |
3 |
Clearly defined completion criteria. |
3 |
Clearly defined priorities. |
3 |
The relative priority of cost, schedule, and scope. |
3 |
Project ownership. |
3 |
Mandated tools, personnel, and other resources. |
3 |
The requirement that scope will change only per change control. |
3 |
Vendor terms and conditions. |
3 |
Company terms and conditions. |
3 |
OBJECTIVE |
CHAPTER |
A best practices life cycle for this type of project. |
3 |
Required reviews of deliverables by stakeholders and approvals by sponsors. |
3 |
RFP procedures, selection criteria, evaluation criteria and standards. |
6 |
1.10: Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organizational resources as the project scope statement is being developed. |
3 |
1.11: Given an incomplete project scope definition, complete or rewrite the definition to: 1) reflect all necessary scope components, or 2) explicitly state which is included in the project and which is not included. Necessary components include: |
3 |
Project size . |
3 |
Project cost. |
3 |
Projected schedule and window of opportunity. |
3 |
Stakeholders, their roles and authorities. |
3 |
The project manager s role and authority. |
3 |
Completion criteria. |
3 |
Methodologies to be followed. |
3 |
The scope change control process. |
3 |
Mandated tools, personnel, and other resources. |
3 |
Industry or government regulations that apply. |
3 |
1.12: Identify the following as possible elements of a final project scope definition and the circumstances in which they would be appropriate: A requirements change control process, including: how to request a change, how to analyze the impact of the change, and how to obtain approval for the additional funds and/or time to implement the change. |
3 |
1.13: Recognize and explain the need to build management buy-in and approval into the structure of the project, and describe strategies for doing so, including: |
2 |
Involving management in up-front definitions of project concept and charter. |
2 |
Involving management in defining and approving project scope. |
2 |
Involving management in reviewing and approving all key project deliverables as they evolve , providing a role for management as a spokesperson-advocate for the project, for team member participation, and for the deliverables. |
2 |
1.14: Recognize the need to obtain consensus of stakeholders and to obtain buy-in from the team to proceed to the planning stage of the project given a high level estimate of scope, schedule, budget, and resources. |
3 |
OBJECTIVE |
CHAPTER |
1.15: Recognize the need to conduct a review meeting as the project transitions from the initiation phase to the planning phase. The review would include an assessment of key items. |
2 |
Completion of the project initiation documentation. |
2 |
Viability of the business case. |
2 |
Achievement of the stakeholder consensus. |
2 |
Domain 2.0 Project Strategy Development and Preliminary Planning Objective |
|
This domain requires the knowledge and skills to: |
|
Define in adequate depth the project deliverable(s)/product(s) and associated requirements. |
|
Create a work breakdown structure (WBS). |
|
Identify a project strategy and life-cycle. |
|
Create a schedule. |
|
Create a list of required resources. |
|
Perform project cost estimation and create a budget. |
|
Perform risk analysis and create a risk management plan. |
|
Create a communication management plan. |
|
Create a quality management plan. |
|
Organize a comprehensive, detailed project plan. |
|
Validate stakeholder expectations. |
|
Establish change control over the project plan and develop procedures for updating and/or changing the plan. |
|
Close out the planning phase. |
|
2.1: Demonstrate knowledge of the typical IT Project life cycle and its application to IT projects, including: Phases (requirements, design, build/unit test, integration test, deploy) |
1 |
The reasons for the phases. |
1 |
The common deliverables from the phases. |
1 |
Target phase transition dates. |
1 |
2.2: Given an approved project charter, high level scope documents, and schedule/budget objectives, demonstrate the ability to create a project management plan that illustrates the following: |
7 |
Understanding of the roles of stakeholders, what reporting information each needs, and when it is needed. |
7 |
Understanding the risks incurred by not including key participants during the planning process. |
7 |
OBJECTIVE |
CHAPTER |
Knowledge of how to establish a project tracking mechanism. |
7 |
Awareness that a training plan may be necessary. |
7 |
Awareness that a procurement plan may be necessary. |
7 |
2.3: Demonstrate understanding of the following estimating concepts, techniques, and issues: |
5 |
The concept of bottom up cost estimates, their purpose, and the conditions under which they are necessary. |
5 |
Standard estimating techniques that can be used to solicit initial financial budget inputs based on mutually agreeable high level requirements. |
5 |
2.4: Given a team-building scenario, including a scope definition and work breakdown structure (WBS), identify selection criteria for particular team members. Demonstrate the ability to ask interview questions that will assist the team selection process. Assume project organization includes: |
6, 7 |
Business. |
6 |
Leadership. |
6 |
Administration. |
6 |
Technical. |
6 |
Stakeholders. |
6 |
2.5: Identify methods for resolving disagreements among team members when evaluating the suitability of deliverables at each point in their evolution. |
8 |
2.6: Given a project description/overview and a list of the project business and technical requirements, do the following: |
3 |
Decide if the project is defined well enough to achieve a measurable outcome and metrics for success. |
3 |
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. |
3 |
Distinguish any input provided which do not relate to the project at hand in order to achieve greater focus. |
3 |
Recognize whether the list of requirements is complete, accurate, and valid enough to move on to the planning step. |
3 |
Given a situation where the project outcomes are not possible to verify. |
3 |
Recognize the role which poorly detailed requirements, assumptions, and expectations play. |
3 |
Identify the high level value of the project to sponsors and users of the outcome. |
3 |
Describe the role of project value and its importance to individual and team effectiveness. |
3 |
OBJECTIVE |
CHAPTER |
2.7: Describe the goals of a useful project 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, 3 |
2.8: Given the client s approved project requirements and the input of stakeholders, decompose these requirements into business, functional and technical requirements while maintaining trace ability within strict configuration control. |
2, 3 |
2.9: Given a project planning scenario, demonstrate an understanding of and the ability to develop a phase-oriented WBS with high detail for an early phase and with low detail for later phases by: |
3 |
Identifying elements (phases) likely to require iterative planning. |
3 |
Explicitly deciding to provide for iteration in the project plan (e.g., scope approval, plan approval, project design, final deliverable turnover , etc.). |
3 |
2.10: Given a scenario involving tasks , resources (fixed or variable), and dependencies for a multi-phase IT project, demonstrate knowledge of the standards for creating a workable WBS by: |
3 |
Recognizing and explaining the need to creatively visualize all deliverables (interim and finished). |
3 |
Thoroughly decomposing the system into all potential hardware and software components. |
3 |
2.11: Recognize and explain the need to obtain: |
3 |
Consensus among all stakeholders regarding project deliverables and other elements of the WBS. |
3 |
Formal approval (sign-off) of project sponsor(s) regarding project deliverables and other elements of the WBS. |
3 |
2.12: Given a project scenario with many phases and activities: |
4, 5 |
Set realistic, measurable milestones. |
4 |
Demonstrate understanding that measurable targets are required in order to determine if the project is proceeding on time and within budget. |
5 |
2.13: Given a set of specific milestones and their descriptions, specify entry and exit criteria for each. |
4 |
2.14: Demonstrate the ability to create an activity cost estimate Given: |
5 |
An activity scope of work. |
5 |
Required resources. |
5 |
Level of effort. |
5 |
Resource availability. |
5 |
Resource rate. |
5 |
OBJECTIVE |
CHAPTER |
2.15: Demonstrate the ability to create an activity time estimate (in units of time) given: |
4, 5 |
An activity scope of work. |
4 |
Required resources. |
4 |
Level of effort. |
5 |
Resource availability. |
4 |
2.16: Recognize and explain the difference between a project cost estimate, effort estimate, and time estimate. |
5 |
2.17: Identify and list the components needed to generate a workable project schedule. Demonstrate the ability to create appropriate project schedules, which meet the approved project start and finish dates, given the following information: |
4 |
A detailed list of project deliverables (both interim and finished). |
4 |
A detailed estimate of project tasks. |
4 |
A list of activities and phases. |
4 |
A detailed estimate of the time and resources required to complete all project tasks. |
4 |
Information about the preferences of the project team regarding schedule formats. |
4 |
2.18: Given a scenario with necessary project documents, and given enterprise holiday and individual resource calendars, demonstrate the ability to develop a project schedule by doing the following: |
4 |
Define and sequence project tasks, activities, and phases which are needed to bring about the completion of given interim or finished project deliverables. |
4 |
Estimate durations for project tasks, activities, and phases. |
4 |
Estimate work effort for project tasks and assignments. |
4 |
Specify resources required for the completion of each phase. |
4 |
Identification of the project critical path . |
4 |
2.19: Demonstrate the ability to identify project team organization roles and responsibilities required for the execution of the project including: |
6 |
The role of the customer (sponsor) of the project as it relates to the project manager s role. |
6 |
The major skills required in the project team. |
6 |
The type of team structure; e.g., part-time matrix, full-time matrix. |
6 |
Confirm the roll of the project manager including any of the following: Responsibilities, accountabilities; Authority; formal and informal; Percentage of time available to this project; Performance appraisal process relative to this project. |
6 |
OBJECTIVE |
CHAPTER |
2.20: Demonstrate the ability to assign resources to the schedule by: |
5 |
Creating a list of resources needed and their availabilities. |
5 |
Assigning responsibilities to tasks. |
5 |
2.21: Given a project scope, timeline, cost, project team, and dependencies, demonstrate the ability to: |
5 |
Create and manage a high level (top down) budget based on assumptions/ estimates. |
5 |
Identify and budget the level, cost, and duration of resources and dependencies (internal and external). |
5 |
Create and manage a detailed bottom up budget, containing actual/ scheduled expenses. |
5 |
Identify, implement, and budget all project trade-offs, while understanding the implications, and impacts of the trade-offs. |
5 |
Install and maintain systems for tracking budgetary expenses against the plan based on the existing enterprise systems. |
5 |
Align the budget with the spending plan of the organization. |
5 |
2.22: Demonstrate an understanding of the components of a project quality management plan (e.g., measured quality checkpoints, assignments for architectural control, systems test, and unit tests, user sign-off, etc.). |
6 |
2.23: Demonstrate the skills to develop a quality plan that assures: |
6 |
Awareness of the need to develop a test plan and defect tracking procedure which ensures that appropriate testing steps and defect resolution and documentation steps occur during the project life cycle. |
6 |
A configuration management exists that ensures: Phase deliverables are reviewed and inspected for completion, defects are removed, and issues are resolved prior to acceptance; Documented sufficiency criteria exist for the exiting of each phase; A change control process exists for all technical environments; A requirements management process exists; Formal customer acceptance and sign-off is obtained at appropriate points. |
6 |
2.24: Demonstrate the ability to perform risk assessment and mitigation (given a scenario including the appropriate project documentation): |
6 |
Identify and prioritize the most important risks that will impact the project. |
6 |
Evaluate the severity of the risks to successful completion of the project. |
6 |
Identify risks contained on a project s critical path and identify procedures to reduce potential impacts on schedule. |
6 |
2.25: Demonstrate the ability to create a project communication plan that clearly indicates what needs to be communicated during a project, to whom, when, and how (using formal, informal approaches). |
6 |
OBJECTIVE |
CHAPTER |
2.26: Identify the components/documents of an adequate project plan and explain the function of each. Components include: |
7 |
Table of contents. |
7 |
Overview/Executive summary. |
7 |
Sponsors. |
7 |
Team members. |
7 |
Requirements. |
7 |
Scheduled tasks (WBS). |
7 |
Expected resources. |
7 |
Environmental issues. |
7 |
Business and technical requirements. |
7 |
Implementation plans. |
7 |
Support plans. |
7 |
Training plans. |
7 |
Document (plan) location and revision control. |
7 |
2.27: Identify the steps involved in organizing a comprehensive project plan and using it to close out the planning phase of a project, including: Assembling all project planning elements (estimates of deliverables, time, costs, etc.). |
7 |
Create an outline or table of contents for the comprehensive project plan. |
7 |
Review the outline of the comprehensive project plan with sponsor and key stakeholders, obtaining feedback and concurrence, and revising as needed. |
7 |
Writing the comprehensive project plan by integrating all planning elements according to the outline and creating a full document with transitions, introductions , graphics, exhibits, appendices, etc., as appropriate. |
7 |
Circulating the comprehensive project plan to all stakeholders. |
7 |
Obtaining top management support of the comprehensive project plan by making certain it reflects their concerns and that they have had an opportunity to provide input. |
7 |
Conducting a formal review of the comprehensive project plan in which stakeholders have an opportunity to provide feedback. |
7 |
Adjusting the comprehensive project plan based on stakeholder feedback. |
7 |
Obtaining formal approval (sign-off) of the comprehensive project plan by sponsor(s). |
7 |
2.28: Demonstrate knowledge of how to set performance baselines for: |
7 |
Project scope and deliverable performance requirements. |
7 |
Schedule. |
7 |
OBJECTIVE |
CHAPTER |
Budget. |
7 |
Resources. |
7 |
2.29: Demonstrate knowledge of the need to create change management procedures for the project plan. |
7 |
2.30: Be able to identify project performance indicators that will be used to monitor and control performance during execution. |
7 |
2.31: Be able to secure staffing commitments and resolve staffing issues. |
6 |
2.32: Recognize the need to conduct a review meeting as the project transitions from the planning phase to the execution/control/coordination phase. The review would include an assessment of the following: |
7 |
Completion of the project planning documentation. |
7 |
Resolution of all planning issues. |
7 |
Continued viability of the business case. |
7 |
Alignment of stakeholder expectations with the plan. |
7 |
Domain 3.0 IT Project Execution, Control, and Coordination |
|
This domain requires the candidate to demonstrate knowledge and skills in: |
|
Project monitoring, tracking and performance reporting. |
|
Interpreting project performance indicators and identifying variances from plan. |
|
Taking corrective action. |
|
Updating the plan and re-planning by project phase. |
|
Issue tracking and issue resolution. |
|
Risk tracking and risk removal/mitigation. |
|
Change control. |
|
Quality management. |
|
Team management, coordination and communication. |
|
Resource management. |
|
3.1: Identify the following as tasks that should be accomplished on a weekly basis in the course of tracking an up and running project. Explain the rationale for performing these tasks and explain how to adapt these tasks to different situations such as: |
8, 9 |
Check the project s scope status to determine in scope versus out of scope status of project elements. |
8 |
Check the evolution and status of project deliverables. |
8 |
Check the project schedule. |
8 |
OBJECTIVE |
CHAPTER |
Analyze variances (deviations from plan) by comparing estimated to actual resource time expenditures, dollar expenditures, milestones and elapsed duration of activities. |
9 |
Handle scope changes if needed. |
9 |
List, track, and try to resolve open issues. |
8 |
Report project status. |
8 |
Look for opportunities to and "push" for close out of activities and sign-off of deliverables. |
8 |
Decide whether it is appropriate to continue the project. Discontinue the project if appropriate. |
9 |
3.2: Given a scenario with set project performance indicators, demonstrate the ability to recognize when performance problems are occurring on the project and determine if/when corrective action/recovery needs to occur. |
9 |
3.3: Given a scenario with updates/changes made to the project plan demonstrate the need to check for impact On: |
9 |
The project critical path/schedule/WBS. |
9 |
Project performance indicators. |
9 |
Resource availability. |
9 |
Budget. |
9 |
Risks. |
9 |
Project objectives. |
9 |
3.4: Given a scenario involving a project with a schedule delay, choose an appropriate course of action. |
9 |
3.5: Given an approved project and a status report scenario containing a significant variance from plan (e.g., excessive overtime, purchased items more expensive than anticipated, etc.), do the following: |
9 |
Clearly identify the reasons for the variance. |
9 |
Determine the impact on schedule and budget and the effect on stakeholders. |
9 |
Determine if scope creep is occurring. |
9 |
Identify options for corrective action. |
9 |
Identify options for absorbing part or all of the increase in the overall budget (if any). |
9 |
Identify stakeholders who must be notified or must give approval to a change of schedule or budget and develop a plan for advising them of the change, the rationale for the change, and the consequences if not approved. |
9 |
OBJECTIVE |
CHAPTER |
3.6: Given a scenario in which a vendor requests a two-week delay in delivering its product, explain how to do the following: |
8 |
Negotiate a lesser delay by identifying things the vendor might do to improve its schedule. |
8 |
Clearly identify the impact of the negotiated delivery on the project scope and critical path. |
|
Present this impact to the appropriate stakeholders. |
8 |
3.7: Given a scenario in which there is a disagreement between a vendor and your project team, identify methods for resolving the problem. |
8 |
3.8: Identify issues to consider when trying to rebuild active project support from a wavering executive (e.g., the need to identify the source of doubts , interpersonal communications skills that might be employed, the need to act without creating negative impact, the need to identify and utilize various allies and influences, etc.). Given a scenario involving a wavering executive, choose an appropriate course of action. |
8 |
3.9: Identify issues to consider when trying to obtain approval of a changed project plan that is still within expected budget, but has a schedule that extends outside of the original baseline end date. |
9 |
3.10: Define and explain Estimate to Complete (ETC), Estimate at Complete (EAC), and Budget at Complete (BAC). |
9 |
3.11: Demonstrate the ability to track the financial performance of a project, given the financial management baseline and data on the actual performance of the project. Demonstrate: |
|
The need to identify and understand proposed changes from plan. |
8 |
The need to be able to justify and sell the changes. |
9 |
The need for alternative courses of action if the plan isn t accepted. |
9 |
3.12: Given an approved project plan and a specific scope deviation (for example: design change, schedule or cost change, etc.), demonstrate your ability to: |
9 |
Identify the cause(s). |
9 |
Prepare a status report for the user identifying problems and corrective action. |
9 |
Determine the impact of the deviation on the scope of the project. |
9 |
Quantify the deviation in terms of time, cost, and resource. |
9 |
Distinguish between variances which will affect the budget and duration and those that will not. |
9 |
Determine and quantify at least one possible alternative solution that has less impact but requires some scope compromise. |
9 |
OBJECTIVE |
CHAPTER |
Distinguish between variances that should be elevated to the sponsor and those that should be handled by the project manager and team. |
9 |
Develop a plan to gain stakeholder approval. |
9 |
Use a change order. |
9 |
3.13: Identify and justify the following conditions for initiating a change control process: |
9 |
Resource chances . |
9 |
Schedule changes. |
9 |
Cost changes. |
9 |
Requirements changes (or changes in expectations). |
9 |
Infrastructure changes. |
9 |
As a response to scope creep. |
9 |
3.14: Given scenarios involving requests for changes from sponsors, team members, or third parties, recognize and explain how to prevent scope creep. |
9 |
3.15: Recognize and explain the importance of communicating significant proposed changes in project scope, and their impacts to management, and getting management review and formal approval. |
9 |
3.16: Identify and explain strategies and requirements for maintaining qualified deliverables, given a large project with many team members at multiple locations (e.g., communication standards, work standards, etc.). |
9 |
3.17: Recognize and explain the importance of testing in situations where tasks are being performed both by project team members and by third parties. |
9 |
3.18: Identify and explain strategies and requirements for assuring quality during the turnover phase (e.g., user docs, user training, helpdesk training, support structure, etc.) |
9 |
3.19: Identify and explain strategies and requirements for assuring quality of deliverables and meeting sufficiency standards during each phase. |
9 |
3.20: Recognize the need and explain the importance of controlling changes on the configuration of the project deliverable. |
9 |
3.21: Recognize the relevance of the organization s Quality Policy to project quality. |
6 |
3.22: Identify effective strategies for providing timely performance feedback to team members. |
8 |
3.23: Demonstrate an understanding of how to effectively manage disgruntled team members so that team performance is not adversely affected. |
9 |
OBJECTIVE |
CHAPTER |
3.24: Demonstrate an understanding of how to recognize individual team member performance issues and to identify effective strategies for corrective action. |
9 |
3.25: Given an initial high level scope, budget, and resource allocation, demonstrate understanding of the need to investigate the aspects of the project that could be modified to improve outcomes (i.e., find out what is negotiable, prepare to negotiate). Provide evidence of the following competencies: |
8, 9 |
Recognize that individual project team member s needs must be addressed to the extent that project activities can be modified without significant impact on final scope, budget, quality, or schedule. |
8 |
The ability to evaluate alternatives to a scope change request that stakeholders may find acceptable. |
9 |
The ability to recognize which aspects (schedule, budget, quality) of the project are most important to the stakeholders and be able to propose trade-offs during the project that can be made to meet or exceed those aspects. |
9 |
The ability to identify all of the individuals and groups with which you will need to negotiate during the life if the project (sponsors, vendors , users, internal and external service organizations, other project teams , project team members, finance/accounting, etc.) |
8, 9 |
3.26: Given a project scenario, demonstrate the ability to resolve a resource availability (staffing) issue requiring escalation to the project sponsor and senior level stakeholders. |
8 |
3.27: Given a project scenario during the implementation phases, demonstrate the understanding of the need to organize and effectively run meetings. |
8 |
3.28: Given a project team meeting scenario in which a decision must be made with imperfect information, demonstrate the knowledge of problem solving techniques to help the team through a decision making process. |
8 |
3.29: Given a project team meeting scenario, demonstrate the awareness of the need to provide direction and clarify work instructions to team members. |
8 |
3.30: Given a project team meeting scenario under a situation whereby the project is behind plan, demonstrate the awareness of the need to: |
8 |
Identify an accountable team member. |
8 |
Clarify the root cause of the problem causing the delay. |
8 |
Develop a strategy for corrective action. |
8 |
Implement the corrective action strategy. |
8 |
OBJECTIVE |
CHAPTER |
Follow up to check on results. |
8 |
3.31: Given a project scenario in which intra-team communication is inadequate, demonstrate the ability to improve communication to an appropriate level. |
8 |
3.32: Given a project team meeting scenario, demonstrate the knowledge to review an issue log with team members and secure closure of issues. |
8 |
3.33: Demonstrate the ability to prioritize issues by severity and impact on quality. |
8 |
3.34: Demonstrate understanding of how to determine if/when planned risks have materialized and how to implement planned risk mitigation and removal strategies. |
8 |
3.35: Demonstrate the ability to prioritize risks by severity and impact on quality. |
9 |
3.36: Demonstrate the ability to remove/mitigate a project risk. |
6 |
3.37: Demonstrate an understanding of how to report to the project sponsor that a project is in jeopardy and how to report corrective action strategies that are underway. |
8 |
3.38: Demonstrate understanding of how to determine when a project should be prematurely terminated . |
9 |
3.39: Recognize potential organizational and political barriers inhibiting an effective working relationship between the IT organization and the client/ business organization. |
8 |
3.40: Demonstrate an understanding of the following methods to develop and maintain an effective working relationship during projects between the IT organization and the client/ business organization: |
8 |
Frequent communication. |
8 |
Team building. |
8 |
Managing by fact. |
8 |
Issue management and problem solving. |
8 |
Timely decision making. |
8 |
Importance of written communication. |
8 |
Gaining consensus. |
8 |
Managing expectations. |
8 |
OBJECTIVE |
CHAPTER |
Domain 4.0 Project Closure, Acceptance and Support |
|
4.1: Recognize and explain the value of conducting a comprehensive review process that identifies the lessons learned and evaluates the planning, organizing, directing, controlling, execution, and budget phases of the project, identifying both the positive and negative aspects in a written report. |
10 |
4.2: Recognize the need to plan to transfer the project deliverable to support and maintenance and to budget for these resources including help desk. |
10 |
4.3: Recognize the need for acceptance testing (user acceptance testing, factory acceptance testing, site acceptance testing) of the project deliverable. |
9 |
4.4: Recognize the need to obtain formal customer sign-off of the project deliverable and hand-off to the customer, including: |
10 |
Close out meeting with customer/sign-off to statement of work. |
10 |
Begin support/maintenance. |
10 |
Change control to additional scope. |
10 |
Formally turn over deliverable to the customer. |
10 |
4.5: Recognize the need to complete project documentation, secure approvals, and archive/store appropriately. |
10 |
4.6: Recognize the need to close out contracts and sign-off for vendors. |
10 |
IT Project+ Study Guide
Assessment Test
Answers to Assessment Test