oe.ucdavis.eduoe.ucdavis.edu/resources/project management glossary.docx · web viewproject...

A catalyst for positive change

Project Management Glossary

Project management is the process and activity of planning, organizing, motivating and controlling resources, procedures and protocols to achieve specific goals. Project management is the application of knowledge, skills and techniques to execute project effectively and efficiently. It’s a strategic competency for organizations, enabling them tie project result to business goals, and thus, better complete in their markets. Acceptance: The formal process of accepting delivery of a product or intermediate

project deliverable after having assured that it meets the stated requirements.

Accrual Accounting: A system of accounting in which expenses are recognized when incurred, and revenues are recognized when they are known, regardless of the time when actual payment of cash is made or received.

One Shields Avenue Davis, CA 95616 oe.ucdavis.edu


Action Item: A documented event, task, activity, or action that needs to take place. They are discrete units that, often times, can be handled by a single person.

Action Plan: A description of what needs to be done, when and by whom.

Activity Duration: The best estimate of the time necessary for the accomplishment of the work involved in an activity, considering the nature of the work and resources needed for it.

Activity Status: The state of completion of an activity. A planned activity has not yet started. A started activity is in progress. A finished activity is complete.

Activity: An element of work performed during the course of a project. An activity normally has an expected duration, an expected cost, and expected resource requirements. Activities are often subdivided into tasks.

Actual Dates: The dates that activities really started and finished as opposed to planned



or projected dates.

Actual Finish Date: The date on which an activity was completed.

Actual Start Date ("AS"):. The date work actually started on an activity.

Actual: Information that shows what has actually occurred. For example, the actual start date for a task is the day on which the task actually started, and its actual cost is the amount spent up to the present.

Agenda: A list of things to be done or discussed, typically at a meeting.

Analysis The study and examination of something complex and separated into its more simple components. Analysis typically includes discovering not only what the parts of the thing being studied are, but also how they fit together and why they are arranged in this particular way. A study of schedule variances for cause, impact, and corrective action.



Application (Software): Programs that help the end-user to perform specific, productive tasks or business functions, such as booking a loan or processing a payment.

Approval to Proceed: Approval by an authorizing committee or person at a project's initiation or prior to the beginning of the next stage.

Approve: To accept as satisfactory. Approval implies that the thing approved has the endorsement of the approving agency. Approval may be by several persons.

Approved Changes: Changes that have been approved by higher authority.

Architecture: The design and interconnection of the main components of a system.

Archive: A repository for infrequently used or historic records.

Artifact: Document(s) produced through the project process (project management



deliverables).

As-of Date: The date that a piece of information, such as a status report, is reporting up to.

Attribute: A characteristic or property of a requirement.

Automated Testing: The process of using a specialized tool to generate test case steps, execute the steps and automatically verify the results of the test. Often used for regression testing.

Automation Engineer: An expert in a test automation tool (e.g. HP QuickTest Professional or IBM Rational Functional Tester).

Automation Testing Assessment:

A review process performed during the Technical System Design (TSD) phase of a project to identify processes that may be tested using Automation techniques.



Availability: Capable of being used. Usually refers to resources and/or funding.

Baseline Cost: The amount of money an Activity was intended to cost when the Baseline Plan was established.

Baseline Management: The planning, organizing and control of baseline documentation.

Baseline Schedule: A fixed project schedule that is the standard by which project performance is measured. The current schedule is frozen after formal approval until it is formally modified through the change control process as the result of a significant change. When formally changed, the current baseline becomes invalid and should not be compared with the new schedule.

Benchmarking: A review of what others are doing in the same area. For those who appear to be particularly successful, what they do and how they do it are taken to be examples that should be emulated, i.e. used as 'benchmarks'.



Best Practices: Practical techniques, processes, and methods gained from experience that has been shown to produce best results.

Bid: An offer to perform the work described in a set of proposal documents at a specified cost.

Black Box Testing: Testing a system without knowledge of a program's internal workings. Testers feed input and observe output.

Boundary Value: An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range.

Boundary Value Analysis: A black box test design technique in which test cases are designed based on boundary values.

Boundary Value Coverage:

The percentage of boundary values that have been exercised by a test suite.



