av Veda Vyas Sista 8 år siden
136
Mer som dette
5 Organizational process assets updates
Organizational process assets that may be updated include, but are not limited to: • Causes of variances, • Corrective action chosen and the reasons, and • Other types of lessons learned from project scope control.
Project documents that may be updated include, but are not limited to: • Requirements documentation, and • Requirements traceability matrix.
3 Project management plan updates
Project management plan updates may include, but are not limited to: • Scope Baseline updates. If the approved change requests have an effect on the project scope, then the scope statement, the WBS, and the WBS dictionary are revised and reissued to reflect the approved changes through Perform Integrated Change Control process. • other Baseline updates. If the approved change requests have an effect on the project besides the project scope, then the corresponding cost baseline and schedule baselines are revised and reissued to reflect the approved changes.
1 Work performance information
1 Variance analysis
Variance analysis is a technique for determining the cause and degree of difference between the baseline and actual performance. Project performance measurements are used to assess the magnitude of variation from the original scope baseline. Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline (Section 5.4.3.1) and deciding whether corrective or preventive action is required.
4 Work performance data
3 Requirements traceability matrix
1 Project management plan
4 Project documents updates
3 Work performance information
Work performance information includes information about project progress, such as which deliverables have started, their progress, which deliverables have finished, or which have been accepted. Work performance information produced includes correlated and contextualized information on how the project scope is performing compared to the scope baseline. It can include the categories of the changes received, the identified scope variances and their causes, how they impact schedule or cost, and the forecast of the future scope performance. This information provides a foundation for making scope decisions.
2 Change requests
The completed deliverables that have not been formally accepted are documented, along with the reasons for nonacceptance of those deliverables. Those deliverables may require a change request for defect repair. The change requests are processed for review and disposition through the Perform Integrated Change Control process
1 Accepted deliverables
Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor. Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project’s deliverables is forwarded to the Close Project or Phase process
2 Group decision-making techniques
A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements. There are various methods of reaching a group decision, such as: • unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity. • Majority. A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie. • Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two. • dictatorship. In this method, one individual makes the decision for the group.
1 Inspection
Inspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these different terms have unique and specific meanings.
5 Work performance data
Work performance data are the raw observations and measurements identified during activities being performed to carry out the project work. Data are often viewed as the lowest level of detail from which information is derived by other processes. Data is gathered through work execution and passed to the controlling processes of each process area for further analysis. Examples of work performance data include work completed, key performance indicators, technical performance measures, start and finish dates of schedule activities, number of change requests, number of defects, actual costs, and actual durations, etc.
4 Verified deliverables
A goal of the Control Quality process is to determine the correctness of deliverables. The results of performing the Control Quality process are verified deliverables. Verified deliverables are an input to Validate Scope (5.5.1.4) for formalized acceptance
3 Requirements traceability matrix
2 Requirements documentation
Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.
1 Project management plan
Project management processes selected by the project management team, ○ Level of implementation for each selected process, ○ Descriptions of the tools and techniques to be used for accomplishing those processes, and ○ Description of how the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes and the essential inputs and outputs
2 Project documents updates
1 Scope baseline
The scope baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include: • Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints. WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities. • WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Information in the WBS dictionary may include, but is not limited to: ○ Code of account identifier, ○ Description of work, ○ Assumptions and constraints, ○ Responsible organization, ○ Schedule milestones, ○ Associated schedule activities, ○ Resources required, ○ Cost estimates, ○ Quality requirements, ○ Acceptance criteria, ○ Technical references, and ○ Agreement information.
2 Expert judgment
Expert judgment is applied to all technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training and is available from many sources, including: • Other units within the organization, • Consultants, • Stakeholders, including customers or sponsors, • Professional and technical associations, • Industry groups, • Subject matter experts (SME), and • Project management office (PMO).
1 Decomposition
Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project. Decomposition of the total project work into work packages generally involves the following activities: • Identifying and analyzing the deliverables and related work; • Structuring and organizing the WBS; • Decomposing the upper WBS levels into lower-level detailed components; • Developing and assigning identification codes to the WBS components; and • Verifying that the degree of decomposition of the deliverables is appropriate.
5 Organizational process assets
4 Enterprise environmental factors
3 Requirements documentation
2 Project scope statement
2 Project documents updates
1 Project scope statement
The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project’s deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries. The detailed project scope statement, either directly, or by reference to other documents, includes the following: • Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation. • Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted. • deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail. • Project exclusion. Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations. • constraints. A limiting factor that affects the execution of a project or process. Constraints identified with the project scope statement list and describe the specific internal or external restrictions or limitations associated with the project scope that affect the execution of the project, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under an agreement, contractual provisions will generally be constraints. Information on constraints may be listed in the project scope statement or in a separate log. • Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes the potential impact of those factors if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the project scope statement or in a separate log
4 Facilitated workshops
Facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.
3 Alternatives generation
Alternatives generation is a technique used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management techniques can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.
2 Product analysis
For projects that have a product as a deliverable, as opposed to a service or result, product analysis can be an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.
1 Expert judgment
4 Organizational process assets
Project closure guidelines or requirements (e.g., lessons learned, final project audits, project evaluations, product validations, and acceptance criteria).
○ Change control procedures, including the steps by which performing organization standards, policies, plans, and procedures or any project documents will be modified, and how any changes will be approved and validated; ○ Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); ○ Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking; ○ Organizational communication requirements (e.g., specific communication technology available, authorized communication media, record retention policies, and security requirements); ○ Procedures for prioritizing, approving, and issuing work authorizations; ○ Risk control procedures, including risk categories, risk statement templates, probability and impact definitions, and probability and impact matrix; and ○ Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria.
○ Guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project; ○ Specific organizational standards such as policies (e.g., human resources policies, health and safety policies, ethics policies, and project management policies), product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization); and ○ Templates (e.g., risk register, work breakdown structure, project schedule network diagram, and contract templates).
3 Requirements documentation
2 Project charter
It documents the business needs, assumptions, constraints, the understanding of the customer’s needs and high-level requirements, and the new product, service, or result that it is intended to satisfy
the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities
2 Requirements traceability matrix
• Business needs, opportunities, goals, and objectives; • Project objectives; • Project scope/WBS deliverables; • Product design; • Product development; • Test strategy and test scenarios; and • High-level requirements to more detailed requirements.
The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.
1 Requirements documentation
Components of requirements documentation can include, but, are not limited to: • Business requirements, including: ○ Business and project objectives for traceability; ○ Business rules for the performing organization; and ○ Guiding principles of the organization. • Stakeholder requirements, including: ○ Impacts to other organizational areas; ○ Impacts to other entities inside or outside the performing organization; and ○ Stakeholder communication and reporting requirements. • Solution requirements, including: ○ Functional and nonfunctional requirements; ○ Technology and standard compliance requirements; ○ Support and training requirements; ○ Quality requirements; and ○ Reporting requirements, etc. (solution requirements can be documented textually, in models, or both). • Project requirements, such as: ○ Levels of service, performance, safety, compliance, etc.; and ○ Acceptance criteria. • Transition requirements. • Requirements assumptions, dependencies, and constraints.
Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.
11 Document analysis
Document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There are a wide range of documents that may be analyzed to help elicit relevant requirements. Examples of documents that may be analyzed include, but are not limited to: business plans, marketing literature, agreements, requests for proposal, current process flows, logical data models, business rules repositories, application software documentation, business process or interface documentation, use cases, other requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as laws, codes, or ordinances, etc.
10 Context diagrams
The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.
9 Benchmarking
Benchmarking involves comparing actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.
8 Prototypes
Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Since a prototype is tangible, it allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase. Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations.
7 Observations
Observations provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job.
6 Questionnaires and surveys
Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis is appropriate.
5 Group decision-making techniques
A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements. There are various methods of reaching a group decision, such as: • unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity. • Majority. A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie. • Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two. • dictatorship. In this method, one individual makes the decision for the group.
4 Group creativity techniques
Several group activities can be organized to identify project and product requirements. Some of the group creativity techniques that can be used are: • Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do. • nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. • Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas. • Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review and analysis. • Multi criteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.
3 Facilitated workshops
Facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.
2 Focus groups
Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview.
1 Interviews
An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees.
5 Stakeholder register
This contains all details related to the identified stakeholders including, but not limited to: • Identification information. Name, organizational position, location, role in the project, contact information; • Assessment information. Major requirements, main expectations, potential influence in the project, phase in the life cycle with the most interest; and • Stakeholder classification. Internal/external, supporter/neutral/resistor, etc. The stakeholder register should be consulted and updated on a regular basis, as stakeholders may change—or new ones identified—throughout the life cycle of the project.
4 Project charter
• Project purpose or justification, • Measurable project objectives and related success criteria, • High-level requirements, • Assumptions and constraints, • High-level project description and boundaries, • High-level risks, • Summary milestone schedule, • Summary budget, • Stakeholder list, • Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project), • Assigned project manager, responsibility, and authority level, and • Name and authority of the sponsor or other person(s) authorizing the project charter.
3 Stakeholder management plan
The stakeholder management plan often provides: • Desired and current engagement levels of key stakeholders; • Scope and impact of change to stakeholders; • Identified interrelationships and potential overlap between stakeholders; • Stakeholder communication requirements for the current project phase; • Information to be distributed to stakeholders, including language, format, content, and level of detail; • Reason for the distribution of that information and the expected impact to stakeholder engagement; • Time frame and frequency for the distribution of required information to stakeholders; and • Method for updating and refining the stakeholder management plan as the project progresses and develops.
The stakeholder management plan is a component of the project management plan and identifies the management strategies required to effectively engage stakeholders.
2 Requirements management plan
1 Scope management plan
2 Requirements management plan
Traceability structure to reflect which requirement attributes will be captured on the traceability matrix
Product metrics that will be used and the rationale for using them
Requirements prioritization process
Configuration management activities such as: how changes to the product will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes
How requirements activities will be planned, tracked, and reported
component of the project management plan that describes how requirements will be analyzed, documented, and managed
1 Scope management plan
Process to control how requests for changes to the detailed project scope statement will be processed
Process that specifies how formal acceptance of the completed project deliverables will be obtained
Process that establishes how the WBS will be maintained and approved
Process that enables the creation of the WBS from the detailed project scope statement
Process that documents how project scope will be defined, validated and controlled
It is the component of project or program management plan
It is major input to develop project mgmt plan and other scope mgmt processes
Process for preparing a detailed project scope statement
2 Meetings
Meetings are used to discuss and address pertinent topics of the project when directing and managing project work. Attendees at the meetings may include the project manager, the project team and appropriate stakeholders involved or affected by the topics addressed. Each attendee should have a defined role to ensure appropriate participation. Meetings tend to be one of three types: • Information exchange; • Brainstorming, option evaluation, or design; or • Decision making. Meeting types should not be mixed as a best practice. Meetings should be prepared with a well-defined agenda, purpose, objective, and time frame and should be appropriately documented with meeting minutes and action items. Meeting minutes should be stored as defined in the project management plan.
1 Expert Judgement
4 Organizational Process Assets
3 Enterprise Environmental Factors
2 Project Charter
• Project purpose or justification, • Measurable project objectives and related success criteria, • High-level requirements, • Assumptions and constraints, • High-level project description and boundaries, • High-level risks, • Summary milestone schedule, • Summary budget, • Stakeholder list, • Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project), • Assigned project manager, responsibility, and authority level, and • Name and authority of the sponsor or other person(s) authorizing the project charter.
It documents the business needs, assumptions, constraints, the understanding of the customer’s needs and high-level requirements, and the new product, service, or result that it is intended to satisfy
the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities
1 Project Management Plan
Key management reviews for content, the extent of, and timing to address, open issues and pending decisions
Requirements and techniques for communication among stakeholders
Description of how the integrity of the project baselines will be maintained
Configuration management plan that documents how configuration management will be performed
Change management plan that documents how changes will be monitored and controlled
Description of how work will be executed to accomplish the project objectives
Project management processes selected by the project management team, ○ Level of implementation for each selected process, ○ Descriptions of the tools and techniques to be used for accomplishing those processes, and ○ Description of how the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes and the essential inputs and outputs
Life cycle selected for the project and the processes that will be applied to each phase
Subsidiary Plans
Project Baselines
the process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan
Project Charter
Facilitation Techniques
Expert Judgement
Expert judgment is applied to all technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training and is available from many sources, including: • Other units within the organization, • Consultants, • Stakeholders, including customers or sponsors, • Professional and technical associations, • Industry groups, • Subject matter experts (SME), and • Project management office (PMO).
Organizational Process Assets
Closing
Project closure guidelines or requirements (e.g., lessons learned, final project audits, project evaluations, product validations, and acceptance criteria).
Exec, Monitoring & Control
○ Change control procedures, including the steps by which performing organization standards, policies, plans, and procedures or any project documents will be modified, and how any changes will be approved and validated; ○ Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); ○ Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking; ○ Organizational communication requirements (e.g., specific communication technology available, authorized communication media, record retention policies, and security requirements); ○ Procedures for prioritizing, approving, and issuing work authorizations; ○ Risk control procedures, including risk categories, risk statement templates, probability and impact definitions, and probability and impact matrix; and ○ Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria.
Initiating & Planning
○ Guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project; ○ Specific organizational standards such as policies (e.g., human resources policies, health and safety policies, ethics policies, and project management policies), product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization); and ○ Templates (e.g., risk register, work breakdown structure, project schedule network diagram, and contract templates).
Enterprise Environmental Factors
• Organizational culture, structure, and governance; • Geographic distribution of facilities and resources; • Government or industry standards (e.g., regulatory agency regulations, codes of conduct, product standards, quality standards, and workmanship standards); • Infrastructure (e.g., existing facilities and capital equipment); • Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing); • Personnel administration (e.g., staffing and retention guidelines, employee performance reviews and training records, reward and overtime policy, and time tracking); • Company work authorization systems; • Marketplace conditions; • Stakeholder risk tolerances; • Political climate; • Organization’s established communications channels; • Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases); and • Project management information system (e.g., an automated tool, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems)
Agreements
Business Case
Project Statement of Work