Brainstorming: A technique to develop alternative solutions through an unrestrained exchange of ideas.

Break-Even Point: The productivity point at which value earned equals total cost.

Budget: When unqualified, usually refers to an estimate of funds planned to cover a fiscal period. Also a planned allocation of resources.

Build: Put parts together to form a unified whole.

Business Analyst (BA): A BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service provider and is responsible for gathering and writing the business requirements for a project.

Business Case: A document that ranges from a well-structured written document to an informal and brief composition that captures the reasoning for initiating a



project. Often included in this document are the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks.

Business Component (or Component):

An easily-maintained, reusable unit comprising one or more steps that perform a specific task. A business component can be defined as a manual or automated component. Business components may require input values from an external source or from other components, and they can return output values to other components.

Business Owner: The leader or authoritative representative from a group which has both the Business knowledge (process, clients, impact, calendar), and the Business Authority to make wide sweeping/large scope/impacting decisions on the direction and requirements of a service. If need arises, this authoritative person (or delegate) can make these decisions without polling or otherwise querying the user community.



Capital Asset: Tangible property, including durable goods, equipment, buildings, installations, and land.

Capital Cost: The total expenditure for acquiring an asset. The sum of all moneys spent on a project and transferred to the capital account of an organization, usually upon completion.

Cash Flow Analysis: The activity of establishing cash flow (dollars in and out of the project) by month and the accumulated total cash flow for the project for the measurement of actual versus the budget costs. This is necessary to allow for funding of the project at the lowest carrying charges and is a method of measuring project progress.

Champion: A person who takes on the responsibility for making the project visible to higher management, garnering support and funding for it, and ensuring that the project has a high priority.

Change Control: The process of implementing procedures which ensure that proposed changes are properly assessed and, if approved, prioritized, incorporated into the project plan, and managed as part of the project. Change control



is the most common way to manage scope on projects, and uncontrolled changes are one of the most common causes of problems on projects.

Change in Scope: A change in objectives, work plan, or schedule that results in a material difference from the terms of an approval to proceed previously granted by higher authority. Under certain conditions (normally so stated in the approval instrument), change in resources application may constitute a change in scope.

Change Management: Change management encompasses the requesting, determining attainability, planning, implementing and evaluation of modifications to a process or system. It has two main goals: supporting the processing of changes and enabling traceability of changes.

Change Management Plan:

A defined process for making changes to a project plan.



Change Request: A formal, written request for a change in some aspect of the project that has been baselined, such as scope, requirements, schedule, budget, or documents. Change requests should be logged, assessed and approved by the Change Control Board before the change can be made.

Charter: A document prepared in the planning phase of the project by the primary project participants that includes a mission statement, high level objectives, constraints and assumptions, and any cost or schedule goals that are known. The charter is created during a chartering meeting where the project leads and the project sponsor agree on what will be accomplished by the project.

Close-out: The completion of all work on a project. Can also refer to completion of a phase of the project.

Code and Unit Test: The activities of writing software and performing the initial test.

Communications Plan: A statement of project stakeholders' communication and information



needs and how they will be satisfied during the project.

Community of Practice (COP):

A project management model where a unified team of project management practitioners share best practices, engage in joint activities, and discuss other project related information to support one another on Bank of the West projects. Practitioners within COP build relationships that enable them to learn from each other and develop a shared repertoire of resources: tools, experiences and ways of addressing recurring problems—in short a shared practice.

Completion Date: The date calculated by which the project could finish following careful estimating, planning and risk analysis taking into account resource limitations and contingency.

Component: A self-contained, reusable building block that can be used independently or combined with other components to form a scripted Business Process Test in the form of a Test Case in Quality Center. A component handles a specific event, or related set of events, and provides a particular function



or group of related functions.

Concurrent Tasks: Tasks in a project that can be worked on at the same time.

Constraint: Applicable restriction which will affect the scope. Any factor which affects when an activity can be scheduled.

Context: The background, within which something is reviewed, determined, decided, or otherwise happens.

Contingency Reserve: A provision held by the project sponsor or the project manager for possible changes in project costs when contingency plans need to be invoked.

Contract Administration; Monitoring and control of performance, reviewing progress, making payments, recommending modifications and approving contractor's actions to ensure compliance with contractual terms during contract execution.



Contract Negotiation: Method of procurement where a contract results from a bid which may be changed through bargaining.

Contractor Short Listing: A process whereby a short list of contractors is assembled and designated for receipt of an invitation to bid. This process has the effect of avoiding dealing with proposals by contractors who do not qualify for some reason.

Contractor: A person or organization that undertakes responsibility for the performance of a contract.

Cost Center: The smallest unit of activity or area of responsibility against which costs are accumulated; defined sections in the corporate system, representing units of responsibility as well as accounting units.

Cost Incurred: Costs identified through the use of the accrued method of accounting or costs actually paid. Costs include direct labor, direct materials, and all



allowable indirect costs.

Cost Savings: An action that will result in a smaller than projected level of costs to achieve a specified objective.

Cost-Benefit Analysis: An analysis, often stated as a ratio, used to evaluate a proposed course of action, including approving a project.

Critical Issue: Issues that require heightened attention due to the potential impact to a project.

Critical Path: In a project network diagram, the path with the longest duration. The path may change from time to time as activities are completed ahead of or behind schedule. See critical path method.

Critical Success Factors ("CSF"):

Those measurable factors, listed in order of importance, that when present in the project's environment are most conducive to the achievement of a successful project. Examples include: Project objectives



aligned with corporate mission; Top management support; A culture of open communication, etc.

Current budget: The budget at the current point in time, specified at the last date where accurate budget information is available.

Decision Tree: A graphical representation of the decision process. Sequential decisions are drawn in the form of the branches of a tree, stemming from an initial decision point and extending all the way to the final outcomes. Each path through the branches of the tree represents a separate series of decisions and probabilistic events.

Defect (Bug): A fault in a system where the actual behavior deviates from the expected results. A defect should be repeatable and is only considered by the QA & Test Team when it is documented in Quality Center with supporting documentation, such as screen shots.

Defect Review Meeting: A meeting to discuss open issues or questions related to defects. Defects



are typically reviewed prior to the meeting and comments/issues discussed at the meeting.

Deliverable: Any measurable, tangible, verifiable item that must be produced to complete the project. Often used more narrowly in reference to an external deliverable, this is a deliverable that is subject to approval by the project sponsor or customer.

Dependencies: Relationships between products or tasks. For example, one product may be made up of several other 'dependent' products or a task may not begin until a 'dependent' task is complete. See also logical relationship.

Depreciation: A charge to current operations which distributes the cost of a tangible capital asset, less estimated residual value, over the estimated useful life of the asset in a systematic and logical manner. It does not involve a process of valuation.

Detailed Design: The conversion of design-to specifications into designs and associated build-to and code-to documentation. Includes behavior analysis,



requirements flow down, concept trades, risk management, concept testing, reducibility analysis, models, etc.

Detailed Schedule: A plan of activities for all work. The detailed schedule would typically cover activities up to at least the next major milestone. The detailed schedule supports and is consistent with the Master Schedule.

Discrete Task: A measurable activity with an output.

Document Management: The orderly and appropriate organization, distribution, storage and retrieval of project documents.

Elapsed Time: The total number of calendar days (excluding non-work days such as weekends or holidays) that is needed to complete an activity. It gives a "real world view" of how long an activity is scheduled to take for completion.

End-to-End Test: Evaluates a system's ability to take a business transaction from start to



finish through all of the major functionality of a system or group of systems.

Enterprise: At Bank of the West, this term means the entire bank.

Entry Criteria: Specific conditions or on-going activities that must be present prior to test commencement.

Equivalence Partition: A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.

Equivalence Partition Coverage:

The percentage of equivalence partitions that have been exercised by a test suite.

Equivalence Partitioning: A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.



Escalation: An anticipated rise in uncommitted costs of resources (labor, material, equipment) over time, due to reduced purchasing power of money. A component of a cost type. The allowance for escalation is a component within the anticipated award cost of a cost class.

Exception: A condition that changes the normal flow of execution.

Exception Handling: How a system responds to unexpected conditions or errors.

Execution:The processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan.



Exit Criteria: The specific conditions or on-going activities that must be present before a process can be considered complete.

External Constraint: A constraint from outside the project network.

Fallout: A defect that is created as a result of another defect being corrected – a side effect.

Field: A location in a sheet form or chart that contains a specific kind of information about a task or resource. In a spreadsheet, for example, a field is the intersection of a column and a row. In an input form a field is a named box or place to insert data.

Financial Close-out: Accounting analysis of how funds were spent on the project. Signifies a point in time when no further charges should be made "against'' the project.

Financial Management: Management of the financial activities of the organization, program,



project or major work package.

Forecast: An estimate and prediction of future conditions and events based on information and knowledge available at the time of the forecast.

Functional Requirements: The requirements which state what functions the final product must perform. In contract management, requirements stated in terms of the objectives that must be achieved under the contract.

Go/No-go: The opportunity to decide whether or not to proceed. Usually associated with a major program or project milestone and typically the responsibility of senior management.

Governance: The exercise of authority, management and control.

Impact Analysis: The mathematical examination of the nature of individual risks on the project, as well as potential structures of interdependent risks. It includes the quantification of their respective impact severity, probability and



sensitivity to changes in related project variables including the project life cycle. To be complete, the analysis should also include an examination of the external "status quo" prior to project implementation as well as the project's internal intrinsic worth as a reference baseline. A determination should also be made as to whether all risks identified are within the scope of the project's risk response planning process.

Implementation Phase: The third of four sequential phases in the project life cycle during which the actual work of the project is undertaken to produce the project's deliverables.

Implementation Plan: See Project Implementation Plan.

In Progress: An activity that has been started, but not yet completed.

Incremental: A small increase, implying one of several regular steps.

Infrastructure: The underlying foundation or basic framework (as of a system or



organization).

Initiation: The process of preparing for, assembling resources and getting work started. May apply to any level, e.g. program, project, phase, activity, task.

Integration Test: A process generally performed by the QA Team in which individual software modules are combined and tested as a group. Integration Testing follows Unit Testing and precedes System Testing.

Interface: An external connection between two software modules or Systems where information/data is exchanged.

Issue: Something in dispute or to be decided.

Issues Log: A listing of challenges within a project where resolution is sought to prevent complications that may compromise part, if not all, of the



project.

Iterations: The number of times that an individual business component, or group of components, runs within a single test run, or the number of times that an entire business process test runs within a test set.

Key Performance Indicators:

Measurable indicators that will be used to report progress that is chosen to reflect the critical success factors of the project.

Kick Off Meeting: Ideally, a workshop type meeting in which the principle stakeholders and participants in the project are briefed on the goals and objectives of the project, how it will be organized, etc. and are then able to contribute to its planning, assignment of responsibilities, target dates, etc.

Lessons Learned: The capture of what went well as well, as past errors of judgment resulting in material failures, wrong timing or other mistakes, all for the purposes of improving future performance.



Load Test: Evaluates a system's behavior and user experience under various levels of user load. This type of test is performed when the client does not have any idea about the performance of the system. It is a discovery type of test, where you establish a baseline when does not exist. It is also used when there is limited information known about the number of concurrent users, max users, and etc. Load Testing may be performed by the QA Team during the System Test phase.

Master Schedule: An executive summary-level schedule which identifies the major components of a project, and usually also identifies the major milestones.

Milestone: A significant event in the project, usually completion of a phase or of a major deliverable.

Mitigation: Taking steps to lessen risk by lowering the probability of a risk event's occurrence or reducing its effect should it occur.

Module: A self-contained software entity of a system which has a well-defined



interface to other software entities.

Monthly Status Review: The process of reviewing a project's technical, cost, schedule, material, and corrective action status against the implementation plan in a monthly review for the purpose of identifying situations needing corrective action.

Negative Test: A reasonable attempt to "break" an application or system. For example, a tester may enter a letter in a phone number, or less than 9 digits in a Social Security Number.

Out of Scope: Requirements not included in the current contract and beyond the limits of the change clause.

Peer Review: Meetings to verify documents are correct and complete. Documents are typically reviewed prior to the meeting and comments/issues discussed at the meeting.

Performance A description of how well a delivered system must be able to perform its



Requirement: functions. Sometimes called a 'non-functional requirements'.

Performance Test: Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements. Performance Testing can only be performed when the application has been benchmarked by load testing, or if the team has service level metrics for the different components.Performance Testing may be performed by the QA Team during the System Test phase.

Phase Gate: A project management technique in which an initiative or project (e.g. product development, process improvement, business change, etc.) is divided into stages (or phases) separated by gates. At each gate, the continuation of the initiative is decided by (typically) a manager or a steering committee. The decision is based on the information available at the time, including business case, risk analysis, availability of necessary resources (money, people with correct competencies, etc.).



Phase: A defined segment of work. A major period in the life of a project.

Planning: The planning of time, cost and resources to adequately estimate the work needed and to effectively manage risk during project execution.

PMBOK: An acronym meaning Project Management Body of Knowledge. The term PMBOK™ is used by the Project Management Institute to refer to their Guide to the Project Management Body of Knowledge publication.

Portfolio Management: The management of a number of projects that do not share a common objective. For example, the responsibility of an operations manager of a company managing several different projects for different clients.

Pre-Condition and Post-Condition:

The state of the application before the first step in a business component, and the state of the application after the last step in a business component. For example, the pre-condition for a component may state that all applications should be closed, or a specific application should be open to a specific screen or with a specific dialog box displayed. A post-



condition may state that an application should be open to a particular screen, or be closed.

Probability: The likelihood of a risk occurring. The ratio of the number of chances by which an event may happen (or not happen) to the sum of the chances of both happening and not happening.

Problem Statement: A definition of the problem to be solved by completing the project.

Program Management Office ("PMO"):

The office responsible for the management of a program. More recently, the corporate office responsible for managing all projects in a corporation, a company, or a business unit. The PMO sets standards for project management and ensures a consistent methodology across all projects. See also Project Management Office. A Project Management Office is more likely to be dedicated to a single large project. A Program Management Office generally spans management of multiple projects. Although extremely large projects that go on for years, such as satellite



development, are often called programs also.

Program Management: The management of a related series of projects executed over a broad period of time, and which are designed to accomplish broad goals, to which the individual projects contribute.

Project Calendar: The base calendar used by a project.

Project Champion: A senior manager at a level higher than the project manager, and who gains support and resources for the project.

Project Charter: PMI defines the project charter as a document issued by senior management that provides the project manager with the authority to apply organizational resources to project activities. Many organizations develop the charter by having the major stakeholders in the project, including those stakeholders who control project resources, agree on a mission statement for the project, some high-level objectives, a cost and



schedule target, and what the constraints and assumptions used for planning are. By signing the charter the stakeholders agree that they understand and will support the project.

Project Closure: The formal end of a project. It requires the project board's approval.

Project Cost Management:

A subset of project management that includes resource planning, cost estimating, cost control and cost budgeting in an effort to complete the project within its approved budget.

Project Cost: The actual costs of the entire project.

Project Governance: The management framework within which project decisions are made. Project governance is a critical element of any project since while the accountabilities and responsibilities associated with an organization's business as usual activities are laid down in their organizational governance arrangements.



Project Implementation Plan:

A formal document that describes how the project will be implemented. It describes the complete course of action contemplated, including assumptions, organization, stakeholder communication, milestone schedule, quality and safety provisions, critical success indicators, etc.

Project Life Cycle: A collection of project phases whose name and quantity are determined by the control needs of the organization or organizations involved in the project. The complete set of time periods through which a project passes sequentially in a logical and orderly manner. In its simplest form the life cycle consists of four major periods:

1. Initiation (where the idea is submitted, approved, prioritized and resources are committed)

2. Planning (where the project is defined)3. Execution (where the work product is designed, built, tested and

implemented)4. Close-out (where the project process is completed and



documented)

Project Management Plan:

A document developed by the Project Manager which describes how the project will be planned, monitored, and implemented. The Project Management Plan establishes project management's interpretation of the why, what, how, who, how much, and when of the project.

Project Management Team:

The members of the project team who are directly involved in project management activities. On some smaller projects, the project management team may include virtually all of the project team members.

Project Management: The application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations.

Project Risk Management: A subset of project management that includes risk identification, risk quantification, risk response development and risk response control in an effort to identify, analyze and respond to project risks.



Project Risk: The cumulative effect of the chances of uncertain occurrences which will adversely affect project objectives. It is the degree of exposure to negative events and their probable consequences. Project risk is characterized by three factors: risk event, risk probability and the amount at stake.

Project Schedule: Planned dates for starting and completing activities and milestones.

Project Schedule: Timelines for the project in one or more of the following forms: milestone, deliverables, activity, Gantt.

Project Scope Management:

A subset of project management that includes initiation, scope planning, scope definition, scope verification and scope change control in an effort to ensure that the project has all of the necessary work required to complete it.



Project Scope: A concise and accurate description of what is included in the project and will be managed.

Project Sponsor: A person or group concerned with the definition of project objectives in the context of the sponsoring organization. The person or group acting as Management's representative on behalf of the Company as Owner or Agent of the facility, product or new service resulting from the Project.

Project Stakeholder: A person, group or authority who is involved in or may be affected by project activities (i.e. has a 'stake' in the Project) and who could act against the project if their needs are not considered.

Project Start Date/Schedule:

The earliest calendar start date among all activities in the network.

Project Status Report: A report on the status of accomplishments and any variances to spending and schedule plans. Color schemes defining the status of a project are as follows:



Blue - Too new to evaluate or not evaluated Green - Satisfactory Yellow - Awareness Red – Alert

Project Status: The timely comprehensive measurement of project progress against the plan to identify variances and the seriousness of the variances if not controlled by corrective action.

Project Team Members: The people who report either directly or indirectly to the project manager.

Project Team: The core group on the project. The assembly of people, considered as a group that shares responsibility for the accomplishment of project goals and who report either part-time or full-time to the project manager.

Project: A temporary endeavor undertaken to create a unique product or service. Any undertaking with a defined starting point and defined objectives by



which completion is identified. In practice most projects depend on finite or limited resources by which the objectives are to be accomplished.

QA Analyst:A member of the QA & Test Team that creates the test requirements, validates defects and fixes to the software.

QA Lead: A member of the QA & Test Team that develops the test strategy, establishes the test schedule, creates the test plan, configures the Quality Center environment, assists in establishing the test requirements, makes testing assignments, audits testing, and manages defects.

Quality Assurance (QA): A plan which ensures that requirements are clearly established and the defined process complies with those requirements. QA provides the evidence needed to establish confidence among all concerned, that the quality-related activities are being performed effectively.



Quality Center: A software application developed by HP(Developed by Mercury and later sold to HP) that provides a web-based system for automated software quality testing and management across a wide range of application environments. It is a tool that provides a place where testing requirements may be tracked and mapped to test cases. It also tracks test case execution, test results, and defects.

Quality Control (QC): A measurement of a system's functionality against defined requirements. QC ensures whether a system meets predefined standards and that requisite action is taken if the standards are not met.

Quality Gate: Located at the end of a project phase, a quality gate verifies the activities and deliverables of that phase. The QA & Test Team uses questionnaires to verify that conditions of a quality gate are met before proceeding on to the next phase. Any conditions that are not met are reported on to the project team for response.

Re-Baseline: Re-baselining is required in response to changed contract requirements,



funding changes, or realization that the operative implementation plan is not achievable.

Regression Test: A process which verifies a system's functionality after all defects have been corrected to ensure that no other defects have been introduced. (see Fallout) Regression Testing is performed by the QA Team at the end of the System Test phase.

Requirement: A clear statement of a need, written in such a way that there is no question about what is being asked. For clarification purposes, a modifier should always precede requirements such as user requirements, system requirements, operational requirements, contract requirements, test requirements, etc.

Resource Management: The planning, allocating and scheduling of resources to tasks, generally including manpower, equipment, money, and materials. Resource Management typically covers resource allocation and its impact on schedules and budgets, as well as resource leveling and smoothing.



Responsibility Charting ("RACI"):

The activity of clearly identifying personnel and staff responsibilities for each task within the project.R - ResponsibleA - AccountableC - ConsultedI – Informed

Return on Investment ("ROI"):

The financial return for a given outlay, usually calculated in terms of present value (i.e. today's value of money.)

Risk Assessment: Review, examination and judgment whether or not the identified risks are acceptable in the proposed actions.

Risk Identification: The process of systematically identifying all possible risk events which



may impact on a project.

Risk Management Plan: Part of the project management documents that contains a record of all the risks to the project and how those risks will be managed.

Risk Mitigation: Steps taken or to be taken to avoid or reduce the impact of risk events.

Risk Probability: The degree to which the risk event is likely to occur.

Risk Register: A file that holds all information on identifying and managing a risk.

Risk: A future event which has a probability of happening and will adversely affect the project.Risk is characterized by two factors: the probability that an event will occur, and the impact if it happens.The difference between a risk and an issue is: an issue is a problem you have right now, while a risk is something that might happen in the future.The PMBOK defines risk as "An uncertain event that, if happens, will have a positive or a negative impact on at least one project objective." The reality of daily life as a



project manager is that we rarely have time to worry about identifying positive impacts. We concentrate on identifying those things that can harm the project.

Schedule Variance: Any difference between the projected duration for an activity and the actual duration of the activity. Also the difference between projected start and finish dates and actual or revised start and finish dates. In Earned Value, the difference between the budgeted cost of work performed and the budgeted cost of work scheduled at any point in time (BCWP - BCWS).

Schedule: A display of project time allocation in which events such as tasks, activities, or milestones are plotted against a calendar.

Scope: The work content and products of a project or component of a project. Scope is fully described by naming all activities performed, the resources



consumed and the end products which result, including quality standards. A statement of scope should be introduced by a brief background to the project, or component, and the general objective(s).

Severity (Defect): The absolute impact of a defect on the system under test (Critical, High, Low).

Sign-Off: The formal acceptance of a planned or proposed course of action, constituting authority for the planner or proposer to proceed with the action.

Sizing Matrix: A grid assessment that includes defining parameters for determining the magnitude of a project. Theses parameters include:

1. # FTE2. Duration3. Cost4. Financial Impact5. Schedule flexibility6. Complexity7. Strategic Importance



8. Dependencies9. Business Impact10. System Impact

Status Report: A written report given to both the project team and to a responsible person on a regular basis stating the position of an activity, work package, or whole project. Status Reports should be used to control the project and to keep management informed of project status.

Steering Committee: Formal group representing the owner or client.

Steps: Individual operations in a component. These can be manual steps or detailed automated testing steps and are designed and implemented in a business component to test the workings of a specific task in an application.

Story Boards: A series of graphic images showing a flow through a process, typically a series of screen shots of an application showing where data is input and the expected response.



Stress Test: Evaluates a system or component at or beyond the limits of its specified requirements. Stress Testing is performed to determine the limit of the systems' capabilities. Tests are run until the point of unacceptable performance. Stress Testing may be performed by the QA Team during the System Test phase.

Subject Matter Expert: An expert in the domain, who contributes to requirements, reviews project solution in the context of their area of expertise, uses Quality Center (or other tools) to create business components and business process tests, updates policies and procedures, and may deliver end user training.

Suspension/Resumption Criteria:

A set of decision-making guidelines used to determine whether a particular phase of testing should be halted and/or resumed.

System Requirements Document:

The document that states what the system must do to satisfy all or a part of the user's requirements. System requirements must be traceable to



user requirements. This document is the basis for developing the System Concept and the associated System Specification.

System Test: A process generally performed by the QA Team on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of Black box testing, and as such, should require no knowledge of the inner design of the code or logic. System Testing follows Unit Testing and/or Integration Testing and precedes User Acceptance Testing (UAT).

System Test Plan: A document that describes the approach to all system development, integration, qualification, and acceptance testing.

Test Acceptance Criteria: A list of pre-defined criteria which, when met, provide for acceptance of the deliverable by the business.

Test Measure: The quantity or capacity of testing attributes which are collected during testing tasks or activities.



Example: Number of Defects, Number of Test Cases, etc.

Test Metrics: A combination derived from measurements which provide valuable data to a wide audience indicating such things as:

• Testing progress (in the form of Test Cases passed/failed/not run)

• Application readiness (in the form of Open vs. Closed Defects)

• Application quality (in the form of Open Defects by Priority/Severity)

Test Bed: An environment containing the hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test

Test Data: A set of data identified as necessary to execute specific Test Cases.



Testability: The degree to which:

• A requirement or design document can be analyzed by a tester in order to determine test criteria and translate those criteria into executable Test Cases.

• An application (or component of) lends itself to having manual or automated Test Cases executed against it.

Test Stub: A dummy software component or object used to simulate the behavior of a real component which may not be available during execution of a test. Test stubs are used in testing interfaces.

Testing Sign-off: Documented approval of testing deliverables by project stakeholders.



Test Environment: The overall facility needed to execute the tests, including test libraries and data files, procedures, tools, hardware, support software, etc.

Test Case: The documented execution of the testing of a specific part of a system. It contains pre-conditions, assumptions, special instructions, input, action steps, and expected results. Test cases drive System Testing. Test cases are entered and maintained in Quality Center.

Test Cycle: The execution of all test cases verifying modified functionality to a system, plus and end-to-end test to verify existing (unmodified) functionality has not changed.

Test Execution Schedule: A detailed plan which includes detailed tasks, resources, environments, and dates for a testing effort.

Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be



tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

Test Scenario: A group of test cases or business processes combined in such a way so their execution follows a workflow path through the system (like a use case) or concentrates on testing a specific area of the system. Test scenarios drive User Acceptance Testing.

Test Script: A manual or automated sequence of actions performed that create and execute a test case or test scenario.

Test Set: A group of test cases organized sequentially to execute a group of related test cases or executes a test scenario.

Toll Gate: A project management technique in which an initiative or project (e.g. product development, process improvement, business change, etc.) is divided into stages (or phases) separated by gates. At each gate, the continuation of the initiative is decided by (typically) a manager or a



steering committee. The decision is based on the information available at the time, including business case, risk analysis, availability of necessary resources (money, people with correct competencies, etc.).

Test Script: A set of instructions that will be performed on the system under test to test that the system functions as expected.

Test Scenario: A software testing activity that uses scenario tests, or simply scenarios, which are based on a hypothetical story to help a person think through a complex problem or system for a testing environment. The ideal scenario has five key characteristics: it is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e) easy to evaluate [1]. These tests are usually different from test cases in that test cases are single steps whereas scenarios cover a number of steps. Test suites and scenarios can be used in concert for complete system testing.

Unit Test: A process performed by a developer to validate that a particular module of source code is working properly. Unit testing only tests the



functionality of the units themselves and will not catch every error in the program such as integration errors, performance problems or any other system-wide issues. Unit testing precedes Integration Testing.

Use Case: Identifies one or more scenarios that convey how a system should interact with users or other systems to achieve a specific business goal or function. Use cases may be co-authored by Business Analysts and End Users.

User Acceptance Test (UAT):

A process performed by a Subject Matter Expert (SME), preferably the owner or client of the object under test, to obtain confirmation through trial or review, that the modification of or addition to a system meets the business's needs. UAT is one of the final stages of a project and occurs after System Testing and before a client or customer accepts a new system.

User Acceptance Test (UAT) Criteria:

Conditions that must be met in order for the Business to accept a new or modified system.



Validation: The process of evaluating the system after development is complete to ensure compliance with requirements. It involves actual testing and takes place after verifications are completed.

Variance: A discrepancy between the actual and planned performance on a project, either in terms of schedule or cost.

Vendor: A supplier of material or services offered from a catalog or price list and purchased with a purchase order.

Verification: The process of determining whether or not requirements and approved design are satisfied. It typically involves reviews and meetings to evaluate documents, plans and code. This can be done with checklists, issue lists, walkthroughs, and inspection meetings.

Work Breakdown Structure ("WBS"):

A task-oriented 'family tree' of an activity which organizes, defines and graphically displays the total work to be accomplished in order to achieve



the final objectives of a project. Each descending level represents an increasingly detailed definition of the project objective. It is a system for subdividing a project into manageable work packages, components or elements to provide a common framework for scope/cost/schedule communications, allocation of responsibility, monitoring and management.
